[12:02] <ogra> PITTI !!!
[12:02] <jdong> lol
[12:04] <ajmitch> jdong: it may qualify
[12:04] <jdong> ajmitch: (it's 12 months overdue :) )
[12:04] <Nafallo> jdong: ehm? what's happened to lftp? ;-)
[12:04] <ajmitch> jdong: complaining to me doesn't get it much faster though ;)
[12:04] <jdong> ajmitch: the developer response was "live with it...." no updates to stable releases...
[12:04] <jdong> lol
[12:05] <jdong> well, ajmitch, I'd think you have greater influence on internal policy than me....
[12:05] <ajmitch> jdong: not much more
[12:05] <jdong> I am a mere mortal who breaks others' ubuntu systems :)
[12:05] <jdong> speaking of that, anyone object to OOo 1.1.5 for Hoary?
[12:05] <jdong> adds ODT support; huge incentive
[12:05] <tseng> breezy is in 10 days
[12:05] <tseng> fwiw
[12:06] <robertj^> updates scares me
[12:06] <jdong> I just walked a guy through upgrading hoary->breezy... dunno how well it'd go
[12:06] <robertj^> I just don't grok it at all
[12:06] <jdong> but I did a server from Warty->Breezy, and it worked great
[12:09] <robertj^> jdong: I think 1.1.5 is great for hoary
[12:09] <jdong> initial testing shows that nothing appears to break...
[12:09] <jdong> only time and 20,000 angry users will tell....
[12:09] <robertj^> jdong: its good practice for dapper though
[12:09] <robertj^> people will be backportinng things to dapper for a looong time
[12:09] <jdong> (and a couple incensed devs complaining about me not being on IRC, too)
[12:10] <jdong> robertj^: absolutely. It'll be great to have this Backports stuff 100% smoothed out by Dappper
[12:12] <tseng> 1 : to apply or offer incense to
[12:12] <tseng> 2 : to perfume with incense
[12:12] <jdong> brb, having multiple users complain about X failures.... gonna check myself
[12:13] <jdong> tseng: when fire issues from the eyes, ears, or mouth of an animal
[12:13] <jdong> lol
[12:13] <jdong> or indignant: angered at something unjust or wrong; "an indignant denial"; "incensed at the judges' unfairness"; "a look of outraged disbelief"; "umbrageous at the loss of their territory"
[12:13] <jdong> but that last one sounded so good
[12:14] <Kamion> jdong: I think the FTP client problem you cite above is a perfectly reasonable candidate for warty-updates; somebody just needs to do the work
[12:14] <jdong> Kamion: ok; bugzilla entries have been filed, but I think they were marked INVALID
[12:14] <jdong> months back
[12:20] <ploum> has someone ever set up a planet here ?
[12:20] <ploum> I can afford to set mine with the latest nightly :-(
[12:20] <ploum> ERROR:root:Update failed for <http://zefredz.frimouvy.org/rss.php> (Error: 404)
[12:20] <ploum> for each feed
[12:22] <Nafallo> ploum: dude... the planet maintainers live here.
[12:23] <ploum> Nafallo, it's why I ask here ;-)
[12:24] <robertj^> jdong: the real tough issue is do you recommend users to upgrade from OpenOffice 2.0 to 2.5 in dapper
[12:26] <ploum> so jdub, if you have time to waste, can you tell me if the nightly of planet is broken ? (it's really time to waste, you must have important things to do, I understand)
[12:27] <jdong> robertj^: I think that has to be the case.... Ubuntu has to get the separation of end-user apps from the core system like this
[12:28] <jdong> robertj^: most Windows users find the "distribution" model unappealing
[12:28] <jdong> but I can usually convince them otherwise when showing them the upgrade ease :)
[12:28] <ploum> ok, forget it ! it was on my side
[12:43] <lamont> smurf: ping
[12:43] <smurf> lamont: *yawn*
[12:43] <lamont> smurf: why does keyboard-chooser.udeb fail when there's no keyboard plugged into the machine???? huh? huh?
[12:44] <smurf> lamont: umm... good question. I suggest that I'll try to answer that after I've gotten some sleep. ;-)
[12:45] <lamont> thanks
[12:45] <smurf> lamont: Is there a bug for that problem someplace?
[12:45] <lamont> Just encountered it (headless box), I can certainly file one.
[12:46] <Kamion> I haven't seen such a bug
[12:47] <Kamion> although I've been running into a few annoying problems with kbd-chooser, mostly related to i18n I think - that won't be the case here
[12:47] <smurf> I freely admit I haven't tried to install from a headless box like, umm, ever
[12:49] <jdong> out of curiousity, is /var/lib/dpkg/* repairable?
[12:49] <jdong> I've seen XFS systems where those files got corrupted
[12:49] <jdong> dpkg doesn't work too well without it ;)
[12:49] <Kamion> smurf: I think the if chain at the end of keymap_ask() is just missing a case for kbd-chooser/no-keyboard
[12:49] <jdong> I think RPM has a command to rebuild the db
[12:50] <Nafallo> jdong: heard about the thing commonly called backup? :-)
[12:50] <jdong> Nafallo: this particular server admin didn't think anything important was in /var....
[12:50] <smurf> Kamion: Thanks; I'll look into it tomorrow (meaning, as it's 00:50 right now, "after sleeping")
[12:50] <jdong> Nafallo: I don't know how he kept his job
[12:51] <Kamion> smurf: sure
[12:51] <azeem> jdong: you can usually recover available by running apt-cache dumpavail > /var/lib/dpkg/available, IME
[12:51] <Nafallo> :-P
[12:51] <Kamion> there are backups of old /var/lib/dpkg/status in /var/backups/
[12:51] <Kamion> the rest isn't terribly recoverable
[12:53] <jdong> Kamion: does azeem's commands have any value?
[12:53] <jdong> (wow my grammar sucks today)
[12:53] <Kamion> jdong: yes, although 'dselect update' is simpler
[12:53] <Kamion> (and equivalent)
[12:53] <jdong> ok; but the status file can't be rebuilt?
[12:54] <Kamion> no, the status file contains most of dpkg's brain
[12:55] <Kamion> it's theoretically possible to guess at some of it, but I'm not sure anyone's actually done it, and at best it would only work on systems that are otherwise in a completely sane state
[12:55] <Kamion> which seems a bit optimistic :-0
[12:55] <Kamion> :-)
[12:56] <Nafallo> hehe
[12:56] <Kamion> diversions and statoverride would be hard to rebuild too (you'd have to effectively reinstall all packages for the first, which would be hard without existing diversion state, and the second is sysadmin-provided information)
[12:56] <azeem> TIMTOWTDI
[12:57] <dholbach> hey azeem
[12:57] <Kamion> /var/lib/dpkg/info/ could be rebuilt by downloading all installed and removed-but-not-purged packages and unpacking their control areas, assuming you knew which packages were installed and removed-but-not-purged
[12:57] <jdong> k, thanks guys
[12:57] <jdong> that clears it up
[12:57] <Kamion> basically, back up /var/lib/dpkg/
[12:57] <jdong> exactly
[12:57] <Kamion> jdong: (azeem's a long-time Debian developer BTW)
[12:58] <jdong> Kamion: ok. I'm not too familiar with much of the dev community around here... keep me posted :) I'm new and still a stranger
[01:16] <mdz> Seveas: btw, essentially every bug which has ever been filed against 'acpi' is wrongly assigned
[01:16] <lifeless> yeouch
[01:16] <mdz> Seveas: and belongs either to 'linux', 'acpi-support' or 'UNKNOWN'
[01:16] <Seveas> mdz, ah ok
[01:17] <mdz> the 'acpi' package just contains a trivial command-line tool; it has nothing to do with actually implementing the ACPI spec (that's done by the kernel) or dealing with events (acpi-support and acpid)
[01:17] <Seveas> Thanks for pointing all these things out, I hope I'll make less mistakes in the future
[01:17] <mdz> Seveas: these are minor things; you've been very helpful so far
[01:17] <lifeless> mdz: what *should* go on acpi ?
[01:17] <mdz> lifeless: bugs in /usr/bin/acpi
[01:18] <mdz> which is the only purpose of that package
[01:18] <Seveas> mdz, if minor things occur in large numbers they get very annoying :)
[01:18] <mdz> Seveas: similar for 'kernel-package' vs. 'linux', but I see you already know that
[01:18] <Seveas> yep
[01:19] <mdz> lifeless: which are so exceedingly rare as to be irrelevant in the face of the time we spend fixing it, so I'm considering just deleting that component
[01:19] <mdz> I don't think that's reasonable for kernel-package, though
[01:20] <mdz> we occasionally get real kernel-package bug reports, especially from debian
[01:21] <lifeless> mdz: yeah. I was going down the path of 'if no report is ever on acpi, why do we have acpi listed'
[01:22] <lifeless> mdz: it might not be a bad idea to nuke it and feed acpi bugs to acpi-support *even if that is technically wrong*
[01:22] <infinity> Yeah, kernel-package has plenty of real bugs.
[01:23] <mdz> lifeless: removing acpi would probably just cause all the kernel-side acpi bugs to end up on acpi-support
[01:23] <infinity> And I still have no idea how all the linux-image bugs land there.
[01:23] <mdz> infinity: people type 'kernel' into the selector
[01:23] <infinity> (Why don't we have a component just called "kernel"?
[01:23] <infinity> )
[01:23] <lifeless> mdz: thats what I'm saying. Point is that users don't know enough to make that choice anyway
[01:24] <mdz> lifeless: it's also a PITA to clean up all the old bugs which were closed without being reassigned away from 'acpi' (which bugzilla requires before it could be deleted)
[01:24] <mdz> lifeless: acpi-support isn't all that much better than acpi as a wrong destination
[01:24] <mdz> lifeless: certainly worse for mjg59, and not really better for me
[01:25] <lifeless> mdz: k, was just a thought.
[01:25] <mdz> perhaps we should rename acpi to acpi-the-silly-command-line-tool
[01:26] <mdz> infinity: I was thinking about creating one, actually
[01:26] <mdz> but it would mean that you'd have to search both to find kernel bugs
[01:26] <mdz> the whole point of 'linux' is to collect all of them
[01:26] <lifeless> I wonder if bugzilla could be fooled into aliasing them
[01:26] <mdz> that's closer to what we'd want
[01:29] <infinity> Yeah, that's kinda what I meant.
[01:29] <infinity> But I dunno if bugzilla supports aliases.
[01:30] <Seveas> hmm, continuing the triage on malone -- how can i close bugs there?
[01:32] <dholbach> good night pals, i'm off to bed
[01:33] <Seveas> 'night
[01:33] <dholbach> night Seveas
[01:36] <Kamion> lifeless: I think the company line is that the project to fix bugzilla to be usable is called 'malone'
[01:42] <whiprush> jdub: ping
[01:52] <Seveas> Kamion, in its current state malone is far less usable than bugzilla
[01:52] <Kamion> Seveas: there was a certain amount of irony inherent in my statement
[01:53] <Seveas> Kamion, ah, did not get that :)
[01:53] <Kamion> it probably only came across if you've heard me talk about malone before
[01:53] <Seveas> hehe
[01:53] <Kamion> but still, that *is* the Canonical line, ultimately - Malone is what we'll be using long-term
[01:54] <Kamion> so we all hope it'll get fixed :)
[01:54] <Seveas> let's hope that term is lnog enough
[01:54] <Seveas> I really like the previous - next buttons in bugzilla combined with the outrageously detailed searches that are possible
[01:55] <Kamion> there aren't many things I like about bugzilla either
[01:55] <Kamion> I might like the outrageously detailed search facility better if it didn't take the page an eon to load
[01:56] <Nafallo> wow
[01:56] <lamont> Kamion:  that's because the package list is > 1MB
[01:56] <Nafallo> could we have a purple desktop in dapper+1 please :-)
[01:57] <bddebian> With Pink Polka-dots?
[01:57] <Seveas> yeah!
[01:57] <Seveas> and bright lightblue/green/yellow squares
[01:57] <Seveas> Psychobuntu :)
[01:58] <Nafallo> we should have all squares in diffrent colors on all windows :-)
[01:58] <Nafallo> like: what colors are my firefox today?
[01:59] <Seveas> There's a random-firefox-name extension
[01:59] <mpt> infinity, Malone has aliases, though I'm dubious about the usefulness-to-clutter factor
[02:00] <Nafallo> hmm, maybe I should install that on my girlfriends machine ;-)
[02:01] <infinity> mpt : For obvious things like "kernel/linux", which we get a LOT of bug reports on, it makes sense.  FOr others, probably not so much worth the clutter.
[02:01] <mpt> Kamion, part of my brief when I designed Bugzilla's outrageously detailed search facility was that I wasn't allowed to remove any of the outrageous details
[02:06] <ogra> mdz, jbailey, YAY
[02:06] <ogra> mdz, jbailey, -o retrans=10 seems to be the solution for #12942
[02:06] <jbailey> ogra: Lovely.
[02:06] <ogra> jbailey, thanks for the help :)
[02:06] <mdz> ogra: what does that do?
[02:06] <jbailey> ogra: Glad I could help. =)
[02:07] <ogra> it retries 10 times instead of 3 times
[02:07] <ogra> (...to mount)
[02:07] <ajmitch> you need that many retries? worrying
[02:07] <jbailey> ajmitch: The timeout seems particularily small.
[02:07] <mdz> that doesn't make much sense to me; it never says that it gives up
[02:07] <mdz> it just keeps retrying but never works
[02:08] <mpt> Seveas, IMO the biggest problems with Malone are (1a) too many clicks to do anything to a bug report, (1b) you can't do multiple things to a bug report at once, (2) search is crippled, (3) the one-bug-in-many-places idea isn't obvious enough. Would that match your experience?
[02:08] <mdz> ogra: do you still get the same messages?
[02:08] <ajmitch> jbailey: it must be rather small
[02:08] <ogra> mdz, i booted 5 times with a freshly rebooted server, all first attempts worked
[02:08] <ogra> mdz, works just fine now
[02:08] <jbailey> ajmitch: timeo is "7", no idea what unit that is.
[02:08] <mdz> ogra: you don't even get a single 'not responding' message?
[02:09] <ogra> not on the client
[02:09] <Seveas> mpt, it matches it exactly
[02:09] <mdz> that is weird enough to make me skeptical that it really avoids the problem
[02:09] <ogra> i didnt run a tcpdump or anything, i'll look deeper tomorrow
[02:09] <Kamion> mpt: (1c) it's confusing to see how to do anything to a bug report
[02:09] <Seveas> that too
[02:09] <Kamion> oh, and the display is *so* sparse I keep wondering if I'm missing stuff
[02:10] <jbailey> ogra, mdz: Do you want something in initramfs for now?  I need to do an upload with jfs included anyway, so it would be nice to include this.
[02:10] <mdz> jbailey,ogra: let's get confirmation from some users that it fixes the problem
[02:10] <Kamion> in particular I keep looking in the wrong place to find who reported the bug
[02:10] <mdz> get some instructions into bugzilla and ask for testing
[02:10] <ogra> jbailey, i'd say go ahead, but if mdz has objections lets wait
[02:11] <mdz> it's a pretty safe change, so I think we can afford to wait a day or so to get confirmation
[02:11] <ogra> yup
[02:11] <mpt> Kamion: yeah, sabdfl is pretty fond of putting things in little blue boxes
[02:12] <jbailey> mpt: I think my biggest problem is that the links at the top are context sensitive and I don't expect that.
[02:12] <Kamion> mpt: I don't mind it being on the left-hand side, but in this case I think it could stand to be duplicated. I don't really understand why the report is treated fundamentally differently from comments; I would prefer if they all appeared in the same style (and thus with the commenter at the top right of the text of the initial report)
[02:13] <mpt> Seveas: good, then at least I know I'm on the right track ... Over the next couple of weeks we're going to pull stuff (like making attachments, and subscribing) into the bug page to reduce the number of clicks
[02:13] <Seveas> mpt, awesome
[02:13] <Kamion> at the moment "assigned to" appears roughly to the top right of the initial report, quite close to the relative position of the commenter's name to a comment, which is very confusing indeed
[02:13] <mpt> Kamion, agreed
[02:13] <mdz> jbailey: timeo is in tenths of seconds
[02:13] <mdz> so 0.7
[02:14] <mdz> and the default for retrans is 5
[02:14] <mdz> so 3.5 seconds
[02:14] <mdz> that is pretty short
[02:14] <ogra> mdz, its 3 in my source here
[02:14] <ogra> (retrans)
[02:14] <mdz> ./nfs/inode.c:          timeparms.to_retries = 5;
[02:14] <jbailey> mdz: Default retrans for klibc's nfsmount is 3
[02:14] <ogra> mdz, klibc
[02:15] <mdz> uuarrghhh
[02:15] <ogra> and timeo is 7
[02:15] <ogra> i'll play with timeo tomorrow if you see a need for that
[02:15] <ogra> and leave retrans at 3
[02:16] <mdz> I can believe that we might hit the timeout sometimes
[02:16] <mdz> but I don't understand why it doesn't fail
[02:16] <mdz> it acts as if it is continuing to retry forever
[02:16] <mdz> ogra: let's use the same defaults that the kernel does
[02:16] <ogra> ok
[02:16] <ogra> so retrans=5 then
[02:16] <mdz> timeo=7 and retrans=5
[02:18] <ogra> i guess setting that in klibc directly would be better than using a commandline option every time :)
[02:18] <mdz> The -o retrans option allows designation of the number of timeouts allowed before the client gives up, and displays the Server not responding message. The default value is 3 attempts. Once the client displays this message, it will continue to try to send the request, but only once before displaying the error message if another timeout occurs. When the client reestablishes contact, it will fall back to using the correct retrans val
[02:18] <mdz> ue, and will display the Server OK message.
[02:18] <mdz> the confusing thing is that that never happens in our case
[02:18] <mdz> so I don't see why increasing the timeout should change that
[02:19] <mdz> or the number of retransmissions
[02:20] <ogra> i never saw more than one message...
[02:21] <ogra> the above suggests i should see more
[02:21] <mdz> I have seen it repeat
[02:21] <ogra> hmm...
[02:21] <ogra> in which timeframe ?
[02:22] <Riddell> are the build daemons running today?
[02:22] <ogra> i normally shut down the client after a minute or two
[02:22] <ogra> Riddell, see topic... :)
[02:22] <ogra> i was hit by it too today, all uploads need approval :)
[02:23] <Riddell> ogra: ah
[02:23] <Kamion> mdz: btw, approval baton is yours, I'm well bored of it today
[02:24] <mdz> Kamion: we need an archive admin list
[02:24] <mdz> which gets mail when things land in the queue
[02:25] <ogra> brb
[02:27] <Kamion> Riddell: I've largely been avoiding KDE approvals because I don't know the standing policy on new upstream versions there
[02:28] <Kamion> at least not well enough to want to enforce it
[02:30] <mdz> Kamion: Riddell and I discussed via email; I've taken care of the pending uploads
[02:30] <Kamion> ok, thanks
[02:31] <ogra> mdz, 5 works too.. below it times out for me
[02:31] <ogra> (i.e. 4)
[02:31] <mdz> so weird
[02:32] <ogra> but if 5 is the default forthe kernel it sounds reasonable to use that
[02:33] <mdz> maybe using a lower value triggers a bug somewhere
[02:34] <mdz> ogra,jbailey: let's go ahead and set retrans=5 in initramfs-tools
[02:34] <ogra> hmm, that might be... or the description is simply wrong
[02:34] <ogra> i'd rather set it to 5 in klbc
[02:34] <ogra> *klibc
[02:35] <ogra> since its the default in the kernel anyway as you say
[02:35] <ogra> so the default values should match
[02:37] <jbailey> mdz: 'kay.  I will make a variable for options, set it to that by default and allow it to be overwridden in the initramfs.conf
[02:38] <jbailey> Mmm..  Overwridden must be the intersection of overwritten and overridden, I guess.
[03:10] <wasabi> Looks like in 2.6.12-9 the mppe module isn't audoloading right anymore
[03:10] <crimsun> mppe?
[03:11] <wasabi> ppp encryption stuff for MS VPNs
[03:11] <crimsun> oh, it must be external
[03:11] <wasabi> hmm?
[03:11] <crimsun> I couldn't see anything from modinfo
[03:11] <wasabi> /lib/modules/2.6.12-9-k7/kernel/drivers/net/ppp_mppe_mppc.ko
[03:12] <crimsun> oh, I used ''modinfo mppe''
[03:12] <wasabi> FOr whatever reason, it was being loaded on demand in 2.6.12-8
[03:12] <crimsun> that would explain that
[03:13] <oxez> is it me or the channel is -t, anyone can change topic?
[03:14] <daniels> it's not just you
[03:15] <oxez> okay
[03:16] <tritium> hi daniels.  Good to see you
[03:18] <daniels> tritium: yo
[03:21] <bddebian> daniels: Would you mind looking at a patch for xfonts-terminus for me?
[03:24] <daniels> bddebian: sure
[03:26] <bddebian> daniels: Thx.  It works but I suppose I should probably do a proper patch?  http://www2.bddebian.com:8000/packages/ubuntu/xfonts-terminus/xfonts-terminus_4.12-2ubuntu2.debdiff
[03:27] <daniels> bddebian: *shrug*, looks okay to me
[03:28] <Kamion> so is evolution meant to provide evolution.desktop as well as evolution-2.4.desktop, or should I fix the default panel setup?
[03:28] <Kamion> seems that evolution only provided evolution-2.2.desktop in hoary ...
[03:28] <infinity> bddebian : "proper patch"?
[03:28] <bddebian> daniels: You don't think I need to do a proper debian/rules patching for the Makefile and such?
[03:29] <daniels> bddebian: why bother?
[03:29] <infinity> bddebian : Is there a patch system in the package already?
[03:29] <bddebian> daniels: That was my question but dholbach felt I should "do it right" :-)
[03:29] <daniels> bddebian: often the overhead of adding dpatch and the huge drift (and antagonism) that results is far worse
[03:29] <infinity> bddebian : If not, adding one increases the complexity of our diff against Debian, which is counter-productive.
[03:29] <daniels> bddebian: tbh I wouldn't be adding any patch systems unless I had a huge unmanageable diff
[03:29] <bddebian> infinity: No there isn't :-(
[03:29] <ajmitch> especially for a small change
[03:29] <infinity> bddebian : Right, then don't add one.  PLEASE.
[03:29] <bddebian> Grrr.. :-)
[03:29] <daniels> i don't think this counts as either huge or unmanageable
[03:30] <infinity> bddebian : It just makes syncs harder, not easier.
[03:30] <bddebian> OK, someone wanna upload it? ;-)
[03:30] <daniels> it's a main package?
[03:30] <bddebian> Aye :-(
[03:30] <daniels> Kamion: approval?
[03:30] <ajmitch> universe binary, main source
[03:30] <bddebian> Malone bug
[03:30] <Kamion> daniels: I'm nearly passing out, ask mdz
[03:31] <daniels> Kamion: 'kay
[03:31] <daniels> mdz: ^^
[03:31] <bddebian> I think scribus needs a fixed .desktop file too but it's main also :-(
[03:37] <bddebian> You folks just need to get ajmitch his main upload rights and I'll make him my bitch for any main fixes
[03:37] <infinity> bddebian : What's the point of changing the documentation of "default build locations" in that patch?
[03:37] <bddebian> infinity: It's not necessary, it was just an anal thing :-)
[03:37] <infinity> bddebian : (which is inaccurate anyway, since you didn't actually change those strings to match your changes to the Makefile)
[03:38] <ajmitch> bddebian: hardly likely :)
[03:38] <bddebian> I didn't?
[03:38] <infinity> bddebian : s/local/misc/
[03:38] <bddebian> ajmitch: What, that you'll ever get main? :-)
[03:38] <bddebian> infinity: Didn't I make it /misc?
[03:38] <infinity> bddebian : Not in the docs.
[03:39] <bddebian> Oh must have been an oversight on a subsequent revision :-(
[03:39] <ajmitch> bddebian: no, that's expected, I mean the uploading
[03:39] <bddebian> ajmitch: ;-P
[03:39] <bddebian> ajmitch: Don't feel bad, I still don't have a working @ubuntu.com e-mail :-)
[07:03] <fabbione> morning
[07:07] <sabdfl> mdz: ping
[07:09] <crimsun> morning pitti
[07:10] <crimsun> pitti: when I plug in a usb sound device, a popup appears, but it refers to System> Preferences> Audio. Shouldn't that be Sound instead?
[07:10] <vuntz> Kamion: "so is evolution meant to provide evolution.desktop as well as evolution-2.4.desktop, or should I fix the default panel setup?"
[07:10] <pitti> Hi all
[07:10] <vuntz> Kamion: it should provide it. But it doesn't right now
[07:10] <vuntz> Kamion: it will in the future, though
[07:11] <pitti> crimsun: right, it should
[07:11] <pitti> crimsun: I'll upload a new version, thanks for spotting
[07:11] <crimsun> pitti: thank you :-)
[07:12] <fabbione> daniels: ping?
[07:15] <ajmitch> hi pitti
[07:18] <pitti> Kamion/mdz: approval for uploading a new control-center which fixes the menu name pointer in the audio popup? (s/Sound/Audio/)
[07:18] <pitti> Hi ajmitch
[07:18] <ajmitch> pitti: your phpmyadmin sync last week didn't quite work :)
[07:19] <pitti> ajmitch: why, didn't it build?
[07:19] <ajmitch> pitti: no, it needed a newer yada than was in main
[07:19] <ajmitch> builds ok without it, so I set the build-dep back
[07:19] <fabbione> mdz, Kamion, whoever can answer: permission to upload mysql-dfsg-4.1 to fix 16708. One line change. simple and clear
[07:19] <pitti> oh, thanks
[07:54] <pitti> Kamion: permission to upload  http://www.rafb.net/paste/results/TqQt0d66.html ? (trivial build-time change only)
[07:57] <fabbione> hey pitti
[07:58] <pitti> Hi fabbione
[07:58] <fabbione> pitti: any news about that patch?
[07:58] <fabbione> (kernel)
[07:59] <pitti> fabbione: Linus produced a "totally untested patch" which is currently discussed
[07:59] <fabbione> ok
[07:59] <pitti> fabbione: this is pretty messy
[07:59] <fabbione> yeah i can imagine
[08:07] <smurf> pitti: Since when is Linus' posting totally untested patches news? ;-)
[08:10] <Mithrandir> mdz: given that I can't reproduce it on any system I have access to, no.
[08:15] <mdz> Mithrandir: neither can I, so we need to debug it by proxy with the people who can
[08:16] <mjg59> mdz: sleep is broken in acpi-support 0.42, fixed in 0.43 (though that's not built yet)
[08:17] <mdz> pitti: translated string?
[08:17] <mdz> mjg59: I just approved it about 30 seconds ago
[08:17] <pitti> mdz: no, the bubble is not translated
[08:17] <mdz> pitti: ok then
[08:17] <pitti> mdz: (it should be in the future, though)
[08:17] <mdz> infinity,fabbione: uploads approved
[08:17] <fabbione> mdz: ok done..
[08:18] <fabbione> mdz: i am looking at that mkdirhier
[08:18] <fabbione> but that's a pain to do.. it needs a NEW + an xorg upload
[08:18] <pitti> mdz: permission for http://www.rafb.net/paste/results/TqQt0d66.html  ?
[08:18] <fabbione> not sure it's worth it
[08:18] <lifeless> daniels: ping
[08:18] <lifeless> I just resumed...
[08:18] <mdz> daniels: what is the story with all these xkb bugs?
[08:18] <mjg59> mdz: Ta
[08:19] <lifeless> daniels: and X was hung - showed my screen, with the shapes of the major windows (panel, xterm) in background-colour, but no content
[08:19] <mdz> pitti: ok
[08:19] <pitti> mdz: thanks
[08:19] <mjg59> lifeless: From RAM or from disk?
[08:19] <lifeless> daniels: I switched to console, and ps fux showed me a bash -c 'xscreen-saver-command -deactivate' process that was hung
[08:19] <lifeless> thats from resume.sh I presume
[08:19] <lifeless> mjg59: mem
[08:19] <mjg59> lifeless: Ah. Now that's interesting.
[08:19] <lifeless> daniels: so I killed that.
[08:20] <lifeless> daniels: then there was a xscreensaver-command -throttle, I killed that too
[08:20] <lifeless> no joy
[08:20] <lifeless> so I killed xscreensaver
[08:20] <lifeless> which made everything work again, except my mouse cursor was missing
[08:20] <lifeless> I did a short suspend-mem, resume cycle
[08:20] <lifeless> and it came good.
[08:20] <mjg59> infinity: Win.
[08:21] <lifeless> mjg59: yes, it is interesting.
[08:21] <mjg59> infinity: Now we just need to figure out what state xscreensaver is in
[08:21] <pitti> infinity: what's the status of tbird? pushing this into breezy becomes really hard, I assume
[08:21] <mjg59> For some reason, this seems to happen when people StR for long periods of time but not short ones
[08:21] <infinity> pitti : It's the next on my list after a binutils upload.
[08:22] <infinity> pitti : asack rolled an orig and pushed it into sid over the weekend.
[08:22] <lifeless> mjg59: yes, I had just done a 15 minute suspend
[08:22] <pitti> infinity: can we still put it into breezy?
[08:22] <mdz> mjg59: which one of the changes in 0.43 unbreaks sleep?
[08:22] <mjg59> mdz: The fix in sleep.sh
[08:22] <infinity> pitti : Should be able to.
[08:22] <mjg59> mdz: Which is the "Fix Radeon backlight tweak support"
[08:23] <infinity> pitti : It'll get more testing in breezy in 9 days than it'll get in the other dists, and we're backporting sources... So... <shrug>... I'll review the diff first, of course (coming up later today)
[08:23] <pitti> infinity: ok, thanks
[08:23] <tritium> mjg59, I can also confirm it occurs when hibernating for long periods
[08:23] <mjg59> lifeless: How long had you slept for?
[08:23] <mjg59> When it broke?
[08:23] <mjg59> 15 minutes?
[08:25] <pitti> infinity: JFYI, http://tinyurl.com/davmq could interest you (full set of bugs fixed for 1.0.7)
[08:26] <lifeless> mjg59: yes
[08:26] <infinity> pitti : It will fascinate me endlessly.
[08:27] <mjg59> lifeless: Ok, cool. So the problem is almost certainly when you've slept long enough that xscreensaver activates itself during resume
[08:27] <mjg59> And then gets miserably confused
[08:27] <mjg59> Go xscreensaver
[08:27] <pitti> infinity: I meant, for reviewing the diff :)
[08:27] <infinity> (I know)
[08:27] <lifeless> other data points
[08:27] <lifeless> xscreensaver was not using up lots of cpu
[08:27] <lifeless> (I checked via top)
[08:27] <lifeless> I did not strace.
[08:27] <lifeless> I will do that next time
[08:28] <mjg59> Ok
[08:28] <mjg59> I'll try to duplicate now
[08:28] <mjg59> Oh hnngh I need to do a pile of installs
[08:30] <pitti> fabbione: will you or BenC convert the kernel to the new reboot notification?
[08:30] <infinity> mdz : While this testbuild is running, can I get pre-emptive approval to upload a binutils that A) make binutils-static stop depending on binutils, and B) produces a binutils-static-udeb.udeb?
[08:31] <fabbione> pitti: nobody.. kernel is in strict security only mode
[08:31] <pitti> fabbione: ouch
[08:31] <infinity> Uhm, somebody really should.
[08:31] <pitti> fabbione: the current notice so much sucks
[08:32] <infinity> The current notification is B-R-O-K-E-N, and the unified thing was done for just such reasons.
[08:32] <fabbione> pitti: ask mdz.. in anycase that would be BenC
[08:32] <pitti> fabbione: ok, I will
[08:32] <fabbione> infinity: isn't a bit too late to change stuff around?
[08:32] <infinity> It's never too late, if it's done very carefully.
[08:32] <pitti> fabbione: it's really trivial, just call an u-n script and be done
[08:32] <infinity> Very.
[08:33] <fabbione> that requires a lot of changes around..
[08:33] <fabbione> from kernel-package to modify postinst
[08:33] <fabbione> to the kernel to remove the old notification system
[08:33] <fabbione> again.. i have no problems to do it.. given that mdz approves it
[08:33] <fabbione> or BenC wants to do it
[08:35] <mdz> infinity: it is a bit late for binutils-static-udeb
[08:35] <mdz> the installer needs to be frozen pretty solid
[08:35] <infinity> mdz : Erm?  Kamion requested it, otherwise nic-restricted-modules is useless.
[08:35] <mdz> infinity: yes, much as has been the case for the past few months
[08:35] <pitti> mdz: what do you think about dropping the current kernel update notification and use the new generic reboot notice?
[08:36] <mdz> pitti: I think it would have been a good idea last week
[08:36] <mdz> when we discussed it
[08:36] <pitti> mdz: ok
[08:36] <infinity> mdz : Right, well should we just drop nic-r-m for now, then?  That solves me a hassle or two. :)
[08:37] <fabbione> AH AH!!!!
[08:37] <infinity> So, I could upload static-udeb, but we could just not use it until the dapper cycle opens.
[08:37] <pitti> Hi dholbach
[08:38] <fabbione> mdz: 16812 is easy to fix.. but it needs a xorg upload...
[08:38] <dholbach> pitti: hi martin
[08:38] <mjg59> infinity: That loses us madwifi support in the installer, right?
[08:38] <mdz> infinity: we have bigger fish to fry; if we're not gonig to use it, then it can wait
[08:38] <dholbach> morning everybody
[08:38] <fabbione> mdz: i just figured that there is a shell implementation of mkdirhier
[08:38] <infinity> mdz : True, except I just did it.  Meh.
[08:38] <infinity> mjg59 : Yes.
[08:38] <mdz> mjg59: yes, which we resolved a few months ago that we could live with (which is why no one has been working on it)
[08:38] <mjg59> Ok
[08:38] <fabbione> mdz: so that would fit perfectly in xutils (no need of a new package)...
[08:38] <fabbione> mdz: but it's sort of a hack.. it should really be in its own package
[08:38] <mdz> fabbione: ok
[08:39] <fabbione> mdz: what would you prefer?
[08:39] <infinity> mdz : Apparently, not everyone got that memo, as Kamion has had me fixing the nic-r-m udeb and getting a binutils-static-udeb.  Oh well.
[08:39] <mdz> fabbione: I don't agree that every trivial program originating from X needs its own source package
[08:39] <mdz> infinity: he knows better than to push something like that in this week
[08:39] <fabbione> well xutils is now a dummy package.. so adding stuff back to it is a hack
[08:40] <infinity> mdz : May have been a product of sleep deprivation, who knows.
[08:40] <fabbione> mdz: i would personally prefer to add a mkdirhier package (arch all) and make xutils Depends: on it
[08:40] <mdz> infinity: there is no possible way it can be properly tested in time for the release
[08:40] <fabbione> mdz: but yeah a source package for 20 lines bash script is excessive
[08:40] <infinity> mdz : So, I'll back out the udeb addition for now, upload a binutils that fixes the stupid dependency issue, and drop nic-r-m from lrm?
[08:41] <mdz> infinity: I see no reason to drop nic-r-m
[08:41] <infinity> mdz : Well, if it never makes it anywhere near the installation media, it's okay.  I assume we can just blacklist it?
[08:41] <bob2> fabbione: mkdir -p?
[08:41] <fabbione> bob2: almost..
[08:41] <mdz> infinity: if it's already there, it's clearly not causing any harm
[08:41] <infinity> mdz : It's useless (and broken/bloated) right now.
[08:42] <infinity> I can unbloat it, but the intention of doing so was so that it would get used.

[08:43] <infinity> (dropping it is much easier than fixing it, that was the only reason I suggested it)
[08:44] <daniels> mdz: which ones?
[08:44] <infinity> Oh that's a shame, I even got the udeb creation right on the first shot, too.
[08:47] <jdub> GOOD MORNING FREEDOM LOVERS!
[08:48] <pitti> Hi jdub
[08:48] <fabbione> daniels: yo
[08:48] <pitti> mdz: permission to upload the fix for #16918?
[08:48] <bob2> fsvo morning
[08:49] <daniels> fabbione: sup
[08:49] <pitti> Hi JaneW
[08:50] <pitti> mdz: well, thinking about it, it's a feature, so we should better disable it at all for Breezy
[08:50] <jdub> jsgotangco: what's your bugzilla email?
[08:50] <jsgotangco> jdub<EMAIL_ADDRESS>[08:50] <fabbione> daniels: 16812 <-
[08:50] <fabbione> daniels: i am working on this.. right now.. patch on the way in a few secs
[08:50] <jdub> what does 'gelera' mean?
[08:51] <bob2> glarea?
[08:51] <jdub> jsgotangco: ah! was looking for jsg :)
[08:51] <jdub> bob2: no, in spanish or portuguese or something
[08:51] <jdub> jsgotangco: you now have ALMIGHT EDITBUGS
[08:52] <jdub> ALMIGHTY COMPLETE WORDS
[08:52] <jsgotangco> jdub, gyahhhhh
[08:52] <daniels> fabbione: okay
[08:52] <jsgotangco> jdub, thanks
[08:52] <daniels> tbh I never saw the point of mkdirhier
[08:53] <robitaille> jdub,   the fridge needs e-cards like Mandriva :)  http://club.mandriva.com/xwiki/bin/view/Main/ECards
[08:53] <bob2> daniels: HP-UX 0.5's mkdir didn't have -p
[08:53] <robitaille> then you can spam all your friends with Ubuntu announcements...
[08:53] <jsgotangco> ECards? Like "Happy Birthday from the Fridge?"
[08:53] <daniels> bob2: we're using mkdir -p in several places for 7.0, so it's obviously somewhat portable
[08:54] <bob2> hah
[08:54] <robitaille> jsgotangco,  its personalized.  A coworker sent one to me earlier as joke to tell me about the latest Mandriva version to try to bring me back
[08:54] <jdub> robitaille: heh, fear ;-)
[08:55] <daniels> hell, I think mkdir -p is even specified by POSIX
[08:55] <daniels> x is moving up in the world now.  requiring both C89 (changed late last year) *and* POSIX.
[08:57] <jdub> whoa!
[08:57] <jdub> #14502 :-)
[08:57] <Lathiat> hrm, is there any reason wpasupplicant is not in main?
[08:58] <moyogo> who should I contact to ask about the ttf-ubuntu-title font, I'd like to know if I can improve it (add characters)?
[08:58] <jdub> moyogo: andy fitzsimon
[08:59] <moyogo> jdub: thanks
[08:59] <jdub> moyogo: note that the font will be updated soon with vastly improved quality (but not more characters)
[08:59] <jdub> oh man, sabdfl on slashdot
[09:00] <moyogo> jdub: I really like the font, and would like to either improve or be able to fork it into an OpenType font
[09:01] <daniels> mdz: #15372, #16907 and #16910?
[09:02] <robitaille> jdub, it seems the wiki survived the slashdot.  I was really afraid some people would start editing his wiki entry just for the "fun" of it.
[09:02] <jdub> heh
[09:02] <jsgotangco> heh
[09:02] <jdub> the "need login to edit" thing keeps out stupid people *and* spam ;-)
[09:03] <ajmitch> it could be worse :)
[09:04] <fabbione> daniels: do we still check the MANIFEST at build time?
[09:05] <jdub> "Ubuntu might be popular within its own community, but the distro won't go mainstream until its image matures past high school sophomore."
[09:05] <fabbione> daniels: btw.. i don't see the need of it either.. let's just fix it and get over it
[09:05] <jdub> YES! :)
[09:05] <jdub> rock!
[09:05] <jdub> all these people who think 'dapper' means gay
[09:05] <jdub> man
[09:05] <daniels> fabbione: eh, if you want.  i think it's crack though, since it literally jsust is mkdir -p.
[09:05] <jdub> everybody knows it means 'metrosexual'!
[09:06] <daniels> jdub: it means 'wearing a salmon pink polo shirt with the collar turned up'
[09:06] <fabbione> daniels: yes i know.. i could see that.. but apparently a bunch of old Makefile still uses it
[09:06] <daniels> fabbione: and yes, we still check the MANIFEST
[09:06] <fabbione> daniels: ok
[09:07] <daniels> mdz: 15387 has svu and I rather bamboozled.  given that I'm the only one who's worked on XKB code for some years, and sergey's basically the only one working on layouts upstream ...
[09:07] <daniels> mdz: to be honest, I don't think we should bother shipping mkdirhier; let it be, and if they're building on non-POSIX systems, their problem.
[09:08] <mdz> daniels: finishing up a phone call, one moment
[09:08] <\sh> "Backgrounder: I'm 32 and counting, " *lol* what should I say ... I'm 34 and count down?
[09:08] <JaneW> hi pitti (delayed)
[09:09] <mdz> daniels: generally speaking, all of the x-keyboard-related bugs I've seen go by on ubuntu-bugs.  I've seen my-layout-reverts-to-us, error-activating-xkb-configuration and x-keyboard-vs.-gnome-keyboard bugs recently
[09:09] <daniels> mdz: if 15387 needs fixing, I need latitude to spend a fair amount of time on it; this requires plunging deeper into XKB code than I'm comfortable doing on distro time.
[09:09] <daniels> mdz: there's one x-keyboard-vs-gnome-keyboard bug that I'm looking at today, and is harmless; the first two, see above
[09:10] <mdz> daniels: it's a regression from hoary, and you and seb128 said it was a serious one
[09:10] <pitti> daniels: the gnome keyboard dialog: do you mean fixing the nodeadkeys issue?
[09:10] <daniels> mdz: ime, almost every 'can't activate keyboard layout' bug is 'ralt kicks to level3 vs alts toggle layouts'
[09:10] <daniels> pitti: and the lv3:lwin_switch issue, yeah
[09:10] <daniels> mdz: right, but again, I'd like explicit permission to go chasing it as it's a deep-voodoo-XKB bug
[09:11] <\sh> JaneW: good to see u...I
[09:11] <mdz> daniels: what are the odds that spending one day on it would net results?
[09:12] <daniels> mdz: 40-50%
[09:12] <\sh> JaneW: I wanted to ask you if you can put at least 2 or 3 kg of biltong in your luggage and take it to UBZ? the costs are mine so u'll get the money back :)
[09:12] <daniels> that probability rises with two days, but I'm not sure
[09:12] <daniels> it's a scary frigging bug
[09:12] <mdz> RC is due in two days
[09:13] <mdz> the bug is less than 3 weeks old; if it's so severe, why didn't anyone notice it earlier?
[09:14] <dholbach> morning mvo
[09:14] <daniels> whether it simply lurked until then or no-one picked it up is unknown
[09:14] <mvo> hey dholbach
[09:14] <mdz> daniels: you meant 15372 rather than 15387, right?
[09:14] <daniels> given that neither of the relevant code or layouts have changed
[09:14] <daniels> mdz: yeha
[09:15] <mdz> yes 16907 was one of the ones I was concerned about.you're sure it's really 15372?
[09:15] <JaneW> \sh: er I can try I am already a pack horse for the company and have LOADS of printed goods to haul....
[09:16] <daniels> layouts = [de  deadacute,de    de]
[09:16] <daniels> options = [grp grp:alts_toggle]
[09:16] <daniels> so, yes
[09:16] <JaneW> \sh: can you check if Cananda has rules about that? US and Australia wouldn't allow it in....
[09:17] <\sh> JaneW: ah well...don't tell anybody...but nobody is looking into the big bags...we "smuggled" at least 40kg of all good ZA stuff to germany ,->
[09:18] <JaneW> \sh: yeah, but I LOOK guilty even when I am not ;)
[09:18] <\sh> JaneW: it's not allowed normally without permission
[09:18] <jsgotangco> JaneW, biltong courier hehe
[09:18] <JaneW> \sh: I thought I was going to be arrested for taking a muffin into Oz.
[09:19] <\sh> JaneW: hmmm...well...give it mark then...he can say it's food from space ,-)
[09:19] <fabbione> ahahha
[09:19] <daniels> we have good muffins here, why on earth would you need to smuggle them?
[09:19] <jsgotangco> lol
[09:19] <JaneW> daniels: didn't want to waste a perfectly good SA one ;)
[09:20] <\sh> s/don't/doesn't/
[09:21] <JaneW> \sh: lemme check my luggage allowance if it's 20kgs I might not make it, if it's 35kgs - np... ok?
[09:21] <jsgotangco> jdub, do you know where the ubuntu font andyfitz made can be downloaded from?
[09:21] <JaneW> \sh: I suspect it's 20kgs though :(((
[09:23] <\sh> JaneW: yeah...I was too late with this request I think...who else comes from ZA to UBZ?
[09:24] <mdz> daniels: also #15414
[09:24] <jsgotangco> \sh,  probably adi attar
[09:24] <mdz> daniels: 16628 was marked pendingupload last week; where did the upload go?
[09:25] <jdub> jsgotangco: apt-get install ttf-ubuntu-title :-)
[09:25] <jdub> jsgotangco: but there's a better version coming
[09:25] <daniels> mdz: it's more complex than I hoped.
[09:25] <jsgotangco> jdub, thanks =)
[09:25] <daniels> long story short, I'm having fun with PCI subsystem IDs
[09:26] <schimmi> hmm, acpi does crazy thinks since last update this morning
[09:26] <mdz> PENDINGUPLOAD means "I've fixed it and just need to upload the new version"
[09:26] <crimsun> schimmi: make sure you're current. acpi-support -43 is supposed to fix a few things.
[09:26] <Keybuk> jdub: help!
[09:26] <mdz> mjg59: what's the master bug# for the sleep.sh thing?
[09:26] <Keybuk> jdub: you have an X1 right?
[09:26] <jsgotangco> schimmi, -43 was uploaded a few hours ago
[09:26] <daniels> Keybuk: X300
[09:27] <schimmi> crimsun: no, I am on 42.....
[09:27] <Keybuk> should be close enough, I hope
[09:27] <Keybuk> jdub: can you do lspci | grep IDE and let me know what's in it
[09:27] <mdz> 16958 looks like it
[09:27] <crimsun> schimmi: 43 is available as of 15 minutes ago
[09:27] <schimmi> ic
[09:27] <schimmi> brb
[09:27] <jdub> Keybuk: X300, lifeless has an X1
[09:27] <jdub> 0000:00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 01)
[09:27] <jdub> ^ but that's what's in the X300
[09:28] <Keybuk> jdub: ok, what's in /proc/ide -- anything besides "drivers" ?
[09:28] <jdub> hda ide0
[09:28] <Keybuk> hmm,ok
[09:30] <mjg59> mdz: Yup
[09:31] <mdz> daniels: if you're using PENDINGUPLOAD to mean fixed-upstream, we should create some other way to represent that
[09:32] <daniels> mdz: it hasn't been fixed-upstream
[09:32] <mdz> daniels: http://bugzilla.ubuntu.com/show_bug.cgi?id=11807
[09:33] <daniels> mdz: pendingupload in that case was, well, I had packages, and they were ready to upload
[09:34] <mdz> daniels: 16899 is another of the xkb issues I was concerned about
[09:37] <fabbione> Keybuk: nice screenshot :)
[09:37] <pitti> mdz: can I fix the pmount manpage to correct an inconsistent description? (#16843)
[09:37] <Keybuk> mdz: so, how would you like ntpdate, nfs, pppoe, etc. fixed for breezy?
[09:38] <mdz> Keybuk: the way which can't possibly introduce regressions
[09:38] <Keybuk> the only real way to fix it is to rewrite /etc/network/interfaces for people so all interfaces are "auto" and not "hotplug"
[09:38] <mdz> pitti: yes
[09:38] <Keybuk> which will increase the boot time by about a minute or more for people on laptops
[09:38] <mdz> I have a laptop and use auto without a minute increase in boot time
[09:38] <Keybuk> on both the wired and wireless interfaces?
[09:38] <daniels> mdz: i've needinfo'd 16899
[09:39] <mdz> we needn't use it auto on _all_ interfaces, ssurely
[09:39] <Keybuk> how do you pick which to change, and which not to change?
[09:39] <pitti> Keybuk: without knowing the context, changing hotplug to auto seems utterly wrong
[09:39] <mdz> Keybuk: go back to what we were doing in hoary, where we didn't have this problem?
[09:39] <Keybuk> we had this same problem in hoary
[09:40] <Keybuk> a few of the bug numbers are that old
[09:41] <Keybuk> fresh installs of hoary had the bug (upgrades from warty didn't, just as they won't in breezy)
[09:41] <Keybuk> I think we're just getting more new bugs because more people are installing fresh rather than upgrading
[09:41] <mdz> I've clobbered all my fresh hoary installs, but I thought we used auto
[09:42] <Keybuk> hoary used hotplug, I'm sure of it
[09:42] <Keybuk> it's an installer thing, the bit that writes the initial network-interfaces
[09:42] <mdz> if it isn't a regression, then we live with it
[09:42] <Keybuk> I can't remember which bit that is this morning though <g>
[09:44] <mdz> it would be netcfg, presumably
[09:44] <Keybuk> that's the chicken; I was looking for net-config, net-detect, et. al
[09:46] <Keybuk> yup, we wrote mapping hotplug in hoary too
[09:47] <Keybuk> that'd make most of the symptoms go away :D
[09:47] <dholbach> good morning seb128 :)
[09:48] <seb128> hey dholbach
[09:49] <pitti> hi seb128
[09:51] <bob2> ajmitch: hm, mcs is complaining about NUnut.Framework not existing, but it appears in the GAC.
[09:51] <Lathiat> hrm, gnome-volume-manager setting shows "Burn a CD or DVD when a blank disc is inserted" as off in my fresh install
[09:51] <Keybuk> heh, also in hoary we started portmap by default
[09:51] <Keybuk> which may have added a useful extra couple of tenths to the boot sequence
[09:51] <fabbione> daniels: http://people.ubuntu.com/~fabbione/xorg.diff <- you might want to add the proper C/R with the old xutils package because i don't remember when it was splitted out
[09:51] <seb128> hey pitti
[09:52] <pitti> Lathiat: with a fresh profile?
[09:52] <Keybuk> mdz: how about we do this ... when the first hotplug network interface starts configuring, touch a "doing hotplug" file ... then when the first one finishes, remove that file
[09:53] <Lathiat> pitti: yes
[09:53] <Keybuk> and in the mainline boot sequence, in S:S41hotplug-net, if that file exists, wait for it to go away
[09:53] <daniels> fabbione: eh, why don't we just do it in another source package or so?
[09:53] <Keybuk> that won't get the "two minute" problem because one will finish quickly
[09:53] <Keybuk> but it will take the symptoms away for now
[09:53] <mdz> Keybuk: sleep 5 isn't entirely insane
[09:54] <fabbione> daniels: a source package for a 20 line shell script seems a bit excessive to me when we are so close to release.. it will need seeding and stuff..
[09:54] <fabbione> daniels: this way it will be just a NEW
[09:55] <seb128> pitti: is that known: http://people.ubuntu.com/~seb128/languagepack.png ?
[09:55] <daniels> fabbione: isn't it built from the .c in the monolith?
[09:55] <seb128> pitti: the title of the note is the start of the text
[09:55] <fabbione> mdz: 5 secs is not always enough
[09:55] <pitti> Lathiat: darn, right. I'll ask mdz whether I can fix this, it is a regression
[09:55] <fabbione> daniels: not the shell script
[09:56] <fabbione> daniels: there are both shell and .c implementation.. i think we can rely on the shell one :)
[09:56] <Keybuk> mdz: yes, this will work, I shall add this "wait for the first hotplugging interface to finish" thing to hotplug
[09:56] <pitti> seb128: I'll ask mvo about the correct format
[09:57] <mdz> Keybuk: so long as it fails open if the file doesn't go away after some reasonable time
[09:57] <pitti> mdz: can I fix the g-v-m default settings for auto burning? This worked some weeks ago, and it's only a s/false/true/ in the gconf schema
[09:57] <seb128> pitti: k
[09:57] <Keybuk> mdz: yeah, will put a maximum wait time in there, where it'll carry on after
[09:57] <seb128> pitti: debian/patches/92_ubuntu-new_audio_notification.patch ... is there some text to translate here?
[09:58] <pitti> seb128: you can translate it in Rosetta
[09:58] <pitti> seb128: I'll do the same for German
[09:58] <seb128> nice
[09:58] <seb128> thanks
[09:58] <pitti> seb128: thanks to gnome.mk intltool love :-)
[09:59] <mvo> pitti: please use the description field only. the "name" field is no longer displayed. sorry
[09:59] <pitti> mvo: ouch
[09:59] <pitti> mvo: that's a really bad bug, we have fully translated name fields
[10:00] <pitti> mvo: so where does the header stop and the text begin?
[10:00] <mvo> pitti: can't we just move them down a bit?
[10:00] <pitti> mvo: and why is Name not displayed?
[10:00] <pitti> mvo: of course I can adapt the langpack note, but we also have to fix the kernel's and maybe the reboot note?
[10:00] <mvo> pitti: it was (ab)used as a kind of summary and not as a name
[10:01] <mvo> pitti: the kernel (hopefully) does use the generic reboot notification now?
[10:01] <pitti> mvo: if it was never intended to be displayed, why it is translatable?
[10:01] <fabbione> mvo: no and it won't
[10:01] <pitti> mvo: no, it doesn't
[10:01] <mvo> fabbione: why not?
[10:01] <fabbione> mvo: too intrusive change at this point in time
[10:01] <pitti> fabbione: is there a nonintrusive way to disable it completely?
[10:02] <pitti> fabbione: it is utterly broken for months
[10:02] <fabbione> pitti: nope..
[10:02] <pitti> darn
[10:02] <fabbione> it requires quite some love in debian/rules
[10:02] <mvo> pitti: ok, that changes the "display name" buisness of course :/
[10:02] <mvo> pitti: I'll fix it then
[10:03] <fabbione> i mean.. it can be done. but it's like a few hours of work to ensure we don't break anything
[10:03] <pitti> mvo: that means, Name-* becomes the header again, and Description the pure text?
[10:03] <fabbione> brb
[10:03] <pitti> fabbione: it takes hours to remove/disable the notice creation?
[10:04] <mvo> pitti: yes, looks like there is no other way (given that the kernel notification won't change)
[10:04] <pitti> mvo: I don't understand why it was changed in the first place, was there a special reason?
[10:05] <mvo> pitti: as I said, it was used as a summary and that dosn't looks right
[10:05] <mvo> pitti: but yeah, not a big issue
[10:07] <pitti> who is our bugzilla master?
[10:10] <Kamion> mdz: damnit, sorry, I got you to build the wrong tocd thing - you can tell I was tired
[10:11] <Kamion> mdz: I *have* to have either a reduced nic-restricted-modules or no nic-restricted-modules, regardless of whether it actually works. The current incredibly bloated one is causing other bugs, like us not being able to live up to our stated memory requirements.
[10:11] <Kamion> I've been trying to get it fixed for ages
[10:12] <infinity> Kamion : I'll fix it if that's required, but if we're not shipping static-udeb (and making it work), it's much less effort to just drop it.
[10:14] <pitti> Kamion: can I upload http://www.rafb.net/paste/results/8ooPPC76.html ? It's a regression that was introduced a few weeks ago (wrong configuration default)
[10:14] <Kamion> mdz: ?
[10:14] <Kamion> dropping it is going to get me plenty of hatemail
[10:14] <infinity> Kamion : If we're not using it, dropping it or fixing it amount to the same thing, no?
[10:14] <Kamion> pitti: just upload things - they end up in the approvals queue for us
[10:14] <infinity> Kamion : And apparently, not using it is what we're doing.
[10:15] <pitti> Kamion: ah, I see
[10:15] <Kamion> infinity: with respect I think that's a mistake that we'll regret
[10:16] <janimo> infinity,Kamion is the large restricted modules udeb problem solved?
[10:17] <Kamion> janimo: oh for goodness' sake, we're *discussing* that right now
[10:17] <janimo> I have just logged in sorry
[10:17] <Kamion> sorry, you only joined in the middle of it, I know
[10:17] <fabbione> pitti: yes.. the changes in debian/rules are quite simple.. it takes hours to do test builds
[10:19] <Kamion> I'd like to see the l-r-m udeb fix uploaded just so that at least we can argue about it with it in the approvals queue where we can assess the riskiness more accurately
[10:19] <infinity> Kamion : Alright.  I'll hold off on the matching binutils until I'm told to send that along too.
[10:20] <infinity> Kamion : Or, should I upload that too, and let you and mdz argue about whether to reject or accept it?
[10:20] <Kamion> *sigh* I'll drop the priority of nic-restricted-modules for now, so that at least it doesn't break the installer quite so badly
[10:21] <Kamion> it'll still be bloating installation media by 4MB or whatever unless unseeded, though
[10:31] <Keybuk> right, let's reboot to test this
[10:33] <daniels> mdz: so, in summary, I'd like to leave mkdirhier alone
[10:38] <Keybuk> excellent, worked perfectly
[10:45] <daniels> Kamion: sorry to bug you, but is %% a sensible thing to be using in maintainer scripts
[10:46] <Treenaks> daniels: if you're writing .spec files ;)
[10:47] <daniels> heh
[10:47] <daniels> daniels@ephemera:~% FOO=xfooxbarx
[10:47] <daniels> daniels@ephemera:~% echo ${FOO%%x}
[10:47] <daniels> xfooxbar
[10:47] <`anthony> I'm confused - all of a sudden, ethereal and tethereal won't start, I get Could not set capabilities: Operation not permitted
[10:47] <daniels> (FOO is really emo)
[10:48] <`anthony> this is after doing a dist-upgrade of breezy
[10:48] <daniels> (but less emo after that substitution
[10:48] <Kamion> daniels: it's portable shell, yes
[10:48] <`anthony> this is as root or a normal user.
[10:48] <daniels> Kamion: thanks
[10:48] <Kamion> daniels: although a bit pointless in the example you give there, since it's identical to %
[10:49] <Kamion> (%% is longest-possible-match)
[10:49] <`anthony> hm - sorry, I was wrong, it's only when run as root I get that error.
[10:49] <fabbione> `anthony: can you show me lsmod please?
[10:49] <fabbione> use pastebin or whatever
[10:49] <fabbione> no flood here
[10:49] <`anthony> fabbione: sure
[10:50] <`anthony> http://pastebin.com/382440
[10:51] <fabbione> when did you upgrade to breezy?
[10:51] <`anthony> couple of weeks ago.
[10:51] <fabbione> or better.. when was the last upgrade?
[10:51] <fabbione> ok it has been fixed already
[10:51] <`anthony> dist-upgrade? a couple of hours ago.
[10:52] <fabbione> short version: you need to modprobe capabilities
[10:52] <fabbione> long version: it has been fixed in initramfs
[10:52] <daniels> the short version was longer than the long version
[10:52] <fabbione> so you need to regenerate the initramfs (if there was no kernel upgrade) and reboot into the new one
[10:52] <`anthony> fabbione: Ok. I rebooted after the upgrade, do I need to do anything else?
[10:52] <`anthony> there was a kernel upgrade
[10:52] <`anthony> gonna try another reboot.
[10:53] <`anthony> back in a couple
[10:53] <fabbione> no wait
[10:53] <fabbione> do this:
[10:53] <fabbione> modprobe capability
[10:53] <fabbione> mkinitramfs -o /boot/initrd.img-`uname -r`
[10:53] <`anthony> ok. That makes it work.
[10:53] <fabbione> (as root)
[10:54] <fabbione> and try to reboot
[10:54] <`anthony> hang on - I'm running 2.6.12-8-686. I coulda sworn there was a newer kernel in the last upgrade.
[10:54] <fabbione> there is
[10:54] <fabbione> 2.6.12-9
[10:54] <`anthony> what the heck.
[10:54] <fabbione> so perhaps you didn't boot in the new one
[10:54] <fabbione> :)
[10:55] <`anthony> right. but I don't understand - I don't recall seeing multiple kernels in boot screen.
[10:55] <fabbione> check again.. it must be there
[10:55] <`anthony> stupid computer.
[10:55] <fabbione> or you didn't upgrade properly
[10:56] <`anthony> yep. it's there.
[10:56] <`anthony> gonna reboot again.
[10:56] <`anthony> and punch grub in the head if that doesn't work.
[10:56] <`anthony> back in a couple
[11:06] <`anthony> ok. beats me why rebooting last time defaulted to the old kernel, and this time to the new.
[11:07] <`anthony> maybe it's random selection of kernels in grub. I didn't hit any keys at all last time. Oh well. Going to file it under either "cosmic rays" or "user is stupid".
[11:07] <bob2> you might have been drunk?
[11:08] <`anthony> I wish.
[11:08] <HrdwrBob> little from column a...
[11:08] <`anthony> yeah, that's probably more like it.
[11:08] <fabbione> bbl
[11:10] <`anthony> ta for the help
[11:17] <daniels> pitti: ping
[11:20] <lamont> seb128: why does gnome-session hate ia64?
[11:20] <seb128> lamont: [   ]  gnome-session_2.12.0-0ubuntu1_20050906-1214-ia64-successful.gz   ?
[11:21] <seb128> lamont: what does it do ?
[11:21] <lamont> segv
[11:21] <seb128> utch
[11:21] <seb128> got a backtrace ?
[11:21] <daniels> pitti: if you've still got that crazy mac with the lv3:lwin_switch and nodeadkeys, could you please try an upgrade with p.u.c/~daniels/xserver-xorg.config?
[11:21] <lamont> seb128: would love to know how to get one
[11:21] <seb128> when it crash, do you get this bug-buddy dialog to send a bug upstream?
[11:21] <seb128> it has the backtrace
[11:22] <seb128> other way ... start another wm, let's say wmaker and run gnome-session under gdm from here
[11:22] <seb128> gdb
[11:25] <lamont> pitti: and I need to squeeze about 2 MB from the livecd ISO on ia64...  got any hated-languages?  (all the others are oversize for 650MB media, ia64 is oversize for 700MB)
[11:26] <lamont> ignore the current image, that was an attempt at things by dropping a kernel - not a really good option
[11:28] <lamont> well, clicking 'inform developers' is singularly unhelpful
[11:31] <mvo> infinity: when update-notifier went mad, what operations did you perform? a normal upgrade? do you have a log by any chance what applications got upgraded then? I assume you can't reproduce it?
[11:32] <lamont> seb128: what's the smallest wm I can grab?
[11:32] <talios> anyone here know anything about ubuntu's squeak packages?  I see the inisqueak script mentioned in squeaks manpage, and an inisqueak manpage, but sign of the actual script, bug with the package maybe?
[11:32] <lamont> actually, that should work.
[11:33] <zyga> mvo: hello :)
[11:34] <mvo> hi zyga
[11:34] <lamont> seb128: any cmdline args to gnome-session?
[11:34] <seb128> lamont: wmaker is quite small
[11:34] <seb128> no
[11:36] <lamont> Program received signal SIGSEGV, Segmentation fault.
[11:36] <lamont> [Switching to Thread<PHONE_NUMBER>251442688 (LWP 5455)]
[11:36] <lamont> 0x2000000001256c20 in free () from /lib/libc.so.6.1
[11:36] <lamont> #0  0x2000000001256c20 in free () from /lib/libc.so.6.1
[11:36] <lamont> #1  0x2000000000234690 in IceFreeListenObjs () from /usr/lib/libICE.so.6
[11:36] <lamont> #2  0x400000000001b960 in clean_ice ()
[11:36] <lamont> after several ICE errors earlier
[11:36] <lamont> _IceTransTransNoListen: unable to find transport: tcp
[11:36] <lamont> _IceTransmkdir: ERROR: euid != 0,directory /dev/X will not be created.
[11:36] <lamont> _IceTransmkdir: ERROR: Cannot create /dev/X
[11:36] <lamont> _IceTransPTSOpenServer: mkdir(/dev/X) failed, errno = 13
[11:36] <lamont> _IceTransOpen: transport open failed for pts/bld-27:
[11:36] <lamont> ...
[11:38] <seb128> lamont: seems to not be a GNOME issue ...
[11:38] <lamont> other than to the end user... :-(
[11:39] <lamont> but yeah.
[11:40] <fabbione> DOH!
[11:40] <fabbione>  /dev/X ???
[11:41] <jmg> hey guys, i need to file a bug due to state of suspend on my laptop... but not sure if i should be filing under acpi or under klaptop
[11:41] <fabbione> acpi-support
[11:41] <fabbione> use keyword laptop
[11:42] <jmg> bugzilla?
[11:42] <jmg> or malone?
[11:43] <carlos> pitti, hi, around?
[11:43] <ploum> Hello
[11:43] <pitti> lamont: I didn't care for the ia64 image yet, since there were no images I could base size calculations on
[11:43] <pitti> Hi carlos
[11:43] <slomo> seb128: is it a known problem that evolution-alarm-notify crashes on gnome startup?
[11:43] <lamont> pitti: ah, makes sense
[11:43] <Kamion> jmg: bugzilla
[11:43] <seb128> slomo: no
[11:43] <pitti> lamont: I have a clever script that makes determining the fitting set of langpacks easy
[11:43] <jmg> Kamion: thx
[11:43] <slomo> seb128: fine, i'll file a bugreport then ;)
[11:43] <carlos> pitti, I'm going to prepare a language pack all days this week so you can choose whatever you want to generate the latest language pack. Is that ok for you?
[11:44] <ploum> I've two soundard (one onboard and another). The only way I've found to use the other one was to blacklist the onboard module (intel8x0) in hotplug conf.
[11:44] <seb128> slomo: with a backtrace please or it's useless
[11:44] <ploum> seems very unfriendly
[11:44] <pitti> daniels: you mean just upgrade the current breezy xorg to that versoin, or upgrade hoary to it?
[11:44] <slomo> seb128: sure
[11:44] <carlos> pitti, btw, we had a problem with control-center that should be fixed today, that's why it's a bit outdated
[11:44] <pitti> carlos: that's great
[11:44] <ploum> against wich package must  I report a bug ?
[11:44] <seb128> thanks
[11:44] <carlos> pitti, the others should already be up to date
[11:44] <pitti> carlos: what about evolution-2.4?
[11:44] <pitti> carlos: from the Friday tarball I removed c-c and evo
[11:44] <seb128> ploum: the sound capplet has a soundcard selector
[11:44] <pitti> carlos: the others were fine
[11:45] <fabbione> jmg: bugzilla
[11:45] <carlos> pitti, evolution is being imported atm, will be available with the language packs tomorrow
[11:45] <ploum> seb128 : "changer le priphrique" ?
[11:45] <carlos> after  breezy release, I will move the language pack generation to production so we don't need to wait for the staging sync
[11:46] <seb128> ploum: gnome-sound-properties ... try to find it on the screen
[11:46] <seb128> ploum: there is no that many option on this capplet :)
[11:47] <ploum> aaaah!
[11:47] <lamont> daniels: ping
[11:47] <ploum> I didn't see this ...
[11:47] <ploum> ok, I'm lame
[11:47] <seb128> :)
[11:47] <ploum> thanks ;-)
[11:47] <seb128> np
[11:47] <lamont> daniels: wth is _IceTransTransNoListen defined?
[11:48] <daniels> lamont: by /usr/include/X11/Xtrans/transport.c probably, because of the absence of TRANS_SERVER
[11:48] <daniels> pitti: either
[11:48] <pitti> daniels: ok, I'll reconstruct the broken xorg.conf and upgrade
[11:48] <lamont> daniels: source package?
[11:48] <daniels> lamont: xtrans-dev
[11:49] <daniels> lamont: probably source package xtrans
[11:49] <slomo> seb128: we won't get abiword 2.4 for breezy?
[11:49] <daniels> pitti: you need to reconstruct the broken debconf answers ;)
[11:49] <lamont> ok
[11:49] <daniels> lamont: basically, it'll be getting /dev/X instead of /tmp/.ICE-unix because of a lack of ... maybe ISC
[11:49] <daniels> i can't remember which
[11:49] <lamont> ISC?
[11:50] <pitti> daniels: not sure what you mean, but I didn't see/change any debconf answers
[11:50] <lamont> daniels: wth does this mean: _IceTransTransNoListen: unable to find transport: tcp
[11:51] <daniels> lamont: that it wasn't built with -DTCPCONN, and rightfully so.  don't worry about it
[11:51] <daniels> pitti: hm
[11:52] <pitti> daniels: ok, my xorg.conf now matches /var/lib/xfree86/xorg.conf.md5sum
[11:52] <pitti> daniels: i. e. I have the exact same state as after the upgrade
[11:52] <lamont> daniels: let me rephrase that... I'm trying to figure out why we segv in IceFreeListenObjs
[11:52] <daniels> lamont: libice6-dbg might be useful there, I guess ...
[11:53] <daniels> lamont: the PTS errors will beharmless, don't worry about them
[11:54] <pitti> daniels: ah, there's no debs, but a script - I just execute it with sudo?
[11:54] <daniels> lamont: for _IceTrans* functions, strip the IceTrans and then grep for it over /usr/include/X11/Xtrans
[11:54] <daniels> lamont: xtrans is god's punishment for touching yourself at night.
[11:54] <daniels> pitti: ah, don't worry about it, think I've got it figured out here
[11:56] <lamont> well, that was diff.  now we die in strlen()
[11:57] <pitti> Kamion: can you sync packages from Debian? I need some universe syncs for security updates
[11:57] <lamont> heh... maybe if I logged in first
[12:01] <lamont>   network_id = 0x49a90 <Address 0x49a90 out of bounds>,
[12:01] <lamont> neato
[12:01] <lamont> daniels: do I care about this? ** (gnome-session:5244): WARNING **: Unable to lock ICE authority file: /home/lamont/.ICEauthority
[12:01] <daniels> yeah, probably
[12:02] <daniels> sounds like libICE is completely broken on your platform
[12:02] <Kamion> pitti: yes
[12:02] <smurf> lamont: I've updated kbd-chooser, please test
[12:02] <lamont> smurf: that'll have to be once I get to work...  in about 4-6 hours
[12:02] <pitti> Kamion: can you please sync gtkdiskfree 1.9.3-4sarge1, and apachetop 0.12.5-1sarge1 or 0.12.5-5 ?
[12:02] <Kamion> smurf: kbd-chooser takes a while to propagate to anywhere people can usefully test it, because it's in initrds
[12:03] <lamont> daniels: is this normal?
[12:03] <lamont> _IceTransOpen: transport open failed for pts/bld-27:
[12:03] <lamont> _IceTransMakeAllCOTSServerListeners: failed to open listener for pts
[12:03] <lamont> _IceTransISCOpenServer: Protocol is not supported by a ISC connection
[12:03] <lamont> the last ICE printf is:
[12:03] <pitti> Hey haggai
[12:03] <lamont> _IceTransMakeAllCOTSServerListeners: failed to open listener for sco
[12:04] <smurf> Kamion: He can build his own ;-)
[12:05] <Kamion> pitti: done
[12:05] <lamont> Kamion: so does kbd-chooser then require a d-i daily, or just a CD crank?
[12:05] <pitti> Kamion: thanks; dia sync would also be nice; no big changes between -11 (breezy) and -14 in Debian, and -15 has a security fix
[12:05] <Kamion> lamont: d-i daily
[12:06] <pitti> Kamion: however, I can also backport the patch easily
[12:06] <daniels> lamont: don't worry about those
[12:06] <lamont> Kamion: if I cron one of those for an hour or so from now on hppa, could you crank it through while I sleep?
[12:06] <Kamion> pitti: dia's in main; please backport
[12:07] <Kamion> lamont: yes
[12:07] <pitti> Kamion: alright
[12:07] <lamont> daniels: ok, then what routine do I want look at for who's assigning listenObjs[] ->network_id?
[12:07] <lamont> oh feh./
[12:08] <lamont> actually, keyboard-chooser made it through before evo.
[12:09] <zyga> hi
[12:10] <zyga> there is an issue with our ruby version
[12:10] <zyga> we ship 1.8.2-9 which claims to be 1.8.3 (it has many patches)
[12:10] <zyga> that version doesn't work with alexandria 0.6.1 (internal ruby errors)
[12:11] <zyga> I did a debdiff of ruby as suggested on #u-motu
[12:11] <zyga> it's over 4 megs long unfortunatly
[12:11] <zyga> debdiff from our version to debian's unstable 1.8.3-1
[12:11] <slomo> zyga: maybe apply the patches from our version and diff against that
[12:11] <zyga> the debdiff is here: http://www.suxx.pl/ubuntu/ruby.debdiff
[12:12] <ploum> http://bugzilla.ubuntu.com/show_bug.cgi?id=16964 : I'm not sure I understand what this bug means. It's me or there's no bug at all ?
[12:13] <zyga> slomo: I'm not good at this stuff yet really
[12:17] <lamont>   network_id = 0x49a90 <Address 0x49a90 out of bounds>,
[12:17] <lamont> interesting...
[12:17] <lamont> becuase 0x6000000000049a90 contains "unix/bld-27:/tmp/.ICE-unix/5248"
[12:17] <lamont> or maybe just xorg
[12:18] <lamont> daniels: guesses on who's casting pointers through 32bit ints?
[12:18] <seb128> ploum: you may want to /j #ubuntu-desktop
[12:18] <lamont> ../../src/listenwk.c:84: warning: implicit declaration of function '_IceTransGetMyNetworkId'
[12:19] <lamont> I wonder if that would do it, eh?
[12:19] <lamont> daniels: you have time to deal with all of the implict defs found in people.ubuntu.com/~lamont/buildLogs/libi/libice/1\:6.3.5-3/libice_1\:6.3.5-3_20050601-0420-ia64-successful.gz ??
[12:20] <lamont> ../../src/listenwk.c:84: warning: cast to pointer from integer of different size
[12:20] <lamont> that's the real fatality
[12:21] <daniels> wonder why that's not defined
[12:22] <lamont> only 20 lines of 'implicit definition of...' crap
[12:22] <daniels> lamont: edit that file, add #define ICE_t and #define TRANS_SERVER before the Xtrans.h include; does that help?
[12:22] <daniels> lamont: you may also need TRANS_CLIENT and/or TRANS_REOPEN
[12:23] <daniels> though why this doesn't also fail on amd64 is beyond me
[12:23] <lamont> because the upper 32 bits on amd64 pointers tend to be zer0
[12:23] <daniels> lamont: you may also want to do the same with src/misc.c
[12:23] <daniels> and src/listen.c
[12:23] <daniels> and src/connect.c
[12:23] <mjg59> Grngk.
[12:23] <mjg59> Right.
[12:23] <mjg59> DAILY INSTALL TIME
[12:26] <lamont> accept, connect, listen, listenwk, misc, shutdown
[12:27] <lamont> #define ICE_t
[12:27] <lamont> #define TRANS_SERVER
[12:27] <lamont> #define TRANS_CLIENT
[12:27] <lamont> #define TRANS_OPEN
[12:27] <lamont> any reason not to do all 4 in each of the files?
[12:30] <daniels> REOPEN, not OPEN
[12:30] <daniels> you can do all four, but finding the most minimal set needed would be most useful for me
[12:33] <lamont> sigh, ok
[12:33] <haggai> pitti: hiya
[12:42] <lamont> ../../src/authutil.c:58: warning: function declaration isn't a prototype
[12:42] <daniels> lamont: yes we are.
[12:43] <daniels> lamont: we're now requiring C89 instead of K&R.  so yeah, in the 80s, albeit just.
[12:44] <lamont> daniels: people.ubuntu.com/~lamont/libice.diff
[12:44] <lamont> seems to be minimal or near minimal
[12:45] <mvo> pitti: update-notifier fixed to display the langpack notifications again correctly
[12:46] <lamont> daniels: you want the privilege of uploading, or shall I?
[12:47] <daniels> lamont: rockin, seems sensible to me
[12:47] <daniels> lamont: all yours if you want it
[12:47] <lamont> Kamion: please to approve the libice upload, it lets windowing work on ia64, by fixing missing implicit defs.  kthxbye
[12:48] <lamont> gonna call it -4 though, not -3.1... K?
[12:48] <Kamion> noted
[12:49] <daniels> Kamion: it's the right fix
[12:49] <Kamion> diff looks suitably non-intrusive if you (plural) can confirm it doesn't make the header files do other wacky things
[12:49] <daniels> i'll commit it upstream in a sec; ice would be the only libxtrans-using module I haven't fixed it for already
[12:49] <daniels> Kamion: i'm willing to assert that it doesn't
[12:49] <Kamion> ok, thanks
[12:49] <Kamion> go ahead thn
[12:49] <Kamion> then
[12:49] <Kamion> what does '#define ICE_t' do anyway?
[12:49] <daniels> Kamion: based on past experience.  admittedly my recollection may be a little hazy, since every time I have to do anything with xtrans, there's usually an empty bottle of vodka in the recycling bin the next day, but yeah.
[12:50] <Kamion> other than being a bad joke
[12:50] <daniels> Kamion: xtrans is polymorphic code based on #defines
[12:50] <daniels> Kamion: so you have common functions which change their name based on #define foo_t (X11_t, XSERV_t, FONT_t, FS_t, ICE_t)
[12:50] <Kamion> that's a nasty abuse of _t
[12:51] <Kamion> (which at least C99 reserves for the implementation, BTW, and C89 might do as well ...)
[12:51] <daniels> /usr/include/X11/Xtrans contains a bunch of files which change like such (and expose varying functionality based on other #defines)
[12:51] <Kamion> but obviously not something fixable for breezy ;)
[12:51] <daniels> xtrans is a nasty abuse of fucking *everything*
[12:51] <daniels> seriously.  #include'ing C files, which change function names based on some #define.
[12:51] <daniels> it needs to go completely, not just lose the _t.
[12:52] <daniels> but yeah, as I said, C89 was only made a requirement early this year or late last year or something.  i think xtrans predates it.
[12:52] <daniels> at a time where you wanted to switch between unix sockets and decnet.
[12:53] <daniels> if it explains anything, the same dude who wrote xtrans also wrote the current X module loader.
[12:53] <lamont> Uploading via ftp libice_6.3.5-4_source.changes: done.
[12:53] <lamont> Kamion: but X is part of the implementation... :-)
[12:54] <Kamion> actually I wonder if I'm wrong about _t; I can find a statement that int*_t and uint*_t are reserved
[12:54] <lamont> the problem with C's reserved namespace is that it doesn't say what the middle layers may use...
[12:54] <lamont> but must go back to bed now...
[12:55] <lamont> Kamion: tomorrow I'll make a pass through the rest of the log files looking for known-fatal ones...  Then run in circles and scream and shout
[12:55] <Kamion> yeah, looks like I'm wrong
[12:56] <daniels> lamont: it's only Xtrans that has this particular pathological evil, so just check everything that reverse build-deps on that
[12:57] <daniels> i'm pretty sure libx11, xserver-xorg/xorg-server, libfs, libxfont, are okay
[12:57] <lamont> daniels: only Xtrans has implicit deps?  I don't think so.
[12:57] <lamont> er, defs
[12:58] <daniels> lamont: well, only Xtrans has them, and then has some murderously bad casting around, within X
[12:58] <daniels> leading _ is reserved?
[12:58] <lamont> there are _LOTS_ of packages that have implicit defs of various things, from strcpy to xtrans...
[12:59] <lamont> daniels: per the ANSI spec, yes.
[12:59] <daniels> christ
[12:59] <daniels> well there goes half the archive
[12:59] <lamont> iz reserved "for the implementation"
[12:59] <daniels> that's stupid
[12:59] <Kamion> it's not quite that
[12:59] <lamont> no, that's why the ansi namespace guarantees (with a few documented exceptions) that the user can have any name he wants, unless it begins with _: namespace purity
[01:00] <Kamion> -- All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
[01:00] <Kamion> -- All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.
[01:00] <lamont> the part the spec forgot was to declare (1) what is/is not "implementation", and (2) what do all the middleware libraries do?
[01:00] <Kamion> (C99 7.1.3)
[01:00] <daniels> oh, C99.  i won't have to worry about that for ten years yet.
[01:00] <Kamion> I very much doubt that's new in C99
[01:01] <daniels> hm.
[01:01] <lamont> X libs fall squarely into the "we're not part of user space, but we're not part of implementation either, what the hell do we do for our namespace?" camp
[01:01] <lamont> which means that they pick _$mumble and pray
[01:01] <Kamion> I don't see it in the foreword
[01:02] <lamont> it's part of the original ansi defn
[01:02] <Kamion> (list of major changes from C89)
[01:02] <lamont> late 80's would be about right for my recollection of the screaming time.
[01:02] <Kamion> surely X has a perfectly good X* namespace
[01:02] <lamont> (somewhere 85-95 ish...)
[01:03] <lamont> Kamion: well, but what about internal, non-static names?
[01:03] <Kamion> as long as each middleware library declares what namespace it uses, there's no problem, surely; if you're using that library, you know about it
[01:03] <lamont> the API is pretty much X*, and the users tend to avoid X* accordingly, but...
[01:03] <Kamion> or should
[01:03] <lamont> right
[01:03] <Kamion> lamont: XInternalFoo?
[01:03] <Kamion> or XIntFoo or whatever
[01:03] <lamont> XDontCallMeFoo
[01:03] <Kamion> XDontCallMeShirley
[01:04] <lamont> heh
[01:05] <daniels> Mithrandir: ?
[01:05] <lamont> Mithrandir: so does infinity
[01:05] <daniels> we use _foo for internal stuff
[01:05] <daniels> like _IceFoo, which is internal API that libSM uses
[01:05] <daniels> WAY TO GO GUYS
[01:05] <lamont> daniels: right.  THat'd be a violation of spec, in the purist sense.
[01:06] <daniels> even better is the prototype of same in the libSM source, with a comment above saying 'this is libICE private API'
[01:06] <lamont> Kamion: the issue comes down to how good the lib is at being pedantic about namespace.
[01:06] <lamont> most aren't.
[01:06] <Mithrandir> daniels: I'm trying to fix mysql by (ab)using lucifer.  It gives me flashbacks to 1200/75.
[01:06] <daniels> Mithrandir: the link has been doing weird things lately.  i was getting thirty-second burstlag to my desktop earlier.
[01:06] <Kamion> AFAIK _[a-z] .* is fine for identifiers in function, block, or function prototype scope
[01:06] <daniels> i think we're 1500/256 at the moment
[01:07] <Mithrandir> daniels: it's working fine, it's just that it's a long way from where I'm sitting.
[01:07] <Mithrandir> daniels: and that 1500/256 is kbit/sec, I was talking bit/sec. :-P
[01:07] <daniels> heh
[01:07] <daniels> Mithrandir: think you've got crap latency, eh?
[01:08] <Treenaks> daniels: you're just on the wrong side of the planet
[01:08] <Kamion> ah, but function prototype scope only covers formal arguments, not the function identifier itself
[01:08] <Treenaks> daniels: latency-wise
[01:08] <daniels> Mithrandir: i just started a xorg source upload and now I'm off to have dinner.  cheers.
[01:09] <Kamion> lamont: even glibc only started getting much more pedantic about it relatively recently
[01:10] <Mithrandir> daniels: doesn't seem to affect me.  Have a nice dinner.
[01:13] <fabbione> Kamion: how would you feel about 2x256MB USB keys in RAID1 for /boot + / and the rest on a 20GB USb disk?
[01:13] <Kamion> fabbione: *shrug* if you can get grub to boot off that, more power to you :)
[01:14] <fabbione> Kamion: ehehe let's try :)
[01:14] <fabbione> but it should. d-i sees the disks as SCSI
[01:14] <Kamion> BTW, if #16094 rings a bell with anyone, I'd be interested
[01:15] <Kamion> oh, wow, major partitioning speedup by fixing partconf/find-partitions to ignore read-only devices
[01:16] <Diziet> I thought _... identifiers were only reserved if they had external linkage.  BICBW about  static int _zonk;
[01:16] <daniels> the reply that says<EMAIL_ADDRESS>try that, it works perfectly for me!' is pure gold.
[01:17] <infinity> mvo : <poke>
[01:17] <fabbione> Kamion: *perhaps* he needs to remove the old md superblock.
[01:17] <Kamion> Diziet: C99 says "identifiers with external linkage" elsewhere in the same section but only "identifiers" for the _[a-z] .* case
[01:17] <Kamion> I don't know about C89
[01:17] <fabbione> Kamion: old super blocks might confuse stuff around.. specially if they don't change position for a different partition size
[01:18] <infinity> mvo : When update-notifier went nuts, I hadn't done anything previously.. It just... Went nuts... And after a reboot, no, I can't reproduce it.
[01:18] <Kamion> fabbione: how does one most easily remove the old superblock?
[01:18] <fabbione> Kamion: sec.. i need to look that up
[01:20] <fabbione> mdadm --zero-superblock <pathtodevice>
[01:20] <fabbione> but that needs to be done with all the raids turned off
[01:20] <fabbione> otherwise they get rewritten
[01:21] <Kamion> turned off as in not assembled yet, or turned off as in mdadm --stop?
[01:21] <fabbione> mdadm --stop will do
[01:21] <Kamion> if they're not assembled yet then I'd've thought /dev/md/0 etc. wouldn't mean anyway
[01:21] <Kamion> s/anyway/anything/
[01:21] <fabbione> if they are not assembled is ok too
[01:22] <fabbione> but if they get started for some reasons, you need to stop them first
[01:22] <fabbione> done that, zero the superblocks
[01:22] <fabbione> recreate/start again the raids
[01:22] <Kamion> if they aren't assembled, what device do you use? the underlying physical volumes?
[01:23] <fabbione> you need to use the real partition/hd
[01:23] <Kamion> ok
[01:23] <fabbione> you never use /dev/md
[01:23] <mvo> infinity: oh well. not restarting dbus by any chance or something like this :) ?
[01:23] <Kamion> fabbione: can you think of any way to test whether this is the problem, non-destructively?
[01:24] <Mirv> mvo: did you write that get-18n script in language-selector?
[01:25] <fabbione> Kamion: i am thinking...
[01:25] <fabbione> i am not sure i understand 100% what he wants to achieve.. i know tht old md blocks are a pain..
[01:26] <Kamion> I can imagine adding a partman commit script which zeros the superblocks of new RAID physical volumes before going into the RAID configuration screen; I think that's too risky for breezy though, because if done wrong it could lose data
[01:26] <fabbione> Kamion: he wants to: raid the 2 6.4GB in a stripe and than raid1 with the 15G?
[01:26] <Kamion> fabbione: I have no idea what he's trying to do; the relevant point seems to be that he created *new* RAID physical volumes and mdcfg didn't see them all
[01:26] <fabbione> Kamion: no you really don't want to do that.. i might go there just to start again a raid :)
[01:27] <fabbione> Kamion: it gives the feeling he is trying to do md partitioning, that's not exctly supported
[01:27] <Kamion> fabbione: I think he's trying to have two RAID0 pairs, but not RAID those two pairs together, but use them as LVM PVs or something
[01:28] <Diziet> Kamion: Did someone approve the metacity `new upstream' for the long titles crash ?  I'm not convinced that this is the right answer to this problem at this stage.
[01:28] <infinity> mvo : Could have been an upgrade from several hours previous that I hadn't restarted/rebooted yet.  But I know I wasn't doing anything much at all when I started noticing the churn.
[01:28] <jdub> mdz, jbailey: YOU POUR COLD WATER ON MY HEART (and rightly so) re: shutting up grub
[01:28] <infinity> mvo : Even so, that's hardly "reasonable" behaviour.
[01:28] <Kamion> fabbione: the problem he describes is not doing anything unsupported, regardless of whether he's trying to do anything unsupported later
[01:28] <mvo> infinity: no, certainly not :/
[01:29] <Kamion> Diziet: yes, I did; standing policy since warty is to take the newest GNOME upstream versions we can
[01:29] <Kamion> I looked over the diff and it didn't seem insane, although I didn't test it
[01:29] <Diziet> kamion: OK.  Hmmm.
[01:30] <Kamion> Diziet: (hence why Sebastien and Daniel are busy uploading all of GNOME 2.12.1 at the moment)
[01:30] <Diziet> I think I will change it in firefox anyway.
[01:31] <fabbione> Kamion: ahhhh ok.. i think i understand what it is trying to do...
[01:31] <fabbione> Kamion:  i will try to reproduce it later
[01:31] <janimo> daniels, any idea what could make 'xset dmps force off' only dim the screen now, while about a week ago it turned it off? ati driver, X600 chip
[01:31] <fabbione> i need to get some rest becuase headacke is showing up
[01:31] <daniels> janimo: no idea, we haven't touched that code for ages -- try downgrading the kernel?
[01:32] <janimo> daniels, ok thanks
[01:33] <Kamion> fabbione: problem is the only machine I have with multiple disks is my server, which I'm not taking down for installer tests
[01:33] <pitti> Hi seb128
[01:33] <fabbione> Kamion: yeah don't worry
[01:33] <Kamion> I don't know if it's a multiple-disks thing, or maybe a SCSI thing
[01:34] <fabbione> it can be reproduced on a one disk machine i think
[01:34] <Kamion> oh, no, he's using IDE
[01:34] <seb128> hey pitti
[01:34] <fabbione> it's just question of faking 4 partitions
[01:34] <infinity> mvo ; Does a greek install tweak/mangle the console font in /etc/console-tools/config, or did you do so by hand?
[01:34] <fabbione> and try to raid them as he sais
[01:34] <Kamion> fabbione: I just tried that, and it worked fine
[01:34] <Kamion> fabbione: faking how?
[01:34] <fabbione> Kamion: i did several RAID installs.. never had a single problem
[01:35] <Kamion> fabbione: I'm seriously wondering if it's a missing udevstart or something
[01:35] <Kamion> but it doesn't seem to be all that racy
[01:35] <mvo> infinity: I didn't tweaked anything by hand, it is/was a stock greek install
[01:35] <fabbione> Kamion: i think the problem is that the first time he did try to create some kind of very weird raid
[01:35] <fabbione> Kamion: till he realized he couldn't do that
[01:35] <fabbione> (note the select one/select 3 dance)
[01:36] <infinity> mvo : And I broke it, somehow?  Hrm.
[01:36] <fabbione> Kamion: our raid code is ok.. it's mostlikely a small bug where we allow mdcfg to run is non perfectly sane situation
[01:36] <Kamion> fabbione: the select one / select three business was only because partman wasn't showing him all of his devices, AFAIK
[01:36] <fabbione> Kamion: but you can land there doing messes like that
[01:36] <infinity> mvo : Does /etc/init.d/console-screen.sh, run from the console on a running system, fix/change anything?
[01:37] <Kamion> the procedure he described seems totally sane
[01:37] <Kamion> in the *first* post, ignoring the later ones
[01:37] <Kamion> certainly later on he seems to have tried to do odder stuff
[01:37] <fabbione> I set up two RAID partitions (physical volume) on one large drive and one RAID
[01:37] <fabbione> partition on each of two smaller drives.
[01:37] <fabbione> this is non-sense to me
[01:38] <fabbione> (first line)
[01:38] <Kamion> it's not very conventional, but I can see no reason at all why partman doesn't support that
[01:38] <fabbione> i did try that stuff for fun
[01:38] <mvo> infinity: no, but I think (could be wrong though) that it used to fix vt2-6. vt1 used to work ok
[01:38] <fabbione> now the point is:
[01:38] <fabbione> you create hda1
[01:39] <Kamion> all it's doing is creating the volumes, then doing /usr/lib/partconf/find-partitions --ignore-fstype a bit later
[01:39] <fabbione> than you create md0 out of hdb1 + hdc1
[01:39] <infinity> mvo : And now all 6 are broken?...
[01:39] <infinity> mvo : That could be an artifact of you playing. :)
[01:39] <Kamion> which should show up all of the volumes you just created
[01:39] <fabbione> afaict he is trying to create /dev/md1 out of hda1 + md0
[01:39] <mvo> infinity: yes, that was what I was thinking too. I'll do a reinstall now
[01:39] <fabbione> that's not exactly a supported situation
[01:39] <infinity> mvo : My (global) font gets set correctly here, I haven't test per-vc fonts, but I also didn't touch that part of the code, so I'll assume it still works.
[01:39] <fabbione> because you need to mark /dev/md0 as raid disk
[01:40] <fabbione> and iirc that's not something nice to do
[01:40] <fabbione> but again i need to test it
[01:40] <fabbione> i did it too long ago
[01:40] <fabbione> when i was more insane than now
[01:40] <infinity> mvo : If it still breaks, yell loudly in the bug, and I'll do a test install in Greek in some free space somewhere.
[01:40] <Kamion> fabbione: not to start with, he isn't
[01:40] <mvo> infinity: will you still be around in ~30-45min?
[01:40] <infinity> mvo : Just need to download an ISO to play with.
[01:41] <infinity> mvo : FSVO 'around', yeah.  I'll be in and out all night, working off and on.
[01:41] <Kamion> fabbione: you seem to be trying to say RESOLVED/INVALID - I really don't think that's the case and I don't like dismissing this, because it feels like it could quite easily be a partman bug given the complexity of that code.
[01:41] <fabbione> Kamion: i didn't say RESOLVED/INVALID
[01:41] <fabbione> i said: I need to retest it
[01:41] <Kamion> you're saying he's doing something wrong and unsupported
[01:41] <Kamion> that's what RESOLVED/INVALID means
[01:41] <fabbione> and "fabbione Kamion: our raid code is ok.. it's mostlikely a small bug where we allow mdcfg to run is non perfectly sane situation"
[01:42] <Kamion> I'm not sure I believe your premise :-)
[01:42] <Kamion> have you read all of partman-md and mdcfg? :)
[01:42] <Kamion> they're pretty nasty as far as partman integration goes
[01:42] <mvo> infinity: ok, I'll keep you updated, thanks
[01:42] <fabbione> Kamion: no. i need to understand what he is trying to do first.
[01:43] <fabbione> Kamion: and as i said i need to get some rest first because headacke is coming up..
[01:43] <Kamion> fair enough
[01:43] <Mirv> mvo: _if_ you happened to write the get-iso-codes-i18n, it should do some extra checking: currently, when the language and the country is called the same in Finnish, a wrong translation is put in the language; in Finnish, language names are written in lower case, and the script seemingly gets the country name instead
[01:43] <fabbione> Kamion: i didn't close the bug or anything :) i find it diffcult to believe we have such a strange bug
[01:43] <fabbione> given that i do test a lot of installs on RAID
[01:43] <fabbione> but they are sane config
[01:43] <fabbione> +s
[01:44] <mvo> Mirv: could you please file a bug and (if possible) do a patch :))) ?
[01:44] <Mirv> mvo: ok, I will try :)
[01:44] <Kamion> fabbione: hmm, partconf checks for LVM before RAID; I wonder if that could be a problem
[01:44] <Kamion> fabbione: the output of the commands I asked him for should help, anyway, I hope
[01:45] <mvo> Mirv: thanks, I'm happy to help if you have any questions (just /msg me)
[01:45] <hunger> I can no longer burn CDs with breezy. cdrecord assumes /dev/sg0 as the divice to use, while it is actually /dev/sg1 (sg0 belongs to /dev/sda I think, not /dev/scd0). Should I file a bug on cdrecord or udev for this?
[01:46] <mvo> hunger: cdrecord should look for /dev/cdrw. do you have that?
[01:46] <fabbione> Kamion: i doubt that could be the issue.. the problem is lower than LVM or RAID.. like not all partitions are tagged as RAID devices
[01:46] <fabbione> or something
[01:46] <hunger> mvo: Let me check...
[01:46] <Kamion> fabbione: partconf is what reports that tagging
[01:46] <fabbione> i really need to test it and read all the logs
[01:46] <Kamion> fabbione: so if it says LVM, partman-md won't display the device
[01:49] <fabbione> Kamion: you can see tha LVM doesn't recognize any partition as sucj
[01:49] <fabbione> such
[01:49] <fabbione> (from the first log)
[01:50] <hunger> mvo: /dev/cdrw is a link to /dev/scd0
[01:50] <Kamion> fabbione: I can see that *parted* doesn't think that any partitions are flagged as LVM, but that's not necessarily exactly the same as what /usr/lib/partconf/find-partitions thinks
[01:50] <hunger> mvo: Sorry for the delay... Im in the office and had to boot my private laptop:-)
[01:51] <mvo> hunger: no problem. might be a hal problem then. <---- pitti ?
[01:51] <hunger> mvo: Does cdrecord even look in hal?
[01:52] <mvo> hunger: no, but the symlink is IIRC setup by it
[01:53] <fabbione> Kamion: there is something i am not sure i understand.. in order to access the mdcfg menu, all the changes must be committed to the disks
[01:53] <fabbione> Kamion: if so.. why do the old partitions still show up?
[01:53] <Kamion> fabbione: old partitions?
[01:54] <fabbione> http://bugzilla.ubuntu.com/attachment.cgi?id=4181 <-
[01:54] <fabbione> at the end of the file
[01:54] <Mirv> mvo: actually, I might have been wrong.. it might be that one translator has actually done the few incorrect translations there. hmmkay.
[01:54] <fabbione> parted_server: Closing infifo and outfifo
[01:54] <fabbione>  /lib/partman/choose_partition/60partition_tree/choices: paragraph: 1	32256-6399267839<PHONE_NUMBER>	primary	unknown	/dev/ide/host0/bus0/target0/lun0/part1
[01:54] <fabbione>  /lib/partman/choose_partition/60partition_tree/choices: paragraph: 2<PHONE_NUMBER>-12395496959<PHONE_NUMBER>	primary	unknown	/dev/ide/host0/bus0/target0/lun0/part2
[01:54] <fabbione> and so on
[01:54] <fabbione> they shouldn't be there at all
[01:55] <mvo> Mirv: ok, fair enough
[01:55] <Kamion> fabbione: why not?
[01:55] <Kamion> fabbione: partman doesn't forget about the underlying volumes just because you've configured RAID on top of them
[01:56] <Kamion> AFAIK, that's still what's on his disk
[01:56] <fabbione> Kamion: IIRC when you enter the raid setup, you need to commit your changes first
[01:56] <Kamion> yes
[01:57] <fabbione> so once you commit the changes, the old partition table should be gone
[01:57] <Kamion> in what way is that an "old" partition table?
[01:58] <hunger> mvo: Changing the cdrw ling to /dev/sg1 does not work.
[01:58] <fabbione> Kamion: i can guess that by the fact that it is the same discovered in the first log?
[01:58] <Kamion> the log does not indicate him having changed that partition table in any way
[01:58] <hunger> mvo: Debug output of K3B lists "BLAHDEVICE (/dev/scd0, /dev/sg1) at /media/cdrom0 [All kinds of formats]
[01:59] <hunger> mvo: Then cdrecord fails opening /dev/sg0.
[01:59] <hunger> mvo: Looks like a cdrecord bug to me...
[01:59] <Kamion> he's attempted to configure a RAID device using some of those partitions as physical volumes, but he hasn't done anything else to the physical partition table
[01:59] <mvo> hunger: yeah, interessting
[02:00] <Kamion> fabbione: parted_server looks at the partition type (for DOS partition tables, anyway) to determine whether a partition is an LVM physical volume or RAID or whatever
[02:00] <Kamion> fabbione: partconf/find-partitions looks at /proc/lvm/VGs/*/LVs/* and /proc/mdstat instead
[02:00] <Kamion> so it's possible for it to give different results
[02:00] <fabbione> hmmm
[02:00] <fabbione> crack
[02:01] <hunger> mvo: I guess I'll file a bug on cdrecord...
[02:01] <fabbione> i am trying to reproduce that thing
[02:02] <mvo> hunger: could this be a k3b problem? cdrecord seems to be setup for /dev/cdrw, you can try with "cdrecord -toc"
[02:02] <Kamion> fabbione: oh, hmm, no, I'm looking at the wrong bit of code there
[02:02] <Kamion> I was looking at the code which lists active LVM/RAID *logical* volumes
[02:03] <hunger> mvo: cdrecord -toc tries to work with /dev/sg0
[02:03] <mvo> hunger: odd, because cdrtools (4:2.01+01a01-4ubuntu1) breezy; urgency=low
[02:03] <mvo>   * Add 27_default_device.dpatch:
[02:03] <mvo>   was supposed to fix that
[02:03] <hunger> mvo: cdrw is a symlink to /dev/scd0 by default anyway... and thatis associated with /dev/sg1
[02:04] <Kamion> oh, heck, partconf/find-partitions doesn't list LVM or RAID volumes any more
[02:04] <Kamion> I must have broken that :(
[02:04] <mvo> pitti: hal is supposed to setup /dev/cdrw, no?
[02:04] <pitti> mvo: no, udev
[02:04] <hunger> mvo: Maybe this is because I have a sda instead of a hda.
[02:04] <fabbione> Kamion: ok.. now i have a spare disk with 4 partitions.. let see what is going to happen
[02:05] <mvo> hunger: still, it should point to the correct cdrw device (I assume you have only one)?
[02:05] <hunger> mvo: CDRW device as in /dev/scd* or /dev/sg*?
[02:05] <hunger> mvo: It does point to the proper /dev/scd... (and yes, I only have one).
[02:07] <mvo> hunger: hmmmmm ...
[02:07] <smurf> hunger: is there a CDR_DEVICE entry in your /etc/default/cdrecord, and what does it say?
[02:08] <fabbione> Kamion: ok.. i managed to get the error he mentions about "Earlier, I was seeing some sort of error reported where the partitioner could
[02:08] <fabbione> not inform the kernel of the partition changes."
[02:09] <fabbione> it seems like parted/partman or whatever is trying to tell that there is a partition (/dev/md0p1) on top of the raid
[02:09] <fabbione> when there is none
[02:09] <Kamion> yes, I just noticed that myself too
[02:09] <Kamion> #16706
[02:09] <Kamion> I think it's a separate bug, but probably implicated somehow
[02:09] <hunger> smurf: 1,0,0
[02:09] <fabbione> Kamion: mostlikely 2
[02:09] <fabbione> if not more
[02:10] <fabbione> i wonder if this is realted to raid0 only
[02:10] <Kamion> the message in question comes from parted/libparted/linux.c
[02:10] <Kamion> no, #16706 was reported on RAID5
[02:10] <fabbione> ok
[02:10] <mvo> hunger: can you try seting it to /dev/cdrw?
[02:11] <smurf> hunger: does replacing that with "CDR_DEVICE=/dev/cdrw" fix the problem?
[02:11] <smurf> mvo: ;-)
[02:12] <mvo> smurf: thanks! :)
[02:12] <mvo> infinity: greek install looks great so far (I'm in stage2 currently)
[02:12] <hunger> smurf: It complains about it not being intended to work and not being supported, but it does seem to work.
[02:13] <hunger> smurf: Let me try burning something...
[02:13] <mvo> hunger: cdrecord likes to whine
[02:13] <smurf> hunger: that's not a problem with cdrecord, but with cdrecord's author. :-/
[02:13] <hunger> smurf: Yeap... that guy is notorious for that, isen't he?
[02:13] <fabbione> Kamion: nothing.. i can't reproduce the bug.. i can only get to the md error..
[02:13] <Kamion> fabbione: ok, now I've got 'No unused partitions of the type "Linux RAID Autodetect" are available', which I'm guessing is a problem with unzeroed superblocks
[02:14] <fabbione> Kamion: you did reboot the machine, without rebuilding the partition table, right?
[02:14] <fabbione> so it's like an old raid setup laying there
[02:14] <Kamion> fabbione: right
[02:15] <Kamion> yep, looks similar to his report
[02:15] <fabbione> ok.. yes than you are hitting the superblock thing
[02:15] <fabbione> try to zero the blocks and reboot again
[02:15] <fabbione> or make parted restart from scratch.. not sure which one is easier
[02:16] <hunger> smurf/mvo: K3B ignores thase settings:-(
[02:16] <fabbione> brb
[02:16] <Kamion> have to mdadm --stop some things first
[02:20] <mvo> infinity: you rock! greek install went fine and all vt's are setup correctly
[02:21] <fabbione> re
[02:22] <Kamion> mvo: are those base-config changes now obsolete? I'm afraid I got snowed under and haven't got round to them
[02:24] <mvo> Kamion: looks like it, yes. the install looked good in stage2 (fonts setup correctly). after a reboot usplash/gdm came up with no problems and vt1-6 have correct fonts
[02:25] <Kamion> mvo: cool - in that case I'll just revert all the changes I have in arch
[02:26] <mvo> Kamion: let me check stage2 again to be absolutly sure please
[02:27] <smurf> hunger: Settings => Configure k3b => Devices, does that look sane?
[02:28] <hunger> smurf: Yeap. It is using /dev/scd0 there (which it considers to be (1,0,0).
[02:30] <hunger> smurf: Which is what cdrecord -scanbus thinks it is, too.
[02:30] <segfault> pitti: shouldn't update-notifier_0.38.11ubuntu1_translations.tar.gz include latest translations from rosetta?
[02:30] <smurf> hunger: Hmmm. Does adding dev=/dev/cdrw (to ... => Programs => cdrecord) help?
[02:30] <pitti> segfault: no, that's only the data from the source package
[02:31] <Mithrandir> hmm, how does one disable inotify in the kernel?
[02:31] <fabbione> Mithrandir: you can't
[02:31] <segfault> pitti: ah, ok
[02:31] <fabbione> you can recompile
[02:31] <Mithrandir> fabbione: that really, really sucks.  15571.
[02:32] <hunger> smurf: Nope.
[02:32] <fabbione> Mithrandir: inotify doesn't use /dev/inotify anymore
[02:32] <fabbione> the test program in the last comments is foobar
[02:33] <Mithrandir> fabbione: yes, and? :-)  I want to have those users check if inotify is to blame.
[02:33] <Mithrandir> I guess I should take concordia for a spin, without inotify.
[02:33] <hunger> smurf: Oh, wait... it forgot my setting... retrying.
[02:33] <hunger> smurf: Yeap, that works.
[02:33] <pitti> fabbione: so the "noinotify" patch is gone?
[02:34] <fabbione> Mithrandir: i doubt.. i can easily move over 40MB/sec...
[02:34] <Mithrandir> fabbione: yes, but you don't have the same hardware as those users, do you?
[02:34] <smurf> OK, it seems that something in your system gets confused about SCSI device order. Can you "cat /proc/scsi/scsi" and "ls -l /dev/sg*", and put that into a pastebin?
[02:34] <fabbione> pitti: the noinotify patch was a local hack...
[02:35] <fabbione> Mithrandir: inotify is hw independent
[02:35] <fabbione> Mithrandir: it's a hook at VFS layer
[02:35] <ogra> Mithrandir, we had another inotify test proggy on the "disappearing menu items" bug ... let me look up the bugnumber
[02:35] <Mithrandir> fabbione: unless it tickles bugs in other drivers or something similar.
[02:35] <fabbione> Mithrandir: i did check the code.. no it doesn't interact with drivers at all
[02:35] <fabbione> it replaces some dnotify (fs) calls with generic ones
[02:35] <ogra> Mithrandir, #14967 there was a link iirc
[02:36] <fabbione> so that they can be diverted between dnotify and inotify
[02:36] <Mithrandir> fabbione: do you have any other suggestion what it might be, then?
[02:36] <fabbione> pitti: the noinotify/inotify patch was only a local hack (rejected upstream) to disable/enable it for our kernel
[02:37] <pitti> fabbione: I see
[02:37] <hunger> smurf: k3b runs cdrecord ... dev=1,0,0 ... dev=/dev/cdrw ... now. Lucky me that mine overrides the first one:-)
[02:38] <fabbione> Mithrandir: it's a gnome bug!! :P
[02:38] <Mithrandir> fabbione: sorry, I meant _useful_ suggestion. :-P
[02:38] <fabbione> Mithrandir: one question would be why gamin is polling
[02:38] <jbailey> Anyone here happen to use NIS on their network? =)
[02:39] <fabbione> if it uses inotify, it should just sit and wait
[02:39] <jbailey> I have a bug, and I'd really rather not setup NIS to test it. =)
[02:39] <Mithrandir> jbailey: I have networks using NIS, yes.
[02:39] <fabbione> jbailey: i am not going to answer to that
[02:39] <Mithrandir> jbailey: #?
[02:39] <fabbione> Mithrandir: wrong answer to jb! you win a mess
[02:39] <Mithrandir> pft, setting up nis takes about two minutes anyway.
[02:39] <jbailey> Mithrandir: http://bugzilla.ubuntu.com/show_bug.cgi?id=16893
[02:39] <jbailey> (I'll even be nice and paste a clickable URL)
[02:40] <jbailey> Mithrandir: Upstream closed a similar bug as WorksForMe
[02:40] <smurf> hunger: Can you "cat /proc/scsi/scsi" and "ls -l /dev/sg*", and put that into a pastebin? (http://ubuntu.pastebin.com for instance)
[02:41] <jbailey> Mithrandir: If you can reproduce it, there are a couple patches in CVS that might be candidates.
[02:41] <Mithrandir> jbailey: that should be reproducable in a chroot?
[02:42] <Mithrandir> jbailey: wfm
[02:42] <jbailey> Mithrandir: I think so, yes.
[02:42] <fabbione> Mithrandir: you can try to spin concordia and disable inotify, but note again what gamin is doing
[02:43] <hunger> smurf: I can't... no net on the ubuntu box.
[02:43] <hunger> smurf: The CDRW is scsi1, chan 0, id 0, lun 0 in /scsi (HD is scsi0, chan 0, id 0, lun 0) (both are SATA drives).
[02:43] <fabbione> Mithrandir: with the new inotify gamin should jsut wait for inotify to actually notify it of the changes
[02:43] <fabbione> so that polling thing is suspicious
[02:43] <hunger> smurf: sg0 is 21,0 (mayor,minor), sg1 is 21,1
[02:45] <Mithrandir> seb128: do you have any idea on 15571 wrt fabbione's comments?
[02:45] <Mithrandir> jbailey: so, works for me, can't reproduce.
[02:45] <Mithrandir> jbailey: not even outside a chroot
[02:46] <jbailey> Mithrandir: Thanks.  It's inherited from Debian, so I'll mark it NOTWARTY then.
[02:46] <seb128> Mithrandir: what about it?
[02:46] <jbailey> Might be another sideeffect of them using gcc-4 to compile instead.
[02:46] <seb128> Mithrandir: current inotify doesn't use a /dev entry
[02:47] <Mithrandir> seb128: any idea why gam_server is spinning rather than just sleeping in that case?
[02:47] <seb128> it spins?
[02:47] <Mithrandir> seb128: or is that an old trace?
[02:47] <seb128> which one?
[02:47] <Mithrandir> seb128: comment #7 in http://bugzilla.ubuntu.com/show_bug.cgi?id=15571
[02:48] <fabbione> THANK YOU MOZILLA.. for crashing again and again.. and again.. and again
[02:48] <seb128> Mithrandir: afaik gamin pool for non-existant files
[02:49] <seb128> Mithrandir: not sure if inotify can put a monitor on non-created yet entries
[02:49] <seb128> Mithrandir: ie: ~/.recently-used
[02:49] <Mithrandir> why shouldn't it?
[02:49] <seb128> the panel monitor recently-used even if the file is not created yet
[02:50] <seb128> Mithrandir: dunno how the linux inotify code work and what you can monitor, I just know than polling was used for non-created files
[02:50] <seb128> by gamin
[02:53] <jdub> http://fridge.ubuntu.com/node/5 <- that's the badger :-) :-) :-)
[02:53] <jdub> oh
[02:53] <jdub> http://fridge.ubuntu.com/taxonomy/term/1
[02:53] <jdub> ^ see it there
[02:55] <jsgotangco> taxonomy?
[02:55] <jsgotangco> jdub: man that's they hype machine
[02:55] <jdub> means categories, essentially
[02:56] <jsgotangco> wow it has gloss terms
[02:57] <jdub> that's how we did the sabdfl definition bit ni the faq story
[02:58] <fabbione> +l
[02:59] <fabbione> Mithrandir: another solution for the itontify bug.. reassign it to jdub.. he wanted that crack in
[02:59] <mvo> Kamion: tty1-3 in stage2 are fine (I waited for gdm to start). tty4 after a fresh stage2 has no getty and some log/error messages left. is that known? tty5,6 have a getty but the console-font is set wrong. after a reboot vt1-6 are fine again
[02:59] <Kamion> mvo: tty4 known; tty5-6 are probably just not there when base-config starts (look at the initial inittab)
[03:00] <Kamion> if you have any good ideas for fixing the tty4 thing, let me know, otherwise I'll probably leave it alone for breezy
[03:00] <jsgotangco> jdub: the fridge calendar is awesome
[03:00] <Kamion> we could work around tty5-6 by running console-screen.sh after telinit q, but I think that's a bit risky
[03:01] <Kamion> (because init probably doesn't create the gettys synchronously)
[03:01] <mvo> Kamion: it's not really a huge issue IMHO because vt1-3 are ok and a reboot fixes the problem anyway
[03:01] <mvo> Kamion: just wanted to let you know about the current state :)
[03:01] <Kamion> thanks
[03:02] <mvo> np
[03:03] <infinity> mvo : Rock, so it all works?
[03:03] <mvo> infinity: yeah, looks perfect. no flicking when gdm starts, nice fonts on all terminals. looks like we are done there :)
[03:07] <kingos> anyone want to help me ? I am experiencing bug 13497 - amd64 system, dhcp3-client 3.0.2-1ubuntu6
[03:07] <kingos> breezy
[03:13] <maswan> how large are you planning the release set to be? 6 cd isos? dvd isos?
[03:14] <ogra> maswan, do you plan to mirror edubuntu too ? we have 6 CDs and 6 DVDs now
[03:15] <maswan> ogra: hmm. well, we might. :)
[03:16] <ogra> maswan, just to inform you about the extra size :)
[03:16] <ogra> s/size/space/
[03:16] <maswan> ogra: ehm. it is there already. :)
[03:16] <ogra> oh, including the DVD ?
[03:16] <maswan> we mirror releases as provided by rsync from releases
[03:16] <maswan> seems to be cd isos
[03:17] <ogra> ah, k
[03:17] <maswan> we are working on a full cdimage mirror too, but that is a bit of work to keep up to date
[03:18] <maswan> ok, so, are you going to have live edubuntu isos too at release?
[03:20] <Kamion> maswan: 6 CDs for each of Ubuntu and Kubuntu, 3 CDs for Edubuntu, some as-yet-unclear number of DVDs
[03:20] <Kamion> maswan: edubuntu live> no
[03:20] <ogra> maswan, next release probably
[03:21] <Kamion> maswan: oh, plus source CDs
[03:21] <Kamion> 4/5 per project
[03:21] <acyr> anyone know if all xorg binaries in Hoary are moved to /usr/bin from /usr/X11R6/bin now?
[03:22] <daniels> nope, they aren't
[03:23] <daniels> Xorg, in particular, is still in X11Rfrigging6
[03:23] <acyr> daniels: but in breezy they are in /usr correct?
[03:23] <daniels> nope
[03:23] <bddebian> Morning
[03:23] <daniels> daniels@ephemera:~/canonical/xorg/app/imake/imake-7.0% ls /usr/X11R6/bin
[03:23] <daniels> X  Xnest  Xorg  Xorg-debug  Xvfb  gtf  ioport  mmapr  mmapw
[03:23] <daniels> the servers are all still there in breezy
[03:24] <acyr> daniels: where would you recommend I drop the fglrx apps into?
[03:24] <infinity>  /usr/bin
[03:25] <daniels> yeah
[03:25] <daniels> nothing should be in /usr/X11R6/bin at all
[03:25] <daniels> particularly nothing new
[03:25] <acyr> for both hoary and breezy that'd be cool?
[03:25] <daniels> yah
[03:25] <acyr> sweet.
[03:25] <daniels> thanks for doing the packaging stuff, btw -- much appreciated
[03:25] <acyr> np
[03:26] <acyr> where can I get your package stuff from (or how can I pull from the repository)?
[03:27] <daniels> you can just apt-get source linux-restricted-modules-2.6.12
[03:27] <acyr> ah ya that's right, forgot it is hiding in the restricted-modules.  thanks
[03:27] <daniels> no worries.  ignore all the lrm-manager, and split-module stuff.
[03:28] <acyr> will do.  I just wannt make sure I get the paths etc right.
[03:28] <daniels> yeah
[03:29] <infinity> acyr : Easiest to grab the binary .debs and do "dpkg-deb -c foo.deb" and make sure yours matches.  Then if you make sure your dpkg-divert calls in the maintainer scripts match ours, you must have (basically) identical packages.
[03:30] <acyr> infinity: thanks for the info, will do
[03:34] <infinity> acyr : Do you require the user to have debhelper insalled, or do you do it with bare dpkg-dev (dpkg, dpkg-deb) calls?
[03:35] <infinity> acyr : Oh, also, you're aware that on breezy, kernel modules need to be build with gcc-3.4, right?
[03:35] <infinity> s/build/built/
[03:38] <acyr> infinity: I am using debhelper.  I am not packaging binaries for the kernel modules currently, just make-kpkg/m-a compat source.
[03:39] <infinity> Ahh, kay.
[03:42] <acyr> joy, linux-restricted-modules source is only 73MB...
[03:42] <bddebian> Heh
[03:43] <daniels> yeah, nvidia-legacy really screwed our day
[03:46] <acyr> daniels: what happened?
[03:47] <daniels> they don't support old cards with current releases anymore, so l-r-m has two versions of the nvidia driver now, for each of i386 and ia64
[03:48] <acyr> oh, hehe
[03:50] <pitti_live> Diziet: ping
[03:51] <maswan> Kamion: Well, we are counting on a trivial ammount of source cd downloads :)
[03:52] <maswan> Kamion: the reason I'm curious is for dimensioning offload hosts that need to keep all data in ram
[03:52] <pitti_live> jdub: here?
[03:54] <pitti_live> Kamion: did you recently try to shutdown a live CD on powerpc?
[03:55] <pitti_live> Kamion: this hangs at "Shutting down LVM Volume Groups..."
[03:55] <jdub> pitti_live: pong
[03:55] <pitti_live> jdub: (just testing live CD): firefox still does not have a start page
[03:55] <pitti_live> jdub: do we miss a new package in the live seed?
[03:55] <pitti_live> jdub: AFAIR this file was moved to somewhere else
[03:58] <jdub> pitti_live: it's now in ubuntu-docs
[03:58] <jdub> pitti_live: changed too late for the livecd build, perhaps?
[03:59] <jsgotangco> most likely
[04:00] <pitti_live> jdub: current image has u-d 5.10-4
[04:00] <jdub> jbailey: ?
[04:01] <pitti_live> jdub: right, so tomorrow's image shuold have it
[04:01] <jdub> sweet
[04:01] <jsgotangco> we still need to beautify that page though its horrid
[04:01] <pitti_live> jdub: odd though, it was uploaded two days ago...
[04:01] <Treenaks> pitti_live: it got quite a bit larger
[04:02] <Treenaks> (didn;t it?)
[04:02] <jsgotangco> Treenaks: yes around 10MB im checking why
[04:02] <jsgotangco> it seemed to have included some images that are not used
[04:02] <Treenaks> jsgotangco: livecd space restrictions
[04:03] <jsgotangco> oh so it exploded?
[04:03] <Treenaks> jsgotangco: maybe
[04:03] <Treenaks> jsgotangco: it could be why there is no startpage on the livecd
[04:04] <jsgotangco> darn
[04:07] <jdub> jordi: ping
[04:09] <pitti> Kamion: darn, I just saw that breezy still has postgresql-common 25; it seems my sync request got lost in the IRC crowd; -27 has no new features, just bug fixes, can we please sync?
[04:16] <jbailey> jdub: Yessir?
[04:16] <jdub> jbailey: pitti was asking questions about the ubuntu-docs home page not on the livecd
[04:17] <pitti> jbailey: it already resolved, the current live images still have version -4
[04:17] <jbailey> Ah, excellent.
[04:17] <jbailey> Already resolved good.
[04:17] <jsgotangco> jbailey: except that ubuntu-docs is 10MB and it has images that seem to not been used :(
[04:18] <jbailey> jsgotangco: I wasn't sure what was used or not, I can slim that down.
[04:18] <bob2> does that have the corrected ubuntuguide thing?
[04:18] <jsgotangco> bob2: yeah without the crack and the marillat stuff
[04:24] <jordi> jdub: pong
[04:25] <jdub> jordi: what is the language of mallorca's independence army (non-spanish)?
[04:26] <jordi> jdub: GUESS IT
[04:26] <jdub> haha
[04:26] <jdub> elite :-)
[04:26] <jsgotangco> hah
[04:26] <jdub> estic cercand meus pantalons!
[04:27] <jdub> though google doesn't do catalan ;)
[04:28] <Treenaks> jdub: may 5th, 2006 is next No Pants Day
[04:29] <jdub> :-)
[04:29] <jdub> oh
[04:30] <jdub> i see what you mean
[04:30] <jdub> hrm
[04:30] <Treenaks> jdub: link it to http://www.nopantsday.com/
[04:30] <jdub> nopantsday.com has't been updated
[04:31] <Treenaks> hm I see
[04:31] <Treenaks> maybe the wikipedia page?
[04:35] <jdub> should do a new poll
[04:37] <jdub> anyone here subscribe to ubuntu-users via digest?
[04:39] <jdub> Version: 27
[04:39] <jdub>  postgresql-common (27) unstable; urgency=low
[04:39] <jdub> oh
[04:39] <jdub> postgresql-common, separate source
[04:39] <jdub> weird
[04:44] <jsgotangco> jdub: i do
[04:45] <jdub> jsgotangco: do you like the pace of the digests?
[04:45] <jdub> i've had requests that they be sent only once a day
[04:45] <jsgotangco> twice a day isn't really that bad
[04:45] <jdub> they're twice a day atm?
[04:45] <jsgotangco> i rarely reply to digest anwyays
[04:45] <jdub> mailman only has a "# of kb" setting
[04:45] <jdub> which is frustrating
[04:45] <jsgotangco> jdub: depends on the volume i guess
[04:46] <jdub> i was thinking of cranking up the kb to something fairly huge
[04:46] <jdub> and turning on the "send daily even if not big enough"
[04:46] <jdub> option
[04:46] <jsgotangco> you'll have a failry long digest if that's the case
[04:46] <jsgotangco> 10 - 12 entries per digest is actually chewable
[04:47] <Lathiat> digests are just for those who dont have mail filtering :)
[04:48] <jsgotangco> Lathiat: oh ubuntu-users is just not my cup of tea really
[04:48] <jsgotangco> especially if you have .* on the wiki
[04:48] <jdub> that's a lot of tea
[04:49] <jsgotangco> ok i gotta sleep good night
[04:55] <mdke> Kamion, mdz, any indication on what to do about that string change proposal for ubuntu-docs?
[04:56] <Kamion> I'll look at it in a bit; it turned from an easy decision into a hard one all of a sudden and I had other things to do
[04:57] <mdke> Kamion, fair enough, thanks
[04:57] <mdke> Kamion, shout if you want clarification on anything
[05:02] <Nafallo> are there likely to be another kernel for breezy or should it be safe to dist-upgrade my server?
[05:05] <pitti> Kamion: ping
[05:06] <mdke> Nafallo, even if there is, it should be relatively safe
[05:06] <Nafallo> yea, but I don't want to restart her if not needed :-P
[05:07] <mdke> ah one of those eh
[05:07] <Nafallo> it _is_ a server ;-)
[05:07] <mjg59> Kamion: What time are the dailies built?
[05:12] <Diziet> Damn, 16599 is still hanging around.  Anyone here know anything about why some font pfb might be missing on some user's system ?
[05:12] <Kamion> pitti: yo. I hadn't seen the powerpc problem before. postgresql-common synced.
[05:13] <Kamion> 21 8 * * *      for-project ubuntu cron.daily
[05:13] <Kamion> 31 7 * * *      for-project ubuntu cron.daily-live
[05:13] <Kamion> mjg59: ^-- those are the Ubuntu dailies, London time
[05:13] <StR> Hi all!
[05:13] <pitti> Kamion: thanks
[05:13] <StR> where can I see why did you choose usplash instead of splashy?
[05:14] <pitti> Kamion: I just installed amd64; I got the grub dialog that asked me to enter "/dev/hda" or "(hd0)" - is that really on purpose?
[05:14] <mjg59> Kamion: Ok. So if I'm getting a train at 6am tomorrow, I might as well just go for what's there now?
[05:14] <pitti> Kamion: AFAIR Hoary just asked me whether to install in the MBR, or didn't ask at all
[05:14] <Kamion> pitti: it depends on the circumstances.
[05:15] <pitti> Kamion: (it didn't find my already installed breezy system either, but that's already in bugzilla)
[05:15] <Kamion> pitti: if there's an operating system on your disk that os-prober couldn't understand, grub-installer assumes that it must be too stupid to get the answer to the boot device question right for itself and asks you instead
[05:16] <Kamion> pitti: bug#?
[05:16] <pitti> Kamion: #12885
[05:16] <pitti> Kamion: ah, so os-prober saw my other breezy system, didn't recognize it because it automatically mounted it to /media/hda2, and then grub-installer goes the safe way?
[05:17] <Kamion> pitti: the automatic mounting under /media doesn't interfere; mounting outside /media might, those
[05:17] <Kamion> s/those/though/
[05:17] <pitti> Kamion: yes, I changed the mount point
[05:18] <pitti> Kamion: ok, then it's not that critical
[05:18] <Kamion> pitti: in #12885 you mounted it at /breezy32, which behaves differently
[05:18] <pitti> Kamion: just checking whether this was a bug, but it seems to make sense
[05:18] <Kamion> pitti: partman-target has a special case to avoid mounting subdirectories of /media while the installer is runnign
[05:18] <pitti> Kamion: ok, that's fine then; thanks for the heads-up; I will do my next test-install without mounting the partition then
[05:19] <Kamion> pitti: let me get this straight - are you still mounting it at /breezy32, or did you change to taking the installer's default of /media/hda2?
[05:19] <Kamion> we could possibly be a bit more intelligent and only mount filesystems mounted at standard Unix paths for the duration of the installer
[05:19] <pitti> Kamion: nope, I changed it to /breezyold this time
[05:20] <pitti> Kamion: I didn't know about the /media special-case
[05:20] <Kamion> ok, I'll try my suggested fix above in dapper, then
[05:21] <spayne> why are so many packages come through each day?
[05:21] <spayne> and what is up with lists.ubuntu.com?
[05:22] <Kamion> spayne: because there's a lot to do
[05:22] <Kamion> spayne: lists> jdub's looking at it
[05:22] <spayne> is it just the archives?
[05:22] <jdub> yes
[05:23] <spayne> yo jdub btw
[05:23] <jdub> yo
[05:24] <mjg59> Kamion: Is anyone other than elmo able to do syncs?
[05:24] <daniels> mdz?
[05:24] <daniels> he has archive powahs, doesn't he
[05:25] <Kamion> mjg59: mdz or me
[05:25] <Kamion> mjg59: what's needed?
[05:28] <mvo> Kamion: ok to upload http://paste.ubuntulinux.nl/2760? various fixes in update-notifier
[05:28] <mvo> Kamion: I can do you a debdiff if you want too
[05:30] <mjg59> Kamion: sdparm
[05:33] <carlos> pitti, todays' language pack: http://mawson.ubuntu.com/~carlos/rosetta-breezy-2005-10-04.tar.gz
[05:33] <Nafallo> mjg59: please tell me you are going to propose that for main? :-)
[05:33] <mjg59> Nafallo: With luck
[05:33] <pitti> carlos: so evolution and control-center are current now?
[05:33] <carlos> pitti, I will try to automate it so you have it all days when you wake up
[05:33] <pitti> carlos: that's nice, thanks
[05:33] <carlos> pitti, evolution is current, control-center is not
[05:34] <pitti> carlos: when is the tarball ready? I'd like to set up my own cronjob that merges the buildd output with yours
[05:34] <carlos> pitti, I think production has control-center already but the mirror is done around 2:00 A.M. (in our time zone)
[05:35] <carlos> pitti, hmm, not sure, I will launch it at 4:30 AM
[05:35] <pitti> carlos: can you set up a symlink like rosetta-breezy-current.tar.gz?
[05:35] <carlos> pitti, and it takes between 3-4 hours
[05:35] <carlos> pitti, sure
[05:35] <pitti> carlos: so a cronjob at 10:00 should be safe?
[05:35] <carlos> pitti, yeah, I think so
[05:36] <Kamion> mvo: please just upload stuff, providing that you believe they're sensible for this stage of the freeze; it's much easier to analyse/approve things once they're in the queue
[05:36] <Kamion> it looks reasonably sensible if you've tested it
[05:37] <Kamion> mjg59: we don't have sdparm in the archive at all?
[05:38] <mjg59> Kamion: Yeah. It seems to have hit Debian after syncs were stopped.
[05:38] <sivang> Hi all
[05:38] <mvo> Kamion: thanks. I'll do more testing before the upload, but it's mostly obvious fixes
[05:39] <mhz> Kamion: hi
[05:40] <mhz> Kamion: will you be around in 4 hours?
[05:40] <Kamion> mjg59: ok, syncing, will NEW it later
[05:40] <mjg59> Kamion: Ta
[05:40] <Kamion> mhz: no, we have a guest round for dinner tonight. Why?
[05:41] <mhz> Kamion: ogra  suggested you may help me if I continue having TFTP problems (spent 19 hours already)
[05:42] <ogra> Kamion, i dont know the url for the netboot install howto from the top of my head, i thought you would know it
[05:42] <mhz> tftp to install unbuntu from a ubuntu server to a thin laptop that boots PXE ok
[05:42] <Kamion> http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/doc/manual/en/
[05:42] <Kamion> TFTP stuff is chapter 4.5
[05:43] <mhz> cool, i'll read it, thou I have read many howtos so far.
[05:43] <mhz> Kamion: thx
[05:43] <ogra> mhz, but thats the right one :)
[05:43] <mhz> LOL
[05:43] <mhz> I hope so, real badly
[05:43] <mhz> because this is the laptop I'm gonna be using for Ubuntu/Edubuntu/Kubuntu presentations
[05:45] <mhz> (and using the default MS200 really sucks)
[05:46] <mjg59> Kamion: Can I upload an acpi-support that fixes the sleep key whitelisting support, fixes resume when the machine is asleep for longer than a few minutes and doesn't print nasty errors on SATA machines?
[05:47] <Kamion> mjg59: yes
[05:47] <mjg59> Kamion: Thanks
[05:48] <Kinnison> seeeeeeeeeeeeeeeeb!
[05:48] <Kinnison> seb128: Unfortunately, my apps menu seems to be lacking in gedit goodness
[05:48] <Kinnison> seb128: and the menu editor doesn't list it either
[05:48] <mhz> Kamion: BTW, all this hours spent ONLY 'cos afaik, there's no way to boot from PCMCIA CD drive, or is there??
[05:48] <Kinnison> seb128: which is odd, 'cos I have gedit open over |/_ there
[05:49] <Kamion> mhz: depends on your hardware
[05:49] <mjg59> mhz: You can only boot from a PCMCIA cdrom drive if your machine supports it
[05:49] <lamont__> smurf:
[05:49] <mhz> bios level?
[05:49] <lamont__> Oct  4 15:47:30 kbd-chooser[3361] : ERROR **: kbd-chooser: cannot open file No keyboard to configure
[05:49] <lamont__> Oct  4 15:47:30 main-menu[2862] : WARNING **: Configuring 'kbd-chooser' failed with error code 1
[05:49] <lamont__> Oct  4 15:47:30 main-menu[2862] : WARNING **: Menu item 'kbd-chooser' failed.
[05:49] <ogra> mhz, thats a BIOS thing
[05:49] <mhz> tsktsktsk! no bios option for that :(
[05:50] <mhz> well, the positive side of this story is that I'll endup wikin a howto local netboot install from edubuntu onto thin laptops  :D
[05:50] <Kinnison> seb128: keybuk told me to bug you :-)
[05:52] <seb128> Kinnison: about what?
[05:52] <seb128> oh
[05:52] <mhz> Kamion: ogra: BTW, is it ok if I export this document to Moin wiki format?? or I'll be doubling efforts.
[05:52] <seb128> Kinnison: do you have a /usr/share/applications/gedit.desktop ?
[05:52] <smurf> lamont__: bah, I didn't get that this morning
[05:53] <lamont__> smurf: moving the kbd-chooser inside the if makes things happier too.....
[05:53] <ogra> mhz, ist fine, i dont think there is a wiki version of it yet... but make sure to keep it up to date
[05:53] <Riddell> Kamion: can I upload a small amarok fix?  http://muse.19inch.net/~jr/tmp/amarok.diff
[05:53] <Kinnison> seb128: yes
[05:53] <jordi> jbailey: ping
[05:53] <seb128> Kinnison: gnome-menu-spec-test | grep gedit ?
[05:54] <Kinnison> no output
[05:54] <Kamion> mhz: no, I'd really prefer you not to
[05:54] <lamont__> smurf: let me push it back up to the top of the hill one more time, and see what I can see.
[05:54] <jbailey> jordi: pong
[05:54] <smurf> lamont__: sure
[05:54] <seb128> Kinnison: ls ~/.local/share/applications/ | grep gedit
[05:55] <mhz> ogra: oh, then maybe it is not worth the try, because Moin does have version controling, when it is wiki work. I don't imagine how to uptodate with html files.
[05:55] <mhz> Kamion: ok
[05:55] <jordi> jbailey: how's glibc doing?
[05:55] <jordi> jbailey: does your pending upload contain kurdish stuff?
[05:55] <Kinnison> seb128: gedit.desktop and gedit-usercustom.desktop
[05:55] <jbailey> jordi: good, yes.
[05:55] <jbailey> jordi: It'll be cooked by the end of the day.
[05:56] <jordi> jbailey: I mailed you a file, please check it matches what you have in your tree
[05:56] <jbailey> jordi: Do you want me to use what your is?
[05:56] <jbailey> jordi: (When did you learn to speak kurdish? *g*)
[05:56] <Kamion> ogra: we'd never be able to keep it in sync properly
[05:56] <seb128> Kinnison: I bet that this gedit.desktop has a NoDisplay=true
[05:56] <jordi> jbailey: the Kurdish dude sent it, DUDE
[05:56] <Kamion> Riddell: yes
[05:56] <jordi> jbailey: I hope it will be the same as you have now, but just in case.
[05:57] <Riddell> Kamion: thanks
[05:57] <ogra> Kamion, ah, yes... thats why i notified mhz about that...
[05:57] <Kinnison> seb128: So it does. Now. (1) How did it get there, and (2) how is a normal user meant to fix this?
[05:57] <lamont__> smurf: Your keyboard is: No keyboard to configure
[05:57] <lamont__> highlighted selection is: Find your layout by pressing some keys
[05:58] <lamont__> "select from a complete list" immediately fails
[05:58] <seb128> Kinnison: (1) gnome-vfs/nautilus had a such bug, (2) that doesn't happen a lot and should not happen with current version ... for other people I guess bugzilla it
[05:58] <Kinnison> seb128: right
[05:58] <Kinnison> seb128: so I should just rm it?
[05:58] <Kamion> smurf: the QUIT state goes into keymap_set()
[05:58] <seb128> Kinnison: correct
[05:58] <Kamion> smurf: perhaps you should just exit(0) or something
[05:59] <lamont__>  ERROR **: kbd-chooser: cannot open file console-keymaps-none/keymap doesn't exist
[06:00] <Kinnison> seb128: yay, you win a $beer
[06:00] <seb128> Kinnison: cool :)
[06:01] <lamont__> smurf: truthfully, this doesn't need to get fixed for breezy
[06:03] <smurf> lamont__: it's still a bug. Bugs tend to annoy me on principle, especially when I test stuff (like this morning) and they *still* happen. :-/
[06:03] <jdub> tseng: beagle 0.1.1 already - you rock!
[06:05] <lamont__> smurf: true... not like anything needs that installer step to succeed though, and it seems to work just fine on head-ful systems
[06:05] <lamont__> hence not really worth the risk to the release to do an upload of that right now.
[06:05] <dholbach> hey carlos
[06:05] <dholbach> carlos: how are you?
[06:08] <smurf> lamont__: Well, I can put it onto my todo list, next to "tell the decision tree generator to use X keymaps instead of console ones" and "re-do the decision logic so that I can drop the 'do you have this key' dialogs" I already have for Dapper
[06:09] <sivang> ploum: ping, re: 16931
[06:10] <sivang> ploum: right click the workspaceswitcher applet, do you see there is no seperator between "Help" and "Get Help Online" ?
[06:11] <pitti> daniels: still here?
[06:11] <lamont__> thansk
[06:12] <sivang> hey pitti
[06:12] <pitti> Hi sivang
[06:12] <segfault> is there any plan to release today a new langpack?
[06:12] <daniels> pitti: mmm?
[06:13] <bddebian> Anyone know/think that bringing in new libofx and aqbanking versions will break anything?
[06:14] <pitti> daniels: https://launchpad.net/distros/ubuntu/breezy/+translations
[06:14] <pitti> daniels: that should come close to what you asked for
[06:14] <daniels> pitti: rockin', thanks
[06:16] <fabbione> daniels: dude.. where is mkdirhier? ;)
[06:17] <fabbione> daniels: i thought you were going to include it in the last xorg upload
[06:17] <Kamion> Keybuk: re hotplug, isn't a minute and a half a bit long to wait for interfaces to come up?
[06:18] <sivang> mjg59: ping
[06:18] <Keybuk> Kamion: well, 60 seconds is the dhcp timeout
[06:18] <mjg59> sivang: Hi
[06:18] <Keybuk> and that wait is only *if* it really is trying to bring one up
[06:18] <Kamion> oh
[06:18] <Keybuk> the net.ifup timeout is 120 seconds
[06:18] <Kamion> sucky