Re: [9fans] nupas
I continue to use nupas on s daily basis with imap.- erik
Re: [9fans] nupas
On Sun, Mar 04, 2018 at 10:26:46PM +, Steve Simon wrote: > Great, thanks. > > I just need to work out how to migrate my mailboxes > and incorperate my changes to upas (spam prevention). > > -Steve > Erik wrote splitmbox; that can handle the conversion to nupas mdir format. Make sure nothing is accessing the mailserve (e.g. via imap) before you kick it off. khm
Re: [9fans] nupas
Great, thanks. I just need to work out how to migrate my mailboxes and incorperate my changes to upas (spam prevention). -Steve
Re: [9fans] nupas
Excuse my touchscreen. check the 9front commits here https://code.9front.org/hg/plan9front/log?rev=upas
Re: [9fans] nupas
> Has there been any work on nupas since eriks initial design? Yes.
[9fans] nupas
Hi, I am connecting to my plan9 mail server from my iphone/ipads and am seeing the well-known imap performance issues. So, I think I need to move to Eriks nupas eith mdirs to make imap performant. Has there been any work on nupas since eriks initial design? has anyone written any scripts to simply migrate my mailboxes into mail dirs? Anyone have a nice canonical list of the changes nescessary to do the migration? Thanks, -Steve
Re: [9fans] nupas for smtpcarm
This thread would be funny if it didn't hurt so much. On Tue, Jan 31, 2017 at 2:08 PM hiro <23h...@gmail.com> wrote: > > Yes, WE Can (old?). > Make gmail great again. > >
Re: [9fans] nupas for smtpcarm
> Yes, WE Can (old?). Make gmail great again.
Re: [9fans] nupas for smtpcarm
Going 9pi2 image includes the libsec-x509-sha256rsa already. I tried http://mail.google.com/mail/h directory. Now I'm in the same user interface as before. Yes, WE Can (old?). Kenji
Re: [9fans] nupas for smtpcarm
I'm using the most recent )front CD image(5641.6149f97a7801) and the one older version, both of which works for gmail. Abaco is not so different, but webfs is much newer, I suppose. Probably, most works did by cinap and others on this and tls. Cinap can answer best on this I suppose. (I tried to attach my gmail screen(using Japanese), but failed to do it. If neccessary I can send it to yoiu from ordinal mail. I have problem to use that for 9fans. Kenji
Re: [9fans] nupas for smtpcarm
> are you running this on a raspbeery pi? No, this was on a 386 (atom) cpu server on a slow remote connection. Just tried again on a raspberry pi with a direct ethernet connection to my terminal, and that's much faster. So the libsec-x509-sha256rsa patch seems to be enough.
Re: [9fans] nupas for smtpcarm
are you running this on a raspbeery pi?
Re: [9fans] nupas for smtpcarm
> try accessing mail.google.com/mail/h/ manually after login, even if > the login keeps reappearing it might be your session cookie is already > valid. Thanks, that gets a bit farther - into the first screen of messages, and I managed to open a message. But it's unusably slow - eg if I adjust the window, it takes 75 sec before something appears on the page again. Is there a newer version of abaco somewhere? Sources version is dated 2013.
Re: [9fans] nupas for smtpcarm
> try accessing mail.google.com/mail/h/ manually after login, even if > the login keeps reappearing it might be your session cookie is already > valid. Thanks, that gets a bit farther - into the first screen of messages, and I managed to open a message. But it's unusably slow - eg if I adjust the window, it takes 75 sec before something appears on the page again. Is there a newer version of abaco somewhere? Sources version is dated 2013.
Re: [9fans] nupas for smtpcarm
try accessing mail.google.com/mail/h/ manually after login, even if the login keeps reappearing it might be your session cookie is already valid. On 1/28/17, Richard Miller <9f...@hamnavoe.com> wrote: >> Now I checked the standard 9pi, and found it's abaco does not support >> gmail on it, sorry. > > To access gmail.com webmail from plan 9, patch libsec-x509-sha256rsa > must be applied (and webfs/abaco recompiled with new libsec). > > However this now seems to be necessary but not sufficient. Trying > this today (from 386 or bcm), without the patch I get a tlsclient > file descriptor error message. With the patch, I get to the gmail > account sign-in page, but entering account and password just keeps > returning to the same sign-in page. > > If it's possible to sign in to gmail with abaco on 9front, can > someone offer a hint about what the essential extra ingredient is? > > >
Re: [9fans] nupas for smtpcarm
> Now I checked the standard 9pi, and found it's abaco does not support > gmail on it, sorry. To access gmail.com webmail from plan 9, patch libsec-x509-sha256rsa must be applied (and webfs/abaco recompiled with new libsec). However this now seems to be necessary but not sufficient. Trying this today (from 386 or bcm), without the patch I get a tlsclient file descriptor error message. With the patch, I get to the gmail account sign-in page, but entering account and password just keeps returning to the same sign-in page. If it's possible to sign in to gmail with abaco on 9front, can someone offer a hint about what the essential extra ingredient is?
Re: [9fans] nupas for smtpcarm
>( the changed smtp server is still blocked, and this is my first use
of gmail on abaco)
I'm using 9pif of 9front.
Now I checked the standard 9pi, and found it's abaco does not support
gmail on it, sorry.
Kenji
2017-01-24 10:04 GMT+09:00, 岡本健二 :
> I had been blocked to post mail here from my ordinal mail server.
> Then I changed server to another which has smtp auth potocol.
> It was written as smtpcram() function in nupas/smtp/smtpc
> by erik. However, it has a bug.
> Please change the line in smtpcram() in smtp.c as:
>
> dBprint("%s\r\n", ch);
> to
> dBprint("%s\r\n", ebuf);
>
> Kenji
>
> ( the changed smtp server is still blocked, and this is my first use
> of gmail on abaco)
>
[9fans] nupas for smtpcarm
I had been blocked to post mail here from my ordinal mail server.
Then I changed server to another which has smtp auth potocol.
It was written as smtpcram() function in nupas/smtp/smtpc
by erik. However, it has a bug.
Please change the line in smtpcram() in smtp.c as:
dBprint("%s\r\n", ch);
to
dBprint("%s\r\n", ebuf);
Kenji
( the changed smtp server is still blocked, and this is my first use
of gmail on abaco)
[9fans] nupas update pushed to sources
just fyi, there were some silly mistakes eliminates, including some with dec64 that might have security implications. (you may wish to apply "encodeman" patch, too) - erik
[9fans] nupas smtp update
i just pushed a change to nupas smtp that should fix problems with dialing a records before exhausting all possible mx records (on all valid networks). this had been causing me some grief of late. it also logs exactly which server was contacted and some details about the dns entry. for example, ladd Sep 18 05:40:03 quanstro sent 590 bytes to 9fans@9fans.net (mail.9fans.net:67.207.142.3;pref=10) this is good for tracking down trouble, since dns is so unreliable. - erik
Re: [9fans] nupas contrib needs rebuilding
> Anyway, a little naivety has caused me more problems but I won't go
> into details. If I just grab the nupas source and mk install, will
> the end result be sane?
yes. but be careful, i'm pretty sure nupas depends on some changes
in /mail/lib. why don't you do something like this
do one install to make sure missing directories are there. ignore errors.
then
db = /n/sources/contrib/quanstro/replica/nupas/db
args = `{cat $db | awk 'int($3/100) != 2 {print "-s " $1}' }
replica/pull $args nupas
- erik
Re: [9fans] nupas contrib needs rebuilding
On Thu, 2 Jun 2011 13:48:28 -0300 "Federico G. Benavento" wrote: > contrib/pull does > > On Jun 2, 2011, at 1:40 PM, Yaroslav wrote: > > > contrib(1) should have a way to pass -s to replica/pull > > When most of the files in a package the size of nupas fail to install, a -s option isn't much of a solution. ;)
Re: [9fans] nupas contrib needs rebuilding
On Thu, 2 Jun 2011 09:57:54 -0400 erik quanstrom wrote: > On Thu Jun 2 09:28:49 EDT 2011, quans...@quanstro.net wrote: > > > hi erik, i tried to install nupas with contrib today and it failed. > > > my root is from a fairly recent labs iso and, well, you can see the > > > source of the problem in the file dates: > > > > > > kolari% ls -lp /386/bin/upas/fs > > > --rwxrwxr-x M 8 glenda adm 345302 Apr 7 20:32 fs > > > kolari% ls -lp /n/sources/contrib/quanstro/root/386/bin/upas/fs > > > --rwxrwxr-x M 63 quanstro sys 400215 Jan 5 13:55 fs > > > > > > most of the nupas files; source, binary and other, failed to install > > > with the message "locally created; will not update". i guess you need > > > to touch nupas files and rebuild the package. > > > > i'd suggest moving /386/bin/upas and /sys/src/cmd/upas out of the way and > > trying > > again. there will still be some conflicts in /mail/lib, but those should > > be managable. > > to clarify, sources can be rebuilt at any time so touching > files and pushing the contrib package will only serve to > obfuscate when the files were actually last changed. it won't > prevent the nupas contrib package from "breaking" again. True that. I thought of suggesting a cron job to poll sources & rebuild when necessary, but it still obfuscates what changed and that doesn't feel right. > sorry for the inconvienence. i don't know of a better way. > it would be nice if applylog had an option to always resolve > conflicts in favor of the server. It would indeed. I looked at the -s option as per fgb's mail, but -s requires a filename implying each and every file needs to be specified I thought "blow this for a game of soldiers." Anyway, a little naivety has caused me more problems but I won't go into details. If I just grab the nupas source and mk install, will the end result be sane?
Re: [9fans] nupas contrib needs rebuilding
apparently contrib/install needs too... 2011/6/2 Federico G. Benavento : > contrib/pull does > -- - Yaroslav
Re: [9fans] nupas contrib needs rebuilding
contrib/pull does On Jun 2, 2011, at 1:40 PM, Yaroslav wrote: > contrib(1) should have a way to pass -s to replica/pull > --- Federico G. Benavento
Re: [9fans] nupas contrib needs rebuilding
contrib(1) should have a way to pass -s to replica/pull
Re: [9fans] nupas contrib needs rebuilding
On Thu Jun 2 09:28:49 EDT 2011, quans...@quanstro.net wrote: > > hi erik, i tried to install nupas with contrib today and it failed. > > my root is from a fairly recent labs iso and, well, you can see the > > source of the problem in the file dates: > > > > kolari% ls -lp /386/bin/upas/fs > > --rwxrwxr-x M 8 glenda adm 345302 Apr 7 20:32 fs > > kolari% ls -lp /n/sources/contrib/quanstro/root/386/bin/upas/fs > > --rwxrwxr-x M 63 quanstro sys 400215 Jan 5 13:55 fs > > > > most of the nupas files; source, binary and other, failed to install > > with the message "locally created; will not update". i guess you need > > to touch nupas files and rebuild the package. > > i'd suggest moving /386/bin/upas and /sys/src/cmd/upas out of the way and > trying > again. there will still be some conflicts in /mail/lib, but those should be > managable. to clarify, sources can be rebuilt at any time so touching files and pushing the contrib package will only serve to obfuscate when the files were actually last changed. it won't prevent the nupas contrib package from "breaking" again. sorry for the inconvienence. i don't know of a better way. it would be nice if applylog had an option to always resolve conflicts in favor of the server. - erik
Re: [9fans] nupas contrib needs rebuilding
> hi erik, i tried to install nupas with contrib today and it failed. > my root is from a fairly recent labs iso and, well, you can see the > source of the problem in the file dates: > > kolari% ls -lp /386/bin/upas/fs > --rwxrwxr-x M 8 glenda adm 345302 Apr 7 20:32 fs > kolari% ls -lp /n/sources/contrib/quanstro/root/386/bin/upas/fs > --rwxrwxr-x M 63 quanstro sys 400215 Jan 5 13:55 fs > > most of the nupas files; source, binary and other, failed to install > with the message "locally created; will not update". i guess you need > to touch nupas files and rebuild the package. i'd suggest moving /386/bin/upas and /sys/src/cmd/upas out of the way and trying again. there will still be some conflicts in /mail/lib, but those should be managable. - erik
[9fans] nupas contrib needs rebuilding
erik, I tried sending this privately but your mailer timed out: : conversation with mail.quanstro.net[69.55.170.73] timed out while sending DATA command message>> hi erik, i tried to install nupas with contrib today and it failed. my root is from a fairly recent labs iso and, well, you can see the source of the problem in the file dates: kolari% ls -lp /386/bin/upas/fs --rwxrwxr-x M 8 glenda adm 345302 Apr 7 20:32 fs kolari% ls -lp /n/sources/contrib/quanstro/root/386/bin/upas/fs --rwxrwxr-x M 63 quanstro sys 400215 Jan 5 13:55 fs most of the nupas files; source, binary and other, failed to install with the message "locally created; will not update". i guess you need to touch nupas files and rebuild the package.
Re: [9fans] nupas mad libs
On 26 May 2010, at 16:34, erik quanstrom wrote: ___ (machine) ___ (date) Hung up on ___ (ip address); clamed to be ___ (name) ladd May 25 08:21:23 Hung up on 207.36.233.113; claimed to be dedicated ladd May 26 02:00:31 Hung up on 178.125.17.236; claimed to be computer ladd May 26 06:48:02 Hung up on 116.74.92.47; claimed to be genius ladd May 26 07:57:10 Hung up on 94.159.164.125; claimed to be smartbox - erik Reminds me of one line I saw in the logs while working on rc-httpd. GET /something/soapCaller.bs /me takes a deep breath and asks all honestly, "What's a B S file?" -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
[9fans] nupas mad libs
___ (machine) ___ (date) Hung up on ___ (ip address); clamed to be ___ (name) ladd May 25 08:21:23 Hung up on 207.36.233.113; claimed to be dedicated ladd May 26 02:00:31 Hung up on 178.125.17.236; claimed to be computer ladd May 26 06:48:02 Hung up on 116.74.92.47; claimed to be genius ladd May 26 07:57:10 Hung up on 94.159.164.125; claimed to be smartbox - erik
Re: [9fans] nupas update
On Tue, 18 May 2010 20:40:15 -0400 Jorden M wrote: > On Tue, May 18, 2010 at 7:59 PM, ron minnich wrote: > > On Tue, May 18, 2010 at 4:50 PM, Federico G. Benavento > > wrote: > >> just a comment, the python port includes some hg bits because of my > >> lazyness > >> the thing is that hg isn't just python, it has some c modules that had > >> to be built > >> in in python, so python needs to be recompiled to support hg... > >> so I went the easy way, python already comes with the hg c code. > > > > > > wow. That's crazy of the hg guys but I guess I understand. > > If memory serves, it wasn't done willingly. There were performance > problems that the C was used to alleviate. It also doesn't require recompiling/relinking Python on the systems Python and Mercurial are usually used on. (They support dynamic loading of shared libraries.) Robert Ransom
Re: [9fans] nupas update
On Tue, May 18, 2010 at 7:59 PM, ron minnich wrote: > On Tue, May 18, 2010 at 4:50 PM, Federico G. Benavento > wrote: >> just a comment, the python port includes some hg bits because of my lazyness >> the thing is that hg isn't just python, it has some c modules that had >> to be built >> in in python, so python needs to be recompiled to support hg... >> so I went the easy way, python already comes with the hg c code. > > > wow. That's crazy of the hg guys but I guess I understand. If memory serves, it wasn't done willingly. There were performance problems that the C was used to alleviate. > > Anyway, it's not a big problem for people to mix multiple packages > into their root, as long as their proto is ok. > > ron > >
Re: [9fans] nupas update
On Tue, May 18, 2010 at 4:50 PM, Federico G. Benavento wrote: > just a comment, the python port includes some hg bits because of my lazyness > the thing is that hg isn't just python, it has some c modules that had > to be built > in in python, so python needs to be recompiled to support hg... > so I went the easy way, python already comes with the hg c code. wow. That's crazy of the hg guys but I guess I understand. Anyway, it's not a big problem for people to mix multiple packages into their root, as long as their proto is ok. ron
Re: [9fans] nupas update
just a comment, the python port includes some hg bits because of my lazyness the thing is that hg isn't just python, it has some c modules that had to be built in in python, so python needs to be recompiled to support hg... so I went the easy way, python already comes with the hg c code. On Mon, May 17, 2010 at 1:09 AM, ron minnich wrote: > On Sun, May 16, 2010 at 6:35 PM, Akshat Kumar > wrote: > >> Is `rbind' a recursive bind, that takes care of binding at >> all depths? Because that's what you'd need in order >> for the binds to work. And then you shouldn't have any >> problems. > > Yes, aki wrote it and yes, I thought it should solve the problems. It > did not seem to work. > > I'll get you a copy. Oh wait look here. > http://9grid.net/magic/webls?dir=/aki/src/cmd > > i sure do miss aki. Can you try the rbind thing and see if I got > something wrong? Would be *very* nice to leave the files in the .iso > and just bind things. > > >> If I can come up with a general set of commands to revert >> a given package à la history(1)/yesterday(1), I would put >> a set of those commands in /installed/$i when the package >> is installed. Then you just pass it to rc and you're golden. > > I don't think that's good enough. It's fine for standalone packages. > But consider hg. It depends on 3 or 4 things. Should you track that > stuff too, and not remove python is hg is installed? If python creates > 'x', and hg creates 'x', should you remove x if you remove HG? and so > on ... This is what makes tracking packages so ugly. > > It gets ugly fast. I would just as soon mount the .iso's and do binds. > > ron > > -- Federico G. Benavento
Re: [9fans] nupas update
On Tue, May 18, 2010 at 2:35 PM, Georg Lehner wrote: > Another view on software managment: > > http://cr.yp.to/slashpackage/management.html My system is very close to that. But I still like the idea that you have as little state as possible, and that package installation be so convenient you don't think about it much. You want to update tex? Well, maybe it's out of date, maybe it isn't, who cares? If the user says reload it, reload it. It only takes a minute or so anyway -- so who cares? It may take a minute figuring out if it is up to date or not with some of the package managers! And they tend to scatter files all over the place; if the package no longer uses them, you have to hunt them down and remove them. But, oh wait, suppose some other package now depends on that file being there? Do you remove it or not? I think in the limit the problem can't be solved. The incredible complexity of the package managers on many systems doesn't really help as much as it seems to cost. ron
Re: [9fans] nupas update
Another view on software managment: http://cr.yp.to/slashpackage/management.html Regards, Jorge-León On 2010-05-16 20:58, Corey wrote: On Sunday 16 May 2010 10:34:53 EBo wrote: Have you tried Sorcery from Source Mage? No, but I'll definitely look into it. Thanks for the pointer. Might also want to check out paludis, a spiritual successor to portage, built from scratch (written in c++), designed with the focused goal of fixing portage's shortcomings: http://paludis.pioto.org/overview/features.html Somewhat related: http://exherbo.org/docs/features.html Sorry no direct experience with these yet - not promoting them, just providing links to info. (I've been using gentoo for a variety of purposes in a variety of roles/capacities and environments for many years now, and it's my linux of choice - the amount of fine-grained control and convenience I've gained via portage has far exceeded the occasional intermittent frustrations)
Re: [9fans] nupas update
On Sun, May 16, 2010 at 9:19 PM, erik quanstrom wrote: > i'm sure if you've followed the trials of the linux union > mount system on lwn, you can think of 10 potential reasons, > without trying. recursive unions are hard. ah, but I did over time. I'm not a big fan of the super-complicated unions that those guys keep dreaming up. Aki's program is very simple if you look. ron
Re: [9fans] nupas update
> i sure do miss aki. Can you try the rbind thing and see if I got > something wrong? Would be *very* nice to leave the files in the .iso > and just bind things. i'm sure if you've followed the trials of the linux union mount system on lwn, you can think of 10 potential reasons, without trying. recursive unions are hard. - erik
Re: [9fans] nupas update
On Sun, May 16, 2010 at 6:35 PM, Akshat Kumar wrote: > Is `rbind' a recursive bind, that takes care of binding at > all depths? Because that's what you'd need in order > for the binds to work. And then you shouldn't have any > problems. Yes, aki wrote it and yes, I thought it should solve the problems. It did not seem to work. I'll get you a copy. Oh wait look here. http://9grid.net/magic/webls?dir=/aki/src/cmd i sure do miss aki. Can you try the rbind thing and see if I got something wrong? Would be *very* nice to leave the files in the .iso and just bind things. > If I can come up with a general set of commands to revert > a given package à la history(1)/yesterday(1), I would put > a set of those commands in /installed/$i when the package > is installed. Then you just pass it to rc and you're golden. I don't think that's good enough. It's fine for standalone packages. But consider hg. It depends on 3 or 4 things. Should you track that stuff too, and not remove python is hg is installed? If python creates 'x', and hg creates 'x', should you remove x if you remove HG? and so on ... This is what makes tracking packages so ugly. It gets ugly fast. I would just as soon mount the .iso's and do binds. ron
Re: [9fans] nupas update
> and without use flags I end up having k*m packages instead of m. So the
> question still comes to do I write it to allow 2^n^m possible combinations
> and document the two most common scenarios, or write 2*m package variants
> and leave it to the interested to populate any of the remaining 2^{k-2}
> permutations. I'm still undecided, but I know then kinds of bugs that
> creep up when splitting trees like that. (I guess like splitting hairs ;-)
at a minimum, ditch the use flags.
these complications are why i decided it
would be easier to just do 9atom.
- erik
Re: [9fans] nupas update
> i think it's a good question but lacking time travel or a working
> 64-bit kernel, this question is unknowable. :-)
;-) After thinking about it I think amd might have been a better example
>> > please, no use flags. we can't test what we've got. use
>> > flags make the problem go factorial. (gentoo for example
>> > doesn't work if you set the profile use flag.)
>>
>> Now we are getting to the heart of a very important matter. I agree
that
>> use flags causes the dependency graph to go factorial -- but pruned to
>> the
>> number of use flags implemented in each ebuild (so it is not factorial
to
>> the number of accepted use flags).
>
> if each package has only n use flags, then you still have
> 2^n^m options, where m is the number of packages.
>
> proof: each use flag may be on or off. if we order the use
> flags for a package arbitrarly, we can think of them as binary
> digits and there would be 2^n possible values. since there
> are m packages, we can consider this an m digit number with
> each digit taking the value 0 ... 2^n-1.
>
> if they don't all have the same use flags, we can redo this.
> if for package k, there are k_n use flags we would have
> 2^{k_0}2^{k_1} ... =
> 2^(sum k_i}
>
> which i'll grant isn't factorial. but it's still 2^{sum of use flags
> per package}. :-)
>
> i'll give you that this isn't factorial. :-) but on the other hand,
> if a package might not be installed at all, that's like another use
> flag.
and without use flags I end up having k*m packages instead of m. So the
question still comes to do I write it to allow 2^n^m possible combinations
and document the two most common scenarios, or write 2*m package variants
and leave it to the interested to populate any of the remaining 2^{k-2}
permutations. I'm still undecided, but I know then kinds of bugs that
creep up when splitting trees like that. (I guess like splitting hairs ;-)
EBo --
Re: [9fans] nupas update
I left these questions by Ron to be answered collectively by fellow Plan 9 folks who would try out his new "package system". But the conversation deteriorated into a "portage: pros and cons" debate/seminar. My input follows. On 5/16/10, ron minnich wrote: > It actually works quite well, and probably I should just create a > /installed directory, but that > was actually an afterthought. What do you recommend? I've already created mine. :) > Example: I mount python.iso and do an Aki rbind -ra of /n/python/root / > Well ... it just didn't want to work, somehow, although I forget why. > I punted at that > point and did the dircp, I just ran out of time. Is `rbind' a recursive bind, that takes care of binding at all depths? Because that's what you'd need in order for the binds to work. And then you shouldn't have any problems. > So, if we just go with the dircp approach, and copy the files in, what > I hear is missing so far: > - I don't put the installed info into /installed; should I just go > ahead and fix that? > What else? Really, the installed paths would just be there as a log of where things went. A straight `dircp' might seem harsh to some, but in my personal setup, I see no problems with such a log and my WORM dumps being taken every day. Then, reverting just means using the history(1) type tools with respect to the log at /installed/$i. That's only a little slower than a bunch of unmount(1) commands, but in totality, keeps a very efficient maintenance system with no hassles. If I can come up with a general set of commands to revert a given package à la history(1)/yesterday(1), I would put a set of those commands in /installed/$i when the package is installed. Then you just pass it to rc and you're golden. Best, ak
Re: [9fans] nupas update
> > there is no 64 bit kernel.
>
> Will there ever be? Or is that even an appropriate question?
i think it's a good question but lacking time travel or a working
64-bit kernel, this question is unknowable. :-)
> > please, no use flags. we can't test what we've got. use
> > flags make the problem go factorial. (gentoo for example
> > doesn't work if you set the profile use flag.)
>
> Now we are getting to the heart of a very important matter. I agree that
> use flags causes the dependency graph to go factorial -- but pruned to the
> number of use flags implemented in each ebuild (so it is not factorial to
> the number of accepted use flags).
if each package has only n use flags, then you still have
2^n^m options, where m is the number of packages.
proof: each use flag may be on or off. if we order the use
flags for a package arbitrarly, we can think of them as binary
digits and there would be 2^n possible values. since there
are m packages, we can consider this an m digit number with
each digit taking the value 0 ... 2^n-1.
if they don't all have the same use flags, we can redo this.
if for package k, there are k_n use flags we would have
2^{k_0}2^{k_1} ... =
2^(sum k_i}
which i'll grant isn't factorial. but it's still 2^{sum of use flags
per package}. :-)
i'll give you that this isn't factorial. :-) but on the other hand,
if a package might not be installed at all, that's like another use
flag.
- erik
Re: [9fans] nupas update
> i've tried to make this point several times before. > i think it is an error to envision what somebody > might want. build want you want. respond to > complaints. do not build stuff speculatively. Thank you for your clarity. I was hoping to open a discussion and get some feedback so when I do my thing it would likely be more useful. When starting new projects I typically start with a basic idea, then take it to what I call its illogical extreme, and then whittle it back down to the initial project. It is part of how I get a handle on what the scope of work looks like. I guess that approach is in error for 9fans, but it works quite well for me personally. >> Another potential use flag or architecture keyword covers if the package >> can be built, or should build, using 64 bit mode. > > there is no 64 bit kernel. Will there ever be? Or is that even an appropriate question? > please, no use flags. we can't test what we've got. use > flags make the problem go factorial. (gentoo for example > doesn't work if you set the profile use flag.) Now we are getting to the heart of a very important matter. I agree that use flags causes the dependency graph to go factorial -- but pruned to the number of use flags implemented in each ebuild (so it is not factorial to the number of accepted use flags). The situation I am dealing with regards to TinyCoreLinux is that they require that the documentation and source be broken out into separate packages. So, I have currently implemented this as separate portage ebuilds for convenience. But to make this work generally, and for long term maintainability, I have to either implement them as 3*packages or implement this as a "doc source" use flags and possibly an independent ROOT. The advantage of use flags here is that the source and documentation build is kept together. The disadvantage is that building in use flags increases the complexity somewhat, but is it more than what is saved by including them? I do not know. If I do implement use flags I only see the need for maybe 3 or 4, at least for my uses. I've been bitten in the past by separating parts of a logical package at the package level, but seperate source/docs are required, and I see how this will make things easier when I have time to play with embedded systems again. But this discussion demonstrates my point exactly. If I had not opened the discussion we would not have had the above exchange. I would have simply implemented something with use flags and then when you objected later and I would unlikely be willing to rip it out without really good cause or motivation. Best regards, EBo --
Re: [9fans] nupas update
> I see a couple of other applications for use flags besides pruning > overgrown packages -- such as should we install source and documentation > (yes by default on large systems, no on small embedded systems). Should we > strip binaries or compile things for debugging? Install examples? I do > not see much call for more than that, but I see those as useful. i've tried to make this point several times before. i think it is an error to envision what somebody might want. build want you want. respond to complaints. do not build stuff speculatively. > Another potential use flag or architecture keyword covers if the package > can be built, or should build, using 64 bit mode. there is no 64 bit kernel. please, no use flags. we can't test what we've got. use flags make the problem go factorial. (gentoo for example doesn't work if you set the profile use flag.) - erik
Re: [9fans] nupas update
> Might also want to check out paludis, a spiritual successor > to portage, built from scratch (written in c++), designed with > the focused goal of fixing portage's shortcomings: > > http://paludis.pioto.org/overview/features.html > > Somewhat related: http://exherbo.org/docs/features.html Thanks for the pointer. I am aware of paludis, but did not consider its use because lack of C++ support on Plan 9. It might be a better reference than portage though. > Sorry no direct experience with these yet - not promoting > them, just providing links to info. fair enough, and thanks. > (I've been using gentoo for a variety of purposes in a variety > of roles/capacities and environments for many years now, and > it's my linux of choice - the amount of fine-grained control and > convenience I've gained via portage has far exceeded the > occasional intermittent frustrations) my feelings exactly. EBo --
Re: [9fans] nupas update
On Sunday 16 May 2010 10:34:53 EBo wrote: > > Have you tried Sorcery from Source Mage? > > No, but I'll definitely look into it. Thanks for the pointer. > Might also want to check out paludis, a spiritual successor to portage, built from scratch (written in c++), designed with the focused goal of fixing portage's shortcomings: http://paludis.pioto.org/overview/features.html Somewhat related: http://exherbo.org/docs/features.html Sorry no direct experience with these yet - not promoting them, just providing links to info. (I've been using gentoo for a variety of purposes in a variety of roles/capacities and environments for many years now, and it's my linux of choice - the amount of fine-grained control and convenience I've gained via portage has far exceeded the occasional intermittent frustrations)
Re: [9fans] nupas update
>> I think some of the ideas behind portage are good, e.g. the ability to >> handle patches and slim down software via USE flags. > > this is only necessary if your purpose is to prune overgrown > packages. i hope will will solve this problem by not having > overgrown pacakges. I see a couple of other applications for use flags besides pruning overgrown packages -- such as should we install source and documentation (yes by default on large systems, no on small embedded systems). Should we strip binaries or compile things for debugging? Install examples? I do not see much call for more than that, but I see those as useful. Another potential use flag or architecture keyword covers if the package can be built, or should build, using 64 bit mode. EBo --
Re: [9fans] nupas update
> I think some of the ideas behind portage are good, e.g. the ability to > handle patches and slim down software via USE flags. this is only necessary if your purpose is to prune overgrown packages. i hope will will solve this problem by not having overgrown pacakges. - erik
Re: [9fans] nupas update
Isn't everything great until you see the bad side of it? Stay technical, guys.
Re: [9fans] nupas update
> Have you tried Sorcery from Source Mage? No, but I'll definitely look into it. Thanks for the pointer. > I'd say that's Portage > without "3/4 of the junk," but it's still quite complex. I may be > talking out of my arse but I don't see anything inherent to plan 9 > which would simplify a package manager, unless it's the common use of > versioning file systems, the use of which may have removed the need > for this thread. Agreed. I do not think that a versioning file system alone goes quite far enough, but it does most of the way.
Re: [9fans] nupas update
>> Look here EBo, go help maintain a Linux distro for a couple of years and >> THEN come back and tell us your "package managers are wonderful" swill. I >> don't think you've even packaged up one piece of software. You can't >> have if >> you're promoting package managers so much. well let me see, I think I shared my first portage ebuild in 2004. I have had Sunrise commit privileges for a year or two now, and have posted a few additions, upgrades, and bug fixes along the way. In addition, I am working toward becoming an official Gentoo developer and am negotiating taking over maintenance of the plan9port, 9vx, and inferno ebuilds for Gentoo and getting the ones which are not already in the main tree to be added. And as Ron alluded to below, I just got a 9vx package accepted into the standard packages of TinyCoreLinux (called Tvx). But by your standards this does not sound like enough experience to justify an opinion. The basis of my opinion, however, comes from administrating and software development for systems, networks and clusters over the last 25 years. >From a sys admin point of view I often do not have the time to upgrade a system unless I know I can downgrade it if necessary. I have to be able to do this quickly. And no, I do not expect for the upstream maintainers to do this for me and I have 206 ebuilds in my private overlay (I just counted them). > As nemo points out, "relax". > > EBo just did a very good thing for all of us: 9vx is part of a distro. > I think he's got some credibility at this point :-) Thank you Ron for a call for civility. Reflecting over all this I think that I do not yet know how to communicate in the 9fans' language, and that much of the misunderstandings stem from simple miscommunication. I'll learn with time, and I hope I will not be to annoying in the process. But the couple of times I have seen this kind of vehemence in the past with other code bases it stemmed from software systems which had no package management and difficult build/configure systems. The end result was that new users would either get discouraged and drift off, or they would spend literally hundreds of hours to just get to the point where they can dependably configure, build, and run the code. An interesting consequence of this is that any proposed non-trivial change is met by the old-timers with a resounding "DON'T TOUCH IT!!!" And there is good reasons for this -- namely that it took some of these people a year or more (quite literally) of training and experience to understand how to maintain the systems. A significant change will cause them to have to go back and learn the new system, and they remember what happened the last two or three times that happened. I have to wonder if the same this applies to the Plan 9 community. If so, the best way to move forward will be to fork the code. EBo --
Re: [9fans] nupas update
On 16 May 2010, at 17:02, ron minnich wrote: On Sun, May 16, 2010 at 8:53 AM, Ethan Grammatikidis wrote: Look here EBo, go help maintain a Linux distro for a couple of years and THEN come back and tell us your "package managers are wonderful" swill. I don't think you've even packaged up one piece of software. You can't have if you're promoting package managers so much. As nemo points out, "relax". EBo just did a very good thing for all of us: 9vx is part of a distro. I think he's got some credibility at this point :-) ron All right, shutt'n up now, lol. -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [9fans] nupas update
On Sun, May 16, 2010 at 8:53 AM, Ethan Grammatikidis wrote: > Look here EBo, go help maintain a Linux distro for a couple of years and > THEN come back and tell us your "package managers are wonderful" swill. I > don't think you've even packaged up one piece of software. You can't have if > you're promoting package managers so much. As nemo points out, "relax". EBo just did a very good thing for all of us: 9vx is part of a distro. I think he's got some credibility at this point :-) ron
Re: [9fans] nupas update
On 16 May 2010, at 16:46, Jorden M wrote: On Sun, May 16, 2010 at 11:21 AM, EBo wrote: portage is horrid. i hate it more every time i use it. and it doesn't work. revdep rebuild is proof. it is a lot more dependable than any other package maintenance system I've used on *NIX based systems. The fundamental problem requiring revdep is I honestly can't support that. I do like Portage, but it is horribly fragile. The few volunteers that work with it can't keep it from breaking every few months, and when they finally have a fix, it's a long wiki page of instructions, not a simple `ok, everyone update your portage trees for the fix'. Contrast Sorcery which has multiple well-implemented automated repair systems. -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [9fans] nupas update
On 16 May 2010, at 16:37, EBo wrote: From personal experience with taking the backup approach, this works fine until you forget about it once, and it also results in a huge number of copies of the system/source laying around. This is less an issue in this day and age of cheap disks, but but what? I agree making the sysadmin do backups is not the best approach but.. oh man, why has no-one brought this up yet? When the sysadmin forgets he can restore from sources! Look here EBo, go help maintain a Linux distro for a couple of years and THEN come back and tell us your "package managers are wonderful" swill. I don't think you've even packaged up one piece of software. You can't have if you're promoting package managers so much. -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [9fans] nupas update
On Sun, May 16, 2010 at 11:21 AM, EBo wrote: > >> portage is horrid. i hate it more every time i use it. >> and it doesn't work. revdep rebuild is proof. > > it is a lot more dependable than any other package maintenance system I've > used on *NIX based systems. The fundamental problem requiring revdep is I honestly can't support that. I do like Portage, but it is horribly fragile. The few volunteers that work with it can't keep it from breaking every few months, and when they finally have a fix, it's a long wiki page of instructions, not a simple `ok, everyone update your portage trees for the fix'. Now, I've never seen Portage itself screw up the tree, unlike Apt, which I've seen muck up its own database beyond any repair whatsoever. But still, I've only been nuked by Apt once, and beaten bloody by Portage several times, despite having used Portage much much less than Apt. > >> it's not clear to me that this is gentoo's fault. linux and >> gnu together are one heck of a difficult place for >> a distribution to live. but replicating portage would seem >> to me to be a big mistake. > > I see that I was not clear. I have no intention of replicating portage, > but I DO intend to replicate some of the fundamental functionality. I do > not see this as much more than an extension of fgb's contrib or ron's new > package installer. If you see otherwise I would love to hear why. > >> not only does the plan 9 >> community lack the resources to maintain 30 different >> versions of /bin/cp (or whatever), much less portage redux, >> it will encourage gnu/linux habits, because that's what it's >> built for. > > in practice, there are only two versions which are actively maintained -- > the canonical stable version, and the latest experimental. Assuming that > the stable version is in fact actually stable, then there is little need to > actually maintain older versions, but sometimes it is useful to go back and > reconfigure them. Particularly when you have scripts and things which > depend on some oddities command line arguments (I'm referring here to the > thread regarding standard arguments). > > Lacking some mechanism to deal with specific versions, just to name one > issue, is that you have no easy way to get go back to a known working > version when an update breaks something. The situation which prompted this > very thread is a case in point. > > My motivation for wanting, and probably implementing, version controlled > builds/runs is to dependently replicating complicated modeling scenarios. > >> we should build something that encourages a simplier >> system, a system plan 9 people would really want. > > As I said I was motivated by my portage experience not that I intend to > reimplement portage, but even if I did attempt a reimplementation the fact > that plan 9 is a much cleaner design, probably 3/4 of the junk is simply > not needed. The question is how much of the basic functionality is useful, > and what is the most appropriate way to go about implementing it. > > EBo -- > > >
Re: [9fans] nupas update
On Sun, May 16, 2010 at 10:03 AM, erik quanstrom wrote: > portage is horrid. i hate it more every time i use it. > and it doesn't work. revdep rebuild is proof. > > it's not clear to me that this is gentoo's fault. linux and > gnu together are one heck of a difficult place for > a distribution to live. but replicating portage would seem > to me to be a big mistake. not only does the plan 9 > community lack the resources to maintain 30 different > versions of /bin/cp (or whatever), much less portage redux, > it will encourage gnu/linux habits, because that's what it's > built for. > > we should build something that encourages a simplier > system, a system plan 9 people would really want. > > - erik > > I think some of the ideas behind portage are good, e.g. the ability to handle patches and slim down software via USE flags. That said, Portage is horrible to use, either as someone who just wants to use a package mangler or someone who wants to mangle their software into packages. I think it's probably 60% GNU/GTK/Qt/Shared Libraries'/etc. fault, and 40% Portage being wacky. Portage would have worked better had it targeted Plan 9. So would a lot of things, but we all know the story. That said, Ron's work sounds pretty interesting -- I wonder if he'd consider supporting something like USE-flags or easy patch application, as there are some patches/new versions on sources that would be nice to aggregate and install easily on top of an existing `package'
Re: [9fans] nupas update
On 16 May 2010, at 16:21, EBo wrote: As I said I was motivated by my portage experience not that I intend to reimplement portage, but even if I did attempt a reimplementation the fact that plan 9 is a much cleaner design, probably 3/4 of the junk is simply not needed. The question is how much of the basic functionality is useful, and what is the most appropriate way to go about implementing it. Have you tried Sorcery from Source Mage? I'd say that's Portage without "3/4 of the junk," but it's still quite complex. I may be talking out of my arse but I don't see anything inherent to plan 9 which would simplify a package manager, unless it's the common use of versioning file systems, the use of which may have removed the need for this thread. I'd honestly MUCH rather use a versioning file system than any package manager at all. I dare say a versioning file system is the Right Way and a package manager very much the Wrong Way. On a couple of unix machines I've even started using git to keep revisions in /usr/local. I don't suppose it's entirely brilliant but I've dealt with RPM, I've dealt with Portage, I've dealt with Sorcery (which is very good), I've vaguely sort of coped with dpkg (which always gives me "what the hell" and "ye gods, why" feelings), and honestly, even saying Sorcery is very good I'm happier without any package manager. -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [9fans] nupas update
> Indeed, Gnu/Linux is almost unique as an operating system in suffering > from an inconsistent base system which, without going into detail, is > at the very least a huge abuse of everyone's time. and since plan 9 has a consistent back most of the rigmarole is not necessary, but some is. Before people start arguing that it *will* lead to inconsistancies and gnu/linux'isms it doe not have to. A canonical can be kept separate from any avant garde changes. > The problem I see here is like this: > > 1: A consistent base system is extremely desirable. > 2: Some parts of the base system sometimes need to be replaced. > 3: It is often desirable to be able to safely experiment with > replacement basesystem parts. > > Point 2 raises the questions of which parts, and when. Perhaps upas > should be replaced with nupas in the official distribution. > > Point 3 is the only one which suggests a package manager, I would debate that point 2 would also benefit, but that is a minor issue. > but it > equally alternatively suggests using a filesystem with history, or > perhaps care on the sysadmin's part to archive all files which will be > replaced by the new installation. >From personal experience with taking the backup approach, this works fine until you forget about it once, and it also results in a huge number of copies of the system/source laying around. This is less an issue in this day and age of cheap disks, but > Automated solutions are of course > possible, but I don't think there is one which solves conflicts > between packages to everyone's satisfaction. So the question is what functionality are people looking for? EBo --
Re: [9fans] nupas update
> portage is horrid. i hate it more every time i use it. > and it doesn't work. revdep rebuild is proof. it is a lot more dependable than any other package maintenance system I've used on *NIX based systems. The fundamental problem requiring revdep is > it's not clear to me that this is gentoo's fault. linux and > gnu together are one heck of a difficult place for > a distribution to live. but replicating portage would seem > to me to be a big mistake. I see that I was not clear. I have no intention of replicating portage, but I DO intend to replicate some of the fundamental functionality. I do not see this as much more than an extension of fgb's contrib or ron's new package installer. If you see otherwise I would love to hear why. > not only does the plan 9 > community lack the resources to maintain 30 different > versions of /bin/cp (or whatever), much less portage redux, > it will encourage gnu/linux habits, because that's what it's > built for. in practice, there are only two versions which are actively maintained -- the canonical stable version, and the latest experimental. Assuming that the stable version is in fact actually stable, then there is little need to actually maintain older versions, but sometimes it is useful to go back and reconfigure them. Particularly when you have scripts and things which depend on some oddities command line arguments (I'm referring here to the thread regarding standard arguments). Lacking some mechanism to deal with specific versions, just to name one issue, is that you have no easy way to get go back to a known working version when an update breaks something. The situation which prompted this very thread is a case in point. My motivation for wanting, and probably implementing, version controlled builds/runs is to dependently replicating complicated modeling scenarios. > we should build something that encourages a simplier > system, a system plan 9 people would really want. As I said I was motivated by my portage experience not that I intend to reimplement portage, but even if I did attempt a reimplementation the fact that plan 9 is a much cleaner design, probably 3/4 of the junk is simply not needed. The question is how much of the basic functionality is useful, and what is the most appropriate way to go about implementing it. EBo --
Re: [9fans] nupas update
On 16 May 2010, at 15:03, erik quanstrom wrote: portage is horrid. i hate it more every time i use it. and it doesn't work. revdep rebuild is proof. it's not clear to me that this is gentoo's fault. linux and gnu together are one heck of a difficult place for a distribution to live. but replicating portage would seem to me to be a big mistake. not only does the plan 9 community lack the resources to maintain 30 different versions of /bin/cp (or whatever), much less portage redux, it will encourage gnu/linux habits, because that's what it's built for. we should build something that encourages a simplier system, a system plan 9 people would really want. - erik Indeed, Gnu/Linux is almost unique as an operating system in suffering from an inconsistent base system which, without going into detail, is at the very least a huge abuse of everyone's time. The problem I see here is like this: 1: A consistent base system is extremely desirable. 2: Some parts of the base system sometimes need to be replaced. 3: It is often desirable to be able to safely experiment with replacement basesystem parts. Point 2 raises the questions of which parts, and when. Perhaps upas should be replaced with nupas in the official distribution. Point 3 is the only one which suggests a package manager, but it equally alternatively suggests using a filesystem with history, or perhaps care on the sysadmin's part to archive all files which will be replaced by the new installation. Automated solutions are of course possible, but I don't think there is one which solves conflicts between packages to everyone's satisfaction. I haven't written half what I could have, but I'm in no mood for writing, today. -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [9fans] nupas update
portage is horrid. i hate it more every time i use it. and it doesn't work. revdep rebuild is proof. it's not clear to me that this is gentoo's fault. linux and gnu together are one heck of a difficult place for a distribution to live. but replicating portage would seem to me to be a big mistake. not only does the plan 9 community lack the resources to maintain 30 different versions of /bin/cp (or whatever), much less portage redux, it will encourage gnu/linux habits, because that's what it's built for. we should build something that encourages a simplier system, a system plan 9 people would really want. - erik
Re: [9fans] nupas update
>>I think you >> can go a little further: the /installed/$i file on >> disk can contain info for binding the installed >> package onto /. Then, the /installed/$i file >> resulting from the binds can contain removal >> procedures. >> >> I'm not sure what would be the most comfortable >> from a use perspective, but it's an idea > > I think it's worth trying out. I just don't have the time right now. > > So, if we just go with the dircp approach, and copy the files in, what > I hear is missing so far: > - I don't put the installed info into /installed; should I just go > ahead and fix that? > What else? I too have been interested in this, but I come at it from my experience with portage. The following are things that I would like to either see added or would like to try to contribute as time allows: * versioning support and control - helpful for determining exactly what software is being run, and facilitates developers being able to configure machines similarly by providing the installed package list (called world in portage parlance). * ability to specify stable and experimental versions of a program - so we have dependable installs and still can support the bleeding edge * package masking and unmasking - sometimes a particular package is determined to be buggy on a particular system or configuration and we need to be able to mark it as "do not do this" * live vs. predefined versioning - by convention packages in portage are based off of specified versions. They do provide a mechanism for "live" updates. This is done so that pulling the source tree does not roach some part of the system. * dependency specification - package developers know exactly what dependencies are required, and should be able to specificity what versions of libraries, etc., should or should not be built against. * patch ability - adding the ability to specify specific patches in the package system facilitates maintenance and specialty hardware experimentation. * checksum on all associated files - security, but also assures that I did not do a boneheaded move and modified something. * package associated installed file list - each file on the system is associated with a single package which protects it for being hammered by another package, and this facilitates dependable uninstall operations. * auxiliary trees - called overlays in portage, allows different forks to maintain their own changes separately (this would be particularly useful for migrating between 9atom and the canonical source tree). * cross platform and alt root support - this allows us to build for different target platforms which might be unrealistic to have an entire installed platform like the styx-on-a-brik. As a note, the above were some of the motivations behind my Gentoo based GSoC application (I already have a list of over 30 points to consider in my notes). All of the above functionality is available in portage, but portage is written in python; which is to steep a requirement for a useful pla9 build tool IMHO. Hence my plans to writing it in rc if I end up developing this functionality. Also, I only see a small portion of the above as being required for my current modeling work (namely versioning, dependencies, and cuecksums), but I have found the rest of the functionality unbelievably useful from supporting embedded systems to beowulf clusters. EBo --
Re: [9fans] nupas update
On Sat, May 15, 2010 at 9:57 PM, Akshat Kumar wrote: > http://9grid.net/rminnich/src/package-tools/install no, it's not there, as I am not yet satisified with the right way to do this. > > - instead, there is a straight dircp. yes. > So, is this a thing you're developing personally? no, what you see is what I've got right now. It actually works quite well, and probably I should just create a /installed directory, but that was actually an afterthought. What do you recommend? > In consideration of your bind idea, remember: unimplemented because I could not quite get it to work. Example: I mount python.iso and do an Aki rbind -ra of /n/python/root / Well ... it just didn't want to work, somehow, although I forget why. I punted at that point and did the dircp, I just ran out of time. >I think you > can go a little further: the /installed/$i file on > disk can contain info for binding the installed > package onto /. Then, the /installed/$i file > resulting from the binds can contain removal > procedures. > > I'm not sure what would be the most comfortable > from a use perspective, but it's an idea I think it's worth trying out. I just don't have the time right now. So, if we just go with the dircp approach, and copy the files in, what I hear is missing so far: - I don't put the installed info into /installed; should I just go ahead and fix that? What else? ron
Re: [9fans] nupas improper error output
> term% /n/sources/plan9/386/bin/upas/fs -f /imaps/imap.gmail.com > /n/sources/plan9/386/bin/upas/fs: opening /imaps/imap.gmail.com: > imap.gmail.com/imaps:server certificate XXX not > > term% upas/fs -f /imaps/imap.gmail.com > upas/fs: opening /imaps/imap.gmail.com: imap.gmail.com/imaps:fd out of > range or not open > > (cert replaced with "XXX") > So there's some part of the error reporting > in nupas that hides the real problem, which > is with the certificate having changed. error message fixed. add: x509 sha1=d5120bf1c88f4b105d18ae0c909a4c2d88c7d002 cn=*.gmail.com to /sys/lib/tls/mail - erik
Re: [9fans] nupas update
On 5/16/10, ron minnich wrote: > On Sat, May 15, 2010 at 9:28 PM, Akshat Kumar > wrote: > >> I notice you don't keep a list of >> installed file paths in /installed/$i > > I do, but the intent is that you bind -a package /, and the > 'installed' in there has the > files. > > I have this allergy to dropping stuff into / :-) However, I don't see such binds going on in your install script at http://9grid.net/rminnich/src/package-tools/install - instead, there is a straight dircp. So, is this a thing you're developing personally? >> Perhaps the file itself can contain >> the binds and mounts specific >> to its going about its own removal. In consideration of your bind idea, I think you can go a little further: the /installed/$i file on disk can contain info for binding the installed package onto /. Then, the /installed/$i file resulting from the binds can contain removal procedures. I'm not sure what would be the most comfortable from a use perspective, but it's an idea Best, ak
Re: [9fans] nupas update
On Sat, May 15, 2010 at 9:39 PM, erik quanstrom wrote: >> I do, but the intent is that you bind -a package /, and the >> 'installed' in there has the >> files. > > that won't work unless the differences are at the same > level as the bind, in this case /. I already do that today :-) term% bind -a package / term% ls /installed /installed/bz2 /installed/hg /installed/openssl /installed/python /installed/tex /installed/z term% thanks ron
Re: [9fans] nupas update
> I do, but the intent is that you bind -a package /, and the > 'installed' in there has the > files. that won't work unless the differences are at the same level as the bind, in this case /. - erik
[9fans] nupas improper error output
The following tells the story: term% /n/sources/plan9/386/bin/upas/fs -f /imaps/imap.gmail.com /n/sources/plan9/386/bin/upas/fs: opening /imaps/imap.gmail.com: imap.gmail.com/imaps:server certificate XXX not term% upas/fs -f /imaps/imap.gmail.com upas/fs: opening /imaps/imap.gmail.com: imap.gmail.com/imaps:fd out of range or not open (cert replaced with "XXX") So there's some part of the error reporting in nupas that hides the real problem, which is with the certificate having changed. Best, ak
Re: [9fans] nupas update
On Sat, May 15, 2010 at 9:28 PM, Akshat Kumar wrote: > I notice you don't keep a list of > installed file paths in /installed/$i I do, but the intent is that you bind -a package /, and the 'installed' in there has the files. I have this allergy to dropping stuff into / :-) > Perhaps the file itself can contain > the binds and mounts specific > to its going about its own removal. Yes, this is a good idea. I have not taken this idea as far as it can go; consider it a preliminary step and I welcome the kinds of improvements that you smart guys are proposing! thanks ron
Re: [9fans] nupas update
By the way, Ron, in order to sort this mess out, with the help of Federico, I essentially carried out the operations in the install script of your new package system. I notice you don't keep a list of installed file paths in /installed/$i -- is that something you've already tried, for maintaining removal info and what not? Perhaps the file itself can contain the binds and mounts specific to its going about its own removal. Best, ak On 5/16/10, ron minnich wrote: > On Sat, May 15, 2010 at 4:45 PM, erik quanstrom > wrote: >> sometimes replica gets in its own way. usually when >> it gets confused, i remove /dist/replica/$x and >> /dist/replica/client/$x* and often remove any potentially >> conflicting files. i suppose it would be better to get >> replica to tell me about conflicts and use -s. > > Sometimes eh :-) > > For me, more often than that :-) > > This type of situation is why I like the concept of packages that > never overwrite files in the root file system. To back out you just > get rid of the package file, reboot --> fixed. I feel we need > improvement on this score. > > Seems to me with a reasonable set of mount and then binds we could > make this type of thing work, and copy files all over / would be a > thing of the past. That's what I was trying to do with my attempted > package system but failed. Possibly we could put a file in the file > system image called autorun.ini that sets things up, i.e. does binds > and whatever else is needed? That in essence is what tinycore does ... > save for the binds . > > ron > >
Re: [9fans] nupas update
> This type of situation is why I like the concept of packages that > never overwrite files in the root file system. To back out you just > get rid of the package file, reboot --> fixed. I feel we need > improvement on this score. the ramfs trick will not work if you have a standard plan 9 network with >1 machine. if you used /lib/namespace instead, things would be better. unfortunately since union mounts are not deep, this would be a very difficult thing to construct. i still think it's a mistake to think that not overwriting things is a panacea. the essential problem in this case is that is is difficult (if not impossible) to test the tuple (original version upgrade version, base system). - erik
Re: [9fans] nupas update
On Sat, May 15, 2010 at 4:45 PM, erik quanstrom wrote: > sometimes replica gets in its own way. usually when > it gets confused, i remove /dist/replica/$x and > /dist/replica/client/$x* and often remove any potentially > conflicting files. i suppose it would be better to get > replica to tell me about conflicts and use -s. Sometimes eh :-) For me, more often than that :-) This type of situation is why I like the concept of packages that never overwrite files in the root file system. To back out you just get rid of the package file, reboot --> fixed. I feel we need improvement on this score. Seems to me with a reasonable set of mount and then binds we could make this type of thing work, and copy files all over / would be a thing of the past. That's what I was trying to do with my attempted package system but failed. Possibly we could put a file in the file system image called autorun.ini that sets things up, i.e. does binds and whatever else is needed? That in essence is what tinycore does ... save for the binds . ron
Re: [9fans] nupas update
On Sat May 15 19:18:57 EDT 2010, aku...@mail.nanosouffle.net wrote: > So, how to resolve this mess and finally install the > nupas package? It'd also be nice if somehow files > in /mail/lib and other places where installed without > hassle (though I'd like to keep some custom configs > there). first off, i'm sorry about the problems. i should have tested the nupas->nupas upgrade path more thoroughly. contrib isn't quite the right tool for a direct replacement. sometimes replica gets in its own way. usually when it gets confused, i remove /dist/replica/$x and /dist/replica/client/$x* and often remove any potentially conflicting files. i suppose it would be better to get replica to tell me about conflicts and use -s. i've attached the prototype for the files included in the replica perhaps this will help. you can get a full listing of what + expands to from a listing of /n/contrib/quanstro/root/... - erik386 bin upas addhash aliasmail bayes deliver filter fs imap4d isspam list marshal mbappend ml mlmgr mlowner msgcat msgtok nedmail pop3 qer runq scanmail send smtp smtpd spam spf testscan token unspam vf acme bin 386 Mail mail lib spamhaus validatesender rc bin usenupas splitmbox service !tcp993 tcp143 service.auth tcp993 sys man 1 faces filter mail marshal mlmgr nedmail 4 upasfs 6 mdir rewrite 8 aliasmail pop3 qer scanmail send smtp splitmbox usenupas src cmd faces + upas Mail + alias + bayes + binscripts + common + doc + filterkit + fs mkfile bos.c cache.c fs.c header.c idx.c imap.c mbox.c mdir.c mtree.c plan9.c planb.c pop3.c ref.c remove.c rename.c seg.c strtotm.c dat.h imap4d + marshal + misc + mkfile mkupas ml + ned mkfile nedmail.c
Re: [9fans] nupas update
I have nupas from a long time back and recently decided to run contrib/install quanstro/nupas However, it seems that the nupas package has since been moved from nupas to overwrite the base upas, along with base files in /sys/man, other src directories (faces, etc.) and some files in /mail/lib. In short, my upas install is now botched with a mix of stuff from quanstro/nupas that could be updated, and a lot of missing stuff. I don't have a problem with overwriting completely, since nupas has been working so well for me for so long, but now I'm left in the cold with no proper upas or nupas (the old /386/bin/nupas was also removed during the pull). As such, I tried a subsequent pull with the -s flag to list directories I would like updated, but pull thinks everything is up to date, so it makes no action. Then I tried my hand at contrib/remove quanstro/nupas | rc contrib/install quanstro/nupas but of course that brings me back to where I was with the first contrib/pull. And of course a subsequent pull doesn't do anything, as described above. So, how to resolve this mess and finally install the nupas package? It'd also be nice if somehow files in /mail/lib and other places where installed without hassle (though I'd like to keep some custom configs there). Thanks, ak On Wed, Sep 2, 2009 at 7:16 PM, erik quanstrom wrote: > i've pushed an update of my nupas contrib > package to sources. imap successful in use > with apple mail (snow leper, too), iphone, > outlook, opera, ff, upas/fs. > > note on installing: > as devon pointed out, installation is still a > big pain. > 1. move /sys/src/nupas -> onupas > 2. contrib/install quanstro/nupas > > if you want to go cold turkey nupas, then > a. mv /386/bin/upas /386/bin/oupas > b. mv /386/bin/nupas /386/bin/upas > c. (opt) edit top-level mkfile to install in > /386/bin/nupas. > > if you want to hedge your bets > a. add "usenupas" to your profile > b. edit cpurc as you see fit to use nupas > binaries. > > cavet: i have not had a chance to retest the > contrib package. > > as always, feedback welcome. > > - erik > >
Re: [9fans] nupas update
> So when you say that it works with Snow Leopard too, are you meaning that > this works *on* snow leopard with something like FUSE 9p via plan 9 from > user space? imap4d and upas/fs are running on a regular plan 9 install. apple mail is running as normal. there is no 9p required on the mac. while i'm sure that the p9p client stuff would work with nupas imap4d, it would take work to port the servers. - erik
Re: [9fans] nupas update
On Wed, Sep 2, 2009 at 7:16 PM, erik quanstrom wrote: > i've pushed an update of my nupas contrib > package to sources. imap successful in use > with apple mail (snow leper, too), iphone, > outlook, opera, ff, upas/fs. > > note on installing: > as devon pointed out, installation is still a > big pain. > 1. move /sys/src/nupas -> onupas > 2. contrib/install quanstro/nupas > > if you want to go cold turkey nupas, then > a. mv /386/bin/upas /386/bin/oupas > b. mv /386/bin/nupas /386/bin/upas > c. (opt)edit top-level mkfile to install in >/386/bin/nupas. > > if you want to hedge your bets > a. add "usenupas" to your profile > b. edit cpurc as you see fit to use nupas >binaries. > > cavet: i have not had a chance to retest the > contrib package. > > as always, feedback welcome. > So when you say that it works with Snow Leopard too, are you meaning that this works *on* snow leopard with something like FUSE 9p via plan 9 from user space? Just curious. > > - erik > >
[9fans] nupas update
i've pushed an update of my nupas contrib package to sources. imap successful in use with apple mail (snow leper, too), iphone, outlook, opera, ff, upas/fs. note on installing: as devon pointed out, installation is still a big pain. 1. move /sys/src/nupas -> onupas 2. contrib/install quanstro/nupas if you want to go cold turkey nupas, then a. mv /386/bin/upas /386/bin/oupas b. mv /386/bin/nupas /386/bin/upas c. (opt)edit top-level mkfile to install in /386/bin/nupas. if you want to hedge your bets a. add "usenupas" to your profile b. edit cpurc as you see fit to use nupas binaries. cavet: i have not had a chance to retest the contrib package. as always, feedback welcome. - erik
[9fans] nupas changelog
it was too hard being lazy, so i finally put up a changelog from the version of nupas presented at iwp9 3e in volos. http://www.quanstro.net/plan9/changes2009.html - erik
[9fans] nupas update
i just pushed an update of nupas to sources. it fixes a few bugs, including - a recursive sync loop has been eliminated.. (this has been the source of some mystery crashes) - dualing upas/fs operating on the same mbox no longer miss deletions. the fix is less than elegant. also on 27 jul, a crash with truncated mime sections was fixed. it might be that there is still a bug in imap that caused the original problem. but it could also be due to the recursive sync loop. thanks for the bug reports! - erik
[9fans] nupas imap4d
On Tue May 19 08:25:47 EDT 2009, kokam...@hera.eonet.ne.jp wrote: > What is the most important difference between the two? > Would you please post it to 9fans? i sent a more complete answer off list (which i've lost). the main difference is that with nupas you don't have to load the entire mailbox into ram if you use mdirs. at coraid we have >3gb of mboxes opened multiple times on a 2gb machine. the largest active mbox is 598mb. also using mdirs has reduced the size of the dump due to mailboxes by 95%. i'm pretty sure there would be very little block sharing in venti, due to how messages move around wrt venti blocks, so the venti savings would be similar. the paper is http://www.quanstro.net/plan9/nupas.pdf. - erik
[9fans] nupas imap4d
i put a new version of imap4d up on sources that should eliminate uid sequence error messages with outlook. (and the oh-so-helpful dialog boxes that go with them.) thunderbird and apple mail don't seem to care about this problem. for those who care, the problem is ... each imap message is identified by an ephemerial sequence number and a perminant uid. imap4 takes the nonsensical position that while result sets may be returned in any order, uid_a < uid_b <=> seq_a < seq_b; being able to return things in any order is no help at all if you have to sort the messages to sequence them anyway. so that's what i did. but at least i didn't like it. - erik
[9fans] nupas dump results
the conversion of our last two big mail users to mail directories this week is quite interesting: Sun Mar 22 06:08:35: 126514 blocks copied to worm Sun Mar 29 06:01:55: 10922 blocks copied to worm that's a difference of ~900MB/day for two mailboxes. while we could easily sustain dumps of several gb/day, it's hard to argue that it's a good thing to have to cart all that useless data round. - erik
Re: [9fans] Nupas truncated e-mail
On Wed Mar 11 12:44:02 EDT 2009, m...@gmx.net wrote: > > % cat /mail/fs/mbox/99/unixdatesec > 1236524327.00 > % ls -l /mail/box/mn/mbox/1236524327.00 > --r M 226874 mn mn 352001 Mar 9 15:33 /mail/box/mn/mbox/1236524327.00 > % cmp /mail/box/mn/mbox/1236524327.00 /mail/fs/mbox/99/rawunix > EOF on /mail/fs/mbox/99/rawunix after 335937 bytes > are you running the latest version of nupas? this looks like a bug that has been fixed, but it may have popped up in a different form. if you are using the latest and still have trouble, contact me offline so we can debug the problem. - erik
[9fans] Nupas truncated e-mail
Hello, A few months ago I made the switch to nupas and generally I'm very satisfied with it. Sometimes, however, attachments don't get recognised properly. My first thought was that the mailer was doing some nonstandard stuff, but some preliminary diagnostics brought some even more surprising results: % cat /mail/fs/mbox/99/unixdatesec 1236524327.00 % ls -l /mail/box/mn/mbox/1236524327.00 --r M 226874 mn mn 352001 Mar 9 15:33 /mail/box/mn/mbox/1236524327.00 % cmp /mail/box/mn/mbox/1236524327.00 /mail/fs/mbox/99/rawunix EOF on /mail/fs/mbox/99/rawunix after 335937 bytes I probably won't have much time dig much deeper until the weekend, but if anyone knows what's going on or could give a hint where to look first, any input is appreciated. The old upas didn't show that behaviour. Regards, Martin PS: I realise, the actual e-mail in question could be helpful. However, in this case some pretty personal data is involved and quite a few people would be less than amused if I was to share this with the whole interwebs.
Re: [9fans] nupas failure
On Mon Feb 23 14:03:05 EST 2009, aku...@mail.nanosouffle.net wrote: > Hugo Rivera's (uai...@gmail.com) latest post to 9fans on Feb 23, 07:42 > PDT, repeatedly causes nupas (using nupas/Mail in Acme) to crash with > "unexpected line:" messages. are you running the latest upas/fs/imap.c? it's been recently updated. - erik
[9fans] nupas failure
Hugo Rivera's (uai...@gmail.com) latest post to 9fans on Feb 23, 07:42 PDT, repeatedly causes nupas (using nupas/Mail in Acme) to crash with "unexpected line:" messages. ak
Re: [9fans] nupas mk install bug
thanks for the report. can you send me a snap(6) of the broken process? - erik
Re: [9fans] nupas mk install bug
/n/sources/contrib/quanstro/src/imap.c? replace fs/imap.c with this file and recompile. I found one in /n/sources/contrib/quanstro/imap.c and used that and it worked 99% I got a panic (attached) but when I tried to reproduce it the message had gone. It was a notice from ebay but none of my other ebay notices would trigger it. I big thank you. I'll be using it daily from now on so I'll keep an eye on it. matt term% acid 1508 /proc/1508/text:386 plan 9 executable /sys/lib/acid/port /sys/lib/acid/386 acid: lstk() abort()+0x0 /sys/src/libc/9sys/abort.c:6 _assert(s=0x3a9c3)+0x3a /sys/src/libc/port/_assert.c:12 parse(m=0xcbb38,mb=0x59ae0,addfrom=0x0,justmime=0x1)+0x83 /usr/maht/nupas/fs/mbox.c:578 parseattachments(m=0x90750,mb=0x59ae0)+0xee /usr/maht/nupas/fs/mbox.c:443 p=0xe6b00 nm=0xcbb38 l=0x90850 i=0x0 x=0x90750 parsebody(m=0x90750,mb=0x59ae0)+0x1c0 /usr/maht/nupas/fs/mbox.c:553 l=0x15 s=0x988e8 nm=0x93dbc parse(m=0x90750,mb=0x59ae0,addfrom=0x1,justmime=0x0)+0x66 /usr/maht/nupas/fs/mbox.c:582 cachebody(mb=0x59ae0,m=0x90750)+0x1db /usr/maht/nupas/fs/cache.c:495 o=0x1000 fileinfo(mb=0x59ae0,m=0x90750,t=0x0,pp=0xdfffebbc)+0xe3 /usr/maht/nupas/fs/fs.c:444 len=0x p=0x935a8 e=0x4478 i=0x4478 mkstat(m=0x90750,mb=0x59ae0,d=0xdfffebf0,t=0x0)+0xfa /usr/maht/nupas/fs/fs.c:748 p=0x4341c readmsgdir(f=0x93fd8,buf=0x511f8,blen=0x2000,off=0x0,cnt=0x2000)+0x44 /usr/maht/nupas/fs/fs.c:1109 n=0x0 pos=0x0 d=0x0 i=0x0 msg=0x587dc rread(f=0x93fd8)+0x191 /usr/maht/nupas/fs/fs.c:1173 off=0x0 cnt=0x2000 n=0x17 p=0x93fd8 t=0x13 io()+0x1c8 /usr/maht/nupas/fs/fs.c:1505 n=0x18 main(argv=0xdfffef7c,argc=0x0)+0x320 /usr/maht/nupas/fs/fs.c:395 mboxfile=0xdfffef95 nodflt=0x0 srvpost=0x0 v=0xdfffef74 _argc=0x66 _args=0x3e386 p=0x3 maildir=0x69616d2f mbox=0x0 srvfile=0x0 _main+0x31 /sys/src/libc/386/main9.s:16 acid:
Re: [9fans] nupas mk install bug
> when I access the imap version of http://fastmail.fm/ > I've tried it on two mailboxes, it does this command > 9x4 uid fetch 1:* (uid rfc822.size internaldate) > then fails parsing the repsonses thanks for the bug report. i signed up for fastmail.fm to figure out what's going on. there were two independent failures. first, fastmail.fm takes the unusual step of reordering the requested fields. the response parser wasn't able to deal with that. simple fix. the second problem was parsing a list of flags in the return. we didn't ask for flags, but fastmail sent 'em anyway. this part of the fix seems solid, but needs a little more testing. since it's not working for you at all, would you try /n/sources/contrib/quanstro/src/imap.c? replace fs/imap.c with this file and recompile. - erik
Re: [9fans] nupas mk install bug
On Fri Feb 6 09:17:01 EST 2009, mattmob...@proweb.co.uk wrote: > mk install > ... snip ... > cp 8.out /386/bin/nupas/Mail > cp: can't create /386/bin/nupas/Mail: '/386/bin/nupas' does not exist i may be wrong, but that is intentional. i don't know of other plan 9 programs that make their own bin when installed. > 9x4 uid fetch 1:* (uid rfc822.size internaldate) > > then fails parsing the repsonses > > of the form > > * 99 FETCH (UID 32768 INTERNALDATE " 6-Feb-2009 08:52:33 -0500" > RFC822.SIZE 74193) interesting. there's nothing that looks obviously wrong with that line. it must already be out of step. would you mind applying this edit imap.c:1085,1091 - /n/sources/contrib/quanstro/src/nupas/fs//imap.c:1085,1090 } imap = emalloc(sizeof *imap); - imap->flags |= Fdebug; imap->fd = -1; imap->freep = path; imap->flags = flags; and sending along the debugging output? it's going to be a bit chatty. thanks. - erik
[9fans] nupas mk install bug
mk install ... snip ... cp 8.out /386/bin/nupas/Mail cp: can't create /386/bin/nupas/Mail: '/386/bin/nupas' does not exist works ok when I access my Courier server but aborts on nupas/fs/fs.c:157 when I access the imap version of http://fastmail.fm/ I've tried it on two mailboxes, it does this command 9x4 uid fetch 1:* (uid rfc822.size internaldate) then fails parsing the repsonses of the form * 99 FETCH (UID 32768 INTERNALDATE " 6-Feb-2009 08:52:33 -0500" RFC822.SIZE 74193) That's as far as I got :> Matt
[9fans] nupas update
i pushed a new version of nupas out to /n/sources/contrib/quanstro/src/nupas. the upas/fs and delivery system have been significantly hardened since last time i mentioned it. i pushed man pages for mdir and splitmbox (as well as the splitmbox script) to the bits directory. nupas still installs itself to /$objtype/bin/nupas so you will need to modify mknupas to install it as the default mail system. imap4d has come around quite nicely and seems to be largely agreeing with apple mail and firefox. limiting testing with outlook and opera has been successful. mail boxes with spaces, as silly email clients are wont to create are supported even with fs not supporting spaces in file names. (my apologies.) (most of the problem was with the LIST and LSUB commands which i found never worked correctly for some common queries. e.g. "lsub inbox*".) while migration is not complete, nupas does have users with mailboxes with as many as 8,500 messages and as large as 1GB. questions and comments welcome. - erik
