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 it
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
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 qu
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
> 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.
wh
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.
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).
fir
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
> 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
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
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 i
> 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
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 -
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 t
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, wha
>>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
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 mista
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 re
> 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 gent
> 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. Be
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 m
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
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 requirin
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
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 sys
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'r
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 o
>> 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
> 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 simplif
Isn't everything great until you see the bad side of it?
Stay technical, guys.
> 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
>> 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 o
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
> 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
Tha
> 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
>
> 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
> > 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 prob
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 prob
> 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.
> 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-
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 pr
> 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. r
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
union
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 poi
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 do
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, M
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
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 p
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 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
50 matches
Mail list logo
