new lsub nix patch: nocontrib
Fco. J. Ballesteros
nobody has made any packages other than initial ports
of tools that might just be unpacked in-place, by anyone
wanting them. Nor there's any contrib package server.
time to let contrib go.
files:
removed:
/contrib
removed: /contrib
erik quanstrom
but where do the packages live? also, contrib has taken
on a secondary role of being a place for public file exchange.
what are we replacing that use with?
- erik
Nemo
fgb's contrib.
IIRC, it was made, a few packaged (e.g. hg) were created, and that's it.
Nobody made any package, nobody installed any package using the nix contrib tools.
Plus, the existing packaged things could be trivially installed on their own or
you could just use fgb's contrib.
The packages were installed at their place (/sys/src/..., or /sys/lib/..., or whatever).
erik quanstrom
> Whe I say contrib, I refer to the nix contrib package management, not to
> fgb's contrib.
> IIRC, it was made, a few packaged (e.g. hg) were created, and that's it.
> Nobody made any package, nobody installed any package using the nix contrib tools.
>
> Plus, the existing packaged things could be trivially installed on their own or
> you could just use fgb's contrib.
>
> The packages were installed at their place (/sys/src/..., or /sys/lib/..., or whatever).
isn't the file removed /contrib? this directory existed for a decade before
fgb's contrib programs.
- erik
Nemo
It would rm -rf /contrib if applied and no conflicts.
The only thing in there is "package" (a dir tree) with the nix package stuff.
I don't remember, but, doesn't fgb's contrib create anything it needs when you
install it? It's long ago I installed it at lsub...
Nemo
;; 9fs sources
post...
;; lc /n/sources/plan9
386 LICENSE NOTICE alpha cfg env lp mnt power64 sparc64 usr
68000 LICENSE.afpl acme amd64 cron fd mail n rc sys
68020 LICENSE.gpl adm arm dist lib mips power sparc tmp
no contrib there.
erik quanstrom
ls -l /n/sources/contrib.
- erik
Nemo
/contrib in your local system?
The std. distrib does not come with a /contrib dir.
If so, then it might just be better to remove by hand the /contrib directory in the
distribution and leave that dir alone otherwise.
erik quanstrom
> Yes, but, when you install fjb contrib packages, do you get them at
> /contrib in your local system?
no. it does not.
and you're correct, there's no need to have /contrib in nix,
so LGTM.
but there needs to be a place like contrib, no necessarly in the dist.
that's all.
- erik
John Floren
The reason /contrib is in nix is because I wrote a package management
tool which keeps things under /contrib.
john
ron minnich
which repo, lsub or codereview. I may not be the only one.
I think for now it would be good to finalize the fork and separate the
email traffic between the patch system and the hg repo.
This list (nix...@googlegroups.com) is tied to the hg repo, so it
seems sensible to make a new list not tied to the repo for the patch
users.
Nemo, can you set up a nix-dev for lsub and then the people who want
to follow that tree can do it, and we can keep this list for the hg
repo.
Thanks!
ron
Nemo
On Apr 15, 2012, at 6:51 PM, erik quanstrom wrote:
> and you're correct, there's no need to have /contrib in nix,
> so LGTM.
;; patch/Apply nocontrib
applying to /n/src/nix...
/dist/patch/nocontrib
merge...backup...copy...
# remove these files if you want. I will not remove them for you
# (patch/undo will not restore them)
rm -rf /n/src/nix/contrib
done
Nemo
I think nix-dev is for nix development, not for "nix development at google code".
Plus, the main tree is at lsub.
erik quanstrom
> What do others say?
> I think nix-dev is for nix development, not for "nix development at google code".
> Plus, the main tree is at lsub.
let's factor out nomenclature.
i personally don't mind either way with respect to rons problem.
so ron, it might be helpful to spell out what mechanism you'd like
to see, and then we'll name the nodes in the mechanism later.
does that sound fair?
- erik
Nemo
On Apr 15, 2012, at 7:18 PM, Nemo wrote:
> What do others say?
> I think nix-dev is for nix development, not for "nix development at google code".
> Plus, the main tree is at lsub.
I think I mean, there's no fork, yet, unless you want it to become a fork.
Just to further document this, this is an excerpt from a mail from
Ericvh:
--------------
No doubt overly simplistic, but here's the LOC changed since import
into googlecode (not counting the importing and fixes). Now not
counting all the work that went into it since it hit google code is
probably a pretty big omission, and since jmk will never use
mercurial, it unfairly counts him out. Still....
Trogdor:nix-os ericvh$ hg churn -r 48:245
nemo...@gmail.com 62081 *******************************************
0in...@gmail.com 43092 ******************************
quan...@quanstro.net 13874 **********
rmin...@gmail.com 11711 ********
noah....@gmail.com 5949 ****
jo...@jfloren.net 5561 ****
pau...@gmail.com 1418 *
quan...@gmail.com 553
al...@pbrane.org 238
se...@mail.nanosouffle.net 195
ba...@bitblocks.com 27
enrique...@gmail.com 12
--------------
Nemo
ron minnich
> What do others say?
> I think nix-dev is for nix development, not for "nix development at google code".
> Plus, the main tree is at lsub.
the problem is that nix...@googlegroups.com is tied to the nix repo
at google code, by design. For a first example, there is no LGTM for
removing /contrib from the hg repo, and there is not likely to be.
That means that from this day forward, the two repos are going to
diverge.
It would be easier for me at least if I can separate the two repos in
my mind, and that is most easy for me if the mailing lists are
separate.
ron
ron minnich
> I think I mean, there's no fork, yet, unless you want it to become a fork.
My wishes are not really going to change the reality that the repos
are forked. As of today, /contrib is gone from the lsub
repo, and not from the hg repo. That is a fork any way you look at it.
Please do not think I am commenting either way on the existence of the
fork or the issues involved.
My only concern is that as the repos continue to diverge, the
discussion is going to get more confusing at least for me, and I think
the simplest thing to do is create nix...@lsub.org, to which some
subset of us will subscribe.
ron
Steve Simon
> are forked. As of today, /contrib is gone from the lsub
> repo, and not from the hg repo. That is a fork any way you look at it.
I feel its a shame that Ron does not want to, or is unable to move
across to nemo's patch tools. I have never really liked hg, though that
is a wider dislike of VCSs, and nemos tools look a great improvment to me.
> the simplest thing to do is create nix...@lsub.org, to which some
> subset of us will subscribe.
If we must fork, Please, don't call the new list nix-dev also, it would
be too confusing. we could allways fall back on old habits and call it
nixfans.
-Steve
Nemo
The google code repo came from the lsub main tree, (which came mostly from what jmk did,
plus a few ideas and code we added),
and now, the lsub main tree was updated to the state of google code repo before patch
was adopted. So, there's no fork. Yet.
As of now, it's linear, unless you keep on using the hg tree so it becomes a fork.
Damn, I'd like to see more mails with code and less of this kind.
Thanks for the help.
Until others in the list decide what to do, to simplify things for people, I'll keep
the settings as they are. If there's consensus in the list to move to another one, no problem.
In the mean while, you could use a filter to remove
mails with "lsub nix patch" in the subject if they bother you.
hth
Noah Evans
independent work nix is a combination of three sets of code.
1. Nix was initially based on a copy of sources, which was indexed to
hg and uploaded to google code.
2. We added the nix kernel from bitbucket (originally hosted on lsub)
3. Sources doesn't have a full set of 64 bit changes, so the necessary
bits were taken from lsub incrementally until the whole thing
compiled.
This was intentional, in order to ensure the provenance of the code.
Noah
Nemo
I was assuming it was clear for everyone that it all came from
plan 9, so didn't start at that point.
erik quanstrom
wakeup: / wakeup processes waiting for an event by linking them to the
/ queue
mov r1,-(sp) / put char on stack
mov (r0)+,r2 / r2 points to a queue
mov (r0)+,r3 / r3 = wait channel number
movb wlist(r3),r1 / r1 contains process number in that wait
/ channel that was sleeping
beq 2f / if 0 return, nothing to wakeup
cmp r2,u.pri / is runq >= users priority
bhis 1f / yes, don't set time quantum to zero
clrb uquant / time quantum = 0
1:
clrb wlist(r3) / zero wait channel entry
jsr r0,putlu / create a link from the last user on the Q
/ to this process number that got woken
2:
mov (sp)+,r1 / restore r1
rts r0
☺
- erik
Francisco J Ballesteros
--
using ipad keyboard. excuse any typos.
erik quanstrom
> nice. wheres that from?
reconstituted v1 unix. i have to explain how
not to use sleep/wakeup (evidently i have the
most experience). so i thought i'd
start with the question, what do sleep/wakeup
do. i thought that would be easiest to explain
from the beginning. i'm a literalist.
- erik
ron minnich
> I feel its a shame that Ron does not want to, or is unable to move
> across to nemo's patch tools. I have never really liked hg, though that
> is a wider dislike of VCSs, and nemos tools look a great improvment to me.
you're reading a lot into my comment. I stated that
1- the tree is forked -- this is reality.
2- there are people who will not stop using the hg tree
3- it makes no sense, given that we are talking about two trees, to
try to manage the discussions on one mailing list. It's confusing.
When we did this with linuxbios, we actually made a -v3 list for a
year or two to avoid the problem.
Things are going to start to diverge, starting tomorrow, so we might
as well get used to it.
Where from all this did you get "Ron does not want to ...."
ron
erik quanstrom
> > across to nemo's patch tools. I have never really liked hg, though that
> > is a wider dislike of VCSs, and nemos tools look a great improvment to me.
>
>
> 1- the tree is forked -- this is reality.
>
> 2- there are people who will not stop using the hg tree
>
> 3- it makes no sense, given that we are talking about two trees, to
> try to manage the discussions on one mailing list. It's confusing.
> When we did this with linuxbios, we actually made a -v3 list for a
> year or two to avoid the problem.
>
> Things are going to start to diverge, starting tomorrow, so we might
> as well get used to it.
>
> Where from all this did you get "Ron does not want to ...."
oh, i think i can understand how things got wired up that way.
you've stated "there are people who will not stop using the hg tree".
i think the assumption that's easy to make here is that you might
be one of those people.
i guess my question is, who is going to continue to use (as in,
submit to) hg?
- erik
erik quanstrom
> you've stated "there are people who will not stop using the hg tree".
> i think the assumption that's easy to make here is that you might
> be one of those people.
>
> i guess my question is, who is going to continue to use (as in,
> submit to) hg?
i sort of hit <esc> too soon. i hope this didn't sound combative.
that wasn't my intent. i'm just trying to figure out what's going where.
- erik
John Floren
I will, for what it's worth (Nix is very much a part time thing here)
erik quanstrom
> I will, for what it's worth (Nix is very much a part time thing here)
can you explain how these facts are related?
- erik
John Floren
I mean that I won't be sending in much, most likely
erik quanstrom
> I mean that I won't be sending in much, most likely
> On Apr 15, 2012 7:10 PM, "erik quanstrom" <quan...@quanstro.net> wrote:
>
okay, but why does this mean that you'll be using hg, and not the
patch system?
- erik