[gentoo-dev] gentoo-x86-portage on the rsync mirrors
Hi! I'm the admin of rsync5.de.gentoo.org. For quite a while now (over a year, maybe even two or more), the gentoo-x86-portage rsync module has been deemed deprecated. Yet still the manual for setting up an rsync server says that it should be configured. I see about 1700 connections on my server per day. In the last few months I have seen these counts for syncs against gentoo-x86-portage: 22 2006/01 17 2006/02 4 2006/03 11 2006/04 2 2006/05 This tells me two things: First, there are still people out there who use it. They should be more explicitly discouraged from doing so. Second, while there are some people who use the module, there are so few that after all this time we should finally be able to get rid of the module. It hasn't served any useful purpose for months if not years. The only reason it has lingered so long is probably because it uses nearly no extra resources. What do you think? Regards, Tobias -- You don't need eyes to see, you need vision. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Carl - Carl Analyzes Rsync Logfiles v0.4
Hi! I've cleaned up the source of my logfile analyser (and delinted it alot). Also, it's now a Python distutils compatible distribution and I've even included an Ebuild for gentoo systems (in the unlikely case any of you has use for that ;)). It's available here: http://www.schwarzvogel.de/software-misc.shtml Checksums: MD5: 1979641096c005126ee316aab227e13a dist/carl-0.4.tar.gz SHA1: 1c54baa6435f6e5a411d7b6e7da56726dbc65814 dist/carl-0.4.tar.gz As soon as I find the time, it may also be available by svn. Have fun with it and don't hesitate to report bugs. Regards, Tobias admin of rsync5.de PS: For code clarity the obfuscation-mode is gone. If anyone really needs it, drop me a line and I'll see what I can do. pgp3KsfiBHs5E.pgp Description: PGP signature
Re: [gentoo-dev] GWN Comments
Hi! On Mon, 19 Jun 2006, Caleb Tennis wrote: > I'd like to propose some form of ability to post user comments > to GWN stories. I suppose a full blown CMS system would work, > but for the ease of time I'm suggesting that perhaps we open up > a GWN section on the forums and post the text of the GWN (or > perhaps each section) in a new thread each week and allow users > to write comments. I think opening up this venue of feedback > would let users more readily tell us what they're interested > in, and it would allow GWN contributors/editors/etc to see some > of the fruits of their labors. > > Any comments? Principally, I agree (though I'd also rather go with the blog approach as Patrick suggested). One point though: commenting only being possible after registration may cut down on the spam (both commercial and vandalism), but it also raises the bar for legitimate comments. I'm not saying there should be no hurdle, it's just that it should be thought of/decided beforehand. Regards, Tobias -- You don't need eyes to see, you need vision. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GWN Comments
Hi! On Mon, 19 Jun 2006, George Prowse wrote: > >> I'd like to propose some form of ability to post user comments > >> to GWN stories. I suppose a full blown CMS system would work, > >> but for the ease of time I'm suggesting that perhaps we open up > >> a GWN section on the forums and post the text of the GWN (or > >> perhaps each section) in a new thread each week and allow users > >> to write comments. I think opening up this venue of feedback > >> would let users more readily tell us what they're interested > >> in, and it would allow GWN contributors/editors/etc to see some > >> of the fruits of their labors. > >> > >> Any comments? > > > >Principally, I agree (though I'd also rather go with the blog > >approach as Patrick suggested). One point though: commenting only > >being possible after registration may cut down on the spam (both > >commercial and vandalism), > > You have to register for a forums as well (usually) and if it were > made part of Gentoo's forums then there would be no need for extra > moderators. Okay, I put it a bit strangely. What I meant was that a blog does not need registration (if it has sufficient anti-spam measures). A forum usually does. > >but it also raises the bar for legitimate comments. > > Again, the thread system of forums allows for easier viewing of comments. Easier than a blog? I beg to differ. Does a forum have an RSS feed I can subscribe to? A blog puts more emphasis on the order of articles (in time) than a forum does. So I'm leaning towards a blog. > >I'm not saying there should be no hurdle, it's just that it > >should be thought of/decided beforehand. > > Personally I think discussions in a wiki get more difficult the longer > the discussion carries on, also i think the ability to get an email > after comments have been made on a thread is a *big* advantage over > the wiki style. Oh, I wasn't suggesting using a wiki. One probably could make a wiki work the way needed here, but I think using a blog (or forums) is far easier. > It would be easier to clean up and cut down on vandalism because GWN > contributors and authors could have an ability to moderate said forum > and delete threads once they have been used or discarded. Well, moderators on a blog could do that too: most blogs allow comments to be closed for articles older than a set number of months/weeks. Regards, Tobias -- You don't need eyes to see, you need vision. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] packages up for grabs
Hi! On Sat, 31 May 2008, Philip Webb wrote: > 080531 Mike Frysinger wrote: > > many of these are low maintence ... > > i'd forgotten i was even listed under them > > as i havent seen a bug report in a long time. > > some i added (well probably too many) on a lark, > > so if they do end up being crappy and no one cares, > > i guess that's why we have a tree cleaners group. > ... > > net-misc/ntp > > This is rather basic, isn't it ? It keeps your clock accurate. > Is there any alternative ? Yes, net-misc/openntpd and net-misc/chrony are alternatives. Regards, Tobias -- fs_dprintk (FS_DEBUG_INIT, "Ha! Initialized OK!\n"); linux-2.6.6/drivers/atm/firestream.c -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Linux 2.6.28 stable plans
Hi!
On Thu, 25 Dec 2008, Daniel Drake wrote:
> 2.6.28 is out, happy holidays..
I'd be happier if well, see below.
> The usual things:
>
> 1. Bugs in non-kernel packages in the stable tree that appear due to this
> upgrade are tracked at bug #252467
>
> 2. Tentative stable date is January 15th, will be held back if we have bad
> kernel regressions etc, but jan 15th is the aim. If your package breaks due
> to this upgrade, it's your responsibility to fix this in the stable tree
> before this date. You can ask me for help. As long as it's gone jan 15th,
> your broken packages will not hold back the kernel from going stable...
All .28 series kernels (all rc kernels and the final one, too) do
not compile on Alpha at all. We reported this when rc1 came out
and the culprit and a possible solution were discussed[0], but
nothing materialized. I re-triggered this on bugzilla today[1],
hoping it will be fixed soon. Until then, vanilla .28 is unusable
on alpha.
> 3. Who's brave enough to put ext4 on / ? :)
I'll be trying that as soon as I find the time (read: somewhere
around summer 2015 if nothing gets added to my work-pile :))
Regards & Happy End-of-year stuff,
Tobias
[0] http://www.nabble.com/-ALPHA--2.6.28-rc-fails-to-compile-td20223847.html
[1] http://bugzilla.kernel.org/show_bug.cgi?id=12289
--
panic("CPU too expensive - making holiday in the ANDES!");
linux-2.2.16/arch/mips/kernel/traps.c
[gentoo-dev]
Hi,
glibc 2.9 uses a different way to implement getaddrinfo() which
triggers a race condition in most (if not all) Netfilter
firewalls that use connection tracking. glibc does nothing wrong
per se, it just triggers the condition. (technical details here:
http://marc.info/?l=linux-netdev&m=123304473331445)
Since glibc 2.9 fires off two udp packets (a query for the A
record and one for the record), a race condition is
triggered in Netfilter (see URL). This has been acknowledged by
several people and I can reproduce it (relatively) reliably in
our LAN with all Gentoo boxes that have 2.9.
Why am I bringing this up here? Well, I figure that eventually,
2.9 (or some other version with equivalent code) will become
stable and we'll get lots of bug reports from people who run into
this. Since they can not simply backdate to 2.7 for various
reasons *and* they might be unable to fix a packetfilter (because
it might not be their own), this might become very ugly.
The Kernel/Netfilter devs (probably) are aware now of the issue
since I mailed them - but it's not all that easy to fix. On top
of that, even if it was fixed in (say) 2.6.28.3 and 2.6.29, this
does not mean that it's deployed out there and it might be very
hard for our users to get some firewall guy to update their
kernel when this is perceived as glibc's or our fault (plus the
widespread "ricer" clich� about Gentoo users; I've gotten an
idiotic reply to that effect already).
I don't have any experience with glibc upstream but pestering
them about this out of the blue might only cause a flame war
between kernel and glibc folks. Thus, I'm asking you, my fellow
devs (and the glibc and kernel teams specifically), what you
think is the best idea/course of action.
Regards,
Tobias
(Blackb|rd)
--
printk("Cool stuff's happening!\n")
linux-2.4.3/fs/jffs/intrep.c
Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9
Hi!
(fixed the subject)
On Tue, 27 Jan 2009, Peter Alfredsen wrote:
> [Mike: This looks like your field of expertise]
> On Tue, 27 Jan 2009 16:47:50 +0100
> Tobias Klausmann wrote:
>
> > glibc 2.9 uses a different way to implement getaddrinfo() which
> > triggers a race condition in most (if not all) Netfilter
> > firewalls that use connection tracking. glibc does nothing wrong
> > per se, it just triggers the condition. (technical details here:
> > http://marc.info/?l=linux-netdev&m=123304473331445)
> [...]
> > I don't have any experience with glibc upstream but pestering
> > them about this out of the blue might only cause a flame war
> > between kernel and glibc folks. Thus, I'm asking you, my fellow
> > devs (and the glibc and kernel teams specifically), what you
> > think is the best idea/course of action.
>
> The connection with IPv6 leads me to believe that this is
> http://bugs.gentoo.org/250468
> http://sourceware.org/bugzilla/show_bug.cgi?id=7060
I doubt it: sometimes the lookups work, as this race is very
timing-critical. When experimenting, I had to go below 50
microseconds between the two packets to actually trigger it plus
the forwarding machines always were multicore. Also, the content
is irrelevant. I implemented this myself sending the payloads
with sendto() and it didn't matter if I sent the A or query
first.
That said, without seeing a tcpdump from those people with the
error described in those two bugs, I can not rule it out.
On the wire between the client and the firewall, this happens:
a packet 1 is sent
b packet 2 is sent
c answer 1 is received
d answer 2 is received
Sometimes d doesn't happen because b is lost in the firewall
along the way (where the race condition happens).
> Mike has added a patch to Gentoo's patchset but hasn't bumped the
> revision yet. It does look spectacularly hacky, though :-)
>
> Anyway, if this is your problem, it looks like upstream is already
> working on it and that we just need to *prod* Mike a bit to get a fix
> into the tarball.
The bug is in the kernel, not glibc. The latter just triggers it
because the newer resolver has a more aggressive timing. Note
that I think that what the glibc guys did is a *good* idea. It
just happens to rub Netfilter the wrong way.
Regards,
Tobias
--
printk("Cool stuff's happening!\n")
linux-2.4.3/fs/jffs/intrep.c
Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9
Hi! On Wed, 28 Jan 2009, Mike Frysinger wrote: > > On the wire between the client and the firewall, this happens: > > > > a packet 1 is sent > > b packet 2 is sent > > c answer 1 is received > > d answer 2 is received > > > > Sometimes d doesn't happen because b is lost in the firewall > > along the way (where the race condition happens). > > does this affect actual userspace behavior ? in other words, > does this lead to lost lookups and errors from the resolver ? The most visible effect (and the way we found out about it first) is a 5s hang on ssh connects. Thing is: how long that timeout is is program dependant (whatever they use in select()). A recvfrom() simply hangs. I wrote a simple C program to do what glibc does (simplified for brevity): sockfd = socket(AF_INET, SOCK_DGRAM, IPPROTO_IP); connect(sockfd, tgt->ai_addr, tgt->ai_addrlen); sendto(sockfd, payload1, sizeof(payload1), 0, tgt->ai_addr, tgt->ai_addrlen); sendto(sockfd, payload2, sizeof(payload2), 0, tgt->ai_addr, tgt->ai_addrlen); recvfrom(sockfd, buf, sizeof(buf), 0, &addr, &fromlen); recvfrom(sockfd, buf, sizeof(buf), 0, &addr, &fromlen); payload1 and 2 are an A and a request for the same name, respectively. That second recvfrom() hangs indefinitely in the error case. Here's the full program for those interested: http://eric.schwarzvogel.de/~klausman/dnstest2.c.txt It'd be easy to put in a call to select and make the program timeout as glibc does instead of simply hanging. Note that for an actual test in your environment, you'll probably have to change the payloads and line 44. Here's the tcpdump of the error case: 09:42:53.614905 IP 192.168.0.2.39355 > 192.168.22.9.53: 64583+[|domain] 09:42:53.614920 IP 192.168.0.2.39355 > 192.168.22.9.53: 61812+[|domain] 09:42:53.615623 IP 192.168.22.9.53 > 192.168.0.2.39355: 64583[|domain] Or, if you prefer tshark: 0.00 192.168.0.2 -> 192.168.22.9 DNS Standard query A eric.schwarzvogel.de 0.15 192.168.0.2 -> 192.168.22.9 DNS Standard query eric.schwarzvogel.de 0.000667 192.168.22.9 -> 192.168.0.2 DNS Standard query response A 194.97.4.250 As you can see, timing on the two queries is very close. glibc usually is in the 20-50 microsecond range on this machine, my little program can get as low as 5 microseconds. "Correct" timing of course depends on a myriad of variables including load on the packetfilter, kernel version there etc etc. A "quickfix" would indeed be using two different ports for the queries - but the bug in Netfilter would still be there. Regards, Tobias
Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9
Hi! On Thu, 29 Jan 2009, Mike Frysinger wrote: > > The most visible effect (and the way we found out about it > > first) is a 5s hang on ssh connects. > > this is why i turn off dns lookup in all my sshd_config's > (well, not because of this bug, but because DNS lookup on ssh > can cause annoying delays). plus, that info is largely > useless: for the logged attempts from "bad" people, the dns is > usually screwed up / wrong / unavailable anyways. It's not on the daemon side but the client side. If you don't want to remember the IPs of all the hosts you might want to ssh into (at close to 3000, I don't), the client will have to make DNS lookups. Those are what delays the connection. > > Thing is: how long that timeout is is program dependant > > (whatever they use in select()). A recvfrom() simply hangs. I > > wrote a simple C program to do what glibc does (simplified > > for brevity): ... > > so glibc will not trigger hangs, just delays in some cases. Yup. Still: write a wrapper around ssh that will delay connects by five seconds on 50% of the cases. Use it for two or more weeks at work. That's how annoying it really is. > > A "quickfix" would indeed be using two different ports for the > > queries - but the bug in Netfilter would still be there. > > sure, the bug still exists in netfilter (kernel). but if we > can easily mitigate the effects seen by applications using > glibc's resolver code, that seems sane to me. i havent perused > the glibc resolver code in a while ... do you know if it can > easily be tweaked to use different ports, or would such a > change be invasive ? if the latter, well i guess we'll have to > suck it up. I tried understanding what glibc 2.9 does regarding dns lookups, but since it involves a rather complex (and probably quite clever) queueing mechanism, I'm not quite sure I wouldn't break more than I fix in doing so. Regards, Tobias
Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9
Hi! On Thu, 29 Jan 2009, Tobias Klausmann wrote: > I tried understanding what glibc 2.9 does regarding dns lookups, > but since it involves a rather complex (and probably quite > clever) queueing mechanism, I'm not quite sure I wouldn't break > more than I fix in doing so. Apparently, it's enough to not export gethostbyname4() to fix this. I'll try building a glibc-2.9_p20081201-r1 plus this patch: http://pasky.or.cz/~pasky/dev/glibc/glibc-2.10-dns-no-gethostbyname4.diff If it works, I'll test drive it for a while and report back. Regards, Tobias -- if(ct<0) ct=2;/* Shit happens.. */ linux-2.6.6/drivers/net/wan/z85230.c
Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9
Hi!
On Mon, 02 Feb 2009, Tobias Klausmann wrote:
> If it works, I'll test drive it for a while and report back.
I've been running a patched glibc-2.9_p20081201-r1 for a week
now. Nothing broke and I've been unable to trigger the lost
packet syndrome by using getaddrinfo(). I was still able to
produce it by sending UDP packets myself, but that was to be
expected.
So in essence, the patch I mentioned "works". We could use it
should we want to have a glibc 2.9. On the bug mentioned earlier
(where I got the patch from), one of the glibc guys mentions that
more work is planned for the resolver part of glibc, so this
whole ordeal may pass us.
Regards,
Tobias
--
printk("NONONONOO\n");
linux-2.6.6/drivers/atm/zatm.c
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Hi!
My preference, most wanted to least wanted:
- inside the ebuild
If it's not too much pain. Yes, that is a very subjective
metric and it's what a large amount of flames has been about.
- in the filename, but not as a tail
eg: foo-2.3.4-r2+9.build
yes, alternate separators might be better.
I like .build very much, though. What does the e in ebuild
stand for anyway?
- in the filename, as a tail
eg: foo-2.3.4.ebuild-9
I don't like this much, but it's better than never having EAPI
versioning.
Regards,
Tobias
--
printk("Cool stuff's happening!\n")
linux-2.4.3/fs/jffs/intrep.c
Re: [gentoo-dev] stupid ebuild question
Hi!
On Tue, 21 Apr 2009, Greg KH wrote:
> So, I do the following:
> src_install() {
> dodir /lib/firmware
> cp -R "${S}/*" "${D}lib/firmware/" || die "Install failed!"
> }
>
> but that fails badly:
> >>> Install linux-firmware-20090421 into
> /var/tmp/portage/sys-kernel/linux-firmware-20090421/image/ category sys-kernel
> cp: cannot stat
> `/var/tmp/portage/sys-kernel/linux-firmware-20090421/work/linux-firmware-20090421/*':
> No such file or directory
>
> Yet the files are really in that directory.
>
> I can't drop the trailing "*" on the cp command, otherwise we get the
> directory name that the firmware was expanded into during unpack into
> lib/firmware/.
>
> So, anyone want to apply the cluestick?
I don't see an error off the top of my head. What about writing
"echo" or "einfo" in front of the cp line so you see what the
expanded commandline is? An ls -l{,d } "${D}lib/firmware/" in the
same spot might be insightful, too.
Regards,
Tobias
--
printk(KERN_ERR "i82092aa: Oops, you did something we didn't think of.\n");
linux-2.6.19/drivers/pcmcia/i82092.c
Re: [gentoo-dev] Retiring
Hi!
On Tue, 05 May 2009, Markos Chandras wrote:
> Arch teams, according to their project pages, are in a good shape. Major
> arches have enough people ( assuming that the project pages are up2date )
If I keel over and armin76 is stuck in work/'versity, the alpha
dev count is 0. Not exactly good, but we manage. I'm in the
process of recruiting an archtester and he may become a dev one
day.
That said, more feedback from /users/ regarding alpha would be
appreciated, but I doubt -dev@ is the best place to look for it
;)
Regards,
Tobias
(aka Blackb|rd on IRC)
--
panic("smp_callin() a\n");
linux-2.6.6/arch/parisc/kernel/smp.c
Re: [gentoo-dev] Project summaries - Alpha Arch Team
Hi! So where are we at with alpha currently? Xorg-1.5 As some of you know, xorg-1.5 abandoned the "classic" way of interfacing with PCI and AGP cards in favor of using libpciaccess. That, in turn expects support from the kernel in the form of /sys/devicesresourceN files. Unfortunately, alpha until recently hat no support for those PCI resources (which is partly due to the way alpha IO space is structured and partly due to a crucial extension not being available on old Alphas (older than EV5). As such, we weren't able to keyword or stabilize Xorg-1.5 until recently, when 2.6.30-rc* saw support finally being added. Naturally, packages depending on >=xorg-1.5 had to be held off, too. The -rc kernels are keyworded ~alpha so people can test. So far, -rc3 and rc4 are looking good, so we will keyword xorg and deps soon (I'm aiming for this weekend) and if all goes well, we will have it stable, soon. Note that this will mean that people with EV4-Alphas will *not* be able to use Xorg-1.5 just now. I feel that those machines are so slow that very few will run X11 anyway, if there are Gentoo installations on those to start with. Glibc/Toolchain --- Glibc has had a bug for ages (regarding ceil() and friends, bug number 264335) which should really be fixed. Upstream is umm.. their usual selves about it. On top, a patch for fdatasync() (bug 264336) is available which upstream... well, you get it. Workload Currently, the alpha arch team consists of me (the nominal lead) and armin76 who helps a lot with getting stable request answered in a timely manner. Also, we're in the process of recruiting mattst88 as an arch tester. He's currently deep in exam-land at university, so the process is on hold for now. Users/Community --- Aside from those on the team and one or two other devs, I've had little to no direct feedback from Gentoo alpha users. I try to write about Alpha regularly on my blog (available on the planet) and I'm easily reachable as Blackb|rd on Freenode (#gentoo-alpha, naturally). I've been toying with the idea of offering something akin to Debians popularity contest tool. Some people are rather uncomfortable with data gathering tools that send stuff to some strangers, so I don't know how well it would work. I list this idea here, since I have just about no idea what actual alpha hardware is used with Gentoo out there. Knowing which packages are actually *used* (instead of just being stabilized for the heck of it) would be nice. Added benefit of that would be that users helping with testing would reduce workload. In essence: we're busy and I'd love to get more feedback what people (both users and devs) think we could do better, or more/less of. Regards, Tobias, who turned 42 in octal today -- The only problem with troubleshooting is that sometimes, trouble shoots back.
Re: [gentoo-dev] The fallacies of GLEP55
Hi! On Fri, 15 May 2009, Ciaran McCreesh wrote: > > eval `grep '^EAPI=' ebuildfile | head -n 1` > > > > will set EAPI in the current scope to EAPI in the ebuild, without > > sourcing it, unless the issue with something like this would be its > > use of grep and head, but these are both in the system set, so unless > > you don't want to depend on the system set, I don't know what the > > objection would be. > > The objection is that your code doesn't work. It's entirely legal to > do, say: > > export EAPI="1" Change the spec, then. Or aren't we talking about writing/changing/clarifying a spec right now? I mean... yes, ebuilds are actually bash scripts. But I don't see a problem with using a subset of what's allowed for *this* *specific* line. Actually, I personally would prefer taking it out of the parsed-by-bash part entirely. Add it as a shebang-like line at the top: #EAPI-1 as the first or second line. Allowing it on the second line allows you to later bolt on a true shebang-line if you should so desire. Only having to look at the first two lines makes finding it out easier (note that I don't call that parsing on purpose). > or: > > inherit versionator > > if version_is_at_least 2 ; then > EAPI="2" > else > EAPI="0" > fi I was under the impression that it's illegal to change/set the EAPI after using inherit. Regards, Tobias -- Found on a small utility knife in MIT's lab supply: "Caution. Blade is sharp. Keep out of children."
Re: [gentoo-dev] The fallacies of GLEP55
Hi! On Sat, 16 May 2009, Ciaran McCreesh wrote: > On Sat, 16 May 2009 11:27:10 +0200 > Tobias Klausmann wrote: > > Change the spec, then. > > If we change the spec, we can't do anything with the change until we're > absolutely sure that everyone's updated both their ebuilds and their > package manager for it. The change the extension *once*, and make an EAPI spec at the top of the file for that file format. I'd rather have the extension change once, with pain, than with every EAPI change. My opinion is that reflecting the EAPI in the file name is a very, very Bad Idea. > > Actually, I personally would prefer taking it out of the > > parsed-by-bash part entirely. Add it as a shebang-like line at > > the top: > > > > #EAPI-1 > > > > as the first or second line. Allowing it on the second line > > allows you to later bolt on a true shebang-line if you should so > > desire. Only having to look at the first two lines makes finding > > it out easier (note that I don't call that parsing on purpose). > > Would mean we'd have to change every existing ebuild everywhere. No, it means we have to change every ebuild of which we claim that it works that way. Versioned file structures *without* changing the extension have been done and they have worked. Yes, there may be pain along the way. But that is true no matter which route we go. What people prefer is in no small way tied to the amount of pain they expect from a given solution. And they're right to do so. Regards, Tobias -- Found on a small utility knife in MIT's lab supply: "Caution. Blade is sharp. Keep out of children."
Re: [gentoo-dev] The fallacies of GLEP55
Hi! On Sat, 16 May 2009, Ciaran McCreesh wrote: > On Sat, 16 May 2009 17:32:24 +0200 > Tobias Klausmann wrote: > > On Sat, 16 May 2009, Ciaran McCreesh wrote: > > > On Sat, 16 May 2009 11:27:10 +0200 > > > Tobias Klausmann wrote: > > > > Change the spec, then. > > > > > > If we change the spec, we can't do anything with the change until > > > we're absolutely sure that everyone's updated both their ebuilds > > > and their package manager for it. > > > > The change the extension *once*, and make an EAPI spec at the top > > of the file for that file format. > > That doesn't let us do version format changes. What exactly is _needed_ there? EAPI versions could be arbitrary strings without \n in them. I see nothing you couldn't get into that. Or are we talking about the *ebuild* versions? I see that as different matter. Plus: You could change the version format with the changed extension. I sure do hope there are no plans on making those changes as often as new EAPIs. Regards, Tobias -- Found on a small utility knife in MIT's lab supply: "Caution. Blade is sharp. Keep out of children."
Re: [gentoo-dev] The fallacies of GLEP55
Hi! On Sat, 16 May 2009, Ciaran McCreesh wrote: > On Sat, 16 May 2009 17:43:32 +0200 > Tobias Klausmann wrote: > > > That doesn't let us do version format changes. > > > > Or are we talking about the *ebuild* versions? I see that as > > different matter. Plus: You could change the version format with > > the changed extension. I sure do hope there are no plans on > > making those changes as often as new EAPIs. > > Yes, those. The current rules include some pointless arbitrary > restrictions that are only there for historical reasons and that mean > people have to mess with convoluted MY_PV things. Still: a sane spec for those plus a sane spec for inside-the-file EAPI specs can be done with/during *one* extension change. Any further features that mandate a change in filename format? Pile them on. Regards, Tobias -- Found on a small utility knife in MIT's lab supply: "Caution. Blade is sharp. Keep out of children."
Re: [gentoo-dev] The fallacies of GLEP55
Hi! On Sat, 16 May 2009, Ciaran McCreesh wrote: > Tobias Klausmann wrote: > > > Yes, those. The current rules include some pointless arbitrary > > > restrictions that are only there for historical reasons and that > > > mean people have to mess with convoluted MY_PV things. > > > > Still: a sane spec for those plus a sane spec for inside-the-file > > EAPI specs can be done with/during *one* extension change. > > GLEP 55's just one extension change: it moves from .ebuild > to .ebuild-EAPI. So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for EAPI=3 etc? That would just be silly and it was the first idea I got when I saw the proposal. Also, I think there might be better options for the new extensions (.gbuild?, just a random idea). Aside from that, one idea that came to me recently was to specify per tree what kind of files (version-format-wise, EAPI elsewhere[0]) a PM has to expect. Tree distributors (Gentoo itself, other similar distros, overlays... ) would be Providing that information along a similar route as profiles/repo_name. This would also reduce the amount of mixing and matching version formats (something undesirable, if you ask me). It would also make it easier to take a look at historical (snapshots of) repositories. [0] I see EAPI specification and version-format spec as separate issues. > > Any further features that mandate a change in filename format? > > Pile them on. > > There probably will be, and we don't know what they all are yet. > Unfortunately we can't see the future. I meant further as in "not discussed yet". Regards, Tobias -- Found on a small utility knife in MIT's lab supply: "Caution. Blade is sharp. Keep out of children."
Re: [gentoo-dev] The fallacies of GLEP55
Hi! On Sat, 16 May 2009, Ciaran McCreesh wrote: > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for > > EAPI=3 etc? That would just be silly and it was the first idea I > > got when I saw the proposal. > > Yes, yes we are. That's just one change, from a static string to a > pattern for a string. > > Heck, pretend GLEP 55 says .eapi-X.eb instead if it makes you happy. It doesn't. I forsee a non-trivial amount of extra work, breakage and pain with a moving extension. And not anywhere near enough benefit in exchange for it. > > Aside from that, one idea that came to me recently was to specify > > per tree what kind of files (version-format-wise, EAPI > > elsewhere[0]) a PM has to expect. Tree distributors (Gentoo > > itself, other similar distros, overlays... ) would be Providing > > that information along a similar route as profiles/repo_name. > > This would also reduce the amount of mixing and matching version > > formats (something undesirable, if you ask me). It would also > > make it easier to take a look at historical (snapshots of) > > repositories. > > It also means an end to nice incremental updates. I think wanting incremental updates for version specs is a dream we should abandon. The ordering issues avoided by doing so would justify it alone, if you ask me. Yes, that means having a flag day for every repository. But since I figure the new spec will be a superset of the old spec, that could be automated. As for EAPI, I feel we agree that it could live inside the file itself under this scheme. My point is this: from experience I suspect having a hard change once and having easy progress on either side of it is preferable to having mid-range complications all the time. > Well, I strongly doubt that anyone's already thought of all the useful > changes we might want to make in the future, so I don't think proposing > a solution that assumes that they have is a good idea. I think it's a river we should think about once we reach it. > Otherwise, in another year or two we'll just be back to "well we need > to change extensions again, but let's just do it as a second one-off > thing". My experience tells me that with proper preparation of *this* change, that can be pushed past the "in the next ten years" mark. And that is close enough to "indefinitely" for me. Regards, Tobias -- Found on a small utility knife in MIT's lab supply: "Caution. Blade is sharp. Keep out of children."
Re: [gentoo-dev] The fallacies of GLEP55
Hi! On Sat, 16 May 2009, Ciaran McCreesh wrote: > On Sat, 16 May 2009 18:31:38 +0200 > Tobias Klausmann wrote: > > On Sat, 16 May 2009, Ciaran McCreesh wrote: > > > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for > > > > EAPI=3 etc? That would just be silly and it was the first idea I > > > > got when I saw the proposal. > > > > > > Yes, yes we are. That's just one change, from a static string to a > > > pattern for a string. > > > > > > Heck, pretend GLEP 55 says .eapi-X.eb instead if it makes you happy. > > > > It doesn't. I forsee a non-trivial amount of extra work, breakage > > and pain with a moving extension. And not anywhere near enough > > benefit in exchange for it. > > Why? What's the big deal with .ebuild-? or .eapi-?.eb instead > of .ebuild? One that you illustrate yourself: what aboud .eapi-11.eb or .ebuild-11? What if you want to be able to choos EAPI names more freely? > > I think wanting incremental updates for version specs is a dream > > we should abandon. > > It's an easy goal that we can deliver without much work. Ignoring it, > on the other hand, means holding Gentoo back unnecessarily every time > we want to change something. And on the "without much work" we disagree wildly. I think it creates more trouble than it's worth. Being an opinion, it's up for change, naturally. > > My point is this: from experience I suspect having a hard change > > once and having easy progress on either side of it is preferable > > to having mid-range complications all the time. > > .ebuild-? is not complicated. Oh, it adds a variable portion to something that's otherwise static. globregex classic *.ebuild.*\.ebuild \.ebuild$ pms-style *.ebuild-* .*\.ebuild-[0-9]+ \.ebuild-[0-9]+$ The newer sort of extension is much more involved to get *really* right in patterns. Globs and regexen are only the two most popular examples. On top of that, other domains that are involved with ebuilds will be more complex (and complicated) by a variable file extension. And it's not just the command line for users. All code that handles these files (yet probably doesn't even care about their contents) needs to become more complex. For all those who think they are regex wizzes: create a regex that can tell properly formatted email-addresses from improper ones. From scratch; heeding all RFCs. And no googling! > > > Well, I strongly doubt that anyone's already thought of all the > > > useful changes we might want to make in the future, so I don't > > > think proposing a solution that assumes that they have is a good > > > idea. > > > > I think it's a river we should think about once we reach it. > > Why? We know we'll reach it. Pretending we won't just means when we do > reach it, we'll still be crossing it on foot rather than in a > helicopter. Every metaphor only goes so far, so I'll abandon it for now. When we reach a point where we will need another change, we can make an informed decision. Now, we can only guess what might need change. As such, it's very difficult to create a system of easy updates that cover all possibilities. > > > Otherwise, in another year or two we'll just be back to "well we > > > need to change extensions again, but let's just do it as a second > > > one-off thing". > > > > My experience tells me that with proper preparation of *this* > > change, that can be pushed past the "in the next ten years" mark. > > And that is close enough to "indefinitely" for me. > > The only way it'll be "in the next ten years" rather than "in the next > two years" is if Gentoo continues its current approach of making > changes require every single person to agree... There is such a things as too much change too quickly. And even if we take that 2 years number: do *you* know what changes we might need in two years? I suspect not. Neither do I (or just about anybody else). I just think the hoops we have to jump through now to tackle hypothetical problems in two (or ten) years aren't worth it. -- Found on a small utility knife in MIT's lab supply: "Caution. Blade is sharp. Keep out of children."
Re: [gentoo-dev] The fallacies of GLEP55
Hi! On Sat, 16 May 2009, Ciaran McCreesh wrote: > Tobias Klausmann wrote: > > > Why? What's the big deal with .ebuild-? or .eapi-?.eb instead > > > of .ebuild? > > > > One that you illustrate yourself: what aboud .eapi-11.eb or > > .ebuild-11? > > Then you include those in your static list not using patterns that > deals with them. I'm unable to parse this sentence. > > What if you want to be able to choos EAPI names more > > freely? > > Not a problem. We used .kdebuild-1 rather than .ebuild-kdebuild-1 for > kdebuild, for example. Which makes the whole thing more obscure. Are those templates for proper Ebuilds? Or maybe something KDE invented and accidentally chose a strange name for? The kdebuild example is of limited use: very few people outside the original project ever got in contact with it. That does not hold true for good ol' ebuilds. As such, the confusiong by the ever-mutation file extension would be much broader if we did that to the classic portage tree and overlays. > You shouldn't be writing anything that even tries to look at any EAPI > you don't support. You should be using a static list of file > extensions, not a pattern. Not every piece of code dealing with ebuilds does care about EAPI /at all/. And it needn't. There is just no way I can do this with your proposal: find /usr/local/portage -iname foobar\*ebuild -print Or it won't be as easy, at least. > > There is such a things as too much change too quickly. And even > > if we take that 2 years number: do *you* know what changes we > > might need in two years? I suspect not. Neither do I (or just > > about anybody else). I just think the hoops we have to jump > > through now to tackle hypothetical problems in two (or ten) years > > aren't worth it. > > That's my point -- I don't pretend to know what we'll need in the > future, so I don't advocate a solution that requires that we do know. And I don't pretend that I know a way to ensure that the change will be easy. So I advocate *not* going out of our way to comfort that possible Mother of All Changes. Don't get me wrong: I don't want to build format dead-ends into the package manager design specs, either. But I think the amount of work and hassle you want to pour into avoiding it outweighs the benefits, however speculative they may be. Regards, Tobias -- Found on a small utility knife in MIT's lab supply: "Caution. Blade is sharp. Keep out of children."
Re: [gentoo-dev] Baselayout 2 stabilisation todo
Hi!
On Fri, 22 May 2009, Dawid Węgliński wrote:
> Haven't tested it yet on my box, but i'd like to know if openrc
> handles 801.2Q support.
Near as I can tell, it does (some lines shortened for brevity):
[r...@sareth ~]# eix -Ic openrc
[I] sys-apps/openrc (0.4.3...@05/15/2009): OpenRC manages the services, startup
and shutdown of a host
[r...@sareth ~]# ip addr sh
[...]
2: eth0: mtu 1500 [...]
link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff
3: eth1: mtu 1500 [...]
link/ether 00:1e:0b:46:50:b8 brd ff:ff:ff:ff:ff:ff
4: eth0@eth0: mtu 1500 [...]
link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff
inet 192.168.2.166/28 brd 192.168.2.175 scope global eth0.381
inet 192.168.2.164/28 brd 192.168.2.175 scope global secondary eth0.381
inet 192.168.2.165/28 brd 192.168.2.175 scope global secondary eth0.381
5: eth0@eth0: mtu 1500 [...]
link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff
inet 192.168.3.102/24 brd 192.168.3.255 scope global eth0.146
6: eth0@eth0: mtu 1500 [...]
link/ether 00:1e:0b:46:50:ba brd ff:ff:ff:ff:ff:ff
inet 10.104.22.1/24 brd 10.104.22.255 scope global eth0.271
[r...@sareth ~]# grep -v '^#' /etc/conf.d/net
routes_eth0_381=("default via 192.168.2.161")
config_eth1=( "null" )
config_eth0=( "null" )
vlans_eth0="381 146 271"
config_eth0_381=(
"192.168.2.166/28"
"192.168.2.164/28"
"192.168.2.165/28"
)
config_eth0_146=("192.168.3.102/24")
config_eth0_271=("10.104.22.1/24")
Regards,
Tobias
--
panic("%s: CORRUPTED BTREE OR SOMETHING", __FUNCTION__);
linux-2.6.6/fs/xfs/xfs_bmap.c
Re: [gentoo-dev] Old eclasses - candidates for removal?
Hi! On Thu, 04 Jun 2009, Ulrich Mueller wrote: > Do we want to remove any of these? Have I missed other candidates? I think nobody uses the ccc.eclass (Compaq C Compiler) anymore. Also see bug 258153. There are very, very vague signs that CCC support for Alpha might come back, but not in the near or mid-term future. Rgeards, Tobias -- A fanatic is someone who does what he knows that God would do if God knew the facts of the case.
Re: [gentoo-dev] New eselect news item for X11 on alphas
Hi! See below. For a little more background: http://blog.i-no.de/archives/2009/06/28/index.html#e2009-06-28T13_54_50.txt Also note the glibc part of the same post. Maybe that'd warrant a news item, too? What do the toolchain guys think? As for my news item, what I'm not entirely sure about are the Displa-If- headers (What I'm aiming for is to reach people who have installed *either* xorg-x11 (and thus -server) or just xorg-server on any alpha profile) Also, the last paragraph might reek a bit of politics, but I'm quite comfortable with placing pressure on the Xorg guys via users. Title: xorg-x11-7.4 and xorg-server-1.5 kernel support Author: Tobias Klausmann Content-Type: text/plain Posted: Revision: 1 News-Item-Format: 1.0 Display-If-Installed: x11-base/xorg-x11 Display-If-Installed: x11-base/xorg-server Display-If-Profile: default-linux/alpha Display-If-Profile: default/linux/alpha Recent versions of xorg's X11 require kernel support to access PCI and AGP graphic cards. This support has only recently been added to the Linux kernel (vanilla-sources-2.6.30 and gentoo-sources-2.6.29-r5). Thus, you will need to run a recent enough kernel to use recent versions of X11 on an alpha. If you only start programs on your alpha, but the display is on another machine, no upgrade is necessary. Furthermore, not all graphics card drivers have been updated to work with the newer X server API. One example is the glint driver used for Permedia cards. The upstream developers have been informed about this, but nothing has happened so far. -- We are sorry, but the number you have dialed is imaginary. Please rotate your phone 90 degrees and try again.
Re: [gentoo-dev] New eselect news item for X11 on alphas
Hi! Thanks ulm and fauli, here is a new version: Title: xorg-x11-7.4 and xorg-server-1.5 kernel support Author: Tobias Klausmann Content-Type: text/plain Posted: Revision: 2 News-Item-Format: 1.0 Display-If-Installed: x11-base/xorg-server Display-If-Profile: default-linux/alpha Display-If-Profile: default/linux/alpha Recent versions of xorg's X11 require kernel support to access PCI and AGP graphic cards. This support has only recently been added to the Linux kernel (sys-kernel/vanilla-sources-2.6.30 and sys-kernel/gentoo-sources-2.6.29-r5). Thus, you will need to run a recent enough kernel to use recent versions of X11 on an alpha. If you only start programs on your alpha, but the display is on another machine, no upgrade is necessary. Furthermore, not all graphics card drivers have been updated to work with the newer X server API. One example is the glint driver used for Permedia cards. The upstream developers have been informed about this, but but no fixes are available yet, please see https://bugs.freedesktop.org/show_bug.cgi?id=21546 For a general guide to upgrading to Xorg 1.5, see the Gentoo upgrade guide: http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml
Re: [gentoo-dev] Re: New eselect news item for X11 on alphas
Hi! On Tue, 30 Jun 2009, Christian Faulhammer wrote: > Tobias Klausmann : > > > Revision: 2 > > This is only needed for an in-repo revision...so please leave it at 1. > > > but but no fixes are available yet, please see > > But but Imagine a trembling lower lip with that :) Fixed both, new version below. Thanks again. Title: xorg-x11-7.4 and xorg-server-1.5 kernel support Author: Tobias Klausmann Content-Type: text/plain Posted: Revision: 1 News-Item-Format: 1.0 Display-If-Installed: x11-base/xorg-server Display-If-Profile: default-linux/alpha Display-If-Profile: default/linux/alpha Recent versions of xorg's X11 require kernel support to access PCI and AGP graphic cards. This support has only recently been added to the Linux kernel (sys-kernel/vanilla-sources-2.6.30 and sys-kernel/gentoo-sources-2.6.29-r5). Thus, you will need to run a recent enough kernel to use recent versions of X11 on an alpha. If you only start programs on your alpha, but the display is on another machine, no upgrade is necessary. Furthermore, not all graphics card drivers have been updated to work with the newer X server API. One example is the glint driver used for Permedia cards. The upstream developers have been informed about this, but no fixes are available yet, please see https://bugs.freedesktop.org/show_bug.cgi?id=21546 For a general guide to upgrading to Xorg 1.5, see the Gentoo upgrade guide: http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml
Re: [gentoo-dev] [RFC] Changing default serial-console definition in inittab
Hi! On Fri, 27 Apr 2012, Diego Elio Pettenò wrote: > The current definition sets the console at 9600 baud, using vt100 > emulation; I think most of us who configure it, do so at 115200 baud, > and some prefer vt-utf8 over vt100 (the two are partially compatible as > far as I can tell). Also note that some embedded systems (Alix, for example) are not capable of 115200 baud, but top out at 38400 (which is already far better than 9600). Regards, Tobias -- printk(KERN_ERR "happy meal: Transceiver BigMac ATTACK!"); linux-2.6.19/drivers/net/sunhme.c
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
Hi! On Wed, 30 May 2012, Rich Freeman wrote: > On Wed, May 30, 2012 at 6:16 AM, Dirkjan Ochtman wrote: > > Yeah... this is why I was asking about access to infra to test the > > conversion; so far, I haven't had any replies, though. > > A mock conversion would probably help with creating > procedures/docs/etc as well. It is nice to say that we're "just going > to use git" but I think everybody has a slightly different picture of > how that is going to work. I recommend having a smallish set of willing alpha/beta testers for this. This usually helps with some of the near-edge cases. You'll still find a thousand other bugs once things go live for everybody. Still, it turns a million into a thousand. It also gives you slightly more realistic load test. > If we could set up an "official unofficial" portage tree in git based > on a one-time migration (maybe refreshing it from time to time) that > could be a sandbox used to work things out, and it would then be > replaced with the official tree. When the official migration comes > along we'd already be experts in doing it. This is a good idea that goes nicely with what I wrote above. > All we need to do is execute the migration, and just not point the > rsync generation process at it. Maybe it won't be perfectly right at > first, and that would basically be the point of doing it. Devs could > update tools to work against it, and the docs could be written > alongside. The scientist in me wonders how big the dent in productivity will be, actually. After all, there's going to be a lot of people that will hammer the new setup just because of the New! Shiny! appeal. Regards, Tobias
[gentoo-dev] Kernel compiles and you
Hi! Recently, I have again bumped into the question whether one should compile the kernel as root. One of the things that puzzles me is why almost every HowTo, blog post and book recommends building as non-root -- yet basically no distribution /helps/ the user with doing that. I've discussed this with a few people on #gentoo-dev and they've provided valuable insight (thanks AxS, Chainsaw and WilliamH), so I have gathered the results so far here: http://blog.i-no.de/archives/2012/07/index.html#e2012-07-04T19_28_32.txt Feel free to comment (ideally here). Note that I'm aiming for a solution that is not (overly) Gentoo-specific. Thanks, Tobias (aka Blackb|rd on Freenode) -- Sent from aboard the Culture ship GSV Just Read The Instructions
Re: [gentoo-dev] Kernel compiles and you
Hi! On Wed, 04 Jul 2012, Michał Górny wrote: > There's a very simple yet custom solution I'm using. Shortly saying: > checkout the kernel git to /usr/src/linux and chown to your user. As > far as it goes, it's superior to having kernel sources installed by > ebuilds. > > I just have to remember to do 'git fetch' from time to time and 'git > merge' whenever a new version is tagged. It is also beyond the package manager's control. That means users who want to just configure their kernel (and run point releases otherwise) have to actively check for new tags/versions. Aside from that the git tree is not exactly lightweight: my current 2.6 checkout weighs in at 1.4G whereas the unpacked tar is 512M. I'll amend the blog post, though. Regards, Tobias -- Sent from aboard the Culture ship GSV Just Read The Instructions
Re: [gentoo-dev] Kernel compiles and you
Hi! On Wed, 04 Jul 2012, Greg KH wrote: > > Recently, I have again bumped into the question whether one > > should compile the kernel as root. One of the things that puzzles > > me is why almost every HowTo, blog post and book recommends > > building as non-root -- yet basically no distribution /helps/ the > > user with doing that. > > Most distros don't have to do anything, they are not requiring users to > build their own kernels :) As I noted in the blog post. There are still people who prefer to roll their own, but still want to use a binary distro. Those people usually do the wget+tar xf approach, completely ignoring the package manager. And that's just dandy. As I also noted in the blog post, the more radical approach for binary distros is to not supply kernel sources as a package at all. Either you use their binary kernel or you're completely on your own. It's probably what I'd do were I to run such a project. Problem with that approach for us (as in Gentoo) is of course, that we need suitable sources (and config) in an easily findable place since assorted stuff depends on it at build time. > So in reality, they all do help their users with this, it's trivial to > build a kernel as a user on those distros. Actually, it is also on > Gentoo, there's no need to ever put a kernel anywhere except in your > home directory when building it. Mhm? So how do udev, glibc et al then find out if you have the right options set? What about the assorted ebuilds of out-of-kernel software that needs to access the sources? I'm well aware that for some, this is not a strict necessity (they could just hope you did set them up right or look at /proc/config.gz), but dropping the kernel source ebuilds would be rather radical -- I don't see that happening any time soon. > Oh, and one more reason you "never want to build your kernel as root", a > few years ago, the kernel build process had a bug where it accidentally > tried to do a 'rm -rf /*' on your filesystem. None of the kernel > developers ever noticed that as they didn't build a kernel as root, and > the bug stuck around for a relativly long time (weeks at least.) There > was also some semi-serious talk about leaving it in the build as well, > just to "catch" people who were doing this, but sanity prevailed and it > was fixed. But, you never know if that old bug might slip back in one > day :) I vaguely remembered the rm-rf bug, but I was unable to find any reference to it (at least not easily), do you happen to have a pointer? Regards, Tobias -- Sent from aboard the Culture ship Advanced Case Of Chronic Patheticism
Re: [gentoo-dev] Kernel compiles and you
Hi! On Thu, 05 Jul 2012, Dan Douglas wrote: > On Wednesday, July 04, 2012 10:30:20 PM Peter Stuge wrote: > > You may recall there was a kernel build system bug which ran > > -rf / which would be bad if you built as root. > > So there isn't anything during the build that requires writing > outside the source tree? Since I use a custom script for > automating the build, there would be no problem with having it > run everything in the sandbox itself up to installing the > modules? Correct. The only targets that write outside the tree are: install modules_install firmware_install headers_install Plus, possibly, arch-specific targets. I only know about x86/amd64 and alpha. Regards, Tobias
Re: [gentoo-dev] inittab with SIGPWR support
Hi! On Thu, 12 Jul 2012, Diego Elio Pettenò wrote: > > DEP> They _are_ deprecated after all. > > > > Where is that documented? > > man inittab You seem to have a different version than I do: $ equery f sysvinit|xargs grep -i deprecated 2>/dev/null $ equery f sysvinit|xargs bzgrep -i deprecated 2>/dev/null /usr/share/man/man8/shutdown.8.bz2:[DEPRECATED] Don't call \fBinit\fP(8) to do the shutdown but do it ourself. $ eix -Ice sysvinit [I] sys-apps/sysvinit (2.88-r3@08/31/2011): /sbin/init - parent of all processes Can you c&p the paragraph in question? Thanks, Tobias
Re: [gentoo-dev] Re: Any official position from Gentoo about systemd, mdev and udev-static ?
Hi! On Wed, 29 Aug 2012, Duncan wrote: > So in practice, just what are the sorts of times, relative to stand-alone- > build udev, we're talking about? In all this discussion, what, hundreds > of posts by now?, I've not seen ANYONE actually ask, let alone answer, > THAT. But it would seem to be a rather important question... As a first crude datapoint, I compared the build times (configure+make) of udev-171-r6 and -188 on our dev Alpha. This is a machine that's on the speedier side of off-mainstream architecures, but as a datapoint, it should be enough. Tests were run just after ebuild [foo] prepare, i.e. patching was _not_ measured. Since the machine has enough RAM, everything was in the page cache. ver (1)(2) (1+2) udev-171-r6: 15s / 71s / 86s; 1m26s udev-188 : 28s / 636s / 664s; 11m04s 1: "./configure" time 2: "make" time Other observations: - The machine in question did not have dbus, or libcap, which some would argue need to be factored into "build cost". - I expected more difference for the configure phase, since it is what I usually perceive as the slow part of many builds when archtesting. Probably some packages suffer more from this than others. Also, configure does not run in parallel, make does. - Test suite run times were not checked. Though it looks like the -188 ebuild builds the test suite binaries regardless. - This was run as make -j1 even though the machine has 4 CPUs. One reason was to make the compile time longer for better measurement granularity, the other was that most slower machines (as far as we are concerned) are single-cpu. HTH, Tobias
Re: [gentoo-dev] Re: Any official position from Gentoo about systemd, mdev and udev-static ?
Hi! On Wed, 29 Aug 2012, William Hubbs wrote: > On Wed, Aug 29, 2012 at 01:57:48PM +0200, Tobias Klausmann wrote: > > As a first crude datapoint, I compared the build times > > (configure+make) of udev-171-r6 and -188 on our dev Alpha. This > > is a machine that's on the speedier side of off-mainstream > > architecures, but as a datapoint, it should be enough. > > No, not exactly, because udev-188 doesn't build systemd. We use > specific targets in the Makefile to avoid doing that. Amending my earlier post then, here are the numbers for the 171 build and the target-specific build of 188: ver (1)(2) (1+2) udev-171-r6: 15s / 71s / 86s; 1m26s udev-188 : 28s / 78s / 116s; 1m56s Much less difference. Still, I figure _really_ slow machines/arches might be in more pain. I'll run my test with a Geode-based x86 later this week. Regards, Tobias -- Sent from aboard the Culture ship GCU You'll Thank Me Later
Re: [gentoo-dev] Re: Any official position from Gentoo about systemd, mdev and udev-static ?
Hi! On Thu, 30 Aug 2012, Duncan wrote: > Now, for worst-case comparison, on the same machine, what's the > respective times for a full systemd build? (I'm not saying actually > merge it, just configure/compile, plus see the next paragraph.) I think my first set of numbers illustrates that: just running "make" should be a full build, AIUI. For that scenario (and the machine in question, the factor was somewhere between 9 and 10 times slower for a full build. > So far, the results are encouraging. Higher times, but not THAT much > higher, with the new version. But if the worst happens and we really DO > end up building all of systemd and then throwing most of it away, what's > the relative times for THAT? That's actually what I was asking earlier, > and this gets us part way to the answers, but not all the way. > > Regardless, thanks, this is considerably more solid information than was > available earlier, and not everyone has a geode to actually do the test > on, so these numbers are a real contribution to the available > information, indeed! =:^) I'll try the whole thing again sometime later this week (in my copious free time!). Regards, Tobias
Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2
Hi! On Wed, 26 Sep 2012, Chí-Thanh Christopher Nguyễn wrote: > A different question is whether in the cases where parallel bzip2 makes > sense, is it really the best solution? xz is outperforming bzip2's > compression ratio for large files (for an informal comparison, see bug > 434350). And xz is faster at decompression, which offsets the parallel > advantage to some degree. As for the performance side of things: http://blog.i-no.de/archives/2008/05/08/index.html#e2008-05-08T16_35_13.txt Yes, that's four years old and needs to be redone with modern implementations (and machines). Will do so this weekend (I hope). Regards, Tobias -- printk (KERN_ALERT "You are screwed! " ...); linux-2.6.6/arch/i386/kernel/efi.c
Re: [gentoo-dev] [PATCH] Profile-enforced big-endian USE flag
Hi! On Thu, 29 Jun 2017, James Le Cuirot wrote: > > No. Alpha is little endian. > > Wikipedia says it is bi. tc-native() reports alpha* as big so I guess > that's the only variant we support? Then again, this page says it is > usually little. Is tc-native() wrong? > > https://kernelnewbies.org/EndianIssues For the purposes of explanation, let's distinguish Alpha-the-processor from Alpha-the-systems here. Yes, the AtP can be switched between big- and little-endianess. AtS can't. That is, once built, hardware-wise, it has to be either, but can never switch. Even the firmware has to be different between LE and BE systems. There are a lot of LE Alpha systems, in essence, everything that was ever sold as an Alpha system by DEC, Compaq, HP and sundry others (like Samsung, who made the UP1500 and related systems). As a guideline: if it ever ran True64, OSF/1 or digital alpha UNIX, it is little-endian. The machines that run Alpha CPUs in big-endian mode are exclusively Cray supercomputers like the Cray T3D and T3E series. Linux only ever supported parts of the former group (e.g. the high-end Alpha server GS1280 series from Compaq is definitely not, despite running in little-endian mode). The big endian Crays were never even close to be supported. tl;dr: Alpha is little-endian only for (our) practical purposes. Regards, Tobias PS: There may be obscure one-off or developer boards for Alphas which can switch, but the tl;dr still stands. -- Sent from aboard the Culture ship GSV (Range Class) Ethics Gradient
Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow
Hi!
On Tue, 25 Jul 2017, Michał Górny wrote:
> The summary line is included in the short logs (git log --
> oneline, gitweb, GitHub, mail subject) and therefore should
> provide a short yet accurate description of the change. The summary line
> starts with a logical unit name, followed by a colon, a space and a
> short description of the most important changes. If a bug is associated
> with a change, then it should be included in the summary line as
> #nn or likewise. The summary line must not exceed 69
> characters, and must not be wrapped.
This limit can be a problem if there's a nontrivial change to the
more than 80 packages in the tree that have more than forty characters in
cat/pkg[0]. Is the only option there to do word-smithing or
making the commit summary less usefu?
Or do we have a "violate if necessary" agreement regarding that?
Regards,
Tobias
[0]
$ cd /usr/portage
$ ls -d *-*/*|awk '{if (length>=40) {print length, $0}}'|sort -n
--
Sent from aboard the Culture ship
GSV Of Course I Still Love You
[gentoo-dev] Package up for grabs: net-ftp/atftp
Hi! I haven't used atftp in a *long* time and upstream is either dead or has entered a time capsule on SF.net. Open bugs: 513486 net-ftp/atftp - increase BKLSIZE 635786 net-ftp/atftp-0.7-r5 : neither HOMEPAGE nor originalSRC_URI available any more The former is ancient (and I only now realized it was there, shame on me). I am considering last-riting it right away, but if someone has some love and/or use for atftp, feel free to take it. Regards, Tobias
Re: [gentoo-dev] Proposal for changes for the next EAPI version
Hi! On Tue, 17 May 2016, Kent Fredric wrote: > On 17 May 2016 at 19:37, Pallav Agarwal wrote: > > For normal users we wouldn't. But currently, arch-testers need to make a > > judgement call on what to test when a stable-req bug is filed. Tests run in > > src_test are provided by upstream, and does not guarantee that a package > > that has been merged will actually run on the system. > > If the maintainer could add a couple small scripts to check basic > > functionality > > of the merged package, it would make testing for arch testers much easier > > and reliable. > > Let me give an example. Let's say > > app-misc/screenfetch-2.7.7 is the current stable package for screenfetch in > > the portage tree. > > However, on running, it produces an error on the top, along with the proper > > output. > > If screenfetch-3.0.0 happens to fix that error, maintainer can add a simple > > script > > > >if [ "$(screenfetch 2>&1 1>/dev/null)" != "" ] then > > eerror "Still producing error" > >fi > > > > To make sure the build is properly updating the screenfetch version, and > > that > > the bug has in fact been fixed. This is the only way I can see to reliabily > > and automatically test packages that have been merged successfully > > > I don't think this needs to be an EAPI change. And if we can acheive > the goal without one, the better. Agreed. > [... lots of interesting stuff ...] Or maintainers and teams could do what the Emacs team does: provide test plans[0]. Naturally, I'd prefer something automated over the very hands-on tests that are a bit of a necessity for an application like Emacs, but they are still better than nothing. Either way, I think it is preferable to have non-upstream tests of whatever shape we pick to be separate from the ebuilds and the source files, for the simple reason that most users won't care about them. Those who do can retrieve them in the same manner as the ATs. And as for my pet peeve, tests that are known to fail, can we also annotate that somehow so I don't waste hours running a test suite that gives zero signal on whether I should add the stable keyword? Even a one-line hin in the stabilization request would be nice. As it is, I keep a list of known-to-fail packages and my testing machinery tells me to not bother with FEATURES=test in those case. Not ideal, but less time-wasty. Regards, Tobias [0] https://wiki.gentoo.org/wiki/Project:Emacs/Test_plans -- if (user_specified) /* Didn't work, but the user is convinced this is the * place. */ linux-2.4.0-test2/drivers/parport/parport_pc.c
[gentoo-dev] Can ATs add missing test deps?
Hi!
It happens every now and then that during ATing, I find that
USE=test should pull in extra deps. This usually is an easy and
not exactly controversial fix.
What's the hive mind's opinion on letting ATs add such deps if:
- Only one level deep, but multiple first-level deps are ok
- The deps themselves are already marked arch/~arch to the same
level as the package needing them*
- The deps themselves are not humunguous when it comes to
compile/test times.
* And by this I mean *all* arch/~arch keywords the base package
has, not just the one(s) the AT currently cares about.
Thoughts?
Regards,
Tobias
--
panic("floppy: Port bolixed.");
linux-2.2.16/include/asm-sparc/floppy.h
Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)
Hi!
On Tue, 14 Jun 2016, Rich Freeman wrote:
> 1. Developers wouldn't have access to all the ebuilds in the curated
> repositories. They would only have access to the ones they contribute
> to.
> 1a. You could accept a contributor into a small project and not have
> to give them access to the toolchain/etc. Of course, they're still
> messing with curated packages so you don't want just anybody in there.
> 2. Exherbo at least requires peer review for all commits I believe.
> So, even if you're committing to your "own" overlay you're still going
> to need review if your overlay is a curated one.
> 3. Just as with Gentoo if something is curated you can generally
> count on it to follow QA, and if it is in a non-official overlay then
> it is anything go and it is probably not to rely too heavily on things
> like sane version numbering, deps that don't just disappear, etc.
> 4. If somebody really does need to make a "tree-wide" change they're
> going to need access to a bazillion repos or they'll need to ask
> everybody else to commit it for them.
> 4a. Conversely, people who probably shouldn't be making "tree-wide"
> changes won't.
> 5. To the extent that repos contain closely-related packages you can
> probably make much more effective use of git branching and so on. You
> would still be limited by any dependency relationships outside the
> repo.
6. Arch teams would have access to any and all repos that they do
testing on -or- AT work woulkd have to be split between testing
and doing the actual commits.
I very much would not like the second option: it's more
coordination overhead, more space for miscommunication and
increases delays from request to commit (which can be very bad in
the case of security bugs).
Just my CHF0.021 (adjusted for inflation),
Tboas
--
printk("NULL POINTER IDIOT\n");
linux-2.6.6/drivers/media/dvb/dvb-core/dvb_filter.c
Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass
Hi!
On Sat, 03 Dec 2016, William L. Thomson Jr. wrote:
> Google has hired a few core developers as has Gaikai. Both seem
> to be good, though not sure Google is giving back as much given
> their financial benefit. Gaikai isn't selling an OS, but Google
> is based on Gentoo...
That last bit is not true. While yes, Chrome OS and Core OS had a
Gentoo base, a lot was done of top of that.
Furthermore, most of Google's products (both shipped devices and
services) are _not_ based on Gentoo and never were. The base of
Google's production server OS is another Linux distribution, and
there, too, a lot of what makes the thing tick has no outside
equivalent.
Source: I worked on the relevant Google production teams for six
years.
Regards,
Tobias
--
panic("Fod fight!");
linux-2.2.16/drivers/scsi/aha1542.c
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
Hi! On Mon, 30 Jan 2017, William Hubbs wrote: > I have been looking at the meson build system [1] [2], and I like what I > see. > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > meson build system [3]. > > As I said on the bug, the downside is the addition of py3 and ninja as > build time dependencies, but I think the upside (a build system where > we don't have to worry about parallel make issues or portability) > outweighs that. > > What do folks think here? Meson isn't even keyworded anywhere but amd64 and x86 and I couldn't find an indication that they care about off-mainstream architectures at all. Yes, it's written in Python as such is more portable than if it were written in C or somesuch, but for a build system, the arch it runs on and targets are more important than for most other programs. As others have pointed out, the gains are not quite as obvious as the potential downsides are. Just my 2 Rappen, Tobias -- Sent from aboard the Culture ship GSV Just the Washing Instruction Chip in Life's Rich Tapestry
[gentoo-dev] Gentoo and Root CAs
Hey, Ryan Sleevi, who's working on Chromium and is familiar with other project's Root Cert programs has written an article on how he perceives assorted distributions handle Root CAs: https://plus.google.com/u/0/105761279104103278252/posts/eVdB6X3NpPg """ [...] Debian: From [5]. According to README.debian, to get a CA included, all you need is two or three people to support you. Gentoo: From [6] Same as Debian. Note they also modify other packages (such as dev-libs/nss) to inject root certs into other programs' root stores. [...] References: [5] http://packages.debian.org/squeeze/all/ca-certificates [6] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-misc/ca-certificates/ """ Now before you reply, RTFA. Also note that while my own opinion on the matter is irrelevant, I _do_ think that his concerns need to be addressed, particularly the second half of his statement. Regards, Tobias
Re: [gentoo-dev] call for testers: udev predictable network interface names
Hi! On Tue, 15 Jan 2013, Greg KH wrote: > So anyone who relies on network names right now to be deterministic, and > you have more than one network device in your system, should seriously > reconsider how they are naming their devices, as it will not work if you > only rely on the kernel. > > You might have gotten "lucky" for the past 5 years, but you never know > what could happen if you reboot today. Seriously, I've seen it happen > all the time. It has been rather nifty that if I walk up to a random machine with exactly one NIC (that I've been asked to examine/fix), I _know_ that there will be eth0 and only that. OTOH, maybe it's a good idea to make admins do "ip link sh" and "ip addr sh" every time they examine a new computer -- it goes a long way to root out wrong assumptions in that field. Regards, Tobias PS: Do not use ifconfig. Ever. Except if there's no iproute. And then you should only use ifconfig to enable downloading of iproute :)
Re: [gentoo-dev] call for testers: udev predictable network interface names
Hi! On Thu, 17 Jan 2013, Peter Stuge wrote: > Tobias Klausmann wrote: > > It has been rather nifty that if I walk up to a random machine > > with exactly one NIC (that I've been asked to examine/fix), I > > _know_ that there will be eth0 and only that. > > Only as long as that system hasn't seen *another* NIC first, if it > has persistent interface name udev rules. I was talking about strictly kernel order vs. predictable-net. Persistent-net has VM-related downsides as pointed out in the udev page about the whole thing. Regards, Tobias
Re: [gentoo-dev] Re: New install isos needed
Hi! On Sun, 24 Mar 2013, Duncan wrote: > Samuli Suominen posted on Sun, 24 Mar 2013 09:32:22 +0200 as excerpted: > > > imho we should contact the sysrescuecd developers and suggest more close > > cooperation, such that it could be called official install media in > > gentoo-terms > > I've wondered for years why gentoo invests all that effort into creating > its own install media, when there's many dedicated projects out there > whose whole purpose is live install/rescue media. It has always seemed > to me that we'd be better off simply using one of them and saving the > effort for something closer to our core competency/mission. SysRescueCD does not exist for the fringe architectures. When we first built the install media, the only alternative that was somewhat reliable was Knoppix -- which in turn had its own problems during the x86/amd64 days. So we built our own. I'll say it again: if we don't make install media anymore and tell people to use SRCD instead, we will lose installation support for at least alpha, ppc/64, hppa and ia64. As for sparc, mips and arm, there _might_ be alternatives, but I'm not aware of them. Regards, Tobias -- "Brain, konban wa nani o shimashitai?" "Your Japanese is terrible, Pinky."
Re: [gentoo-dev] New install isos needed
Hi! On Sun, 24 Mar 2013, Alexander Berntsen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 24/03/13 21:17, Ben Kohler wrote: > > I strongly believe it's important that we have an official install > > medium [that] the official installation handbook is based [on]. > I agree. Let's make it SystemRescueCd. I'll say it again: srcd is not available for many off-mainstream architectures. Are you saying you want to give them the boot? Regards, Tobias -- "Brain, konban wa nani o shimashitai?" "Your Japanese is terrible, Pinky."
Re: [gentoo-dev] Re: New install isos needed
Hi! On Mon, 25 Mar 2013, Markos Chandras wrote: > On 25 March 2013 09:30, Tobias Klausmann wrote: > > I'll say it again: if we don't make install media anymore and > > tell people to use SRCD instead, we will lose installation > > support for at least alpha, ppc/64, hppa and ia64. As for sparc, > > mips and arm, there _might_ be alternatives, but I'm not aware of > > them. > > > > We can suggest SRCD as an alternative just for the amd64/x86 isos WFM. Note that I _agree_ that all the install image building is eating time and is a source for errors. Thing is, if we only build them for fringe archs, we might run into the "oh well, it's just for those few dozen users, it doesn't matter if it's slightly broken" effect. Even though the images were broken for the mainstream, it took quite a while (and a longish thread) for them to be fixed/taken care of. Imagine if they'd only been broken for ppc64 and alpha. While my arch team (alpha) is very lucky to have armin76 taking good care of the images, not all of them have somebody like him (who seems to have 36h-days and never sleeping). And if we drop support for the ISO on amd64/x86, fewer people will probably care about it, putting more strain on the already thinly-spread arch teams to fix stuff and track upstream package changes. Recommending SRCD as an alternative sounds fine by me, especially for the sheer volume of possible hardware combinations in amd64-land. But we should still think of our own ISOs as something supported on all arches we want to offer. Regards, Tobias -- "Brain, konban wa nani o shimashitai?" "Your Japanese is terrible, Pinky."
Re: [gentoo-dev] New install isos needed
Hi! On Mon, 25 Mar 2013, Alexander Berntsen wrote: > > SysRescueCD does not exist for the fringe architectures. > Then make it. That way we will have a reliable install medium for all > architectures, an as an added bonus we will have helped a different > free software project become more useful to our community (i.e. the > free software community, but by extension the Gentoo community as well). This not quite as easy as it may seem. I suspect getting SRCD to work with, say, aboot instead of isolinux. Its build process probably is not accommodating that. Now remember that this has to be modular since there is no point in tending to patches for all the architectures we want. Booting is the most obvious part. But I am reasonably sure that SRCD uses some programs as integral parts that won't build or run reliably on some of the architectures I mentioned. Now you suddenly have to modularize the whole thing. I'm not saying it's impossible, but it surely isn't just a matter of "recompile it for sparc". I might take a look at it over the easter holidays, but I doubt I'll have anything beyond "it's feasible" vs. "it can't work because of X". End note that my expertise is Alpha, I can't speak for any of the other architectures when it comes to feasibility. Regards, Tobias -- "Brain, konban wa nani o shimashitai?" "Your Japanese is terrible, Pinky."
Re: [gentoo-dev] New install isos needed
Hi! On Mon, 25 Mar 2013, Alexander Berntsen wrote: > I don't think it seems easy. But nor does devoting time to a CD > that will only serve the purpose of installing Gentoo on these > architectures. Additionally, that strikes me as seriously > pointless if contributing to SysRescCd is a real alternative. Thing is that SRCD does a lot more things than our mini ISO does. As a result, keeping it going on half a dozen architectures is more work than maintaining our arguably very simple images. There is a reason why we abandoned making the "fat" install images a while back and now only do them as one-offs for special events (like the 10y anniversary). While using SRCD will add manpower to our image-making, its userbase will add constraints (X, Y and Z need to keep working, even if we and our users never use it). I'm not sure it's a net benefit in widening the audience several orders of magnitude more than widening the developer pool. Regards, Tobias -- "Brain, konban wa nani o shimashitai?" "Your Japanese is terrible, Pinky."
Re: [gentoo-dev] FYI: libpng16 won't be able to show some broken icons libpng15 was still able to
Hi!
Since we probably will have to fix the files coming out of
tarballs until the various upstreams have fixed them, I propose
running a PNG fixer during or after the install phase. Since
having pngcrush as dep for everything is not exactly lightweight,
I hacked together a PNG file fixer in pure(ish, see below)
Python:
http://git.schwarzvogel.de/?p=pngfixer;a=summary
Feel free to send patches
Note that all I wrote is the mind-numbingly simple pngfixer.py
script. The rest of the Python code is excised from PIL
(http://www.pythonware.com/products/pil/index.htm). I didn't have
to change anything there.
Also note that it is not _strictly_ pure Python I'm using: the
PIL components use Python's zlib.so and therefore are subject to
bugs in _that_ code.
Still needed:
- How do we ship this?
- How do we run it for every ebuild? (probably something like
find /var/tmp/portage/.../image/ -iname \*.png -exec {...}\;)
Regards,
Tobias
Re: [gentoo-dev] FYI: libpng16 won't be able to show some broken icons libpng15 was still able to
Hi!
On Tue, 23 Apr 2013, Ulrich Mueller wrote:
> > I appericiate the work done by Tobias utmost too but I have to agree
> > this is not something I want to see running automatically, or even
> > from within ebuilds.
>
> +1
>
> In Tobias's list, I count some 80 packages that need fixing. That's
> way too few to merit a general solution. Also this number will
> decrease when files are fixed upstream.
I see two problems with this approach:
- What do we do with unresponsive-yet-not-dead upstreams?
- What about future packages that ship broken files? I mean not
just existing packages that keep issuing broken PNGs but also
future packages that we just didn't cover now?
The former has two and a half solutions:
- Wait until itmagically fixes itself or upstream comes around.
This is only 1/2 a solution, IMO.
- Add a separate tarball or the like that the Gentoo maintainer
generates from the broken PNGs. Use this tarball to overwrite
the broken results of equivalent_of("make install").
- Have a convenience function that can be used for known-bad
packages to fix broken IDATs. Basically calling my script or
the binary Samuli mentioned.
The second problem, however, is trickier. We can rely on people
noticing the error messages/broken packages and hope they file
bugs. The other option is to have a QA-like check for it, again
using the simplest possible binary to do so.
Regards,
Tobias
Re: [gentoo-dev] FYI: libpng16 won't be able to show some broken icons libpng15 was still able to
Hi! On Tue, 23 Apr 2013, Walter Dnes wrote: > On Tue, Apr 23, 2013 at 01:19:05PM +0200, Tobias Klausmann wrote > > The second problem, however, is trickier. We can rely on people > > noticing the error messages/broken packages and hope they file > > bugs. The other option is to have a QA-like check for it, again > > using the simplest possible binary to do so. > > Will those messages be during the ebuild? There are currently > messages like... > > > QA Notice: Package triggers severe warnings which indicate that it > >may exhibit random runtime failures. > > ExtensionSubtables.cpp:32:31: warning: dereferencing type-punned > > pointer will break strict-aliasing rules > > > > Please do not file a Gentoo bug and instead report the above > > QA issues directly to the upstream developers of this software. > > Homepage: http://www.icu-project.org/ > > A similar message, about non-displaying icons instead of "random > runtime failures" may be in order. At the very least, it will let end > users know who to report the problem to. Exactly. I'd envision something like this: [snip] QA Notice: Package installs broken PNG files that may cause warnings, errors or fail to display completely. [... list of bad PNGs ...] See http://to-be-written-page/ for more information on how to fix these files. Please do not file a Gentoo bug and instead report the above QA issues directly to the upstream developers of this software. Homepage: http://project-homepage/ [pins] Regards, Tobias
Re: [gentoo-dev] Re: rfc: oldnet scripts splitting out from OpenRC
Hi! On Thu, 25 Apr 2013, Steven J. Long wrote: > Thanks, that sounds reasonable: one minor nitpick, though. Could you not > call it 'stdnet'? Since from all the other discussion it appears like this > is not going away soon for the vast majority of users, but simply being > maintained as another package, which makes sense. And it is the standard > Gentoo > networking setup. > > That way, 'newnet' is clearly a more modern variant, but no-one's disparaging > the traditional setup, which is after all, still the default. +1 It is something that had me puzzled for quite a while. Was I supposed to migrate? Was the current somehow broken? I'm still not quite sure what newnet does that oldnet doesn't, or why somebody felt it was necessary to make a new package (and no, let's not discuss that here). Whatever it is, ideally, it would reflected in the name(s). And package descriptions. Regards, Tobias
Re: [gentoo-dev] rfc: oldnet scripts splitting out from OpenRC
Hi! On Wed, 24 Apr 2013, William Hubbs wrote: > The primary disadvantages of newnet are that services can't depend on a > single network interface, and it is not possible to stop/start a single > interface. Which is why it doesn;t work for my not-exactly-complex, not-exactly-simple setup (NFS and AICCU depending on assorted interfaces being up, which they aren't always). I need to be able to restart individual interfaces and the services need to cycle with them. Regards, Tobias
Re: [gentoo-dev] Re: rfc: oldnet scripts splitting out from OpenRC
Hi! On Fri, 26 Apr 2013, Tobias Klausmann wrote: > I'm still not quite sure what newnet does that oldnet doesn't, or > why somebody felt it was necessary to make a new package (and no, > let's not discuss that here). Whatever it is, ideally, it would > reflected in the name(s). And package descriptions. Scratch that. After reading Rob's post, I know. TYVM. Regards, Tobias
Re: [gentoo-dev] Gentoo Hangouts
Hi! On Mon, 24 Jun 2013, Diego Elio Pettenò wrote: > I've worked on a VC system most of last year and I now go > through regular conferences... it's barely okay from a work > point of view, it takes lots of time to organize so you don't > want to do that every single day for sure. It depends how you run it. We have teams having a video thing open during the day with there geographically-diverse other team members and it works well for them. For those teams, it also improves cohesion. Geographically-diverse teams always have to actively fight the us-vs-them vibe that seems to be fundamental human nature. Aforementioned video link is part of that. > And unlike IRC meetings, you can cannot multitask, say making > your dinner while discussing this or that feature. As others have pointed out, this is a double edged sword: Sometimes, having less distraction (or getting away with less distraction) is a Good Thing. > A VC is a full commitment, and its attractiveness is often much > higher _before_ you use it.. This does not hold true for me. I'd never used VC before joining my current company, and I love it -- iff the alternative is not meeting at all or text-only. As I pointed out above, it is crucial for team cohesion. The basic question is: why do you do it? what do you want to get out of it? If you just want to have a get-together, like going to the pub together for a few beers, all prep it needs is finding a time. And beer, maybe. If you want to have a distincly productive meeting, you need an agenda/goals and someone to _run_ the meeeting. But that is true of IRC meetings, too. About the only thing that IRC meetings are invariably better at, is logging. Note, however, that logging is no replacment for agendas or summarizing the outcome of the meeting. Regards, Tobias
Re: [gentoo-dev] Re: s/disk space/drive space
Hi! On Tue, 30 Jul 2013, Duncan wrote: > OTOH, the "free space" or "space available" suggestions I saw elsewhere > do make a lot of sense and avoid both the "disc" and "mechanical drive" > implications. It's also closer to the common LANG=C expando of ENOSPC. Whatever the underlying physical thing is, it will usually be a device, from the OS' point of view. Regards, Tobias -- Life is like a burrito: If it's really good, You won't need a knife.
Re: [gentoo-dev] rfc: escape sequences in logs
Hi! My two cents for viewing-logs-in-vim (which is a use case for me): $ eix ansiesc * app-vim/ansiesc Available versions: (~)12 Homepage:http://www.vim.org/scripts/script.php?script_id=302 Description: vim plugin: ansi escape sequences concealed, but highlighted as specified Regards, Tobias
Re: [gentoo-dev] heads up: glibc-2.20 will require >=linux-2.6.32
Hi! On Sun, 03 Aug 2014, Mike Frysinger wrote: > upstream glibc has dropped support for older Linux kernels. your choices: > - upgrade your kernel > - switch to a different C library > - stick with glibc-2.19 for a while Also note that 2.6.32 is the oldest longterm kernel. If you use something older, you haven't gotten any security updates at all for a while. Regards, Tobias -- Sent from aboard the Culture ship ROU (Killer-class) Revisionist
[gentoo-dev] Gentoo git workflows and the stabilization/keywording process
Hi! Since we're causing at least mild upheaval process-wise, I thought I'd bring up a topic that will be exacerbated by the git migration if it's not really addressed. AIUI, we try to avoid merge conflicts, unless the merge is a meaningful integration of divergent processes. However, one aspect of how ebuilds are written these days will cause a non-trivial amount of merge commits that are not actually useful in that sense. This is due to the way keywording and stabilization work on an ebuild level. Since keywords are all in one line, any merge tool will barf on two keywords being changed in disparate clones. I.e. if I change ~alpha->alpha while someone else changes ~amd64->amd64, we will have a merge conflict. There several approaches to this problem: 1) Make a merge commit as explained above. Aside from the not really useful merge commit, this also means manual work for the ATs, who could really do with less manual labor. 2) roll back the local commit, fetch and re-do the semantically equivalent commit. This might be automated, but someone has to actually write that code. 3) Do away with one-line KEYWORD lists. This has wide-ranging repercussions, from grepping-and-parsing (which is already broken in different ways[0]), and it makes the "preamble" of ebuilds longer. The fundamental problem is of course that most diff/merge algorithms are line-oriented. If two commits change the same single line, both CVS and git are unhappy and yell for human intervention. The difference with git is that the commit(s) that introduced the change need to be rolled back and semantically re-applied, whereas CVS just puts conflict markers nto the file for me to sort (extra work, but much less than rollback+hand-merge) and the lets me commit. In essence, the local-vs-remote history discrepancy does not exist with CVS, and in git it requires extra manual work to resolve[1]. In any case, this needs to be addressed in _some_ way. Regards, Tobias [0] Think conditional keywords, like: if something; then KEYWORDS=this else KEYWORDS=that fi This is already in the tree and breaks the grep/scripting assumption, so it's a weak argument. [1] As I mentioned, this extra work is scriptable, but that needs to be done and the process for ATs needs to be amended to explain this situation. -- Sent from aboard the Culture ship GCU (Ridge Class) Jaundiced Outlook
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
Hi! On Thu, 18 Sep 2014, Rich Freeman wrote: > On Thu, Sep 18, 2014 at 1:53 PM, Ulrich Mueller wrote: > >>>>>> On Thu, 18 Sep 2014, Tobias Klausmann wrote: > > > >> However, one aspect of how ebuilds are written these days will > >> cause a non-trivial amount of merge commits that are not actually > >> useful in that sense. > > > > Git can do merge conflict markers just like cvs. Also, in practice I > don't tend to run into merge conflicts with cvs - I always do a > directory update before making changes. With git I'd probably not do > a pull if I were working on an obscure pacakge, but if I were doing a > security keywording I'd certainly do a pull before touching anything > since the likelihood of a conflict is much higher. The problem isn't the conflict markers. The problem is that with git, by the time I have a conflict, I also have a local commit that I have to roll back or turn into a merge, which means extra work. > Git even allows the use of tools like meld to resolve conflicts, > besides the usual fill-the-file-with-diffs-to-cleanup approach. > > > > > If this should really turn out to be a problem, then we could also: > > > > 4) Replace git's default merge driver by our own one that is better > > suited for ebuilds. This can be done per repository via .git/config > > and .gitattributes. > > > > Certainly that would be even more helpful! Still, all of these scenarios cause merge commits, which some people seem to be rather allergic to (and I do agree that nothing of use is actually merged, since two stabilizations/keywordings are usually orthogonal). Regards, Tobias
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
Hi! On Fri, 19 Sep 2014, Tom Wijsman wrote: > On Thu, 18 Sep 2014 19:39:08 +0200 > Tobias Klausmann wrote: > > > AIUI, we try to avoid merge conflicts, unless the merge is a > > meaningful integration of divergent processes. > > > > However, one aspect of how ebuilds are written these days will > > cause a non-trivial amount of merge commits that are not actually > > useful in that sense. > > The concept of rebasing your commits has been invented for this. In the > less common case that multiple people change the keywords, a manual > three way merge is a breeze; taking into consideration that maintainers > should be aware of KEYWORDS and other recent changes to their packages. As I pointed out, getting the right code into the tree is not the problem here. It is extra work over the current way of doing it (since I need to deal with a local commit that can't be ff'd or rebased as git is very line-oriented. On top of the extra work, there have been several mentions that only meaning ful merge-commits are wanted in the tree (or not wanted at all). AIUI, avoiding them in the keywording/stabilizing phase is currently very difficult, unless we split KEYWORDS into separate lines or find another mechanism (like having the maintainer/keyword-requestor do all the edits after the archs sign off on them). I'd be delighted to hear a simpler solution that only involves doing the semantic merge (like we do now with CVS). And at least in my case, collisions during keywording are fairly common, and will be even more so with git since fetch/pull are slower than for a CVS subdir (since git checks the whole tree for local changes, not just the current subtree, AIUI). Again, correct me if I'm wrong. I've been using git for ~4 years, but only in single-developer mode. And even there I managed to make a mess of repo histories :-/ Fortunately, nobody cares about my stuff. Regards, Tobias
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
Hi!
On Fri, 19 Sep 2014, hasufell wrote:
> Tobias Klausmann:
> >>> If this should really turn out to be a problem, then we could also:
> >>>
> >>> 4) Replace git's default merge driver by our own one that is better
> >>> suited for ebuilds. This can be done per repository via .git/config
> >>> and .gitattributes.
> >>
> >> Certainly that would be even more helpful!
> >
> > Still, all of these scenarios cause merge commits
>
> No.
>
> 1. git pull --rebase=preserve origin master
> => error: could not apply ...
> 2. fix conflicts via 'git mergetool' (e.g. meld or vimdiff with 3 panel
> view... very easy to see what happened)
> 3. finish rebase via 'git rebase --continue'
> => your unpushed keyword commit has been rewritten without a merge commit
> 4. push
See, this is why I asked: I was not aware of this (and have
pointed out repeatedly that I'd be delighted to be educated).
> That is pretty easy and takes you ~20s for a keyword merge.
> What's the problem?
The problem is that not everyone has deep knowledge of git. I
asked because I wanted to know what (if anything) we can do about
a problem I perceived. When we do the migration, there _will_ be
confusion and breakage and those who actually have deep knowledge
will likely cringe a lot. Documentation is the way out of that.
Regards,
Tobias
--
printk("Penguin %d is stuck in the bottle.\n", i);
linux-2.0.38/arch/sparc/kernel/smp.c
Re: [gentoo-dev] Sunrise contemplations
Hi! I'm not a dev (just someone donating 10GB of traffic per day from his private server to Gentoo), but that's exactly why I think I need to chime in. On Mon, 31 Jul 2006, foser wrote: > 1. Stale ebuilds are often stale for a reason, there is > obviously not enough interest to add and maintain them. Not > just on the developer side, but also on the user side. If > someone really cared enough he/she would go trough the process > of becoming a dev. You're kidding, right? I for one simply can't spare the time to become involved as a dev. Now before you're starting to say that I'm a freeloader and I should just deal with what's there, a few remarks: - I *do* contribute. My private rsync-server has served over a terabyte of data since I've been running it for Gentoo (somewehre in 2002? Years ago, in any case) - I do contribute to other F/OSS projects. Do I have to contribute to any project where I'd like to see a change? Isn't a enhancement reuqest a kind of contribution (as long as it's beyond "this sucks, change it!") > Then what is a solution to these ebuilds ? I for one would like > to see them go upstream, like rpm's and deb's . That would make > it clear that these ebuilds are not Gentoo approved, but would > provide a starting point for the user who would want to use > such a package. I think that was always the main idea when > overlays got introduced to portage. Sunrise just lowers the > step to get these often mediocre ebuilds, people can get them > right now, just not as easy. It's about user experience. I'm not saying any and all M-W ebuilds should get into the tree, but I have a strong feeling that *more* should go in - in unison with stale stuff being removed. But the latter is another project: treecleaners (at least from what I've read). I think Gentoo has a sort-of Debianesque problem: the tree is ever growing which results in growing pains (Debian has other pains but the problem is growth, still). I don't know any other remedy than to keep the tree lean - but not only by being wary of too many new ebuilds. Old ones have to go, too. As a result, a question: how many Gentoo users need to voice interest in an ebuild/package to make it "wortwhile"? I initially provided an ebuild for a package I maintain. I also provide a new ebuild for every new version. For this, proxy maintainership is the thing to do, IMO. > 3. Although I agree Sunrise may lower the step to becoming a > dev, I doubt it will have a serious positive impact on our > developer base and as such there is no reason to support > Sunrise officially. I think the people attracted to Sunrise > development are the ones that fall in the category 'want to be > there, but don't really have the time/skills'. Those people > will not evolve to real developers; they either will stick it > out in Sunrise for a short while or keep to a very small subset > of it. What about those that are able to put together a dead simple ebuild and just want it submitted and *not* rot in Bugzilla? I can understand that some people go for sunrise because some of their ebuild submissions just went stale and then started to rot in bgo. As for official vs. non-official: I don't care either which way. I think it's mostly about truth in advertising: If it's treated by the majority as being official, it's official. As for URLs: how do you think phishing works? People (mostly) don't look too closely at URLs. The layout/logos etc of a page are an entirely different matter. Just my EUR0.02 > My prediction is that Sunrise will see a high turnover of > 'developers', either because they are there for one specific > package (probably fresh and included in the main tree when > mature) or find out they lack the time to really invest in > learning the full extent of ebuilding. Also 'junior' devs on > Sunrise might not take that extra step towards devhood because > they got the influence they want, as such we might lose out on > devs that never develop beyond Sunrise contributors. Well, I think having more candidates will not only result in more "rejects" but also in more acceptable devs. As for the entry step: maybe it's too high now and with Sunrise one could find out where the sweet spot for it lies? Also: do you really want to have junior devs that are only in it for the influence? > As a developer I would not really think of Sunrise developers > any different than someone coming 'fresh' to Gentoo developing. > I would still require them to work on real bugs for a good > while to see their intentions/devotion over time before I would > even consider submitting them for real developership. In that > sense Sunrise would only lengthen the time a wannabe dev has to > spend in the no-mans land between active user and official > developer. So? Then Sunrise is a training ground. I don't see harm in that. > In conclusion these 3 points come together here : being a dev > is not about adding new ebuilds to the tree, it is about > maintaining what is al
Re: [gentoo-dev] Sunrise contemplations
Hi! On Tue, 01 Aug 2006, Jeroen Roovers wrote: > On Tue, 1 Aug 2006 10:21:53 +0200 > > Idea: should it be more obvious in emerge --info and ebuild > > failure that an overlay is involved? If it's obvious enough, > > I don't see a problem. Also, a command that lists all > > installed packages that come from an overlay might be useful > > (maybe even a sa part of --info). > > emerge --info can easily be forged. I've seen people asking for > help on #gentoo do it a few too many times (some even refuse to > provide it), and have wasted precious minutes not just > wondering what the error messages meant, but also whether I > could trust the user. I don't doubt your claim, yet I find it incredible. I'm constantly amazed at how stupid some people are. Not to mention how many idiotic assholes are out there. > The only way to have people submit emerge --info properly and reliably > would be to set up an online ticketing system - something like this: > > > # emerge --submit-info > > * sys-apps/portage generates emerge --info output and uploads it > relatively tamper-proof to tickets.g.o, and > > * returns a ticket to the user, a unique number that he or she can > communicate to developers and active users through a URL like > http://tickets.g.o/#ticket-number. > > * --submit-info includes information about the emerge commandline that > was run last and what category/package/version emerge was > building/installing at the time. I think this is a very good idea. Better than mine. > Now, do I appear to sound mistrustful of Gentoo users? Perhaps. > Perhaps, this --submit-info stuff reminds you of Product > Activation routines used by closed source software vendors. > Perhaps you think I am being paranoid. Maybe you think that > FOSS should be a free-for-all exchange of meaningful > information, which I would whole-heartedly agree with - the > information would be meaningless if could not trust it. I think it's critical how you sell this: don't say "this is because we can not trust you" but "this is because it makes it easier for you to send all relevant info". While it may seem phone-home-ish, the contained info is clearly traceable and everybody can see that there's nothing sensitive in there. Feedback agents to which I can have the source are much less suspicious than binary blobs that send gobs and gobs of binary info to their home. > It's a far cry from what Gentoo originally was supposed to be, > I admit. I am not even going to argue that this ticket system > is necessary or should be adopted by all developers once it has > been implemented - it is a means to an end, or perhaps several > ends, none of which are required to further develop Gentoo. Yet I think it's a good idea. Just don't misuse it as a tool to spy on users. *Don't* turn it into something that pulls more info than gentoo-stats (and then some). Regards, Tobias -- You don't need eyes to see, you need vision. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resurrecting "Project Dolphin"
Hi! On Sat, 14 Oct 2006, Benjamin Judas wrote: > it's been a while since I stepped back as a Gentoo-developer (about 1 1/4 > years) and in that time I did exactly zero. Private life (and unfortunately > stress) kept sucking up my time and interest in helping out in development > work. However, now after a long hiatus, I feel the need to get back to action > and continue at exactly that point at which I stopped. > > I took the decision to reanimate "Project Dolphin". Dolphin was an > experimental minimal CD similar to Grmbl aimed at semi-professionals and > professionals to help repair broken systems or minimize data-loss. > > Opposites to the official Gentoo-Minimal-CDs it contained more software and > also a working gcc (the idea behind that was to provide a quickly available > distcc-host by simply bootng any additional machines in a network with the > dolphin CD). > > Since I am sure that needs and ideas for such a CD have changed in the last > 15 > months, it's definitely a good idea to ask again which applications or > services should be available on that CD. > > I hereby request every person make suggestions. Please note, that Dolphin > will > be a CLI-based CD only, so no X-Applications will be taken into > consideration. Must: screen, cryptsetup with LUKS support (also in the kernel), all available fscks and mkfs's (ditto for the kernel, maybe also for the not-quite-so-unusual partition types), fdisk and friends, partition magic(?), a "find file(s) by byte pattern on this device" tool (there are several), file, iproute2, ping/traceroute/tcptraceroute and ipv6-capable friends where necessary, host and dig, nmap, tcdump or tshark, miitool, ethtool, netcat/6, ssh, arping, lftp, pciutils (lspci), usbutils (lsusb) Would-be-nice: mtr, partition magic, grub, tcpdump *and* tshark, ngrep, dsniff, ettercap, fping, hping, scapy, netwib/wox/whatchmacallit That's a quick list and I think one could argue about the membership in both categories. Regards, Tobias (not a Gentoo dev but a frequent user of live CDs) -- You don't need eyes to see, you need vision. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resurrecting "Project Dolphin"
Hi! On Sun, 15 Oct 2006, kashani wrote: > >As some modern server machines doesn't ship with a cd/dvd-rom drive per > >default also providing an usb-stick image (fitting on 128MB sticks?) > >makes sense and would help a lot :) > > In these days of $40 USD one gig USB drives I see the CD as the size > limiting factor. :-) I have a whole load of machines that can't boot off of usbstorage and for USB1.1, a CD-ROM is orders of magnitude faster. Regards, Tobias -- You don't need eyes to see, you need vision. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SPF at g.o
Hi! On Thu, 26 Oct 2006, Alin Nastac wrote: > Facts: > a) current SPF TXT record of our domain is "v=spf1 mx ptr ?all" > b) I use my own MTA to send my @g.o messages. > c) Probably I am not the only one who does that d) I've just spent nearly an hour to debug an error that resulted from an overly-zealous MX admin thinking it'd be nice to also check the Header-From: against SPF, breaking several mailinglists in the process. > Conclusion: > The proper TXT record for our domain would be "v=spf1 +all", which > translates (according to http://new.openspf.org/SPF_Record_Syntax ) as > "the domain owner thinks that SPF is useless". And it really is useless, > at the very least for our widespread organization. For me the proper conclusion is: don't ever implement SPF for your own domains. It wreaks all sorts of nasty havoc, including, but not limited to, broken mailing lists and forwards. Regards, a slightly pissed off Tobias -- Never touch a burning system. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Hi! On Tue, 07 Nov 2006, Georgi Georgiev wrote: > Quoting Lance Albertson <[EMAIL PROTECTED]>: > >Personally, after skimming through this thread, I'd say leave it as is > >and stick with Kurt's decision. Our developers clearly have nothing > >better to do than rant on about something as trivial as this. > > I ain't no dev, but how is this trivial? A typical scenario is: a > gentoo-dev sends an e-mail to a mailing list (a non-gentoo mailing > list) and that mail gets nuked by a greedy spam filter because the SPF > rules exclude (oh well, "do not specifically include") the server that > forwards the mailing list message. > > Or could it be that my understanding of SPF is flawed (quite likely)? Exactly that happened to me: one of my mailing lists saw very odd bounces if a mail was coming from provider A who published SPF records. Unfortunately, provider B (the one who created bounces) did not only check the Envelope-Sender, but also the Header-From. This resulted in the mail being refused as it came from my server which wasn't in the SPF record of ISP A. One might argue that it's all provider A's fault (so there!), but it's not exactly helpful that way, is it? I *know* it's not my or provider A's fault, still we're the ones who have to deal with the fall out. So I steer clear of SPF as I don't want any of my users to fall into the same trap. That it's notoriously difficult to debug isn't exactly helpful, either. Regards, Tobias PS: That pre-delivery forwards are broken (something used quite often) is another story. SPF is broken in more ways than one. -- Never touch a burning system. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
Hi! On Wed, 08 Nov 2006, Alin Nastac wrote: > Diego 'Flameeyes' Pettenò wrote: > > On Wednesday 08 November 2006 21:01, Kurt Lieber wrote: > > > >> So, in other words, spammers aren't abusing anything related to SPF. > >> They're sending mail using forged return-paths and SPF is highlighting > >> that. Which is exactly what SPF is designed to do. > >> > > If I were to send my gentoo mail through a mail.flameeyes.is-a-geek.org, > > with > > its own SPF record, (I'm not as this is not a "real" domain I have access > > to, > > nor a mailserver for what it's worth), with a From: [EMAIL PROTECTED] and > > a Sender: [EMAIL PROTECTED], would it be a PASS or a FAIL in > > SPF? > > > > > It doesn't matter what From, Sender or whatever else in the message header. > The part that counts is the Return-Path (the "mail from:" part of the > SMTP protocol). Or so it should be. As I've written earlier, some very misguided people not only judge the Envelope-From (i.e. "MAIL FROM" in SMTP-Speak, which usually is identical to the header "Return-Path") against SPF, but also the in-mail header From:. Yes, it's downright stupid because it breaks just about nay mailing software I know. Yes, it's used by at least two larger providers in Europe. No, tech support there soesn't think it's a bad idea after I explained it in easy, friendly words. Idiots. Still: there are two things to keep in mind: 1) Do you "just don't care" about the users of those ISPs. 2) Does Gentoo as a distro want to "advocate" for the usage of SPF (ever so slightly) with the knowledge that it breaks several things? Regards, Tobias PS: Even without those idiots, SPF breaks pre-delivery forwards. But also said that already and it was illustrated why that happens on the "why SPF isn't quite ideal" page someone mentioned earlier in the thread. PPS: Windmills, anyone? -- Never touch a burning system. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] What's it about, anyway?
Hi! First, a few words on where I'm coming from, so you can maybe see why I see things the way I do. I've been using Gentoo since some time before 1.2. I've always liked its flexibility, its excellent docs and that one could always find out how things work. I'm also a Gentoo rsync mirror admin. That is, a community mirror, so I'm no official member of the project. That said, my mirror is probably one of the older (if not oldest) rsync community mirrors out there. I'm quite sure it's in the top 10 of total traffic done over the years. Recently, I've convinced my boss to donate a rather large AlphaServer to the project. I've done that because I heard alpha had lost a good deal of their hardware donations and were looking for someone to help out. So I did. I've always enjoyed both, being a user and being a remotely-yet-not-really dev. Recently, though, that has changed. It's not only about the protracted and increasingly silly flame wars on -dev. What happened today is just outright insane from several points of view. First, someone is offended by something that is said on IRC between a group of devs. He then proceeds to publicly vent his frustration with this incident. Here's a hint: textual communication, be it mail, news or *especially* IRC is very easily misunderstood and even more easily ripped out of its context. I've learned that whenever someone says something that offends you on IRC, there's several ways to deal with it. First: Ignore it. Second: Take it up with them, ask them (politely) what they meant, maybe tell them you found it offensive. Just keep in mind: stay the fuck calm. Once you abandon calmness, things will go downhill rapidly. The third option, taking it up with some authority should only be taken once you've used #1 and/or #2 without getting anywhere. Oh and the fourth option is starting yelling right away. Not really an option. Okay, so far, nothing terribly bad has happened. There was a misunderstanding and someone complained publicly. Not the smartest move, IMHO, but hey, that's the way it is. Then, after finding out it was a misunderstanding, the thing I simply can't wrap my mind around happens: not only silence from the initial complainer, but also two people who suggest things might have gotten off to a wrong start are semi-banned. Absolutely mind-boggling. Where does this lead us (okay, me) to? It leads me to question whether my helping out with Gentoo is worth it. Mind you, I hold very little stake in there as a nondev. But I'm seriously considering my options for another reason: my involvement with Gentoo is something I'd put on a resume. But seeing how things have been deteriorating in the last few months, I begin to doubt that that's a good idea. I'm not pulling the "leave in a huff" card. Gentoo can survive without me just fine. But I think it might be illustrative that I, as a user seek alternatives due to this completely irrational, childish and downright stupid behaviour. Sure, I'm probably one of the more involved users, but if things keep degrading at this pace, the average user will soon notice, too. And then they'll run flocks, I guess. This is not necessarily a "Think of the users!" type of mail. More of a "Geez, are you anywhere near realizing what childish behaviour your showing to the world?" affair. That said, I'll shut up now. Regards, Tobias -- In the future, everyone will be anonymous for 15 minutes. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] What's it about, anyway?
Hi! As I feel it's necessary to clarify: I've *not* made the decision to quite or anything, I didn't wnat to get that notion across in my mail. My point was that it had gotten so bad that I seriously started considering it - which is bad enough and made me think. If that has made half a person think before posting, hey that's great. And now let's get on with doing what we enjoy :) Rgeards, Tobias -- In the future, everyone will be anonymous for 15 minutes. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI-1 (or >1, perhaps) Proposal: AND Dependencies
Hi! On Fri, 15 Jun 2007, Kent Fredric wrote: > On 6/15/07, John R. Graham <[EMAIL PROTECTED]> wrote: > > I occasionally run across a package version dependency issue that cannot > > be elegantly solved by the current dependency syntax. Every time I've > > come across this, it's boiled down to a range. For example, package > > some-cat/foo has the following versions in the tree > > some-cat/foo-4.0.0-r2 > > some-cat/foo-4.1 > > some-cat/foo-4.1.1 > > some-cat/foo-4.1.2-r2 > > some-cat/foo-4.2.1-r5 > > some-cat/foo-4.3 > > some-cat/foo-4.4 > > > > /me votes for rubyesqe range syntax > > some-cat/foo-( s:4.1 .. s:4.2) // start at slot 4.1 , and go upto > and including 4.2 > some-cat/foo-( s:4.1 ... s:4.2) // start at slot 4.1 and go upto, but > not including 4.2 > some-cat/foo-( v:4.1.0 .. v:4.2.0 ) // start at version 4.1.0 and go > upto and including 4.2.0 > some-cat/foo-( v:4.1.0 ... v:4.2.0 ) // start at version 4.1.0 and go > upto , but excluding 4.2.0 > > I know thats probably not possible in a bash env tho, but hopefully > the 'range' concept will give some inspiration, as IMO, having to > specify the ebuild atom name for both upper and lower values is > redundant, and easily missused as lamented by Vlastimil Babka > > /me hides in his corner to avoid abuse from people despising ruby lovers > > /me goes and joins ruby addicts anonymous As a side note, while we're talking ranged dependencies. It would also be really, really nice to be able to (un)mask ranges in /etc/portage/package.(un)mask. Just my 1.953 Eurocent (adjusted for inflation). Rgards, Tobias -- In the future, everyone will be anonymous for 15 minutes. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
Hi! On Wed, 20 Jun 2007, Ciaran McCreesh wrote: > On Wed, 20 Jun 2007 15:31:32 -0700 > Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-06-20 at 22:01 +0100, Ciaran McCreesh wrote: > > > The specific underlying question being, what are the use cases for > > > binary packages? > > > > Ever managed a network of multiple Gentoo identical Gentoo machines? > > That's one use case, yes. Now what are the others? I sometimes help out with arch testing. I don't like having all the deps and packages installed even if I don't use them. So I usually quickpkg the and unmerge them. Advantage is: if I have to archtest a package tomorrow that needs one of the deps I merged today I don't have to recompile it. On slower archs, this really helps. Regards, Tobias -- In the future, everyone will be anonymous for 15 minutes. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Feedback req: Confirm/thank on bug fix or is that unwanted bug spam?
Hi! On Mon, 09 Jul 2007, Chris Gianelloni wrote: > On Sat, 2007-07-07 at 12:56 +1200, Kent Fredric wrote: > > I /believe/ when you close a bug a notification is sent anyway > > irregardless of whether or not you add a comment, but i might be wrong > > here. > > > > I myself think dev's should be thanked for their good work and would > > like to continue doing so :) > > > > ( something has to be done to compensate for the amount of crap i bet > > dev's get, recognition occasionally IMO should help them feel loved > > and want to stay here at gentoo :) ) > > Personally, I tend to get annoyed by any messages sent after the > "RESOLVED-FIXED" is done. I do appreciate thanks from users, but a > direct email to the developer in question is much nicer than a bug > comment. For one, it only goes to the intended audience. Second, for > those of us that do most of their bug sorting via email, it doesn't give > us a post-resolution email for a bug we've already completed. Again, it > is just a personal preference, but sending a direct email seems to have > the least possibility of bothering anyone and gives you the ability to > thank the hard worker directly. First off: my experience comes from small OSS projects and a rather large inhouse TT system at work. The latter does not interact with external customers, just corp-internal stuff. I see it this way: I wouldn't close the bug before there is positive feedback[0]. If the user wants to thank me, he can (and probably will) do so with the positive feedback. After that, closing the bug is just that. YMMV, of course. Regards, Tobias [0] unless there's a certain amount of awkward silence[1] [1] which in the case of the corp TT will show up in *our* quarterly review and in very extreme cases will show up in his, too. -- In the future, everyone will be anonymous for 15 minutes. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] x86 toolchain changes heads up
Hi! On Tue, 17 Jul 2007, Mike Frysinger wrote: > historically, gcc on x86 has always defaulted to i386. some people noticed > recently that glibc-2.6 fails to build in this situation as they were only > setting -mtune via CFLAGS, not -march. i'll be tweaking gcc so that it will > default -march based on your CHOST. so all the i686-* people will now have a > default -march=i686 implied in their gcc systems, i586-* people will > have -march=i586, etc... keep in mind this is merely the default. Do I understand this correctly? Up until now, gcc implicitly assumed -march=i386 if nothing else was specified by the user. Now, it defaults to something different, so -mtune works differently than it used to. If both are correct, I have questions? - With what version did/will gcc change? Corollary: In what Changelog of gcc can I find out more? (Rather: which changelog can I point my coworkers to) - What's the new default? Thanks, Tobias -- In the future, everyone will be anonymous for 15 minutes. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
Hi! [... baselayout-2 is on the horizon ...] Is there a common bug to report snags to? I've hit one: /etc/init.d/net.eth0 used to be a symlink to net.lo. After installing, it was gone (I figure it went with baselayout-1). Luckily, I have direct console access, otherwise the machine would have been gone after the reboot. Definitely something to yell about during merging. Regards, Tobias PS: If said bug exists, I'll gladly re-report there, but my cursory search didn't turn up anything. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
Hi! On Fri, 31 Aug 2007, Mike Frysinger wrote: > On Friday 31 August 2007, Marius Mauch wrote: >> Petteri Räty <[EMAIL PROTECTED]> wrote: >>> Matthias Schwarzott kirjoitti: On Freitag, 31. August 2007, Matthias Schwarzott wrote: > What do you think about adding /etc/udev/rules.d/ to > CONFIG_PROTECT_MASK. This will no longer bother the user with > updating these files. Thus it will reduce the number of bugs > triggered by forgotten config-file updates. > > If user needs home-brewn rules he is requested to add own files, > and not use the already existing ones. Only problem I see: What to do with people having custom modifications inside the default rules-files? >>> >>> Can they add /etc/udev/rules.d back to CONFIG_PROTECT in make.conf? >> >> No, that wouldn't work. However they could add '-/etc/udev/rules.d' to >> CONFIG_PROTECT_MASK or add individual files to CONFIG_PROTECT. > > either solution sucks > > the question is, should people be modifying the default rules ? is there > something in the default rules file that they cant accomplish in a sep rules > file ? if so, then the dir cant be masked ... I find the persisten-net-generator.rules particularly annoying (for various reasons including, but not limited to system images and system cloning). So I have an empty file of that name and happily nuke whatever comes along with udev updates. I could of course unmask that file if it were to be masked in the future. Still, this reeks of layers upon layers of customization to me. I'd prefer a more elegant solution - although know of none. The classic approach would be a USE flag to toggle installation of the shipped udev files - which wouldn't work for me, as I only have gripes about *one* of them. There probably simply isn't a simple, elegant solution that is a) not wrong and b) works for just about everybody. Regards, Tobias -- In the future, everyone will be anonymous for 15 minutes. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: use flags -> use options
Hi! On Sun, 07 Oct 2007, Christian Faulhammer wrote: > "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]>: > > I imagine there are a lot more cases where the simple on/off system > > we have now is suboptimal. I could be wrong of course. Please comment. > > This key=value systems sounds interesting. Another use could be the > choice between xulrunner, seamonkey, firefox. And maybe it can be alleviated for some of the virtuals problem space. For those apps that need an editor, one could think of editor=vim. That would then of course raise the question of a sensible default - as it is with virtual/editor right now. Generally, its prime area of use is where something can be turned off (foo=off) or turned on with different ways of getting the functionality (foo=gnufoo, foo=freefoo, foo=foong). Another thing to keep in mind is though, that gnufoo might not have all the nifty-but-patent-ridden stuff that freefoo has. Then again, the user/sysadmin should know which of those fits the bill. The question would only be how to convey this info to the admin. Regards, Tobias -- In the future, everyone will be anonymous for 15 minutes. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: USE flag transition: tetex and latex
Hi!
On Tue, 06 Nov 2007, Christian Faulhammer wrote:
> > tetex-alike distribution. So, imho, in that case a kpathsea useflag
> > would make more sense; but I doubt such a useflag name will speak by
> > itself.
>
> Yes, we should introduce tex, latex and kpathsea USE flags. Anyone?
As long as the description of the USE flag (such as by euse -i)
is usefule (and *not* the equally omnipresentand useless "foo -
enables foo support"), I see no trouble in using it.
In this case I'd go for:
kpathsea - Enable (La)TeX integration.
I do understand that sometimes a given USE flags description
can't be unified. USE="foo" might enable very different things in
different packages. But then, global USE flags are the only once
where this is a concern.
For example, take mplayer's (local) USE flag "vidix". euse -i isn't
exactly helpful: "Support for vidix video output"
IMHO, it'd better be "Support X11 DGA video output using the
vidix interface"
One might argue that I should know the stuff I want but what if
I'd want the support for foo if I only knew about it?
Also, my (arguably not very good) example illustrates how extra
keywords might help the user find out what exactly vidix is using
Google.
Regards,
Tobias
PS: Yes, I've read the recend mp3/mp3{de,en}code discussuion,
same problem, actually.
--
In the future, everyone will be anonymous for 15 minutes.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: USE flag transition: tetex and latex
Hi! On Tue, 06 Nov 2007, Christian Faulhammer wrote: > Tobias Klausmann <[EMAIL PROTECTED]>: > > On Tue, 06 Nov 2007, Christian Faulhammer wrote: > > > > tetex-alike distribution. So, imho, in that case a kpathsea > > > > useflag would make more sense; but I doubt such a useflag name > > > > will speak by itself. > > > Yes, we should introduce tex, latex and kpathsea USE flags. > > > Anyone? > > As long as the description of the USE flag (such as by euse -i) > > is usefule (and *not* the equally omnipresentand useless "foo - > > enables foo support"), I see no trouble in using it. > > In this case I'd go for: > > kpathsea - Enable (La)TeX integration. > > Which I don't consider as correct: "enable integration with kpathsea > search library (TeX related)" > > > IMHO, it'd better be "Support X11 DGA video output using the > > vidix interface" > > Right, we have too many bad descriptions. Maybe a project for you > to prepare a patch for use*.desc? :) Actually, I might consider it. Unfortunately, I tried to cut off my finger last sunday and as such I'm typing-impaired for now. At least I got sick leave until Friday :-/ And two nasty tetanus shots :-( Anyway, I'm considering your "offer" :) Regards, Tobias -- In the future, everyone will be anonymous for 15 minutes. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Wanted: Stats collection (not submission!) testimonials
Hi! On Sun, 12 Jul 2009, Sebastian Pipping wrote: > Here are precise commands you need to run: > > # git clone git://git.goodpoint.de/smolt-gentoo.git > # cd smolt-gentoo > # git checkout -b gentoo origin/gentoo > # cd client/distros > # python gentoo.py |& less > > Again, no data is submitted, just locally collected and presented. > > Please send your feedback to the list; collected data better goes > to if you are willing to share it. I've tried this on my private dev alpha machine as well as the teams dev machine, both look ok to me. My everyday workstation (amd64) looks quite ok, too. The only thing I noticed is this: /home/klausman/tmp/smolt-gentoo/client/distros/gentoo/globaluseflags.py:22: DeprecationWarning: the sets module is deprecated which is due to Python 2.6 being my default interpreter. Interestingly, my cross-compile alpha setup (created using crossdev) is noticed as a "secret package" - I presume that is on purpose? In all, very nicely done! Regards, Tobias -- printk (KERN_DEBUG "Somebody wants the port\n"); linux-2.6.6/drivers/parport/parport_pc.c
Re: [gentoo-dev] Wanted: Stats collection (not submission!) testimonials
Hi! On Sun, 12 Jul 2009, Robert Buchholz wrote: > On Sunday 12 July 2009, Tobias Klausmann wrote: > > Interestingly, my cross-compile alpha setup (created using > > crossdev) is noticed as a "secret package" - I presume that is on > > purpose? > > That's an interesting phenomenon that pops up with both g-cpan and > crossdev, because they generate new ebuilds. I don't know how crossdev > works in detail, but g-cpan will create ebuilds in the first overlay in > PORTAGE_OVERLAYS -- if that is a public overlay, the stats client will > report them. If it has a private or no repo_name, the stats client will > not do that. I would assume crossdev generared the ebuilds in a private > overlay? Crossdev creates ebuilds on the fly, too, in this vein for a cross-compiler with target alpha: cross-alpha-unknown-linux-gnu/binutils cross-alpha-unknown-linux-gnu/gcc cross-alpha-unknown-linux-gnu/glibc cross-alpha-unknown-linux-gnu/insight cross-alpha-unknown-linux-gnu/linux-headers It also adds to package.keywords/.mask/.unmask to give you exactly the version you want. The ebuilds end up in /usr/local/portage/ for me, but that might be configurable. Regards, Tobias -- printk (KERN_DEBUG "Somebody wants the port\n"); linux-2.6.6/drivers/parport/parport_pc.c
Re: [gentoo-dev] Wanted: Stats collection (not submission!) testimonials
Hi! On Sun, 12 Jul 2009, Sebastian Pipping wrote: > Tobias Klausmann wrote: > > /home/klausman/tmp/smolt-gentoo/client/distros/gentoo/globaluseflags.py:22: > > DeprecationWarning: the sets module is deprecated > > I'm looking for advice how to best handle this. > > @all > If you read this and know how please contact me! You could make that import conditional on sys.version_info. I.e. only import it if you need it (neither Python 2.5.4 nor later versions need that import to make sets work, the specifics are documented on python.org). Regards & HTH, Tobias -- printk (KERN_DEBUG "Somebody wants the port\n"); linux-2.6.6/drivers/parport/parport_pc.c
Re: [gentoo-dev] Re: New eselect news item for X11 on alphas
Hi!
On Wed, 15 Jul 2009, Jeremy Olexa wrote:
> > Display-If-Installed: x11-base/xorg-server
> > Display-If-Profile: default-linux/alpha
> > Display-If-Profile: default/linux/alpha
>
> The Display-If-Profile field didn't work because I am seeing this news
> item on my amd64 host..
A bug has been opened for peper to look at:
http://bugs.gentoo.org/show_bug.cgi?id=277619
Regards,
Tobias
--
dprintk("kick_rx: maybe kicking\n");
linux-2.6.6/drivers/net/ns83820.c
Re: [gentoo-dev] Stabilization of Python 3.1
Hi! Aside from the remarks made by others (and speaking as someone who maintains Python software), there is one reason for me to not switch Python 3 to stable yet: lack of compatibility. Software that runs with 3.x will not run with any 2.x version as of today (and I doubt there will ever be a 2.x version of Python that can run 3.x code). As such, upstream devs will have to maintain two branches of software for a rather long time. Thing is, some projects just don't have the manpower to maintain two branches, so they will stay with 2.x versions for now. Yes, it's a catch-22, but I doubt that a sufficiently large portion of projects will have a 3.x-compatible branch/version this year (sufficient meaning over 95%). On the other hand, we can patch everything that doesn't run with 3.x (i.e. "fixing" the shebang lines and maybe assorted paths). The Python team is more suited to evaluate the feasibility of that. Regards, Tobias PS: As an illustration: just look at how long it took to get a 2.6-compatible version of mailman into the tree...
Re: [gentoo-dev] RFC: USE=qa-test
Hi!
On Tue, 06 Oct 2009, Ryan Hill wrote:
> [... separate testing flag/feature for
> complicated/long/somehwat broken test suites ...]
> [1] http://bugs.gentoo.org/287722
I agree. However, some of the cases aren't quite clear-cut. Take,
for example fftw. Its test suite takes about half an hour on a
modern machine (or so the ebuild claims). That's still several
times the normal build time. And in the case of slower arches,
the time can skyrocket: even on our quad-cpu Alpha dev machine
(definitely on the beefy end), the test suite takes over three
hours.
Bottom line: at least for the build time, some sort of guideline
("increases buildtime by more than a factor of X or more than Y
minutes") might be useful. The same goes for ballooning
installed-package size.
I think the "breaks a lot" is more clear cut, and "causes
security problems" definitely is.
Regards,
Tobias
--
We are sorry, but the number you have dialed is imaginary.
Please rotate your phone 90 degrees and try again.
Re: [gentoo-dev] Init systems portage category
Hi! Here's another chance to be reminded that Gentoo is about choice: how about a config file that comes with a pre-set list of packages that are important (if they're installed), for example e2fsprogs, the init system, stuff like that. But the user can add to this list (cryptsetup if it's needed for boot, the critical service this machine provides (say, apache), openssh because the machine is in a small metal box just off William's Field, AQ). Then, come update day, those packages, if to-be-emerged, are highlighted and/or there's a message at the bottom of emerge output (you /do/ a pretend run before you upgrade world, right?) warning that special care must be taken. Just my €0.012 (adjusted for inflation) Regards, Tobias
Re: [gentoo-dev] New ebuild metadata to mark how robust the package is?
Hi!
On Sat, 17 Oct 2009, Rémi Cardona wrote:
> Now we (gentoo devs) are finally starting to add news items for
> bigger updates (gnome, X, java, etc) and that's a good thing.
> But we definitely cannot and should not use news items for
> minor upgrades.
>
> elog is much better suited for such upgrade notices.
>
> However, since elog was put in portage, ebuilds have been using
> elog/ewarn/einfo _way_ too much. We're now at a point where the
> elog output at the end of an emerge phase is just _useless_
> because of all the noise.
One problem with this is that there is no way to "Acknowledge"
such ewarns/einfos. For example, I really, honestly know that
vanilla-sources isn't supported; I don't need the reminder every
time I upgrade it. Neither does the message from gentoo-sources
help me in any way anymore.
Come to think of it, how about an ewarn/einfo that is only
triggered on fresh installs, but not on upgrades? You can still
warn that foobard needs an etc-update and a restart, but I don't
need to be reminded where the examples are every time.
Ideally, one would be an einfo and one an ewarn, but in my
experience, many messages are ewarns "to be safe" (or so I
suspect).
> And with your metadata proposal, I'm worried the same thing
> will happen. Devs will enable the "troublesome" flag for a
> release, forget to remove it for the next bump and a few months
> later, half the packages in portage are labeled as such.
>
> I really don't want to sound like I want to kill your idea but
> I'm somewhat doubtful it'll really work given our track record
> with other such infrastructure.
As usual with such things, it should as simple as possible to
use, especially when only bumping a package (hence my idea of
separate "one-shot" message functions).
Regards,
Tobias
--
printk ("Barf\n");
linux-2.6.6/arch/v850/kernel/module.c
Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations
Hi! On Wed, 04 Nov 2009, Christian Faulhammer wrote: > Ben de Groot : > > What about ppc64? They are MONTHS behind on stabilization, > > even for security bugs (see bug 281821 for example). The Qt team > > feels this is no longer acceptable. We propose that any arch that > > can't keep up will be demoted to experimental status. > > I surely subscribe to that. At the moment Brent (ranger) is > definitely alone on that arch. So am I on alpha.[0] It is doable, but it wears you thin - and it's extra bad because it means I have hardly any free time to mentor anybody. That said, I hope whoever feels the need comes to me /before/ they file a bug for "Let's make alpha experimental". Regards, Tobias [0] Yes, armin76 helps, but he does so for many arches (and around of applause for that), but the majority of bugs for alpha are on my plate.
Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations
Hi!
On Thu, 05 Nov 2009, Petteri Räty wrote:
> In the past when smaller arches were not that active we used to
> mark Java packages stable after testing by at least one arch
> team. The probability to find arch specific issues in something
> like Java is not so high so I think arrangements like this are
> acceptable when the arch teams have problems keeping up.
For alpha, the java keywording policy is easy: don't.
We currently don't have any working JVM/JRE/JDK, so there's no
point in adding Java packages.
We *do* have dev-java/java-config keyworded, though the reason
escapes me at the moment :)
Regards,
Tobias
--
printk("NONONONOO\n");
linux-2.6.6/drivers/atm/zatm.c
Re: [gentoo-dev] URGENT: exotic arches need Qt 4.5.3 stabilization
Hi!
On Mon, 09 Nov 2009, Ben de Groot wrote:
> We especially request ppc64 to be marked as an experimental arch, as it
> is the worst one lagging in stabilization. See bug 281821 for a poignant
> example, a 3 months open security bug.
As a side note, don't hesitate to poke me or armin76 if you have
the feeling that anything is lagging because alpha isn't quick
enough. I try to handle security bugs (i.e. "CC: alpha and (CC:
or requestor security@)") first, but in the case of Qt, there
were two bugs, one normal stablereq with CC alpha and security
bug without arch CCs. Thus, it just wasn't on my radar as needing
quick action.
Regards,
Tobias
PS: I assume the "just poke me gently if you think I'm slow" goes
for other arches as far as armin76 is concerned, but I let him
speak for himself.
--
printk("Pretending it's a 3/80, but very afraid...\n");
linux-2.6.19/arch/m68k/sun3x/prom.c
Re: [gentoo-dev] adding a modification timestamp to the installed pkgs database (vdb)
Hi!
On Sun, 17 Jan 2010, Ciaran McCreesh wrote:
> > 1) portage/pkgcore support the PMS defined vdb2 while paludis doesn't
> > 2) portage/pkgcore are invoked modifying the livefs; vdb1, vdb2 is
> > updated.
> > 3) paludis is invoked. vdb1 is updated, vdb2 is not
> > 4) portage and pkgcore now cannot rely upon vdb2, since vdb1 now
> > contains extra modifications due to paludis not supporting vdb2.
>
> No, we'd not do it that way. If we're ditching VDB, the only sane way
> to do it is to ditch it with an rm -fr when creating the new layout.
> Keeping two sets of data around is going to lead to breakage no matter
> how well we do things.
Please also provide a downgrade path, i.e. a way to go back from
the new DB version to the current one should it be necessary (if
there is no such path, Murphy will see to it that the new format
breaks in interesting[0] ways).
Just my 0.0139304869 Euros (at current exchange rate),
Tobias
[0] Chinese-style interesting
--
printk("whoops, seeking 0\n");
linux-2.6.6/drivers/block/swim3.c
