#ubuntu-devel 2005-04-11
<Kamion> lamont: ppc-netboot> yes?
<lamont> yes
<lamont> how?
<lamont> on my poor iMac G3.
<Kamion> first, have a network card supported by Open Firmware
<lamont> most notably, overriding the boot from disk...
<lamont> grumble
<lamont> is builtin lan...
<Kamion> should be fine
<[Cliff] > hi all
<Kamion> lamont: when you boot, hold down cmd+opt+o+f simultaneously, until the Open Firmware prompt appears
<lamont> then what do I need where on the dhcp/tftp server?
<[Cliff] > i'd like to tweak some stuff on metacity. can any one here lend me a hand?
<Kamion> lamont: usual netboot stuff on the DHCP server, 'filename' should point to yaboot
<Kamion> copy yaboot from the archive] 
<lamont> right - copied all of powerpc/netboot
<[Cliff] > what i'm trying to do is to enable the mousescroll on the titlebar to enable shading (kind of what xfwm does)
<Kamion> lamont: so you have initrd.gz, vmlinux, yaboot, yaboot.conf; correct?
<lamont> and boot.img.gz
<Kamion> lamont: make sure yaboot.conf has vmlinux and initrd.gz paths that match what's needed over TFTP
<Kamion> lamont: then 'boot enet:' at the OF prompt should do it
<Kamion> lamont: failing that, try 'boot enet:0'; failing that, try 'boot enet:0,/path/to/yaboot'
<thom> meh, how did you guys break torrent?
<dredg> just looking at modconf (not currently building). it build-deps on kernel-source, which is not a package itself. any ideas on how to proceed? should modconf depend on a particular version of kernel-source? suggestions greatly appreciated
<diamond> dredg: the buildd handles that situation alright, picking the first candidate for the kernel-source name,
<diamond> dredg: the issue is that it expects the kernel source to be expanded in /usr/src
<dredg> ah, you're right
<dredg> my bad
<diamond> dredg: was going to poke it earlier, but my dsl connection didn't like the look of the 40M download just to play ,-)
<Kamion> thom: we'd all like to know ...
<dredg> diamond: which is why i'm tempted to put an ubuntu uml together with 10M dedicated :)
<diamond> dredg: yeah well, i hate you. -)
<Kamion> dredg: surely that'd want to be "linux-source" for Ubuntu kernels
<Kamion> and you'd need to cope with other related renamings ...
<Kamion> I looked at modconf ages ago, it's non-trivial, so good luck :)
<dredg> Kamion: no, the source packages seem to be called kernel-source
<dredg> ie there's no linux-source-2.6.9
<dredg> (and thanks. now i don't wanna do it ;) )
<Kamion> dredg: I think you'll find that there *is* most certainly a linux-source-2.6.10
<dredg> interesting
<Kamion> the kernels we imported from Debian are kernel-*; that's the Debian naming scheme
<dredg> apt-get build-dep modconf
<Kamion> when we started doing our own kernel packaging, we also changed the name
<dredg> Package kernel-source is a virtual package provided by:
<dredg>   kernel-source-2.6.9 2.6.9-3
<dredg> and so on
<Kamion> yes, linux-source-* does not provide kernel-source, it provides linux-source
<diamond> Kamion: ah. yes. i too was thinking it was weird that both the package name was kernel-source, and that there was no 2.6.10 version
<diamond> that would certainly explain it
<Kamion> unfortunately I don't really remember what the issues I ran into were - I just remember thinking "hmm, this is more effort than s/kernel/linux/g"
<Kamion> it's possible I was trying to make it work with either Debian or Ubuntu kernels, although I sort of doubt it
<dredg> ok
<Kamion> ah, I know, I think nobody ever actually updated modconf to work properly with 2.6 kernels either
<Kamion> even in Debian
<dredg> i'll poke it til it either works or i cry
<diamond> Kamion: *cringe*
<Kamion> so IIRC it needed a fair bit of hacking for that
<dredg> ok, i'm bailing out now then
<Kamion> don't let me discourage you though, it would be great if somebody did it - enlist somebody who's familiar with Ubuntu kernels
<lamont> Kamion: btw, enet:0 worked 
<lamont> and local mirrors work best for installing when you have .udeb's. :-)
<Kamion> lamont: yep, think yourself lucky that choose-mirror now actually asks for the local mirror ;)
<lamont> Kamion: nah - firewall blocks the house machines from hitting archive.u.c :-)
<lamont> so it errors out
<seb128> thom: around ?
<lamont> Kamion: btw, would be wonderful if the cdimage happened to include the netboot files... :0-)
<Kamion> lamont: couldn't remember whether the 0 was needed, I haven't kept notes of how to do powermac netboot because it's more or less fresh enough that I can remember it with a little bit of trial and error as needed
<lamont> Kamion: way beyond my memory though.  thanks.
* lamont looks around to beat mvo
<Kamion> lamont: problem with that is that it makes the *3 kernel/initrd issue even worse
<lamont> son of bitch... where does debootstrap get it's idea of the keyring?\
<ogra> jdub, ping
<Kamion> lamont: ubuntu-keyring-udeb
<Kamion> lamont: the filename is passed to it by base-installer.postinst
<lamont> yeah, fixoring
<dredg> Kamion: on further inspection, modconf appears to have some knowledge of 2.6
<dredg> it just expects the source to be untarred in /usr/src/linux which would currently require manual intervention
* mjg59 returns from the wilds of Scotland
<diamond> dredg: that's bad and wrong
<lamont> what's the d-i magic for installing a udeb?
<diamond> dredg: the kernel source should not be untarred into /usr/src/linux
<dredg> many things are bad and wrong. let's see if i can make it handle it sanely
<lamont> (what do I type in vc2, again?)
<lamont> Kamion: ^^
<diamond> dredg: hehe, k
<Kamion> lamont: anna-install <udeb>
<lamont> ciik
<lamont> cool, even
<dredg> diamond: well, if you a linux-source package it drops a tarball in /usr/src. i could untar it to a temp directory
<diamond> dredg: yeah, that's much better
<thom> seb128: yo
<thom> mjg59: glad you made it out alive
<lamont> Kamion: that's gotta be the most bizzare error I've seen in a while...
<seb128> thom: update gtk and let me know if the booog is fixed for you too :)
<lamont> 'failed to fetch adduser'  -->  Missing dists/hoary/main/binary-powerpc/Packages (although .gz existed)
<lamont> Kamion: for breezy, d-i should understand that there might not be a Packages file...
<thom> seb128: rock, you found it?
<mjg59> These HP Bioses are approximately the worst thing ever
<Kamion> lamont: er, I thought debootstrap already did
<Kamion> lamont: it certainly looks for .bz2 and .gz
* mjg59 failed to find precisely why one of the machines still blows up on resume from disk, but did work out why lid switching is tied to video stuff
<diamond> mjg59: on proliants?
<mjg59> No, on HP Compaq things
<seb128> thom: yep, I've tracked it down and a gtk guy has made a ximian bug with a patch public when I've pointed it ...
<Kamion> lamont: might be buggy though, I guess
<seb128> thom: bad suse guys hide patches in their bugzilla :p
<lamont> hrm.. could be because there is an entry in Release, but no file...... 
<thom> seb128: hahah
<diamond> mjg59: aye, the only experience i've had with them is on some of the hp proliant servers
<Kamion> lamont: heh. DDTT
* lamont pleads the fifth
<lamont> DDTT?
<mjg59> Argh now epiphany has blown up on me
<lamont> don't do that then
* mjg59 cries
<lamont> or don't do that turdball, not sure which.
<Kamion> although it would certainly be nice if debootstrap behaved more permissively there
<Kamion> don't do that then :-)
<sabdfl> night all
<lamont> Kamion: so it gives me the choice of which kernel to install.  linux-powerpc being the only choice...  hrmpf
<lamont> hrmm.. and it fails to install... bet that could have something to do with it...
<Kamion> lamont: yeah, sounds like you've dropped down to expert mode somehow due to errors
<Kamion> lamont: check /var/log/messages
<lamont> does apt use md5 or sha1 sums?
<diamond> lamont: md5, afaik
<seb128> thom: bog ?
<diamond> lamont: apt-cache show bc | grep MD5sum
<diamond> (for example)
<lamont> diamond: for Release files, that is
<diamond> lamont: as in, the file list in Release files? 
<Kamion> Release has both md5 and sha1
<thom> seb128: can't see it
<Kamion> I think apt knows how to check either; dunno if it can check both
<mdz> apt only pays attention to the md5s in Release
<mdz> (currently)
<Kamion> ah, I just noticed apt-pkg/contrib/sha1.*
<seb128> thom: rock
<Kamion> I've been meaning to make a bunch of d-i stuff check sha1 instead of md5
<mdz> yes, it has SHA1 code in it (and apt-ftparchive release will generate the SHA1 hashes), but apt doesn't check them when downloading
<mdz> it needs some refactoring
<Kamion> probably not worth it if apt doesn't, though
<Kamion> imo it isn't worth the computing time to check both
<thom> seb128: yeah, looks good to me
<diamond> also sha1 now has known brute-force weaknesses
<seb128> nice
<tseng> diamond: so does every crypto algorithm
<Kamion> diamond: only collision, not second-preimage
<tseng> its just a matter of time.
<Kamion> tseng: sha1 has known collisions (which is worse than the plain stupid brute-force attack), but it doesn't have a known second-preimage attack yet AFAIK which is what you'd need for significant attacks
<Kamion> on the Release/Packages scheme
<diamond> Kamion: aye, but it's a good enough reason to be moving away from it
<diamond> any such migration is going to take quite some time anyway
<tseng> as I understand it its inevitable for a known colision to happen anywhere
* lamont finally finishes hacking over the Release file so that it agrees with the Packages files
<Kamion> diamond: sure, sha-256 or sha-512 - but those are just pushing back the barriers a little, and there's some reason to believe they'll fall soon. so far there exists no hash algorithm that isn't vulnerable to the basic attack
<diamond> Kamion: *nod*
<lamont> and then restarts the install
<lamont> sigh
<Kamion> tseng: when cryptanalysts speak of collision attacks, they are talking about something more interesting than that
<Kamion> anyway, bedtime
<diamond> i'll leave ye folks to it anyway, i have decided on sleep. nite
<Kamion> lamont: boot with archive-copier/copy=false
<lamont> server
<Kamion> heh
<thom> Kamion: i've been meaning to ask, what the heck is a "second pre-image"?
<lamont> just give me a working install dammit!
<thom> (appropriate pointers to RTFM happily accepted)
<Kamion> thom: second-preimage> given M and H(M) = X, find M' such that H(M') = X
<Kamion> i.e. find second message (preimage) with same hash (image)
<Kamion> tseng: an interesting collision attack is one where you can find a collision more cheaply than could be done by plain guesswork
<Kamion> and since people generally rely on the expense of finding collisions, that is not something to shrug off with "oh, but it would have happened anyway"
<Kamion> but still, a collision attack is only: find M and M' such that H(M) = H(M')
<Kamion> for a collision attack, you aren't aiming at any particular hash
<mdz> Kamion: night, great work on RC
<Kamion> in order to attack a Release file, you're trying to find another Packages file with the same hash, which is a second-preimage attack problem
<Kamion> anyway, really bed
<Kamion> mdz: thanks, night
<lamont> File does not exist: /org/ubuntu/tree/dists/hoary/main/binary-powerpc/Packages.bz2
<lamont> now what did I do to piss it off?
<thom> Kamion: right. thanks :-)
<lamont> "Please wait, loading kernel...\n"
<lamont> and then all the time in the world...
<lamont> I don't think it likes my G3...
<mdz> we get a regular stream of bug reports about "B&W G3" machines
<lamont> this one is color!
<lamont> B&W is unsup, colour is officially supported, last I heard...
<lamont> (that's why I bought it...)
<lamont> hung with just return (or timeout), and with "/boot/vmlinux video=ofonly"
<ogra> hmm, in total 72 from 892 hwdb submissions have a dectivated swap partition, interesting...
<Burgundavia> ogra: I only bothered making one a little while a go, and I don't see a performance increase
<ogra> Burgundavia, depends.... this guy wont be happy without swap: http://hwdb.ubuntu.com/?xml=3b301d3f8bc58a58edc0bafc6af59c45
<ogra> only 240MB mem are not very good....
<dredg> i always have one. just because you have oodles of ram doesn't mean that any apps that are sitting idle should be using it
<Burgundavia> ogra: ouch. I have a gig, so I am in a little different boat
<Burgundavia> dredg: that is waht sold me on getting a swap partition too
* dredg finds that the test sound does not play
<ogra> heh, while we speak the next one rushes in http://hwdb.ubuntu.com/?xml=b09ef584490854dff848b4952485be13
<Burgundavia> ogra: is it mailing now?
<dredg> or at least, i cannot hear it
<ogra> Burgundavia, nope, HTTP-POSTing
<Burgundavia> ogra: ok
<Burgundavia> ogra: how do I tell what my id is?
<ogra> Burgundavia, read whats written under the id search field ;)
<ogra> does only work if you submitted online...
<Burgundavia> ogra: hmm, that reading thing is really getting to me
<zenwhen> so is the current image the RC
<zenwhen> ?
<ogra> zenwhen, the image with -rc- in its name... 
<Burgundavia> ogra: usability suggestion with your send to server thing
<Burgundavia> ogra: make it part of the same window and provide some better feedback
<CarlK_afk> is the RC the same as rsync cdimage.ubuntulinux.org::cdimage/daily/current/hoary-install-i386.iso ?
<ogra> Burgundavia, i'm having plans with the separation of the scripts in mind for breezy, so i cant integrate it...
<Burgundavia> ogra: ok
<ogra> but i'm aware of the feedback problem....
<Burgundavia> ogra: if it timesout, it doesn't give any feedback, that is what I just discovered
<ogra> oh, please file a bug, i havent had this case yet
<Burgundavia> I ran it from a terminal
<Burgundavia> then I closed the terminal after the main window went away
<Burgundavia> and then it timedout
<Burgundavia> I am going to try and replicate it first
<ogra> ah, ok....i didnt think anyone would run it from a terminal, hehe
<Burgundavia> yep
<Burgundavia> I can replicate it
<Burgundavia> will file a bug for you
<Burgundavia> should I file 2? one for feedback issue and 1 for terminal issue?
<ogra> but i guess it doesnt happen if you run it from your menu
<Burgundavia> no, if you run from menu it works fine
<ogra> ok
<Burgundavia> ogra: 8424 and 8425 are yours
<ogra> thanks :)
<ogra> oh, that one is interesting...http://hwdb.ubuntu.com/?xml=bc62bb4efe25dc7c19845369a9453bc9
<Burgundavia> ogra: that is me
<Burgundavia> my bios is crap
<Burgundavia> doesn't detect my chip
<ogra> Unknown CPU Typ is funny
<Burgundavia> it is a mobile 2500+
<Burgundavia> overclocked to 2.2 GHZ
<schweeb> I sent a record in earlier
<ogra> schweeb, you can look up your id and look if your cpu and mem data is correct...
<schweeb> http://hwdb.ubuntu.com/?xml=c5e70fd84c43df20f8e4e091988721f3
<schweeb> looks good
<Burgundavia> ogra: the hwdb thing is very very cool. It is also completely unique in the linux world to the best of my knowledge
<ogra> yeah
<Burgundavia> ogra: how many PPC and amd64 overall?
<ogra> Burgundavia, lets see how big we can grow it with a real DB :)
<Burgundavia> ogra:  it is just flat data right now?
<ogra> Burgundavia, havent got a DB yet, its just the interim solution to win a little time...
<Burgundavia> ok
<ogra> its all grep and ls output ;.P
<Burgundavia> post hoary is where the major hacking is going to happen?
<ogra> currently its in the source package and on the server....i will set up a bazaar repo...
* lamont goes to parent teacher conferences
<HrdwrBoB> lamont: :/
<dholbach> goooood morning
<ogra> heh
<jbailey> dilinger: There?
<dilinger> jbailey: i was about to hop in the shower, i smell like sweat and chalk.  what's up?
<mdz> ogra: how many submissions so far?
<ogra> mdz, hwdb.ubuntu.com ;)
<ogra> +180 on my disk that i still have to process manually
<mdz> ogra: nice!
<ogra> mdz, 77 of the online submissions have no swap :(
<mdz> ogra: why is that a problem?
<ogra> because we had a hibernate bug during the development process ... hibernate stuff
<ogra> that broke the swapspace...
<whiprush> oh hot, it accepting stuff from the clients and everything?
<mdz> ogra: that can be fixed on upgrade eventually
<ogra> so i guess a lot of these people dont know they have no swap.... especially these with 256MB =<
<ogra> will hvae a very bad life currently
<ogra> ergh s/</>
<schweeb> whiprush: yes
<mdz> jbailey was working on a fix, was he not?
<whiprush> neat
<mdz> I saw some relevant changes going in
<ogra> the fix is to have 3xmem = swap on hibernate
<ogra> which is done by the installer afaik
<daniels> ogra: 
<daniels>   File "/usr/bin/hwdb-xml", line 39, in __init__
<daniels>     for line in self.xorgconf():
<daniels>   File "/usr/bin/hwdb-xml", line 147, in xorgconf
<daniels>     xconf.append("  <subsection name="+splitted[1] .strip()+">")
<daniels> IndexError: list index out of range
<ogra> ouch
<mdz> mako: ping?
<ogra> daniels, can you send me the xorg.conf ?
<mdz> mako: I received what looks like an automated email about confirming my shipit order
<mdz> mako: it doesn't explain what I should do in order to confirm, though
<daniels> ogra: sure.  it's my own hacked one, which might explain it
<ogra> ah, night be :)
<ogra> might even
<daniels> http://amnesiac.heapspace.net/~daniel/misc/xorg.conf
<daniels> this is probably it:
<daniels> SubSection<tab>"Display"
<daniels> as opposed to a space
<ogra> i'll check it .... but not yet, 4:30am is sleep time :)
<ogra> thanks for the file
<ogra> night all
<daniels> g'night dude
<jbailey> mdz: Yes, I have a patch against file (Accepted upstream), and the rest is a bit of shell script, planning to upload tomorrow.
<mdz> jbailey: where is the shell script going to go?  it's very late in the release to put something like thi sin
<mdz> it has to fail absolutely safe
<jbailey> mdz: in mountall, there's a second swapon.  The bits of script looks for any swap partitions that aren't listed in /proc/swaps, and does a file -s /dev/FOO on them.  If the output string contains the string SWSUSP1 in it, it runs mkswap on it, and reruns swapon -a.
<mdz> jbailey: will it cope with devfs pathname borkage?
<jbailey> I'd have to test to be sure.  I think the worst that happens in that case is that it does extra 'file -s', which is a readonly test.
<jbailey> The biggest risk is running a swapon against a live swap partition.  mkswap doesn't seem to have any sanity checks on that.
<jbailey> Do you think that's too risky?
<mdz> the biggest risk would be running a swapon against a partition with a filesystem on it :-)
<mdz> er, a mkswap
<jbailey> Erm, right. =)
<mdz> this is to handle the case where a resume fails, right?
<jbailey> right.
<jbailey> Usually caused by someone doing a suspend, where the kernel guesses which swap partition to use, but there's nothing in grub/lilo/whatever to tell it to resume.
<mdz> so it doesn't affect fresh installs, which set that up correctly by default?
<jbailey> I think it could also happen if someone upgrades a kernel then suspends.
<mdz> it seems like it would expose practically every user to a certain amount of risk, in order to cover a corner case
<mdz> the worst of the corner case is that the user has no swap
<jbailey> Right.
<mdz> the worst of the risk is that they lose data
<mdz> mkswap has practically no safety checks; it'll blow away whatever you ask it to
<mdz> it's a very uncomfortable choice
<jbailey> Yup.  Could put it in the release notes and note it as a mostfreq reported bug.
<mdz> I haven't seen a lot of bugzilla activity around this issue; is it really that common?
<jbailey> I don't know how to measure that.  I've helped 2 or 3 people in #ubuntu with it, and certainly hit it myself.
<mdz> since it has a simple workaround, I'm inclined to delay the automatic fix until Breezy
<jbailey> Fair 'nuff.  I'll put my patch in the bug and tag it 5.10
<mdz> thanks
<jbailey> dilinger: Sweat and chalk?  Do you do gymnastics?
<infinity> jbailey : That's what I was thinking... Or marathon chalkbrush cleaning.
<jbailey> *lol*
* jbailey should try gymnatics again now that he's working out on a regular basis.
<infinity> I'd feel silly going back to it.
<infinity> I was on the national team when I was 10.  Kinda haven't done much since then.
<infinity> At 27, I'm not quite as.. Bendy.
* daniels kicks infinity.
<jbailey> There was a lovely club in Vancouver that had an adult gymnastics program that was really nice.  Wide range of folks and a few instructors.
<Guilmon> damn. Me expected an answer, but I guess new people are active in #ubuntu 
<jbailey> They'd let you hang out on the machines pissing around as long as you were being reasonably safe about it and a couple times an hours go to one of the stations and demonstrate/help.
<Guilmon> anyone want to answer me a question because me blind? :P
<dilinger> jbailey: heh.  rock climbing.  might as well be gymnastics tonight, though.  i definitely bent ways that i'm not supposed to
<Guilmon> Me wishes to ge mountain climbing :)
<Burgundavia> jbailey: your a canuck eh. come to #ubuntu-ca
<Guilmon> Maybe in aslaska :)
<jbailey> dilinger: Nice.  There's that whole "trust your belayer" bit that I have troubles with.
<jbailey> Burgundavia: I did tell you guys that I wouldn't be there often.  I have 5 #ubuntu-SOMETHING windows open already...
<Burgundavia> jbailey: ok
<Burgundavia> jbailey: I was just wondering if you were going to make it down to LFNW
<dilinger> jbailey: i've known my belayer for 5+ years
<jbailey> Burgundavia: dict LFNW?
<dilinger> jbailey: i have no problems trusting him
<infinity> dilinger : All the more reason to distrust.  People who know you well are more likely to kill you.
<Burgundavia> jbailey: Linux Fest Northwest
<jbailey> dilinger: Cool.  I would probably learn to climb with my while.  She's cute, but occasionally she's as distractable as a golden retriever. =)
* infinity fears off-topicness going the way of debian-devel, and shut up.
<dilinger> infinity: i'm not sure if i give people motive enough to kill me
<infinity> s/shut/shuts/
<dilinger> jbailey: so anyways, what's up/
<jbailey> Burgundavia: I see a collection of user groups involved, I don't see a city.
<Burgundavia> jbailey: ? it is in Bellingham, WA
<jbailey> Burgundavia: But in any event, no, I won't be attending.  I'm not available on April 30th for heading out that way.
<jbailey> dilinger: I was reading the link you posted to.. Lemme find the bug.
<jbailey> dilinger: 1763, ide auto detection stuff.
<jbailey> Bartlomiej Zolnierkiewicz's patch for move the ide stuff to a driver model, and I see that it's in his sync set from March 8th.
<jbailey> dilinger: How does it usually work from there?  I've never followed how patches get pulled from the ide folks into the main trees.
<jbailey> dilinger: I'm wondering what sort of craziness we would have to face if suddenly people upgrade their kernels themselves to this.  Will they get breakage with ide-generic being loaded by hotplug and such?
<Burgundavia> mako: ping
<dilinger> linus needs to pull it; check out the netdev-2.6 posts that jgarzik does to lkml
<dilinger> obviously, it would need to be tested.  i haven't been following bart's work, although i still intend to play w/ it once all the travel craziness and sarge stuff passes
<infinity> lamont : Around?
<fabbione> morning
<lamont> infinity: yo
<lamont> morning fabbione 
<mako> Burgundavia: hey dude
<fabbione> no daniels?
<infinity> lamont : Two things.  Can you retry 'php4-universe' on all arches?
<infinity> lamont : And once that's kicked off, can you rety php4, and see if it's still confusing the heck out of buildd/sbuild?  (And if so, help me figure out why?) :)
<infinity> lamont : php4-universe was failing because it was in main, not universe.  mdz fixed that.  No idea why php4 is so confused, mind you, since the string "universe" doesn't show up anywhere in its source package.
<mdz> it had to get into the archive before I could move it, so there was a largely inevitable window there where it would fail
<infinity> Heh.
<mdz> what's php4 doing?
<infinity> mdz : It's not getting far enough to do anything.  sbuild's confusing it with php4-universe.
<fabbione> hmmm it looks like people have some kind of love for "blocker" in bugzilla
<mdz> oh dear, that's weird
<mdz> fabbione: indeed
<infinity> mdz : It downloads the source, then tries to open php4-universe.dsc, which obviously fails.  Very odd.
<schweeb> fabbione: did you say you had completed those Xen kernels, or were you still workin on them?
<infinity> I wonder if this has to do with binary/source packages of the same name coming from different sources, or something.
<infinity> Oh, it probably does too.
<mdz> lamont: I think you want apt-get --only-source source
<infinity> Some broken heuristics for "apt-get source php4".
<fabbione> schweeb: actually i do have the kernels, but they can't boot. For some reasons the final vmlinux is an ELF binary that grub can't understand, while a normal image is marked as x86 boot something
<mdz> for values of 'broken' including 'gets it right in every case except the weird one you just created, and has a convenient override which should have been used here in the first place', sure :-P
<infinity> mdz : Are you sure it isn't using --only-source already?
<infinity> mdz : Without it, I'd expect it to download php4-universe's source too (since that's the source for the php4 binary)
<fabbione> schweeb: i was hoping to fix them sometime during this week
<mdz> infinity: I can think of no other explanation
<fabbione> schweeb: or at least try to
<mdz> oh, wait, this isn't apt at all
<infinity> mdz : Still, fixing apt bugs right now seems bad, it might be easier to move the (empty) php4 meta-package to main.
<mdz> sbuild does the unpacking
<infinity> Oh, good point.
<mdz> apt is getting the right package, and then sbuild is looking for something else
<infinity> apt only downloads.
* lamont goes looking
<infinity> mdz : If lamont can't find/fix it reasonably quickly, I can just move the php4 package from universe to main.  It's only 1120 bytes.
<mdz> lamont: a simple retry, now that I've moved php4-universe to universe, might suffice for now
<mdz> https://www.ubuntulinux.org/wiki/CantInstallMP3Support
<mdz> there's a new and creative way to ask for support without using the appropriate channels
<infinity> Oh, ffs.  net-snmp FTBFS now.
<infinity> (And not due to my change.. It never got that far)
<infinity> Great.
<mdz> weird; lamont test-built the entire archive recently
<lamont> mdz: wow.  we should make somewhere where they can create things like that.
<lamont> mdz: is test-building again
<infinity> COuld be cosmic rays.  This machine has occasionally flaky RAM.  <tries again>
<lamont> as of this morning ish?
<calc> lamont: similar to pastebin?
<mdz> ugh, it runs auto* during the build
<mdz> no wonder it doesn't work
<lamont> calc: is there a reason that php4-universe has a binary named 'php4'?
<calc> no idea
<lamont> that's probably part of the confusion somewhere
<lamont> Package: php4-universe
<lamont> Binary: php4-imap, php4-curl, php4-mhash, php4-gd, php4-odbc, php4-pear, libapache-mod-php4, php4-ldap, php4-domxml, php4-mysql, php4, php4-universe-common, php4-recode, php4-sybase, php4-xslt, php4-mcal, php4-snmp
<infinity> lamont : Yes, we know that's the confusion.  I've offered a simple solution (I can move the binary), but this situation should be fixable anyway. :)
<infinity> lamont : Also, I'm not calc. ;)
<lamont> infinity: doh
* calc was wondering why he was supposed to know about php4 ;)
<infinity> lamont : THe only reason it's in that source package is cause someone put 'php4' in universe long ago, and I just divided the source packages to match the current layout.
* calc bbl
<infinity> I see no reason why moving the 1120 byte package to main would hurt anyone terribly.
<infinity> (And it would allow for people to apt-get install php4, which they seem to love so much)
<mdz> infinity: net-snmp builds just fine here (the version in hoary)
* Burgundavia is away: I'm busy
<infinity> mdz : My second build is still going, so it much have been ghosts in the RAM.
<infinity> s/much/must/
<mdz> php4-in-main doesn't sound so evil, so long as it doesn't depend on apache 1.3.x
<lamont> php4-universe is either building or uploaded now
<mdz> but then you need to have php4 build it, not php4-universe
<lamont> which should break the loop nicely, I expect
<infinity> mdz : it depends on "libapache-mod-php4 | libapache2-mod-php4"
<mdz> or does it already?
<infinity> mdz : Uploading two new source packages to swap who builds it isn't rocket science.
<lamont> php4-universe was looping on apache-dev
<mdz> infinity: the old php4 package built php4, didn't it?  why move it?
<infinity> mdz : And no, it's built by universe, specifically to keep my sanity at bay.  If I need two source packages, I'd rather have them both target specific suites.
<lamont> sbuild should handle php4 just fine now that php4-universe is in universe
<mdz> retrying?
<infinity> mdz : The old one built everything it could that didn't build-dep on stuff in universe.  That was the whole point in the split, to get the extra stuff back.
<infinity> Anyhow....
<infinity> lamont : If it Just Works now, the point is moot.
<infinity> lamont : If they both get past the unpack stage, let me know. :)
<lamont> infinity: in the new world of php4, which source package delivers the php4 binary?
<infinity> lamont : php4-universe delivers it currently.
<mdz> infinity: but if php4 is just a metapackage, build-depends shouldn't enter into that particular choice
<infinity> lamont : php4 provides all binaries in main, php4-universe provides all binaries in universe.  Like I said, to make me go less crosseyed when dealing with them. :)
<infinity> mdz : Right, build-deps don't matter for it (or for many of the modules packages I moved).  It was purely a cosmetic "who builds what" thing.
<infinity> mdz : Honestly, though, if we're going to provide the php4 metapackage at all (hey, there's idea #3, we could just drop it), it may as well be in main, where people will expect to be able to get at it.  If it's not in main, I don't see much point in having it at all.
<lamont> Mar 31 05:50:02 buildd-mail: php4-universe must be manually dinstall-ed -- delayed
<lamont> php4-universe binaries are NEW
<mdz> infinity: I agree; if you'd proposed it before uploading, I most likely would have agreed
<infinity> lamont : Known.
<infinity> mdz : If I had known sbuild would freak out, I would have proposed. :)
<lamont> accepted on the 3 though
<mdz> need to let php4-universe stuff get into the archive, then move it to universe
<lamont> that is, uploaded, almost certainly sitting in NEW/
<infinity> Alright, well, if sbuild doesn't sort itself, I can swap who builds the php4 metapackage with no real issues.
<infinity> And then if you want to re-seed it to match, that's your choice.
<infinity> Deal?
<mdz> I would like to have php4 in main regardless, to be honest
<infinity> Oh.  In that case, I'll just do another upload to move it from one source to the other.
<infinity> And you can fix the seeds.
<infinity> And we'll all live happily ever after.
<mdz> assuming germinate DTRT
<infinity> And net-snmp finished fine here.  False alarm.
<mdz> is that "| caudium-php4" really useful?
<infinity> It's not there anymore.
<mdz> considering we don't have such a package
<infinity> Debian doesn't have such a package either anymore.
<infinity> And caudium-php4 shouldn't be in php4's dep list at all in either dist, unless I missed it.
<infinity> But it's harmless if I did.
* infinity goes to look.
<mdz> seed updated
<lamont> dpkg-source: extracting php4 in php4-4.3.10
<lamont> dpkg-buildpackage: source package is php4
<infinity> Nope, didn't miss it.  I'm not retarded.  Yay me.
<infinity> lamont : Ahh, so it sorted itself.  Fancy.
<infinity> mdz : I'll get new source uploaded ASAP with the swap.
<infinity> lamont : Thanks for the fiddling.
<lamont> of course, having a binary package foo delivered by source package bar, and a source package foo is just, well, wrong.
<mdz> there's a lot to be said for "apt-get install php4" doing the right thing
<infinity> lamont : That will be fixed in the next upload.
<lamont> infinity: near certain that's what had sbuild all confused.
<infinity> lamont : But thanks for babysitting the brokenish situation. :)
<infinity> lamont : I'm positive that was the source of the confusion.  Still looks like an sbuild bug to me, weird corner case though it is.
<lamont> (but with the ogre model, php4-universe (being in universe) is not in the cache for the main build of php4
<lamont> infinity: yeah
* infinity pisses off to type and test some more.
<lamont> given the corner-case-ness of it, and how much I loathe perl, and the fact that lunchpad obsoletes sbuild, I'm tempted to temporarily lump that in the 'doctor it hurts when I do this' category
<infinity> ;)
<mdz> infinity: please test an upgrade from Warty with php4 stuffs installed and make sure everything is kosher there as well
* lamont makes a note to mention the bug to neuro
<infinity> mdz : Will do.  They're functionally equivalent to Debian's packages, where I've been keeping an ongoing upgrade path all the way from Woody, so it SHOULD be okay.  But I'll test nonetheless.
<infinity> (I can't wait to scrap a lot of that code..)
<infinity> In fact, some may be upgrade from potato era...
<infinity> Hrm.
<pitti> Morning
<lamont> talk about obscure options
<lamont> if exists dhcp-parameter-request-list {
<lamont>         # Always send the PXELINUX options (specified in hexadecimal)
<lamont>         option dhcp-parameter-request-list = concat(option dhcp-parameter-request-list,interface-mtu);
<lamont> }
<lamont> gah - bad comment
<fabbione> morning pitti
<pitti> Hi fabbione 
<dholbach> hey pitti 
* pitti asks himself how early he must get up to be the first European out here...
<fabbione> pitti: way too early
<fabbione> i started soffering of insomnia again
<dholbach> pitti: at 03:45 i couldnt sleep anymore
<dholbach> but i was in bed at 22:00, maybe that's why
* Burgundavia is back (gone 00:27:24)
<dholbach> Burgundavia: could you turn that away-script off?
<Burgundavia> sorry
<dholbach> thanks :-)
<Burgundavia> done
* lamont owes ironwolf a beer
<infinity> Mornin', pitti.
<pitti> Hi infinity 
<pitti> mdz: here?
<mdz> pitti: somewhat
<pitti> mdz: you had some concerns wrt. #8263 (adding the gimp help files to l-support-*)
* lamont heads to bed
<fabbione> good night lamont..
<pitti> mdz: -en would land on the CDs, so they would grow by ~ 500 KB
<pitti> Night lamont 
<mdz> pitti: 500kb is OK
<pitti> okay, so I can add them?
* fabbione kicks k3b in the middle of the code
<pitti> mdz: -zh-cn is in universe, all other langs are in main; okay for you?
<pitti> (i. e. okay to promote to supported)
<pitti> mdz: I followup on the bug report and CC you, there is another issue
<fabbione> YAY
<fabbione> finally some multiarse good news
<aj> multiarch?
<fabbione> multiseat
<fabbione> renamed as multiarse
<fabbione> ;)
<aj> ahhh...
<aj> so not related to multiverse either
<fabbione> nope.. it's stuff in main
* mako writes a multi-verse sonet about fabbione's multiarse
<fabbione> mako: eheheh
<mako> a sonnet even
<fabbione> but i don't own the multiarse copyright
<fabbione> i didn't forge that nick
<mdz> pitti: yes, ok to promote
<mdz> pitti: hmm, looking at the bug though
<mdz> pitti: 500k is OK, but 6M may be too much
<pitti> mdz: it would sum up to 6.6 MB
<mdz> pitti: that is a bit more than 500k :-)
<pitti> mdz: yeah, I didn't take -common into account at first
<dholbach> bbl
<Lathiat> ~>
<fabbione> bah no wonder why #8396 hangs the world
<fabbione> k3b is a SIGKILLorama
<fabbione> mdz: btw did you read that link i gave to you yesterday?
<Jeeves_> Morning all
<fabbione> any MOTU's around?
<infinity> mdz : Alright, new versions built, tested, and uploaded.
<pitti> elmo: ncpfs sync, please
<fabbione> AHHHHHHH
<fabbione> amen
* fabbione feels a punk
<pitti> hi sabdfl 
<fabbione> schweeb: i figured why xen doesn't boot :)
<fabbione> hi sabdfl 
<sabdfl> morning all
<fabbione> sabdfl: i got the AGP/PCI solved!
<fabbione> sabdfl: but it's both bad and good news
<sabdfl> ok?
<fabbione> the bad news is that for hoary we will have to use the nv driver = no 3d accel
<sabdfl> erk
<fabbione> the good news is that the problem is not the bios or the hardware
<fabbione> but the nvidia binary driver
<sabdfl> ok
<sabdfl> ah
<fabbione> the new version fixes it
<sabdfl> is there an update on the way
<sabdfl> ok
<sabdfl> mdz?
<fabbione> but we can't upload it to l-r-m
<fabbione> it's way to late to jump so far
<sabdfl> hmm
<fabbione> i think using the nv for hoary is a good compromise and not intrusive
<fabbione> just commeting one line in multiarse-configurator
<sabdfl> ok
<sabdfl> isthe new nvidia binary known good or bad?
<fabbione> sabdfl: dunno.. works here on one machine.
<sabdfl> how new is it?
<fabbione> checking now...
<fabbione> Release Date: March 11, 2005
<fabbione> 20 days old...
<fabbione> kinda risky
<fabbione> and i am pretty sure mdz will not like the idea of a major upstream release change after RC
<infinity> binary-only drivers are unsupportable either way, regardless of when it's added, so maybe he'd let it slide.
<fabbione> infinity: there is more than that. remember that the nvidia stuff also adds libs that are used by xorg
<sabdfl> fabbione: the cape town machine, was that also nvidia, or was it ATI-based?
<fabbione> sabdfl: afaik it is nvidia too
<fabbione> sabdfl: can you give me the email address of the guy handling it in SA?
<infinity> fabbione : libGL stuff, you mean?.. Or does it do more these days?
<fabbione> i would like to get some info about that machine
<fabbione> infinity: libGL
<infinity> FWIW, I've never had the nVidia libGL blow up, only the video driver (occasionally) and the kernel driver (more often).
<infinity> But that's just my personal experience on a few machines.  Not much help, I suppose.
<infinity> (Well, my personal experience as an avid Quake player, so I do USE libGL..)
<fabbione> infinity: no relly.. i am not confortable at all in updating the driver
<fabbione> 1) it taint the kernel
<fabbione> 2) it interacts with xorg
<fabbione> this is a suicide combination if the driver is borked
<fabbione> + we are going to release in a wekk
<fabbione> week
<fabbione> that means that it will not get enough testing
<infinity> Oh, I'm inclined to agree, it's just a shame if there's a showstopper bug on the current one.
<infinity> Not that I'm familiar with the bug you're talking about.
<fabbione> infinity: it's a very specific setup we are talking about
<infinity> Ahh, kay.
<fabbione> a machine with N gfx cards
<fabbione> one agp and the others are PCI
<fabbione> the problem is the order in which you initialize the cards
<fabbione> on 2 machines we have 2 different behaviours
<fabbione> machine a) init agp first, pci after = ok
<fabbione> machine b) same as above = hard freeze
<fabbione> if we init agp as last
<fabbione> the behaviour is reverted
<HiddenWolf> daniels: ping
<HiddenWolf> Anyone working with Xorg on now?
<infinity> Does it relate to the BIOS setting for initialising video cards, by any chance?
<fabbione> infinity: nope.. test that too
<fabbione> it's just a bug in the nvidia binary driver
<fabbione> infinity: the nv driver works perfectly in both combination
<fabbione> HiddenWolf: daniels is not online and he is working xorg
<infinity> Find the offending bit with a hex editor and twiddle it? :)
<HiddenWolf> fabbione: I just installed warty > hoary-rc and I do not have X
<fabbione> infinity: yeah right :)
<fabbione> HiddenWolf: report the bug on bugzilla
<HiddenWolf> fabbione: I have no clue what the bug is. Using links and irssi atm
<sabdfl> jdub: around
<fabbione> HiddenWolf: check the usual stuff.. /etc/X11/xorg.conf /var/log/Xorg.0.log
<fabbione> HiddenWolf: and add them to the bug
<fabbione> HiddenWolf: daniels will help to debug
<fabbione> (if he needs more info)
<HiddenWolf> fabbione: thanks. I'll go back to being totally and utterly stressed out now. (my old pc died 2am yesterday-night, before I could get my data off, and now the new one is totally fucked up)
<fabbione> HiddenWolf: usually the log has a clear message of why X didn't start
<fabbione> at least check that
<fabbione> schweeb: ping?
<jdub> sabdfl: yo
<HiddenWo1f> fabbione: do you by any chance know what busid I should give for a pci-e graphics card?
<fabbione> HiddenWo1f: you need to check with lspci
<fabbione> gimme a sec...
<HiddenWo1f> fabbione: thanks. (somehow I can't switch vt's if I have irssi open, so I'll have to quit to try modding)
<fabbione> HiddenWo1f: run this command: lspci -Xn | grep " 0300:"
<fabbione> the BusID is the entry that looks like: PCI:1:0:0
<HiddenWo1f> I'll brb
<mako> so evidently, *userlinux* doesn't know where the source is to the userlinux metapackages
<mako> at least not to the userlinux-server-base package :)
<Burgundavia> lol
<fabbione> mako: ehehe yeah.. i read that :)
<HiddenWo2f> fabbione: busid is correct, but I get the error "unable to open framebuffer device / screens found, but none has a usable configuration"
<fabbione> HiddenWo2f: can you put your xorg.conf somewhere?
<sabmoc> mako So after talking to the LFNW people it turns out nobody has made arrangements to setup a booth, maybe that group you talked to backed out, or maybe they just planned to hand out CDs and thats it.
<sabmoc> mako:: Anyway, so we have made arrangements to setup a booth now, and I even roped Burgundavia into giving a presentation.
<HiddenWo2f> fabbione: if you can tell me how to ftp from the command line
<spiv> HiddenWo2f: http://rafb.net/paste may help
<fabbione> HiddenWo1f: use lftp
<HiddenWo2f> brb again
<mako> sabmoc: awesome
<mako> sabmoc: Burgundavia already contacted me.. i pointed him to my notes/slides from a previous set of talks
<Burgundavia> mako: have you seen this? http://lwn.net/Articles/129465/#Comments
<sabmoc> mako:: I pointed him to the same slides :)
<sabmoc> mako:: what is a good ratio for attendee's/cd's at a confrence? There will be about 300 people I think.
<mako> Burgundavia: i didn't even know that it made it onto lwn :)
<mako> sabmoc: one for everyone? :)
<Burgundavia> mako: came almost right away, but only made the weekly roundup now
<sabmoc> Thats what I was thinking but I didnt want to go overkill 
<Burgundavia> from being there last year, I can say that not a lot of people were actually taking cds, but I could be wrong
<mako> Burgundavia: that guy doesn't know what he's talking about
<mako> Burgundavia: bruce's message is the most sane
<mako> at the bottom of the page
<mako> it basically says that we shouldn't say that it *is* userlinux
<mako> which we wouldn't, since it's not :)
<mako> well, so it got on lwn and nobody mailed me any bug reports yet.. that's a good sign
<Burgundavia> I suspect that is simply a non-starter all around
<mako> yeah, i wouldn't install them on my main machine :)
<Burgundavia> sorry, but the boat has sailed Bruce
<Burgundavia> some mad millionare came on said go
<Burgundavia> so it did
<mako> well bruce doesn't seem to care all that much about userlinux any more
<Burgundavia> and said
<mako> he used to care about it a lot more
<Burgundavia> it is too bad
<Burgundavia> userlinux is a good idea
<Hiddenwolf> fabbione: lftp is being a bitch, won't work
<Burgundavia> mako: another misguided soul --> http://ninkendo.org/view.pl?id=49
<sabmoc> mako:: I hear they got pretty bogged down with ideas and didnt get much done.
<mako> well.. i am on the userlinux list now.. i'm going to post a few messages and then go to sleep i think :)
<Burgundavia> mako: that is new on the userlinux page. A mark protection link
<Hiddenwolf> fabbione: ftp.ibasr.nl/ubuntu/xorg.conf
<fabbione> Hiddenwolf: invalid username/passwd
<fabbione> it doesn't allow anon access
<Hiddenwolf> fabbione, damn
<spiv> Hiddenwolf: Simplest is probably to submit a bug report and attach the xorg.conf and the Xorg.0.log.
<fabbione> Hiddenwolf: ok hold on a sec...
<Hiddenwolf> spiv: "this version of links does not include ssl/tls support
<Hiddenwolf> fabbione: going nowhere, save for cardiac arrest
<crimsun> Hiddenwolf: install links-ssl instead
<Hiddenwolf> crimsun: lifesaver
<fabbione> Hiddenwolf: check your xorg.conf for a line like this one: Option FbDev true
<fabbione> or "yes"
<fabbione> Hiddenwolf: comment it out if there is one
<fabbione> and try to start X
<fabbione> see if something changes in the logs
<Hiddenwolf> fabbione: which section?
<Hiddenwolf> nm, got it
<fabbione> Section "Device"
<HiddenWo1f> fabbione: that did change something. Instead of a new error message, I get a psychedelic pink/gray/green x screen that isn't killable
<fabbione> HiddenWolf: i need the logs and the config. can you boot with a liveCD and put them somewhere i can actually access them?
<HiddenWo1f> fabbione: I'll go and figure a way, then get back to you
<fabbione> ok
<GheRivero> res people
<crimsun> doko_: thanks for the python update!
<HiddenWolf> fabbione: #8438
<HiddenWolf> Tell me if the attachments are there, doesn't seem that links likes uploading
<fabbione> HiddenWolf: one moment...
<fabbione> HiddenWolf: remove the VideoRam 128000 line and the UseFBDev
<fabbione> forcing the VideoRam is not required on nv
<HiddenWolf> Tell me, what's the most direct way to cut off X if it starts looping again?
<HiddenWolf> cntrl-alt-backspace didn't cut it
<fabbione> HiddenWolf: probably not starting gdm, but it really depends on the problem
<HiddenWolf> fabbione: uncommenting fbdev led to psychedelic effects again. had to reboot to kill x
<fabbione> HiddenWolf: did you uncomment the VideoRam too?
<HiddenWolf> Yup
<HiddenWolf> The default install didn't put that in there btw, dpgk-reconfigure did
<fabbione> HiddenWolf: i can't see anything else wrong.. we will have to wait daniels
<HiddenWolf> fabbione: thanks. :S
<HiddenWolf> fabbione: this wouldn't be so bad if I could figure out why my main/old rig suddenly gave in and refused to boot. :S
<HiddenWolf> anyhow, I'll wait and shut up. :)
<fabbione> HiddenWolf: sorry, but it is really too long since i have been digging into X for debugging
<HiddenWolf> fabbione: doesn't matter, I'm just totally stressed about the old rig not booting, giving a few beeps only. Don't have the manual, so can't check what the beep code is, but I fear it's fucked.
<fabbione> HiddenWolf: the beep have a standard format. usually a few beeps = bad ram
<HiddenWolf> had two pc's running the other day. Each on a bank of the same identical ram. Switching it didn't work either.
<HiddenWolf> Fabbione: It seems 'nv' driver doesn't support 6600 cards yet. Changing to nvidia does the trick
<doko> d3vic3: ping
<d3vic3> doko, pong 
<Mithrandir> hm http://www.ubuntulinux.org/ubuntu/releases/document_view still lists 5.10 as grumpy
<fabbione> hey pitti
<fabbione> i was just waiting for you
<fabbione> pitti: if you have time, can you just check teh security history of xen?
<pitti> fabbione: yeah, I attended the diploma presentation of a friend
<pitti> sure
<fabbione> thanks
<sabdfl> Kamion: is it safe to say that fabbione's multiseat work will get into tomorrow's daily if it is uploaded today>
<sabdfl> ?
<sabdfl> is anybody else seeing aplay getting stuck?
<sabdfl> try /usr/bin/aplay /usr/share/sounds/question.wav
<sabdfl> and let me know if it works for you?
<sabdfl> for me it just hangs
<Mithrandir> worksforme
<trukulo> hi
<Mithrandir> won't aplay try to use alsa directly, so it'll hang if you don't have hardware mixing?
<pitti> sabdfl: aplay can't possibly work
<pitti> sabdfl: because esd already claims the alsa interface
<Mithrandir> pitti: it can, but you need hardware mixing
<pitti> sabdfl: try esdplay
<sabdfl> pitti: i thought the whole point of alsa was to make that possible
<pitti> Mithrandir: ALSA can mix, too, but its not configured to do so by default
<pitti> sabdfl: ^
<Treenaks> dmix?
<pitti> sabdfl: it is possible, but we don't do it by default
<pitti> Treenaks: exactly
<sabdfl> pitti: does it break on some setups? is that why we don't try by default?
<pitti> sabdfl: I don't know it overly well; I tried it the other day and it worked relatively easy, but I lost dynamic frequency adaptio
<sabdfl> seb128: grrr, what happened to left-double-click-closes-folders-when-opening-new-folders?
<sabdfl> k
<pitti> sabdfl: i. e. I could not play a 22.050 Hz sample at correct speed
<sabdfl> pitti: ok
<pitti> it should be possible to combine mix and resampling, but esound already does it
<pitti> seb128: is there any possibility that you upload another gdm before release?
<trukulo> one question, boot process is as fast in fresh installs of hoary, than in upgrades from warty with aptitude?
<pitti> seb128: the gdm translation tarball was lost; of course I can recompile it, but if you upload anyway, I don't need this
<pitti> trukulo: hm, should
<seb128> sabdfl: you said to wait a day, that you were going to mail the list about it and no news ...
<trukulo> pitti, i don't see any fast boot on my computer, in fact, sid is much more faster than hoary
<seb128> pitti: k, I'll do an upload
<pitti> seb128: not if you don't need to
<Treenaks> trukulo: how much memory do you have?
<seb128> sabdfl: I assumed that you talked with other guys and changed your mind ... do you want the change to go now ?
<trukulo> Treenaks, 768 MBs
<Mitario> lo everyone
<Treenaks> hey Mitario 
<sabdfl> seb128: yes please
<seb128> pitti: for the moment I don't need to
<seb128> sabdfl: k
<sabdfl> seb128: there are some subtleties, apparently that required more than a straight swapping of the keys
<sabdfl> buttons
<seb128> like ?
<sabdfl> if you double click anything other than a folder, the folder should stay open
<sabdfl> is that the case?
<seb128> right
<seb128> that's only a swap of the "folder opening" action
<sabdfl> so double-clicking an image loads the image viewer, leaving the folder open
<sabdfl> double-clicking a folder opens the new folder, and closes the existing one
<Treenaks> I hope that's configurable then
<seb128> hum, need to check but that should be fine
<crimsun> pitti: err, regarding dmix, which virtual device were you using?
<sabdfl> shift-double-clicking a folder opens the new folder, leaving the older one open too
<crimsun> pitti: did you create an ~/.asoundrc || /etc/asound.conf, or were you using plug:dmix ?
<seb128> sabdfl: k, understood. I'll change that today
<sabdfl> thanks seb
<pitti> crimsun: I created an /etc/asound.conf which set up dmix
<seb128> np
<pitti> crimsun: 
<crimsun> pitti: if you have time, please test instead aplay -Dplug:dmix foo.wav
<pitti> pcm.!default {
<pitti>   type plug
<pitti>   slave.pcm "dmix"
<pitti> }
<pitti> pcm.dsp0 pcm.default
<crimsun> hmm
<pitti> crimsun: that doesn't work, because esound still claims the interface
<pitti> crimsun: you need to run esd with dmix, too
<crimsun> pitti: right, I'm just concerned with dmix at the moment :)
<pitti> crimsun: it works, but it doesn't do resampling with this conf
<pitti> crimsun: but resampling is crucial
<crimsun> the built-in dmix (if you don't have /etc/asound.conf or ~/.asoundrc) should work with resampling as plug:dmix.  If it doesn't, that's a bug.
<pitti> fabbione: so far it seems that _every_ user on xen domain0 (i. e. the host platform) can control all domains
<pitti> fabbione: that's not really desirable...
<fabbione> pitti: hmm right
<fabbione> that kinda sucks
<pitti> fabbione: the intention obviously was to have a user-free dom0
<pitti> fabbione: an all users work in a domain
<fabbione> pitti: yes, that was my point too
<fabbione> there should be no users in dom0
<pitti> fabbione: so this should at least be documented properly as long as there is no access control (upstream plans something like this)
<fabbione> pitti: ok. for now it is all limited to userland stuff
<fabbione> kernel appears to be fine tho
<pitti> yeah
<pitti> fabbione: is the kernel part like UML? I. e. you have a normal -i386 kernel for dom0, and -xen arch kernels on top of it?
<fabbione> something like that yes
<smurfix> fabbione: you don't have a normal kernel for dom0 though
<ross> mvo: ping?
<fabbione> smurfix: yes i am aware of that
<fabbione> smurfix: right now i manged to build some kernel images, but they don't boot yet
<fabbione> i need to understand why
<fabbione> but it will be another day work
<fabbione> today i am pretty busy
<smurfix> fabbione: I can imagine. (NB: that was a thinko, I should've typed pitti:.)
<pitti> I read it anyway 
<mvo> ross: pong
<fabbione> smurfix: ehehe
<Kamion> sabdfl: multiseat, tomorrow's daily> yes, certainly
<Kamion> as long as it builds, at least. multiseat isn't in the installer initrd, which is where extra delays get introduced
<sabdfl> Kamion: thx
<fabbione> Kamion: yes, it builds :-) already checked on 5 arches
<fabbione> i am doing some tests at the moment and some bug fixes
<fabbione> it will need NEW love tho
<fabbione> arch: all -> arch: any
<Kamion> why should that need NEW love?
<Kamion> (it doesn't, unless you've also changed package names)
<HiddenWolf> fabbione: thanks again for the effort this morning
<fabbione> HiddenWolf: it's ok. don't worry
<fabbione> Kamion: hmm right...
* fabbione 's brain is melting down
<mvo> ping doko 
<doko> mvo: pong
<mvo> doko: could you please run the testcode for #8447 on your amd64 box? when you have a moment, it's not urgent
<doko> mvo: same behaviour
<mvo> doko: thanks. it doesn't crash on my i386 box, I was wondering if it is amd64 specific
<doko> seems so ...
<ogra> morning world
<trukulo> morning oliver
<dholbach> hey ogra 
<thom> morning ogra 
<ogra> thom, http://hwdb.ubuntu.com ;)
<ogra> just injecting your laptop-detect code in the output scripts....
<koke> mvo: FYI, spanish translation updated on update-manager
<thom> ogra: kick ass
<ogra> hehe :)
* thom submits his amd64
* HiddenWolf can't run amd64 apperantly
<mvo> koke: thanks :) 
* mvo goes shopping to get some food
* mjg59 struggles with Bluetooth
<mjg59> Is the gnome-bluetooth stuff in Universe expected to work?
<dholbach> mjg59: i can test... it worked some weeks ago
<mjg59> The browser thing seems a bit... fragile
<dholbach> browser thing?
<mjg59> Bluetooth manager
<mjg59> And I don't seem to get a Send via Bluetooth thing in Nautilus
<dholbach> i always used gnome-obex-send (since the nautilus-"send to bluetooth..." is broken)
<dholbach> yes
<Treenaks> mjg59: send via bluetooth might be an old-style nautilus extension
<mjg59> Ah. Hrm.
* mjg59 wonders how much pain it would be to fix that before release
<dholbach> oh... gnome-bluetooth-manager just breaks, when starting up
<Lathiat> bluetooth manager doesnt do much
<Lathiat> just lists devices
<Lathiat> it was broken cus gnomeappbar wasnt in python
<pitti> Moin jbailey 
<Lathiat> i patched it to use a normal statusbar
<Lathiat> dunno if that was ever done upstream
<Lathiat> the gnome obex stuff works but
<Lathiat> as does gnome phone manager
<mjg59> Ah, gnome phone manager?
<Lathiat> yeh
<Lathiat> lets you send/receive sms' via bluetooth
<Lathiat> through a mobile
<dholbach> gnome-obex-server & gnome-obex-send work fine
<dholbach> both directions
<Lathiat> they do
<mjg59> Ok, cool
<mjg59> g-p-m is just an SMS manager?
<mjg59> gnome-bluetooth and gnome-phone-manager all seem to be missing menu icons
<Lathiat> restart your session see if they work
<Lathiat> i have a bug where menu icons dont show up until my session is restarted
<mjg59> I've had gnome-bluetooth installed for a while
<Lathiat> oh
<Lathiat> in that case yeh i seem to recall they didnt anyway
<Lathiat> prolly just broken .desktop files as they do have icons on the app
<Lathiat> also im not sure 'System Tools' is the right place to have them
<mjg59> Yeah
<Lathiat> accessories perhaps?
<jbailey> moin, pitti!
<jbailey> ( et al...)
<pitti> jbailey: I'm currently diving into the RT source code
<dholbach> hey jbailey 
<jbailey> pitti: Yay, thanks!
<Lathiat> pitti: request tracker?
<pitti> Lathiat: yes
<Lathiat> sounds like pain :)
<pitti> it _is_ :-)
<Lathiat> now why am i not surprised :( heh
<Mithrandir> pitti: RT is good for you.
<pitti> Lathiat: 200.000 lines of code seems to be quite much for a distributed TODO list...
<mjg59> Ok, cool, gnome-obex-send works nicely
<Lathiat> archer:/usr/share/applications> cat gnome-obex-server.desktop|grep Icon
<Lathiat> Icon=../gnome-bluetooth/pixmaps/blueradio-48.png
<Lathiat> mjg59: :)
* mjg59 has a nice Debian logo now
<Lathiat> the icons arent even installed
<Lathiat> let alone referenced right :)
<jbailey> pitti: 200,000 lines of perl sounds like alot for anything.  I thought you could express all programs at the same time in a hologrpahic manner in about 100... ;)
<mjg59> Grr.
* mjg59 watches his phone claim that it can't find anything to send to
<Lathiat> mjg59: got bluez stuff installed?
<pitti> jbailey: just state the offset into the pi decimal representation :-)
<mjg59> Lathiat: Yeah
<Lathiat> mjg59: like is sdpd running?
<mjg59> It's not finding any of the machines in here
<Lathiat> :(
<mjg59> It did a minute ago
* mjg59 reboots it
<dholbach> mjg59: try setting class 0x100100;
<mjg59> dholbach: No, the phone's even refusing to discover things
<dholbach> hrm ok
<dholbach> mjg59: anything in dmesg?
<mjg59> Rebooting the phone seems to have fixed things
<dholbach> mjg59: what phone is it?
<Lathiat> hmm gnome-bluetooth doesnt tell you what the file is/called
<mjg59> T68
<mjg59> (Not a T68i)
<mjg59> Yeah, works fine now
<dholbach> t68 is ericsson?
<mjg59> Yup
<dholbach> i have one of the new sonyericsson ones... it's a nightmare... rebooting every now and then
<Lathiat> dholbach: what model?
* Lathiat has a sony erricson Z1010, works pretty well
<Lathiat> frozen a couple times in the 4 months i've had it tho
<Lathiat> acutally i thinks its mor elike 9 months now, i dont keep track of time
<dholbach> Lathiat: k700i
<Lathiat> ah those
<Lathiat> they look ok
<mjg59> Woo, working IR
<dholbach> hrm
<Lathiat> prolly what i would have got if i didnt get this
<dholbach> and you have to go to a shop to do a software update
<dholbach> siemens offered downloadable updates ... for windows, but still...
<dholbach> enough ranting :-)
<SlackShrike> hi
<fabbione> elmo: ping?
<elmo> fabbione: ?
<SlackShrike> howto create a live cd of ubuntu ? I am like contribute with the live of ubuntu. where I find the documentation of live-cd ?
<dholbach> SlackShrike: on the wiki
<fabbione> elmo: can you please make sure that all the Build-Dep for l-r-m are installed on concordia/davis/halley hoary chroot and that they are uptodate?
<elmo> btw, new cdimage machine just added - if anyone notices any problems, please shout
<elmo> fabbione: k, doing
<fabbione> elmo: thanks a lot
<SlackShrike> dholbach : The wiki has the documentation of as to customize the live-cd !
<dholbach> SlackShrike: could you please elaborate on what you're exactly trying to do?
<thom> so, i guess consensus is that we shouldn't p4-clockmod on laptops, either
<Kamion> hm, might be a good idea to actually turn CD builds back on
<elmo> p4-clockmod sounds like it shouldn't be compiled
<SlackShrike> dholbach: To study casper and the process of creation of live of ubuntu to be able to help in the hardware detention that is sold in Brazil and the translation and configuration of the system for pt_BR
<dholbach> SlackShrike: i hope someone read what you just wrote and will be able to help you... i have no real clue about the internals
* mjg59 swears at IR
<mjg59> I can't work out whether my inability to get the machines talking is down to something being broken or IR just being cra
<mjg59> p
<SlackShrike> dholbach: thanks
<dholbach> :-)
<thom> elmo: well, that's the other option yes
<mjg59> Oh, gah, it seems to be an Ericcson bug
<mjg59> Why does ALL HARDWARE SUCK?
<Treenaks> mjg59: your ericsson is bug-free compared to my nokia
<Mithrandir> mjg59: apply hammer.
<Mithrandir> hammers don't suck
<jbailey> Mithrandir: No, hammers bite. ;)
<mjg59> Hrngh. I still get nothing.
* mjg59 curses phones
<Mithrandir> mjg59: apply hammer, I say.  It'll solve all your worries.
<dholbach> woohoo, i have memtest86+ now! :-))
<Kamion> jbailey: hammers claw, surely ...
<Mithrandir> dholbach: does it work?
<dholbach> Mithrandir: didn't test yet... does it have update-grub in postinst?
<dholbach> Mithrandir: at least i didnt see the msg
<Mithrandir> dholbach: unsure, I actually haven't rebooted to see
<dholbach> Mithrandir: i'll report later
<Mithrandir> goodie
<jbailey> Any evms guru's around?
<jbailey> I've tried a few times to figure this stuff out to solve the boot bugs that are showing up with raid, and the documentation is just a bit convoluted.
<dholbach> Mithrandir: postinst only has lilo crack
<Mithrandir> dholbach: hm, I'm not going to change that for release.
<dholbach> Mithrandir: hrm... why not? if the user updates/newly-installs a kernel, it will get dragged in anyway
<Kamion> dholbach: is this a kernel package? update-grub is done in a kernel-package hook
<Mithrandir> dholbach: because we're releasing in a week and I'd like not to touch more than needed.
<Kamion> /etc/kernel-img.conf
<mjg59> Oh, woo, that worked
<ogra_> 1140 submissions on hwdb.ubuntu.com, 165 of them are amd64, 24 are ppc
<dholbach> Kamion: ok
<mjg59> Whee! Patches over mobile link.
<mjg59> Uh, packets.
<mjg59> Christ.
<HiddenWolf> ogra: Wait for another one. Pumping over my data atm, then watch me. 
<ogra_> 97 have no working swap !
<ogra_> about 10%
<jbailey> ogra_: Is that page supposed to be for finding supported hardware?
<ogra_> jbailey, naah, thats my interim until we have a real DB.....its currently just grepping through the entry....
<elmo> Mithrandir: did you test our version of memtest86+ on amd64? it's quite old
<Mithrandir> elmo: it's the same version as is in debian, iirc?
<elmo> no, debian has 1.50-1
<elmo> we're on 1.30 or so
<ogra_> jbailey, all these files will go in a SQL db after release, that will be searchable then and show you the percentage of support a device gets (at least thats the plan), but currently i only want something the user can be pointed to to aprove everything was detected right....
<jbailey> ogra_: Cool, thanks.
<elmo> fabbione: done, btw
<fabbione> elmo: thanks.
<Mithrandir> elmo: works on my box at least.
<elmo> Mithrandir: ok, cool
<maswan> Mithrandir: are you sure it actually detects errors above 4 gig? I seem to remember we had some issues like that.
<Mithrandir> maswan: I only have 2G memory in the box.
<maswan> Mithrandir: ah
<Mithrandir> maswan: it probably doesn't, since it runs in 32 bit mode.
<maswan> I wonder. Hmm.. Let me check around a bit.
<elmo> I suspect memtest86+ is underwhelmingly used - it seems to be utterly broken on (super common) poweredge 2650's
<Mithrandir> if you ship me a box with 6G memory, I can test, no problem.
<elmo> Mithrandir: how?  going to poke out some of the pins on the top 2Gb? :P
<Mithrandir> elmo: see whether it detects 6G of memory for a start. :)
<elmo> oh, well, there is that
<maswan> Ok, it was local patches to make it work on opteron
<Mithrandir> I could probably also find some faulty memory, yes.
<elmo> I could try memtest86+ on emperor for fun
<Mithrandir> elmo: please do.
<elmo> Mithrandir: it's not amd64, just x86 PAE with LOTS of memory
<Mithrandir> isn't PAE like dog slow?
<maswan> Ok, it wasn't 4gig+ issues, it was Opteron-internal memory controller problem.
<elmo> Mithrandir: yes - I hate it passionately
<elmo> and the stupid NX protection on newer Xeons requires it
* elmo beats Intel
* HiddenWolf hands elmo a club
<maswan> So, do you guys want patches for Opteron support? :)
<elmo> maswan: they not upstream yet?
<elmo> I suspect it's too late to get them in hoary in any event
<elmo> given the < 7 days thing and all
<Mithrandir> yeah, I'm not comfortable putting them in now; breezy, sure.
<maswan> elmo: well, the guy that did them just muttered about the problem and him having patches, not actully submitted it.
<maswan> so no, it's no big deal to build them either yourself
<elmo> yeah, that's the other thing about memtest86+; you can always grab the latest .deb, no matter what distro you're running
<maswan> yeah
<Mithrandir> as long as your system doesn't die halfway through booting linux. ;)
<elmo> Mithrandir: then you grab the .iso from www.memtest86.org :P
<elmo> or whatever it is
<maswan> the part about "Do a trivial check to make certain we can see a host bridge." assumes that it is pci device id 0, where the opterons have 24, which makes it break in spectacular ways. :)
<HiddenWolf> mithrandir: I like it worse if the system dies on post, really
<Mithrandir> maswan: ah, sounds fun.
<maswan> but yeah, these patches should probalby rather be pushed upstreams
<maswan> I just suck at dealing with most upstreams. :)
<torkel> maswan: I think ake did, but they have not been accepted yet...
<maswan> torkel: ah, ok. not just mubmled about having a problem with a patch? :)
<elmo> maswan: submit them to the debian bts
<maswan> elmo: ah, good plan
* maswan goes off submitting :)
<HiddenWolf> Why is there a debian logo in the synaptic popup to configure a package that asks a question? (for the love of god forgot the name )
<sabdfl> maswan: is that patch in hoary too?
<maswan> sabdfl: The patch isn't anywhere but locally here, I'm going to submit it to the debian bts so other people can see it.
<maswan> (well, parts of the local patch, I don't think we need some of the default config changes propagated :) )
<jani> elmo, please sync sylpheed, fixes two security bugs
<maswan> I just remembered these issues because memtest86+ was mentioned in here. :)
<elmo> jani: done
<jani> thanks
<crimsun> elmo: if you have time, would you please sync xfce4.2.1 from os-works?  The packages are also in experimental if you'd rather sync from there.
<elmo> crimsun: what's os-works?
<crimsun> elmo: Benny's repository (deb-src  http://www.os-works.com/debian/ testing main)
<crimsun> elmo: those packages are also in Debian experimental
<elmo> crimsun: well, which would you prefer?  is one better than the other?
<elmo> oh, they're the same?
<jani> crimsun, I was just about to ask elmo the same :)
<elmo> I'll do experimental then - have a trust path to it
<crimsun> elmo: Benny's is slightly newer
<crimsun> elmo: ok, that works for us!
<crimsun> either way, it means we can clear up xfce 4.2.1 for Hoary :)
<crimsun> elmo: thanks a bunch
<jani> cool
<sabdfl> maswan: cool, as long as it's in hoary :-)
<jani> so exeprimental does not have the 4.2.1.1 fixes ?
<crimsun> jani: no, but they're not terribly intrusive; we can use dpatches
<jani> so we will apply those in time for hoary right ?
<crimsun> yep
<crimsun> as soon as the sources are in, I'll begin updating the diffs
<jani> cool, what about the other lightwaight benny pack which are orthogolnal (libexo, terminal and mousepad)?
<jani> those go well with xfce4 on limited ram machines 
<jani> mousepad is the only X app that starts in <1 sec for me :)
<crimsun> those are only in Benny's os-works repo
<Treenaks> jani: how about xclock? :P
<jani> treenaks, who needs that ;)
<elmo> crimsun: if they're not the same, I can sync from this newer site, if you want?
<jani> elmo, crimsun that would be nicer I think it's the same maintainer and xfce4 core devel
<crimsun> elmo: merging from Benny's would be more helpful for jani and me, but the trust issue is understandable.
<elmo> crimsun: I only brought that up, 'cos I thought you meant they were the same ..
<crimsun> elmo: the core packages are listed here in sorted dependency order: http://sh.nu/~crimsun/list.sources
<crimsun> (source package names)
<jani> that's not a private site though it's a company that makes xfce4 livecd among others, but I can understand if exp is more trusted
<elmo> i.e. all other things being equal, I'd prefer debian over random site.  if they're not, I'll go with whatever has best sw
<elmo> s/sw/software/
<jani> os-works has the best, I think crimsun and I  agree
<crimsun> elmo: well, it's easiest to sync from experimental
<elmo> crimsun: how come?
<crimsun> jani: right
<jani> crimsun , let elmo do the work instead of us ;)
<crimsun> elmo: well, I'm considering the amount of effort it'd require you
<elmo> crimsun: don't worry about that - the syncing program is generic, as long as the site has a Sources, I can sync from it
<elmo> if it doesn't, I still can, it's just a bit more work, but it looks like os-works has a Sources
<crimsun> elmo: ok, then os-works is jani's and my preferred source
<jani> elmo, is that program public, it could be useful for MOTU staff
<zul> hey
<dholbach> hey zul
<elmo> jani: not yet, hopefully will be eventually - not sure it'd be useful useful for MOTU folks tho as it plays various games to get katie to bypass some of her checks, and those games are tied to certain PGP keys etc.
<zul> hey dholbach 
<jani> elmo, I see thanks
<jani> elmo, one other thing I've been meaning to ask, do all syncs end up in hoary-changes? I was notified for the darcs 1.0.2 sync a couple days ago but it did not show up on the list
<elmo> jani: hoary-changes has some overly fascist spam filtering - mithrandir wrote up a better filter for it, which we can hopefully get installed there soon
<elmo> but yes, all syncs go to hoary-changes
<elmo> (in theory)
<jani> I see, thanks
<elmo> crimsun: hum, that's not a list of source packages?
<elmo> e.g. it has xffm4, but source is xffm?
<elmo> OTOH, do you just want me to sync everything in that repo?
<HiddenWolf> elmo: for -changes, why not whitelist instead of filtering?
<elmo> HiddenWolf: way more work than the filter mithrandir has already done
<crimsun> elmo: err, odd, the source package is xffm4 in experimental and xffm in os-works.
<jani> hmm maybe syncing all and we sorting it out later would be easier on elmo
<crimsun> elmo: yes, please sync all
<jani> we can get rid of xfld stuff
<crimsun> yes, per our discussion regarding meta-xfce4
<mjg59> thom: So, do we get a release party next week?
<dholbach> mjg59: i set up wiki.ubuntu.com/ReleaseParty ages ago... but hrm... see for yourself
<zul> hell yes
<mjg59> Oh.
<mjg59> Enabling DMA while in the middle of burning a CD makes bad things happen
<Lathiat> i noticed that
<Lathiat> :(
<Lathiat> unfortuantely
<Lathiat> hdparm init scripts seems to run before ide-cd is loaded
<Lathiat> i shoudl file a bug about that
<zul> dholbach: it needs to be updated you still have it april 6th :)
<smurfix> dholbach: Is that page linked anywhere?
<dholbach> zul: true that
<dholbach> smurfix: dunno
<elmo> crimsun: can't sync startup-notification, it's in main.  doing the rest
<smurfix> dholbach: no wonder nobody subscribed if people do't even know the page exists ;-)
<ogra_> hehe
<dholbach> don't laugh... link it then ;-)
<ogra_> put t in the release announcement ;)
<crimsun> elmo: all right, thanks again
<thom> Lathiat: kindly don't; check that /etc/dev.d/block/hdparm is 755 and then find out why it's not being run
<thom> mjg59: dunno, i'm gonna be on a plane since we rescheduled to friday
<seb128> pitti: here ?
<pitti> yeah
<seb128> any new on the gamin plan ?
<pitti> not yet
<seb128> we need to work with upstream now if we want to get that fixed for hoary
<pitti> jbailey: here?
<seb128> don't count on upstream beeing available to fix that on 1 day
<jbailey> pitti: Yup
<pitti> jbailey: do you know DBIx::SearchBuilder?
<pitti> jbailey: this is what RT uses for DB access
<jbailey> pitti: I don't, but I'm not a Perl guru at all.
<pitti> jbailey: hmm, okay
<jbailey> pitti: I have someone I trust that I can ask for info...
<pitti> jbailey: I try to find out whether anything in RT/DBIx/DBI quotes strings to prevent SQL injection
<mjg59> thom: Teh suck
<elmo> crimsun: hmm, FYI, lots of epochs used in this repo
<thom> mjg59: yah
<crimsun> elmo: indeed.
<zul> q
<zul> doh..
<Lathiat> thom: oh, hrm....
<pitti> seb128: I pinged him
<seb128> thanks
* Kamion decides to create a post-base-installer hook
<Kamion> once you have two uses for something ...
<Lathiat> thom: aha :)
<Lathiat> thom: that must have been added sine it wasnt working a while back
<Lathiat> thom: i wont bother you now :)
<Kamion> I suppose it should have occurred to me earlier that prebaseconfig was no longer necessarily right for various things
<tritium> Lathiat, I've had the same problem with hdparm running before modules are loaded.  How did you fix it?
<Lathiat> tritium: hal now runs it when devices come up
<mjg59> Waa.
<Lathiat> im gonna reboot and see if it works
<Lathiat> its possible ide-cd is loaded after hdparm and before hal
<mjg59> My write died halfway through, and now cdrecord refuses to blank my CD.
<Lathiat> mjg59: eww :(
<mjg59> Cock.
<Treenaks> mjg59: even if you do a complete blank?
<mjg59> Treenaks: Yeah
<abelli> mjg59: the same for me ..
<abelli> i mounted it another time and it worked
<Treenaks> that's just plain wankage
<mjg59> Power calibration area error
<abelli> huh .. this may mean that the burner is gone
<abelli> s/may(might
* mjg59 tries another blank
<tritium> Lathiat, so you re-ordered some init scripts?
<Lathiat> no
* Lathiat reboots
<mjg59> Hmm. It's making unhappy noises with this one, too.
* mjg59 wonders if DMA is just broken on this drive.
<Lathiat> mjg59: :(
<abelli> mjg59: DMA huh ?
<elmo> mjg59: you and hardware are just the bestest of friends
<mjg59> abelli: Problems started when I turned on dma
<abelli> mjg59: ahh right... 
<mjg59> Gah. No.
<mjg59> Maybe it needs a full power cycle.
<mjg59> Either that or I've managed to kill it.
<mjg59> (But it's not mine and it's under warranty, so...)
<abelli> but it's still strange.
<elmo> crimsun: small problem
<abelli> dma shouldnt break anything
<elmo> crimsun: xfce4-theme-brushedchrome is under a nasty non-commercial CC license
<abelli> i mean there's a control circuit that should avoid this kind of things . and block the lens.
<elmo> how important is that package?
<Kamion> abelli: large numbers of bug reports suggest otherwise
<abelli> Kamion: yeah i know.
<Kamion> abelli: I think you're assuming non-broken hardware :)
<abelli> Kamion: yeah ... its a sw problem :)
<mjg59> Ok, power cycling seems to have made it happier
<abelli> :-D
<Kamion> fabbione: think we can switch multiseat to priority: standard?
<fabbione> Kamion: let
<Kamion> fabbione: requirement for that would be that it does nothing unless the hardware you're in front of is multiseat
<fabbione> Kamion: just a sec.. 
<fabbione> re
<fabbione> let me check the code Kamion
<fabbione> i didn't write the udeb at all
<Kamion> that was my impression of how it worked last I checked
<fabbione> Kamion: the postinst looks ok to me and it seems to only ask for multiarse in case it finds 4 gfx
<fabbione> Kamion: i think we can switch it safely
<fabbione> but it would be nice if you can double check
<Kamion> elmo: could you please override multiseat-udeb to Priority: standard?
<fabbione> or otherwise switch it
<fabbione> and i can do a netinsta
<elmo> Kamion: done
<fabbione> and see if it work
<Kamion> thanks
<elmo> crimsun/jani: xfce4-genmon-plugin-1.1 has an incorrect debian/copyright file too
<Kamion> fabbione: yeah, I'll give it a try in a bit; booting with 'multiseat' on uniseat hardware is a good test, it should do nothing
<fabbione> exactly
<Kamion> ask no more questions, I mean
<Kamion> if that works, I'll remove the multiseat boot option
<fabbione> sounds good
<fabbione> guys please: http://lists.ubuntu.com/archives/ubuntu-devel/2005-March/006353.html
<fabbione> and let me know
<pitti> fabbione: yay, nvidia is supposed to work again?
* pitti tests
<HiddenWolf> pitti; is that nv or nvidia
<pitti> HiddenWolf: binary nvidia drivers (l-r-m)
<HiddenWolf> pitti; pity, I installed hoary today and was forced to go to nvidia because nv wouldn't work
<pitti> HiddenWolf: for me it's the other way round
<HiddenWolf> pitti, is there any difference between a fresh and an upgraded hoary?
<pitti> HiddenWolf: yes, several if you upgraded from Warty
<HiddenWolf> pitti: damn. I was forced to upgrade from warty, indeed. 
<pitti> HiddenWolf: shouldn't affect the graphics drivers, though
<HiddenWolf> (my old rig died when I connected the burner that would burn my hoary-rc iso I had been begging for all day)
<pitti> although, there is a note about it
<pitti> http://www.ubuntulinux.org/wiki/HoaryUpgradeNotes
<pitti> HiddenWolf: ^
<HiddenWolf> pitti, thanks
<elmo> crimsun/jani: and exo too
<tritium> fabbione, I'm currently using your 1.0-7167 nvidia.  So far so good!
* pitti tests new nvidia, brb
<LeeJunFan> hrm, just doing a server install with 3/28/05 dvd snapshot it asked for adding more repositories. When I hit 'YES' it really screwed up the screen with out of place text.
<pitti> fabbione: ROCK!
<pitti> fabbione: your version finally works again for me
<pitti> fabbione: the version currently in Hoary doesn't, it was broken for ages
<Kamion> LeeJunFan: should be fixed since
<Kamion> specifically base-config 2.62ubuntu20, 29 March
<LeeJunFan> Kamion: cool.
<lamont> morning world
<ogra> hey lamont
<lamont> Kamion: thoughts on why my freshly installed G3(color) hangs on loading the kernel?
<schweeb> fabbione: pong
<schweeb> fabbione: sorry, cable modem died right after I pressed "enter" that first time
<pitti> Hi lamont
<pitti> elmo, jbailey: https://www.ubuntulinux.org/wiki/RequestTrackerSecurityReview
<jbailey> pitti: Ooo, nice!  So aside from the lack of taint mode, you'lre generally happy?
* ogra reboots amd64 to test fabbionnes nvidia driver
<pitti> jbailey: it does not verify its input, but since you cannot use metacharacters to modify HTML/SQL queries, I don't really mind
<pitti> jbailey: so at most you can modify some strings in the HTML
<pitti> jbailey: but not insert tags
<lamont> fabbione: but I was hoping to build a 2-seat multiseat... :-(
<pitti> jbailey, elmo: in short: looks good
<tritium> Lathiat, did hdparm enable dma for your cdrom on reboot?
<Mithrandir> Kamion: if you get approval from mdz, the memtest86+ package can be seeded, put in the debootstrap list and so on for amd64 as well
<jbailey> pitti: Great, thanks.  I appreciate it.
<HiddenWolf> Is there any way to enable dma on an nforce 4 chipset?
<tritium> something in recent kernels is giving me this problem: hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
<tritium> followed by: ide: failed opcode was: unknown, and hda: drive not ready for command
<Lathiat> tritium: yep
<Lathiat> works now
<Lathiat> fails when hdparm is started
<Lathiat> but hal runs it
<Lathiat> and works 
<Lathiat> tritium: just you have to set it up in /etc/hdparm.conf
<dholbach> bbl
<ogra> fabbione, ....
<tritium> sorry to whoever replied.  my system froze and I had to reset
<ogra> fabbione, nvidia doesnt work right with my xorg.conf, i get only 1280x768 instead of 1280x800 the same config works fine with nv (amd64 here)
<ogra> i generated the config brandnew new with the last xorg update
<tritium> Who had replied to me about hda: status error ?
<pitti> tritium: nobody so far
<crimsun> elmo: ok.  Multiverse ok?
<tritium> pitti, hmm...I heard the sound I setup for nick highlights, so I alt-tabbed over to xchat when my system locked up.  strange.
<pitti> tritium: <Lathiat> tritium: just you have to set it up in /etc/hdparm.conf
<tritium> thanks, pitti.
<pitti> trulux: this was the last message before you disconnected
<tritium> I appreciate it.
<pitti> did you get it? there were some msgs before this
<tritium> Yes, diamond /msged me the rest.  Thanks.
<tritium> Thanks, Lathiat for the info.  Unfortunately, I have setup my hdparm.conf, to no avail.
<Nafallo> hmm, we upgraded my girlfriends shuttle yesterday and xorg only gives 640x480. xfree gave 1024x768. and that should be no-good for a release? i845GE chipset.
<Nafallo> daniels: hi there. got time to check an Xorg.0.log? ;-)
<daniels> Nafallo: emailing me is better -- it's late, and i'm tired and kinda busy, sorry
<elmo> crimsun: yes, multiverse looks okay
<Nafallo> daniels: oki. *defending myself from angry girlfriend* ;-)
<daniels> heh
<Nafallo> daniels@ubuntu.com, right?
<daniels> yeah
<fabbione> lamont: that's easy.. i will help you to do that :)
<fabbione> ogra: check the xorg logs please
<lamont> fabbione: is post-UDU, btw
<schweeb> fabbione: poke
<fabbione> lamont: better.. so we make a better multiarse package
<fabbione> schweeb: yes.. i figured why xen didn't boot
<schweeb> cool
<schweeb> fabbione: my cable modem died last night, right after I asked that first question, lol
<fabbione> schweeb: but there are other problems.. basically i get it to boot the xen.gz microkernel, but it reboots as soon as it tries to load the xen0 kernel
<fabbione> schweeb: no problem.. it's not urgent
<schweeb> yea
<schweeb> you have the package or whatever you're using to generate the kernels anywhere?
<ogra> fabbione, hmm, funny, the detection seems to have detected a 1280x768, but only nvidia seems to respect this...nv ignores it
<ogra> s/1280x768/1280x768 Display
<Lathiat> ogra: probably has no modeline for it, google?
<Lathiat> i seem to recall seeing a bug about that
<ogra> (WW) (1280x768,Standardbildschirm) mode clock 80.14MHz exceeds DDC maximum 70MH
<schweeb> fabbione: you sure you selected the right CPU type?  I think I had that problem when I selected K7 rather than P4
<ogra> Lathiat, it was solved...
<ogra> Lathiat, (or should have been)
<Lathiat> not for you obviously :)
<fabbione> schweeb: yes. it's on a P4 and i did set MPENTIUM4
<fabbione> schweeb: i did compare the 2 configs 
<schweeb> odd
<fabbione> perhaps it is some other config that makes problems
<fabbione> i will have to dig into it
<ogra> Lathiat, despite the prob with nvidia (which i dont touch normally) it works fine ;)
<schweeb> you're more of a kernel guru than I, I'll let you figure it out ;)
<Lathiat> nv driver looks like ass on my laptop
<Lathiat> gradients in the ubuntu images go all bandy
<fabbione> ogra: yes, the 2 drivers have different opinions on clockmode
<Lathiat> despite claiming its in 24bit
<Lathiat> works fine under nvidia
<Lathiat> its rather annoying
<ogra> fabbione, i'll try to regenerate my xorg.conf then, lets see
<fabbione> ogra: ok thanks
<mdz> Mithrandir: I don't think we want to change debootstrap etc. at this point, but it would be good to have memtest86+ in the archive for amd64. is that done already?
<mdz> fabbione: what link that you gave me yesterday?  I don't remember
<fabbione> mdz: http://kernelplanet.org/ 
<Nafallo> daniels: mailed :-)
<fabbione> mdz: check the entry from the 29th of March about memset
<mdz> fabbione: yes, I did read that
<fabbione> mdz: he is basicaly right and we have the opportunity to fix these bugs
<fabbione> since we are aware of them
<zul> fabbione: already started last night
<zul> i just got back too late from soccer last night 
<ogra> fabbione, funny....there is no option for 1280x800@60 in the monitor list
<fabbione> ogra: rant with daniels about that :)
<ogra> heh
<Mithrandir> mdz: yes, as of per some hours ago
<mdz> fabbione: I don't understand; those memset calls look OK to me
<mdz> Mithrandir: cool
<Mithrandir> mdz: didn't you like, approve it, yesterday? :)
<fabbione> mdz: void *memset(void *s, int c, size_t n);
<pitti> Morning mdz
* ogra restarts with new xorg.conf
<fabbione> mdz: what's the point of a size 0 ?
<fabbione> and with that pattern?
<fabbione> it is morelikely that they want to 0 the mem with size of that struct
<mdz> oh, heh
<fabbione> memset(&bpart, sizeof(struct blkpg_partition), 0); <-
<mdz> I've probably made that mistake myself; it should be the other way :-)
<daniels> Nafallo: thanks
* Robot101 liked when he got memcpy's arguments the wrong way round :)
<fabbione> mdz: yeah.. it took a bit to understand it too :)
<mdz> fabbione: I even looked at the man page
<fabbione> ehehe
<ogra> fabbione, 1024x768 :)
<ogra> fabbione, with the new generated xorg.conf and selected nvidia driver
<fabbione> ogra: weird...
<fabbione> ogra: so let me understand all the details
<fabbione> if you run nv it works ok
<ogra> fabbione, but i have not the slightest idea what to choose in the monitor list :)
<fabbione> if you run nvidia (new release) you only get 1024x767
<fabbione> what about the old nvidia drivers?
<fabbione> ogra: ahhhhhh
* fabbione hits ogra with a cluebat
<mjg59> Any MOTU about?
* fabbione points the finger at ogra
<crimsun> mjg59: a few, yup
<diamond> ogra: i genereally remove any monitor specs from the .conf and let X figure it out.
<mjg59> sl-modem-daemon really shouldn't depend on sl-modem-source - the kernel support will work in a lot of cases
<ogra> no, with the same xorg.conf i get 1280x768 (nvidia) instead of 1280x800 (nv)
<daniels> ogra: which one is right?
<daniels> if nv is right, and nvidia is wrong ... *shrug*
<ogra> daniels, the latter one
<daniels> ok
<daniels> the fact all my machines run pure open source X drivers isn't just good luck ...
<ogra> daniels, i generated a new conf with the update yesterday...which runs very fine (thanks) 
<ogra> (with nv)
<ogra> but i noted that there was no resolution for my display in the list
<daniels> fabbione: my only comment so far is that you haven't put a changelog entry in :P
<fabbione> daniels: right :)
<mdz> jbailey: what happened with #5421?
<daniels> ogra: hm -- if it's not in the list, then xserver-xorg shouldn't tell you about it
<ogra> daniels, 1280x800@60 would be nice to have in the last screen of the configuator (monitor selection that is)
<daniels> ahhh, I see
<ogra> i got it in the device list, but not in the monitor list
<daniels> ogra: yeah, just found the problem then, will fix it in the morning
<mjg59> ogra: Would it be possible to upload an sl-modem build with the sl-modem-source dependency removed from the sl-modem-daemon binary package?
<ogra> great
<zul> heh if we only have slrmodem in l-r-m oh wait there is a patch in bugzilla ;)
<ogra> mjg59, absolutely.... :)
<mjg59> zul: intel-8x0m works in several cases
<mjg59> ogra: Could you do it? :)
<ogra> mjg59, during the evenin :)
<zul> mjg59: i know but its blacklisted in hotplug i think
<crimsun> ogra: / mjg59: I'm on it
<mjg59> zul: Doesn't seem to be
<mjg59> It's been autoloaded here
<ogra> crimsun, thanks :) you just donated to hwdb deveopment *g*
<mjg59> crimsun: Thanks!
<crimsun> ogra: great :)
<daniels> fabbione: ok, I've looked through it and I can't see any of the usual mistakes; it looks pretty clean
<fabbione> daniels: ok thanks
<daniels> actually
<daniels> fabbione: nvidiaminor -> 0ubuntu1
<daniels> come to think of it
<daniels> since it has a new base version
<daniels> which should generate you 1.0.7167-0ubuntu1
<daniels> instead of -0ubuntu24
<fabbione> daniels: ah right, but it's too late for that
<fabbione> some people have it installed already
<jbailey> mdz: I've been looking for help from someone who knows evms.  I haven't been able to get a system working that can make it work.  I'd like to just follow the least prefered suggestion for now and remove evms support for root devices until our installer supports it.
<ogra> btw, could anybody who submitted data online through hwdb-client please check his data on hwdb.ubuntu.com (there is not much shown yet, but i'd like to know if the laptop detection works)
<daniels> fabbione: ah, ok
<fabbione> daniels: it's just cosmetic anyway
<daniels> yeah
<daniels> it shouldn't make much difference
<fabbione> i am more interested in real packaging issues :)
<daniels> heh :)
<daniels> well, it all looks OK to me
<fabbione> jbailey: hey dude..
<jbailey> Heya Fabio.
<fabbione> jbailey: did you ever upload mpeg2dec again?
<fabbione> 8455 looks scary
<jbailey> fabbione: Nope, since Sparc wasn't a release target it didn't seem to make sense to do the upload.
<daniels> fabbione: if you don't have anything else, I think I'm going to hit the bed now
<daniels> fabbione: was travelling for a fair while to get back home, then had to walk a few km back from the station
<fabbione> daniels: good night
<daniels> fabbione: ok, night dude.  thanks very much for all this, beer counter goes up once again :)
<daniels> let me know if you need anything else from me
<jbailey> fabbione: It needs to be fixed properly right after release anyway.  The reason it actually works on ppc now is mostly because the altivec detection fails rather than it actually fixing altivec capabilities.
<fabbione> jbailey: you said that you had to rever to gcc-3.3 anyway for other reasons and special case ppc
<fabbione> ah ok
<fabbione> i guess i will do just a bin NMU for sparc
<fabbione> since it's not a release candidate nobody will care :)
<jbailey> fabbione: If you remove the inline from that cpu_accel function, it should work fine on gcc-3.4, I think.
<fabbione> jbailey: i will just compile with gcc-3.3
<jbailey> fabbione: Or revert to gcc-3.3.  Either way it'll be broken just after hoary releases and we bump up to gcc-4.  Depends how persistant you want the fix to be. =)
<fabbione> jbailey: just for hoary basically
<fabbione> since i have all of main there
<fabbione> i am quite happy as it is
<fabbione> it would really upset me to see sparc missing one package for a stupid reason, when it can be there
<jbailey> fabbione: Well, and it's useful if you want to use totem-gstreamer to play mpegs.
<fabbione> right :)
<pitti> seb128: hate, hate, hate, hate, hate!!!
<pitti> seb128: now I compiled everything, set up gamin for testing, and now I can't reproduce it any more
<pitti> heisenbug...
<mdz> jbailey: you haven't been able to get evms to work, you mean?
<mdz> jbailey: I know evms (as you might imagine), and the guys on #evms are generally helpful
<Nafallo> daniels: I belive my girlfriend just mailed you ;-)
<jbailey> mdz: 'k, I'll check there.
<mdz> infinity: ping
<thom> seb128: you happy for me to resolve 7552?
<pitti> seb128: hmm, logged out/in, now I see it again *phew*
<mvo> quick poll: what do you think about http://people.ubuntu.com/~mvo/update-icon.png for update-notifier?
<thom> mvo: i like that
<elmo> is it blurry? :P
<Mitario> mvo, it's cool :)
<lamont> mdz: why are there binary packages in pool/main that have no source?
<Mitario> hi everyone
<mvo> elmo: phhh :p
* lamont points the angermuppet at pool/main/p/php4-universe
<mvo> thom, Mitario: thanks, will be part of the next upload then
<trukulo> hi ppl
<Mitario> nice!
<seb128> pitti: k
<Mitario> hi Treenaks 
<ogra> mvo, does that work for the red/green blind ?
<Mitario> eh trukulo 
<trukulo> daniels, i want wo ask you something. are you there?
<trukulo> hi Mitario :)
<seb128> pitti: running the CVS ? for the session I don't know, gam_server is not in the session but started when needed
<trukulo> ogra, have you seen amaranth?
<ogra> trukulo, nope
<pitti> seb128: it doesn't matter, I can start a second server with another id
<mvo> ogra: should be ok (I'm partly color-blind and can make out the difference)
<ogra> ok
<seb128> pitti: right, that's on the website :)
<seb128> thom: I've closed it, thanks :)
<pitti> seb128: I can't find any errors with test_gam, but I see the bug with the desktop icons. weird
<thom> seb128: rocking
<ogra> mvo, that was my only concern, otherwise its awesome :)
<seb128> now we have to fix this gamin issue
<seb128> if we do I'm happy with the desktop for hoary :)
<mdz> fabbione: new driver works OK on amd64 here
<fabbione> mdz:  thanks
<fabbione> mdz: enjoy your first non-free experience and run glxgears!
<fabbione> :P
<pitti> tuxracer
<pitti> seb128: can you please try something?
<pitti> seb128: while true; do touch Desktop/baz; sleep 1; rm Desktop/baz; sleep 1; done
<mdz> fabbione: I did
<fabbione> eheheh
<mdz> if there is something better I can run to stress it, tell me
<fabbione> mdz: tuxracer
<fabbione> q3a
* ogra GRRRs at sid crossgraded systems and the debian hal.....
<pitti> seb128: or, rather: while true; do echo Hello > Desktop/baz;  sleep 1; rm Desktop/baz; sleep 1; done
<trukulo> enemy territory
<ogra> so many erroneous hwdb reports....
<pitti> seb128: for some reason the touch worked ad infinitum, but with echo it stopped after a few iterations
<trukulo> more nonfree stuff for your experience :)
<seb128> pitti: touch works fine
<seb128> pitti: echo boooog
<pitti> HEY!
<pitti> seb128: probably if the file size is prime, or so
<mdz> I can't see which menu choice is highlighted in tuxracer; is that normal?
<mdz> I have to navigate blind
<trukulo> mdz, umm, think it's not normal, menus are suposed to select choose, not to randomly choose
<trukulo> when i played tux on the past (not now with ati igp) i can view menus, with nvidia binary drivers on debian
<mjg59> Kamion: About?
<mjg59> Anyone know how I generate a Packages file that includes all the correct Task information?
<elmo> use apt-ftparchive and 'ExtraOverride' in a conf file
<elmo> look at katie (av. on cvs.d.o or in 'dak' package in sid) for an example
<mjg59> Ah
<mjg59> Is the Ubtuntu taskfile handily available?
<Kamion> mjg59: yep?
<mjg59> Kamion: ^
<Kamion> mjg59: /indices/ in the archive
<mjg59> Kamion: Ta!
<mjg59> So I just feed those to apt-ftparchive and point it at my pool?
<elmo> pretty much
<elmo> you need to be using the apt.conf style invocation of apt-ftparchive
<elmo> not old-skool dpkg-scanpackages imitation mode
<crimsun> mjg59: uploaded
<mjg59> crimsun: You rock
<mjg59> Making custom ISOs is a bit of a pain
<sabdfl> mvo: i like it, but the exclamation mark might look better in yellow
<_mvo_> sabdfl: yellow is a interessting idea, I'll try it out
<ogra> crimsun, thanks! :)
<lamont> mjg59: yes, it is.
<trukulo> one question, in booting speed, it's the same install freshly than upgrade from warty? because it seems to me that booting is slower now than before (in warty)
<seb128> pitti: this gamin issue will be funny to debug :/
<koke> mako: ping?
<pitti> seb128: we currently discuss it in #g-hackers
<pitti> seb128: it doesn't seem a gamin-only bug after all
<seb128> I know, I'm here :)
<seb128> that's why I say it'll be funny to track :/
<dholbach> re
<ogra> hiya
<pitti> seb128: in any case I can't reproduce it with test_gam as client
<dholbach> Mithrandir: memtest86+ on amd64 works fine
<mako> koke: hey dude
<koke> do you know which is my key status atm?
<koke> IIRC, elmo was waiting for you
<Mithrandir> dholbach: yeah, 'cept on opteron, maswan says
<dholbach> Mithrandir: that i couldnt test
<mako> koke: i uploaded the approved file yesterday
<maswan> With 1.5TB ram in an opteron cluster, you kind of end up needing a working memtest86+ :)
<koke> mako: ok, thanks, so next step is for elmo or I can already upload?
<bronson> I just upgraded Hoary and now all my moz-based browsers crash when visiting http://anandtech.com .  Konq works fine.  Not looking for tech support -- just letting you guys know.
<bronson> It appears ad-related...?
<seb128> works fine here
<mako> koke: i emailed telling him i updated the file.. so he should handle it
<bronson> seb128: are you using an ad blocker?
<bronson> x386?
<mjg59> Hm.
* mjg59 generates Packages files and discovers that the one for each section contains the packages from every other section
<mjg59> Oops
<seb128> bronson: no
<mjg59> And the Task headers are missing, too.
* mjg59 wonders if he's messed up the indices
<trukulo> bronson, seem to work well here (x86 and firefox)
<bronson> WEIRD
<trukulo> bronson, hoary last updated
<bronson> Last night.
<jani> fabbione GeForce2 MX works fine with the new driver
<trukulo> bronson, same here
<trukulo> Amaranth, how about bugs on gnome-editor?
<Amaranth> trukulo: ?
<fabbione> jani: awesome! thanks
<trukulo> Amaranth, kde and translation related (yesterday)
<Amaranth> trukulo: oh, i haven't gotten to them yet
<Amaranth> trukulo: been working on PyMusique
<trukulo> Amaranth, ok, keep on pymusique ;)
<mjg59> Kamion: Oh, hrm. Do I need a filelist?
<lamont> install -m0755 post-base-installer debian/localechooser/usr/lib/post-base-installer.d/05localechooser
<lamont> install: cannot create regular file `debian/localechooser/usr/lib/post-base-installer.d/05localechooser': No such file or directory
<Kamion> the CD uses a filelist
<Kamion> dunno what katie does
<Kamion> lamont: bugger
<lamont> ah, was Kamion.  just looking that up
<lamont> missing dirs entry?
<Kamion> yeah, will fix
<Amaranth> ugh, i hate it when people write nasty code with no documentation
* Amaranth runs rm -rf renderer/ and starts from scratch
<mjg59> Kamion: Is the filelist on the CD?
<fabbione> ok new l-r-m uploaded
<fabbione> fasten your seatbelts
* lamont contemplates proposing bind 9.2.5 for hoary, decides it's not worth asking...
<T-Bone> heh
<lamont> but I want 9.3.1 in breezy
<Kamion> mjg59: no, but it's just the output of 'find' over the pool
<Kamion> (sorted)
* Kamion eyes localechooser-data and wonders how on earth it made it past elmo's NEW checks
<elmo> eh, in ubuntu or debian?
<Kamion> Ubuntu
<elmo> was it NEW or part of a sync?
<Kamion> NEW
<Kamion> it's, er, kinda lacking a few things ...
<lamont> hrm... actually....
<elmo> Kamion: eh, you added it
<Kamion> elmo: yes, I know, that's why I'm eyeing it ;)
<elmo> udebs by you are basically whitelisted in ubuntu NEW, TBH
<elmo> as I assume if _you_ don't know what you're doing, we might as well all go home :p
<Kamion> it's a .deb actually
<elmo> oh
<Kamion> and it's fixed now :)
<elmo> boggle
<elmo> ok, yeah, I was crap too for not noticing that - I think I thought it was a udeb
<Kamion> are missing changelog/copyright not covered by an auto-reject then? I suppose they run into all the fun with /usr/share/doc symlinks to other binaries in the same source package that you depend on
<elmo> yah
<mjg59> Kamion: Sorry, a list of files from which standpoint? The top of the archive?
<mjg59> Or the top of the pool?
<HiddenWolf> Hm. powernowd is *very* agressive
<Kamion> mjg59: it's "find pool/main | sort"
<mjg59> Kamion: Rock, thanks
<fabbione> mdz: if there is nothing urgent left for today i would be off until tomorrow.
<mdz> fabbione: ok
<fabbione> mdz: i have my mobile phone with me in case
<fabbione> it's turned on
<fabbione> if i don't answer, either SMS or leave a message
<elmo> (till he gets out the door ;)
<fabbione> elmo: nah.. i am not going out this evening
<fabbione> my wife is out.. me party at home!
<Kamion> mjg59: if you want what cdimage does, get colin.watson@canonical.com--2005/cdimage--mainline--0 from http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005, baz build-config configs/devel, and look in debian-cd/tools/scanpackages
* fabbione grins
<fabbione> rocking.. only one package missing in main for sparc
<fabbione> elmo: do you think you can manage to move sparc.u.c?
<fabbione> elmo: never mind.. i promised not to bitch.. sorry 
<elmo> fabbione: yah, sorry - just need to concentrate on stuff I need to do while still at DC ATM
<fabbione> elmo: yes.. sorry...
<fabbione> don't worry...
<fabbione> i can still live with the cache :)
* fabbione -> food
<mdz> Kamion: can you update the germinate-output for hoary?
<T-Bone> fabbione: you're way behind. We're left with less than 1900 packages to build on hppa (main/restricted/universe) =}
<T-Bone> about 30% uncompiled
<fabbione> T-Bone: you have a cluster.. i have one machine.. oh btw.. does the installer work on hppa?
<fabbione> because on sparc does
<T-Bone> lol
<Amaranth> is ubuntu going to have something like debian unstable?
<T-Bone> damn you :)
<T-Bone> fabbione: installer is on the todo list :)
<Amaranth> people in #ubuntu are saying breezy is the name of the next release and that grumpy is the name of what will be like unstable
<elmo> Next week on PORTS WARS!
<T-Bone> elmo: hehehe ;)
<elmo> fabbione and t-bone are shipped off to a desert island.  they're given nothing but spare m68k parts.  to survive they must collaborate to build a radio and call for help.
<T-Bone> elmo: rotfl ;o))
<fabbione> elmo: ahahahahahah
<fabbione> elmo: be careful :) i still have a bunch of m68k's around..
* T-Bone too ;)
<fabbione> you don't want m68k.ubuntu.com, do you?
<fabbione> :)
<Amaranth> heh, that'd be funny
<Amaranth> debian is talking about dropping archs while ubuntu starts adding more :P
<fabbione> ok time to cook dinner :)
* T-Bone signs another hundred of hppa .changes
* T-Bone contemplates setting up a duplicate chroot to use two buildds on the same machine, wonders if that's easy to do
<Kamion> Amaranth: not quite
<Kamion> Amaranth: breezy is the name of the next release, grumpy (if ever implemented) will be something like builds from upstream CVS
<Amaranth> wouldn't that be a lot more work for little gain? :)
<elmo> no
<elmo> building from upstream CVS has a lot of benefits
<HiddenWolf> Kamion: Breezy .... what is it? :)
<Kamion> HiddenWolf: huh?
<elmo> HiddenWolf: badger
<HiddenWolf> elmo, thanks
<Kamion> ah, I thought you were asking for the meaning of breezy or something
<mjg59> Kamion: Do I need to do something special about language packs?
* mjg59 just got prompted to install one
<Kamion> mjg59: what sort of prompt?
<mjg59> Kamion: The CD does not contain full support for your chosen language
<mjg59> Kamion: Ok, the apt-get that installs most of the system has prompted me due to lack of authentication
<mjg59> Oh, and it wanted the CD back in - do I need to add extra packages to the list of stuff to be copied from the CD?
<mjg59> (I've added a multiverse section, so things may be complicated)
<mjg59> Grah. And now X has blown up, in a slightly unexpected turn of events (it wants resolution prompting)
<mjg59> Which is odd, because I used the same package earlier today without any trouble
<tritium> fabbione, I can't seem to use NVagp with the newer nvidia packages.  I had to switch to agpgart.
<fabbione> tritium: the packages from archive or people?
<Kamion> mjg59: you'll need to make sure that multiverse is in /.disk/base_components, and if you want a package to be copied to the disk, put 'Task: ubuntu-ship' on it
<mjg59> Kamion: Ah, right
<tritium> fabbione, people could use NVagp, but I experienced freezes about once per hour.  Just tried the one in archive.
<Kamion> mjg59: (for a CD, every package should probably have one of ubuntu-{base,desktop,ship})
<fabbione> tritium: yes, that is correct. there is an errata from nvidia in the pkgs in the archive.
<mjg59> Ah, it must have been pulling in dependencies
<tritium> fabbione, okay, thanks.
<mjg59> Kamion: apt-get failed with an error - is that logged?
<fabbione> tritium: http://www.nvnews.net/vbulletin/showthread.php?t=47405 <- this one
<Kamion> mjg59: in the second stage? /var/log/base-config.log
<Kamion> mjg59: the "full support" thing comes up if language-support-$LL isn't on the CD
<mjg59> Setting up python2.4-ldap... dpkg-query: error writing `stdout': Broken pipe
<mjg59> Kamion: Hrm. I copied files off a .iso, then mkisofsed it and stuffed it back on
<fabbione> Kamion: can you please build a cd image with the new l-r-m and multiarse?
<fabbione> Kamion: i need to give it a shot before tomorrow's daily
<mjg59> Ah, I see why stuff broke
<zul> multiarse?
* mjg59 will deal with stuff later on
* mjg59 heads out
<tritium> thanks, fabbione.  I'm looking it over.
<fabbione> zul: dpkg -p multiseat
<zul> Package `multiseat' is not available.
<zul> and yes i did an update
<fabbione> zul: your box is on crack
<fabbione> zul: it's not in warty....
<zul> probably
<zul> not on hoary
<zul> er..warty
<mdz> pitti: gah, I had already run the script and shut down the machine again when I saw you attached a new version
<mdz> pitti: is it needed?
<elmo> do we have the unpacked source of hoary anywhere?
<pitti> mdz: yeah, it checks for the drive status as well
<pitti> mdz: I just send some explanatory text
<mdz> pitti: ok, I'll re-test
<pitti> mdz: sent, even
<Kamion> elmo: rookery:~scott/merge-o-matic/sources/?
<Kamion> hm, doesn't have everything
<kagou> hi
<elmo> I mostly care about main
<elmo> not to worry, plent of space, I'll find somewhere to unpack it to
<Kamion> doesn't have all of main either
<elmo> /dev/sda3             537G  490G   20G  97% /
<elmo> just not there ;)
<Kamion> heh
<zul> hah
<Kamion> what's that?
<mdz> pitti: sent the output to bugzilla; is it safe to shut down the machine?
<mdz> Kamion: jackass
<elmo> kamion: oh, only jackass
<pitti> mdz: I think so, there is not much I can do about this
<pitti> mdz: thanks for testing
<Kamion> elmo: bit concerning ... is that mostly the morgue?
<elmo> kamion: no, it's my BACKUP THE WORLD policy for the DB
<elmo> cron."""daily""" still takes a pre/post snapshot of the DB
<Kamion> hah
<elmo> I think it's responsible for 150Gb or so
<mdz> elmo: rdiff-backup works well for that
<Kamion> sounds like how cdimage used to be
<mdz> I used to store months and months of hourly db snapshots that way
<jani> elmo I did my first uni upload about 20 min ago and got no ack/nack mail, any idea?
<elmo> jani: pkg name?
<jani> python-soya-doc
<jani> the file name was soya-doc_0.9-1ubuntu1_source.changes
<Kamion> fabbione: new CD building, ETA an hour or so; I'll be gone well before it arrives
<pitti> mdz: argh, status 0 means that there is no CD in the drive
<pitti> mdz: so you tested without a CD?
<pitti> mdz: (sorry, I got the followup just now)
<fabbione> Kamion: that's fine thanks.
<elmo> From: Ubuntu Installer <katie@jackass.warthogs.hbd.com>
<elmo> To: Jani Monoses <jani@email.ro>
<mdz> pitti: the _first_ time I ran the script I had a CD in the drive
<elmo> Subject: soya-doc_0.9-1ubuntu1_source.changes ACCEPTED
<elmo> Message-Id: <20050331181512.938653B9C029@jackass.warthogs.hbd.com>
<mdz> pitti: I got identical results whether the disc was in or not, so the second time I did not re-test
<pitti> mdz: *sigh* sorry
<jani> hmm did not get it :(
<mdz> this is why I asked if we were finished :-/
* mdz boots again
<jani> what time did it send it?
<elmo> 2005-03-31 19:36:12 1DH4CG-0001fl-Jt mx0.email.ro [193.226.99.16] : Connection refused
<elmo> 2005-03-31 19:36:12 1DH4CG-0001fl-Jt == jani@email.ro R=lookuphost T=remote_smtp defer (111): Connecti
<pitti> mdz: hmm, if the status is 0 even if a CD is inserted, then there is really something broken
<elmo> on refused
<jani> oh, crappy free mail hosting
<mdz> pitti: the old script didn't show the status, only the capabilities
<pitti> yeah
<mdz> pitti: I didn't test the new script with a CD inserted
<jani> I think the addres is why it is not seen on changes the spamfilter does not like my address :)
<jani> ok thanks elmo, at least it means my key and all are ok I can go on uploading
<mdz> pitti: status: 0 with a non-blank DVD+RW inserted
<andred> seb128,  So with the new changed spatial thing in Ubuntu, folders will close automatically when you open a new folder?
<andred> If so, why?
<pitti> mdz: this is weird
<pitti> mdz: the kernel blatantly lies...
<kagou> when i save an archive downloaded with firefox on the desktop, i must to refresh the desktop to see it. Is it normal ?
<mdz> kagou: it is normal, but it is also a bug
<kagou> mdz, it's the gamin's goal to do that no ?!
<mdz> kagou: yes, the bug is most likely in gamin
<mdz> kagou: https://bugzilla.ubuntu.com/show_bug.cgi?id=7078
<kagou> thx mdz
<HiddenWolf> I just burned an iso with nautilus. The cd looks physicly like it's burned for about 200mb, but nautilus says it's a 600mb cd
<mdz> pitti: I am not able to reproduce #7078 with your loop after killall gam_server
<mdz> pitti: how many iterations does it take for you?
<pitti> mdz: sometimes 5, sometimes it fails immediately
<mdz> I have been through about 30
<pitti> mdz: in any case less than a minute
<mdz> and it is still working fine
<mdz> I could reproduce it before, e.g. saving files from firefox
<andred> seb128, With that change, spatial nautilus is absolutely worthless.
<pitti> mdz: I reproduced it on ppc and i386, seb128 had it too
<pitti> mdz: I talked with upstream about this
<pitti> mdz: it's not a bug in gamin itself, but a race condition between nautilus and gamin
<pitti> mdz: nautilus accesses libgamin concurrently and opens several watches on a directory
<pitti> mdz: it seems that this clashes from time to time
<mdz> pitti: can we have nautilus use a mutex and avoid the concurrency?
<kagou> i'm upto date, and all tar.gz downloaded do not appear
<jani> elmo are you making ubuntu.com addresses for members?
<pitti> mdz: it could help to open just _one_ watch per directory
<pitti> seb128: can this be done? ^
<mdz> pitti: I can't reproduce the bug anymore
<pitti> mdz: I couldn't either, then I restarted my session and it "worked" again
<pitti> it really seems to be a race
<pitti> mdz: I told upstream everything I found out, maybe he finds something
<mdz> pitti: ok, I tried on my laptop and reproduced after only 2 iterations
* Kamion goes off for the evening; might check in briefly later
<mdz> Kamion: can you re-germinate before you go?
<mdz> (if you haven't already)
<Kamion> mdz: er, yeah, already did, forgot to say
<Kamion> mdz: germinate is currently set to run every hour though, so it doesn't generally need me
<Kamion> 2 * * * *               update-germinate
* Kamion &
<mdz> pitti: I see so many EAGAIN and EINTR in gam_server; I wonder if it is handling them correctly
<mdz> Kamion: ok, night
<elmo> jani: yes, eventually
<mdz> elmo: OK to run cron.sync to verify that php4 is happy nw?
<mdz> now?
<jani> ok, because it looks like hoary-changes does not get any of my changes
<elmo> mdz: already done
<jani> with my current mail address
<mdz> elmo: yay
<elmo> what's a shell way to say "show me everything after REGEXP in a file" ?  csplit seems a bit heavy handed
<diamond> elmo: i'd probably use awk, but messey
<Treenaks> grep with an incredibly large -A
<Treenaks> ?
<elmo> grep -A $(expr 2 \*\* 99) ?
<Treenaks> you could try..
<elmo> hmm, expr doesn't do ** or ^, lame
<Treenaks> well, 1024*1024*1024*4 should be enough
<Treenaks> MOST of the time
<pitti> dholbach: I saw that you added libxinerama-dev to qiv
<pitti> dholbach: is this required for Debian as well? (I'm the maintainer)
<dholbach> pitti: erm... must be x.org related
<mdz> elmo: sed
<dholbach> pitti: so for the moment... no
<elmo> ah, right
<pitti> dholbach: okay, thanks
<dholbach> pitti: sorry, wanted to notify you about the change but forgot it in the hurry
<pitti> no worries :-)
<dholbach> good :-)
<jbailey> elmo:  tail -n+$(grep -n bar infile | head -n1 | while IFS=: read a b; do echo ${a}; done) infile
<jbailey> elmo: Where bar is the regexp and infile is the file to search in.
<elmo> see, I _knew_ someone would come up with a sick shell solution
<jbailey> Posix shell is my bitch. =)
<mdz> sed -ne '/regexp/,$p' is just a bit more elegant
<diamond> jbailey: hah. nice.
<lamont> jbailey: do you _know_ there are no meta characters in a?
<jbailey> lamont: grep returns the line number, so I think it should be safe.
<lamont> ah, yes
<elmo> and the inevitable critique of the sick shell
<lamont> mdz: he said 'after regexp'...  sed '1,/regexp/d' 
<elmo> all we need now is a shoop pimp and I'll be full on flashbacking to #d-d
<diamond> elmo: -)
<lamont> lol
<lamont> elmo: depending on whether you want the regexp or not, see mdz/my version
<lamont> s/regexp/line with the regexp/
<mdz> pitti: does gamin upstream acknowledge the bug yet?
<pitti> mdz: he acks that this is a problem, not that it is a gamin bug
<pitti> mdz: he said that he needs to evaluate this
<doko> mvo: ping
<mvo> doko: pong
<elmo> god it freaks me out how many people must use the non-free nvidia driver
<ogra> gamers :P
<zenrox> elmo, for me its casue the free one dont work
<jbailey> Keeping my wife happy when she asks why the screensavers suck...
<ross> quake really sucks with the nv driver
<elmo> tho, having this loaner laptop, it has to be said.. wow, xscreensaver so pretty pretty these days
<zenrox> lol
<zenrox> that too
<ogra> jbailey, electricsheep looks way cooler and doesnt need GL
<zenrox> i like the smoke one
<zenrox> hufo's smoke
<zenrox> execlet screen saver
* T-Bone -> dinner
<jbailey> Where's the bit in the installer where I'm supposed to be able to setup a partition as raid?   I thought it was in the same list as where you picked the filesystem for the partition.
<elmo> jbailey: it is
<elmo> it's in the "what to use this partition for" bit
<elmo> IIRC
<jbailey> elmo: Right, I'm in that screen, I see ext3, ext2, reiserfs, jfs, xfs, fat16, fat32, swap, newworld boot, and do not use the partition.
<elmo> what arch?
<jbailey> Mac G5
<elmo> raid's not supported
<elmo> by the partitioner
<elmo> apparently svenl was working on it, but it didn't/hasn't gone in in time for us
<jbailey> Ah, that would explain why I've not been able to find it then.
<jbailey> Thanks.
* mvo goes to sleep now
* lamont delunches
<lamont> xsltproc -o output-html/ ./../aptitude-html.xsl ./aptitude.xml
<lamont> error : Operation in progress
<lamont> ./aptitude.xml:65: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
<lamont> hrm... would that be like something we should fix?
<dredg> elmo: ping
<trulux> tritium: writing on the paper, it's getting long and long and I don't see the... end!
<tritium> trulux, you'll get there :)
<tritium> seb128, jpr just told me there will be a patch in evolution 2.2.2 on Monday to fix vcalendar breakage.  Will that make it into Hoary?
<trulux> tritium: I hope, really, I might cry then, 'cos too much work around it creates strong feelings like: what the hell made my LaTeX package to break the pdf!?
<trulux> "oh my dear, you broke it!"
<trulux> it's preparing me for being married in a far away future
<tritium> heh
<seb128> tritium: if somebody send me the patch or if they roll a tarball yep
<tritium> seb128, I'll try to do that for you then.
<seb128> andred: ?
<seb128> tritium: they will probably roll tarballs for GNOME 2.10.1, don't bother
<tritium> seb128, okay, thanks for telling me.  :)
<seb128> pitti: hum, I can have a look but I don't the nautilus code well, this changes are probably not trivial
<pitti> seb128: that's what I was afraid to hear :-/
<pitti> seb128: however, I will continue to debug gamin tomorrow
<pitti> seb128: maybe I can find something and there is an easy workaround
<seb128> I can look on it too if you want, let me know
<pitti> seb128: maybe you can look why nautilus opens so many watches onto the same directory?
<seb128> I'll have a look
<andred> seb128, What did you not understand?
<seb128> <andred> seb128, With that change, spatial nautilus is absolutely worthless.
<seb128> you have a gconf key to set if you don't like the changes
<andred> seb128, Yeah, but why go against upstreams in this way?
<seb128> sabdfl decision
<andred> seb128, It breaks the whole spatial metaphor.
<andred> seb128, sabdfl?
<seb128> /whois sabdfl
<andred> Shuttleworth?
<seb128> andred: right
<seb128> andred: I know that has been discussed upstream again and again
<seb128> default is spatial is nice if you do through several directories
<andred> Yeah, but that was mostly browsing vs. spatial.
<seb128> if you does you have a lot of windows
<seb128> and that sucks
<seb128> no
<seb128> they windows still have they properties
<seb128> one by folder
<seb128> size, position, content, etc
<andred> Yeah, but then default to browsing nautilus, not thos half-done spatial.
<seb128> that's well done spatial :)
<dredg> not the browse-vs-spatial argument again :(
<seb128> arguing for hours will not go anywhere
* diamond cringes
<seb128> you don't like the change turn the gconf key
<andred> I like spatial. I don't like broken spatial.
<azeem_> is this about closing the parent windo automatically?
<azeem_> window, even
<maswan> pfft. your release candidates are week. not even twice the "normal" bandwidth used. ;) http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html.en 
<seb128> azeem_: right
<T-Bone> maswan: heh ;] 
<seb128> azeem_: change left/middle click for the folders
<seb128> andred: that's why there is a gconf key
<azeem_> sounds sensible to me
<andred> seb128, I know, but I'm talking about sane defaults.
<seb128> look on the number of user complaining on the list about the default
<andred> I mean, what's the metaphor here? I open a folder and the previous one closes? That sounds like browsing metaphor.
<azeem_> it's a function of your folder depth I guess
<seb128> having ton of windows open
<seb128> correct
<seb128> exactly
<azeem_>  if you only have two or three levels of folders under $HOME, the old behaviour is alright
<azeem_> if you have more, closing the parent makes more sense
<seb128> there is a mail of alex about that in the spatial discussion saying than if users have to go through 5-6 folders to reach what they want then the spatial mode miss the target
<seb128> that's a discussion about how you should organize your files
<seb128> I don't have strong opinion either way
<andred> I wouldn't have minded if they completely switched to browsing instead then, but this compromise seams weird.
<andred> Oh well, lets hope people like that default.
<pitti> seb128: sabdfl doesn't want browsing?
<trulux> oops, hoary-livcd gets frozen in my laptop while loading the kernel image
<seb128> pitti: dunno, ask him :)
<seb128> pitti: browser kind of suck imho
<ogra> yeah
<schweeb> are you guys discussing what I just happened to have noticed? nautilus only keeps one window open now?
<ogra> we dont discuss it ;) 
<ogra> only commenting
<diamond> don't mention the war? -)
<ogra> hwdb submissions: yesterday 527, today 639 , Yay
<andred> ogra, It's surprising that that many people discover that feature.
<ogra> yeah, i've hidden it well ;P
<dholbach> andred: there are LOTS of people
<dholbach> :-)
<andred> So all that data will be collected on a webpage eventually to show what hardware is supported+
<andred> ?
<ogra> and many many more things, yes
<andred> Like what? I'm curious.
<HiddenWolf> ogra; what are those possibilities?
<ogra> it starts with simple statistics like andred menitioned....
<pitti> ogra: nice idea, I'll send you mine, too :-)
<zenrox> + stuff like debs installed
<ogra> but also the xorf.conf and your bootlog data is collected, you can ues this data for a cool helpdesk system, or attach your id for the datasheet to a bug instead of collecting logfiles
<ogra> etc etc....having the data opens a world of options...just think a bit creative about it, there are endless possibilitys
<andred> ogra, Are you the one coding hwdb-client?
<ogra> yup
<torkel> phonenumber, credit card info,... :-)
<ogra> hehe
<pitti> ogra: nice work :-) just sent you my iBook stuff
<ogra> pitti, i see it ;)
<ogra> http://hwdb.ubuntu.com/?xml=3761d0be1cbf20870f4b24841806eef4
<andred> I discovered a bug in it the other day. If you type something into the comment field, then change to "partial" the "Forward" button is greyed out, even though you already have stuff written in the text field.
<pitti> ogra: erm, that's everything? where is the other stuff?
<ogra> andred, yeah, i'm aware of this, havent fond a way around yet....
<andred> ok, good that you nkow it
<seb128> https://bugzilla.ubuntu.com/show_bug.cgi?id=8465
<seb128> a guy like the nautilus change :)
<ogra> pitti, this is a quickly hacked script that greps cpu, mam and laptop recognition data from the file ;) 
<pitti> ogra: okay, so you do have the other info
<ogra> pitti, sure, but i havet got the time to write a big server app before release, so this must be sufficient for now :)
<pitti> ogra: oh, don't worry, I was just concerned that something got lost
<andred> How do you find the ID so you can find your submission like that?
<andred> aha, in ~/.hwdb
<ogra> yeah...the next version will have a button that opens the webpage for you
<ogra> (i had no server when i released the last)
<andred> Exactly what fields can you search for on that webpage? I can't find a single entry when I search:-)
<ogra> andred, only cpu and memory data of your system and a little laptop detection is done....this is plain flatfile work, no database yet...
#ubuntu-devel 2005-04-12
<andred> ogra, But how do you search for that even? "Memory: 512 MB" gives nothing. "512" gives nothing.
<ogra> andred, have you read whats written below the search field ?
<andred> ogra, Yes, but I don't have my ~/.hwdb left
<andred> oh, so you can only search for the id? That doesn't sound like search:-)
<ogra> thats only a better way of directory listing....theDB will be built after the release...
<zenrox> a reasion to go on to the next devel ubuntu
<ogra> the current usecase is to have a datasheet with logfiles attached for your system, so you just can attach the id to a bugrport or fro support to show your data to others...
<ogra> ...later with a big SQL database we can do a lot more with the data
<lamont> Mar 31 15:08:40 localhost imaplogin: /usr/lib/gamin/gam_server: error while loading shared libraries: libglib-2.0.so.0: cannot open shared object file: No such file or directory
<lamont> I hate it when we forget depends...
<T-Bone> schweet
<azeem_> glib should just be essential ;)
* lamont files a b ug
<Jeeves_> Hey guys. Anyone here who reads mirrors@ubuntu.com?
<seb128> lamont: hum ? how do we do that ? the shlibs should handle this one
<lamont> seb128: nfc
<seb128>  /usr/lib/gamin/gam_server ... it doesn't look in this dir ?
<seb128> BTW that's a bug for jdub :p
<lamont> yeah - I saw it was assgined to him
<lamont> Package: gamin
<lamont> Depends: libgamin0 (= 0.0.25-0ubuntu1)
<lamont> is missing
<seb128> yep, I've looked that too
<lamont> 8471
<seb128> I'll fix it know
<seb128> not sure if jdub does packaging stuff these time
<seb128> Depends: libgamin0 (= ${Source-Version})
<seb128> roh, no shlibs
* seb128 kicks jdub 
* dholbach got kicked by seb128 for that reason too :-)
<dholbach> (but i couldnt upload packages at that stage ;-))
* lamont looks at the clock, screams, runs off. back in a few hours.
<dholbach> *wave lamont*
<T-Bone> lamont: could you avg-pkg-build-time k3d on sarti please? I'm getting a bit worried
* T-Bone guesses he missed lamont by a few
<T-Bone> ogra: i've just been playing around with the hwdb client. It says my current video settings are 1280x1024@75Hz while my monitor is currently running @85Hz. Is that "normal"?
<ogra> T-Bone, it reads the marked output from xrandr -q
<T-Bone> ogra: which says "85"
<T-Bone> ogra: should i fill a bug?
<ogra> yep
* T-Bone tries to remember his bugzilla credentials
<T-Bone> this is what happens when you let firefox remembers everything for you :P
<T-Bone> ogra: #8473, with a typo :P
<pitti> hey seb128, why didn't I read " * Fixed all remaining bugs" in your recent gamin upload? :-)
<seb128> I don't want to piss jdub
<seb128> do you want to steal his nice bogs ? :)
<jdub> go for it dude
<pitti> seb128: hmm, #7078 is mine now, I got it reassigned :-/
<jdub> no NMUs in ubuntu
<ogra> T-Bone, thanks :=
<ogra> :)
<T-Bone> ogra: you're welcome :)
* T-Bone is finishing to submit his G5 2.5GHz
<seb128> pitti: lucky you
<seb128> pitti: I think that's because jdub is MIA
<pitti> seb128: I still remember the polypaudio ppc bug
<pitti> seb128: I spent about 5 hours to fix it, then it got dropped from Hoary
<pitti> seb128: I hope that gamin won't have the same fate :-)
<jdub> we're not going to drop gamin from hoary, even with this bug
<seb128> jdub: is that the same for the g-a-i desktop files ? I don't like the political "will do today" you are serving for weeks ;/
<seb128> jdub: I think we should ponder changing it ...
<T-Bone> ogra: http://hwdb.ubuntu.com/?xml=bb81f0ba0c17d09675fec6a3e78b8f17
<ogra> no swap !
<T-Bone> no
<ogra> oh, wanted ?
<T-Bone> actually that box will have about 4GB RAM in the next few days
<T-Bone> and yes that's wanted
<ogra> ah, ok
<T-Bone> Linux isn't the primary OS
<T-Bone> ;}
* T-Bone will register his G4 while at it
<T-Bone> (and no swap there either ;})
<adobbie> T-Bone: primary? so you're running multiple OSes?
<T-Bone> adobbie: sure
<pitti> Night everybody!
<adobbie> what ones?
<dholbach> bye pitti 
<T-Bone> cya pitti 
<T-Bone> adobbie: OSX mainly, Ubuntu in 2nd and Gentoo64 for the fun of it, on that particular machine
* T-Bone is reminded that the G4 has warty on it, which will delay its submission to its upgrade to hoary when released
<adobbie> 4GB is very reasonable these days
<ogra> oh yes, please waith till hoary...i get a lot of broken datasets from people using hwdb-client in debian or warty...
<adobbie> if you can find cheap modules :)
<T-Bone> ogra: hehe :)
<T-Bone> adobbie: actually you'd better not use "too cheap" ones on such a machine
<adobbie> that's true, you'd have to get ECC modules
<adobbie> that jacks the price up
<T-Bone> g5 doesn't need ECC memory
<T-Bone> it just don't like bad chips
<T-Bone> difference is that contrary to most PC BIOS, it will tell you straight ahead whether you tried to feed him with shitty modules
<adobbie> you can stick 4GB of non-ECC into the machine?
<T-Bone> you can stick 8GB of non ECC
<T-Bone> (on that model)
<T-Bone> Xserve eats 8GB with ECC
<adobbie> I've yet to see an Intel/AMD box that'll let you stick that much non-ECC non-registered in it
<adobbie> but it looks like I've got off-topic for the channel :)
<T-Bone> adobbie: this is why Macs are so cool ;] 
* T-Bone ducks
<adobbie> T-Bone: Intel/AMD is generic
<adobbie> it's not cool but for a little money you can get a lot
<T-Bone> i guess that's a synonym for 'crap' ;] 
* T-Bone ducks again
<adobbie> yeah, AMD suckz!
<adobbie> but dual-core has me interested
<adobbie> I hope they make affordable CPUs
<T-Bone> heh
* T-Bone calls it a night anyway, byall
<mdke> ping jdub 
<jdub> mdke: pong
<mdke> quick word?
<jdub> yeah
<jdub> just replied to your email, btw
<mdke> oh no need then
<mdke> send/receive all
<mdke> jdub, thanks for that
<mdke> jdub, it disturbs me slightly turning it on after only 18 users have expressed a view (12/6)
<mdke> what do you think?
<|QuaD-> is there any chance to see an updated mono in hoary?
<jdub> |QuaD-: tseng is looking into it, see ubuntu-devel
<tseng> im working on it right now
<jdub> mdke: personally, i think munging reply-to is a horribly bad idea
<jdub> tseng: woo!
<mdke> jdub, me too
<|QuaD-> tseng: do you have an eta?
<tseng> no?
<|QuaD-> tseng: ok thanks
<mdke> jdub, but i feel under pressure from this "majority vote"
<tseng> when im finsished, ill be sure to not keep it a secret.
<tseng> its not a promise for hoary, we have a few more days left
<|QuaD-> tseng: haha, yeah, i jsut need to make a simple app, and i would prefer to use winforms
<seb128> elmo: loudmouth sync please 
<tseng> cheer on my pbuilder
<|QuaD-> tseng: :)
<dholbach> pals... i'm off to bed - good night
<mdke> bye dholbach 
<mdke> sleep well
<dholbach> bye mdke, thanks, you too :-)
<mdke> jdub, have sent you a /query with my _last_ question (promise)
<Riddell> jdub: did you have any thoughts about moving ubuntu mouse curors out to their own package?
<jdub> Riddell: hrm
<jdub> Riddell: you want to use them in kde?
<Riddell> jdub: thought it would be a nice touch
<jdub> yeah
<jdub> hrmn
<jdub> and you don't install ubuntu-artwork?
<Riddell> Depends: gtk2-engines-clearlooks
<Riddell> brings in gtk
<jdub> oh, i thought you shipped some of that for the admin tools
<jdub> ok
<Riddell> we're trying not to
<jdub> Riddell: hrm
<jdub> Riddell: so it seems a bit whack to do this so late, but i agree that it's desireable
<dts> i'm writing a script and I want to have it load up synaptics and install a certain package in case it doesn't exist, how did you do that with the time and date tool?
<jdub> Riddell: how about shipping the cursor theme with kubuntu-artwork?
<jdub> Riddell: i had to shift it from the industrial theme package to ubuntu-artwork because it was removed upstream
<Riddell> jdub: that's the other possibility, seems inelegant but would work fine short term
<jdub> Riddell: you can easily copy the postinst/prerm from ubuntu-artwork for that
<jdub> Riddell: yeah, sucks a bit, but safer for nwo
<Riddell> ok, I'll try that
<diamond> mdz: hey. submitter of bug 8476 here. sorry if i chose the wrong severity, was just trying to go by what the guidelines said, tho i know it's probably a corner case
<mdz> diamond: if I find out where to configure the descriptions, one day I'll make them better
<diamond> mdz: hehe, k
<mdz> we're using bugzilla in a much different way than most projects
* Robot101 grumbles in seb128's direction
<diamond> mdz: can't just change page.cgi?id=fields.html#bug_severity then?
<diamond> mdz: as a vague niceity, it might be good if the emails had ubuntu somewhere in the subject: so they stand out as such (i.e. i have a fair number of mails from bugzilla from various projects, '[Bug 8476]  etc..' isn't very findable, but i understand if now is not the time ,-)
<mdz> diamond: that one is definitely toward the bottom of the todo list
<diamond> s/isn't/) isn't/
<diamond> mdz: fair enough -)
<tseng> erm, bugzilla does that for every project im involved with afaik
<tseng> I use procmail.
<CarlK> I am trying to test out the nvida drivers and got an error just trying to install the base system - posiblly becase of nvidia-kernel-common
<netdur> hey, firefox shows flash from another tab, here a screenshot http://www.arab7.com/up/file/1112316116365.jpg
<netdur> because bugzilla doesn't like me, someone should report it there
<mdke> netdur, difficult for us to report it, we can't test.
<mdke> netdur, you should report it :)
<infinity> mdz : pong.
<mdz> infinity: fixed it already
<infinity> Oh.  unpong, then.
<infinity> (What was it?)
<mdz> infinity: php4 depends: libapache-mod-php4
<mdz> needed to be libapache2-mod-php4
<infinity> That's correct.  It's an OR dep.
<mdz> it was an OR dep in the wrong order
<infinity> Warty users could have php4 installed, which in warty IS libapache-mod-php4.
<infinity> So, for them upgrading, it should pull in the right package.
<infinity> For new users of main only, it would pull in libapache2.
<infinity> For new users of main+universe, it would pull in the apache1.3 module, but that's the only "wrong" case.
<infinity> It was done in that order specifically for the upgrade case.
<infinity> (I was planning on reversing the order for Sarge+1/Hoary+1, when the php4->libapache-mod-php4 upgrade case was less of an issue)
<infinity> Also, good morning.
<mdz> infinity: it caused germinate to make the wrong choice, and it would also cause new installations to get the wrong packagae if universe were enabled
<infinity> Hrm.  Not sure about the germinate issue, but the latter issue is sort of a tradeoff, I guess.
<infinity> People upgrading from warty to hoary will now have apache2 forcefully installed for them where they had apache1.3+php4 before.
<infinity> (And no, my packages don't make this new, this has been there since 4.3.9..)
<infinity> Perhaps there's some value in the forced apache transition (I certainly prefer supporting apache2), but it doesn't seem terribly friendly.
<thierry_> I get open /dev/[sound/] dsp: Device or resource busy while opennning a game
<thierry_> what could I do?
<Keybuk> can the game be taught to use esd as an output medium?
<thierry_> don't know
<thierry_> this happens with chromium
<thierry_> and some other random games
<Keybuk> otherwise kill esd, and log out/in again once done to get sounds back
<diamond> thierry_: fuser /dev/sound/dsp?
<thierry_> but my sounds work with anything else
<thierry_> t@modemcable075:~ $ fuser /dev/sound/dsp
<thierry_> /dev/sound/dsp: No such file or directory
<thierry_> I think it's because there's just no directory of that name
<elmo> Keybuk: eh, you can just restart esd rather than logging in/out, can't you?
<daniels> i thought esd got started opportunistically
<Keybuk> elmo: doesn't ever seem to work for me
<Keybuk> everything ignores the new esd
<daniels> rhythmbox (through gstreamer) seems to kick it into life if it's not running
<Keybuk> thierry_: /dev/dsp
<thierry_> t@modemcable075:~ $ cd /dev/dsp
<thierry_> bash: cd: /dev/dsp: Not a directory
<Keybuk> (esd probably has /dev/snd/pcm* open as well)
<Keybuk> and opening /dev/snd/pcm* makes /dev/dsp busy too
<thierry_> yeah there's a dsp file in /dev
<thierry_> it's just not a directory
<Keybuk> why did you think it was a directory?
<diamond> thierry_: try 'fuser /dev/dsp' then
<Keybuk> it's not a file either
<thierry_> don't know
<Keybuk> it's a character device
<Keybuk> fuser /dev/dsp /dev/snd/pcm*p
<Keybuk> that'll reveal what has it locked
<Keybuk> (and it'll be esd :p)
<thierry_> wow! with 'fuser /dev/dsp' , sounds work perfectly
<thierry_> now what should I do to make it work everytime?
<Keybuk> fuser -k ?  or just fuser itself?
<thierry_> just fuser
<Keybuk> esd probably just closed the file because it hasn't played a drum-hit in a few minutes
<Keybuk> it has a timeout
<Keybuk> you could wrap the game with "esdctl off; game; esdctl on"
<jdub> oh man
<jdub> http://lists.progeny.com/archive/cl-workers/200501/msg00026.html
<Keybuk> nice idea, WHAT THE FLYING FUCK at the implementation ... :p
<Keybuk> wouldn't adding the user to the plugdev group be the right solution, not chown pmount!
<jdub> Keybuk: can't revoke until recently
<Keybuk> isn't the point that if you log in on the console, there's no need to revoke?
<elmo> OH DEAR GOD
<elmo> that's so freaking STUPID
<jdub> Keybuk: you might keep the file open if you log in via gdm, etc.
<jdub> but given that we can revoke now, i think we should look at some of the consolehelper stuff
<Lathiat> oh man :P
<Keybuk> jdub: yeah, but what's the security issue of that?  you were granted privilege, you could attack then or later, it doesn't really matter
<Keybuk> same applies for the "setgid shell" theory ... sure, you can leave yourself one to use it later, or you could do what you were going to do when you had privelege; there's no difference
<jdub> oddly enough, see the pam_group thread on ubuntu-devel
<dredg> plugdev comes up here: http://lists.progeny.com/archive/cl-workers/200501/msg00000.html
<Keybuk> jdub: btw, kernelplanet.org
<jdub> Keybuk: yeah
<diamond> that pmount thing sounds very like what fedora do for /dev entries
<dredg> diamond: it, hotplug and gnome-volume-manager work very well with my iriver :)
<diamond> dredg: speaking of, um, stuff, you set up apt-proxy yet?
<dredg> diamond: no. feeling lazy
<diamond> dredg: i'd let you use mine, but i reckon that wouldn't help the situation -)
<dredg> diamond: does apt-proxy do ipv6?
<diamond> dredg: good question, i don't know
<dredg> it would appear not
<infinity> mdz : So, the final verdict on the php4 metpackage thing is that we care more about new installations getting apache2 than we do about upgrades requiring manual intervention?
<infinity> mdz : Not that I much care one way or the other.  Just means fielding bug reports or user confusion reports for a while.
<elmo> infinity: eh?
<elmo> Depends: libapache2-mod-php4 (>= 4:4.3.10-10ubuntu3) | libapache-mod-php4 
<elmo> why will that require manual intervention?
<infinity> elmo : In warty, 'php4' is the apache1.3 module.
<Keybuk> jbailey: ping?
<infinity> elmo : The dependency was in the reverse order specifically to DTRT when people with the old "php4" package installed upgrade from woody/warty to sarge/hoary.
<elmo> ok, but if you're upgrading and already have apache1.3 installed, I'm struggling to believe apt/synaptic/whatever is going to rip it out because the order of that or'ed dep
<infinity> elmo : It won't remove apache1.3, but it will install apache2 (they don't conflict), and remove apache1.3's PHP support.
<infinity> elmo : As you'll be replacing "php4" (the apache1.3 module) with "php4 (an empty package) + libapache2-mod-php4 (php4 for apache2)"
<elmo> meh, I don't know why we go to the bother of supporting such odd ball configs such as running apache1 and 2 concurrently
<infinity> To make my life easier when testing them both? ;)
<elmo> infinity: sucks, but it's still TRTD, 'cos we really are running screaming from apache1
<infinity> I'm sure someone could come up with more compelling arguments, but whatever.
<daniels> elmo: the usecase for a while was you wanted to run php4, but you ddin't want a1 for everything
<daniels> also, fd.o ran the main site on a1 and svn on a2 for ages
<infinity> elmo : Fair enough.  I'm more than happy to tell confused users "just upgrade to apache2, this is a not-so-subtle hint".
<daniels> (this one went back to the days when a2 would just fall over when you poked it)
<infinity> Interestingly enough, some crazy libc+php4+apache crashes only happen with apache1.3, not apache2, so I'm more than happy to scrap apache1.3
<infinity> Sure, the real bug is in glibc, but only apache1.3 can tickle it, as far as I've seen.
<dredg> nn all
<infinity> elmo : Well, with any luck, the broken corner case is a small enough use scenario that no one will much care.  I'm happy leaving it as-is, just wanted to hash out the issues (on both sides of the problematic fence)
<fabbione> morning
<Keybuk> bella fabbione!
<fabbione> bella Scott :)
<Keybuk> jbailey: ping?
<jbailey> Keybuk: Just got back
<Keybuk> ah, cool
<Keybuk> have you got a moment?
<Keybuk> I'd like to see if you can explain something for me ...
<jbailey> Keybuk: My wife says I have a moment, and 'Hi Scott' =)
<Keybuk> Hi Angie *waves* :)
<Keybuk> so, why does libc6-dev conflict with itself? :)
<Keybuk> Package: libc6-dev
<Keybuk> Conflicts: ..., libc6-dev (<< 2.0.110-1), ...
<jbailey> *lol*
<jbailey> That's from before my time, but my best guess is that it probably used to be libc-dev or something like that and we were probably overzealous in the renames to libc6 at some point.
<jbailey> Lemme check snapshot, I don't know if it goes back that far.
<jbailey> Not snapshot.  I thought gluck had a copy of old Debian releases, but I don't see it in ftp.root
<Keybuk> it manages to slip through a corner-case in dpkg's dep checking, it never quite manages to find a conflict because it never thinks to look at itself and instead assumes it must be a virtual package (which it's not)
<jbailey> Keybuk: *lol*
<Keybuk> "conflict with myself, must be a virtual package I provide, not in my list so carry on"
<jbailey> There's a few places in glibc's packaging that still need some love.
<Keybuk> otherwise you'd have a very entertaining case where you couldn't upgrade libc6-dev, and had to remove and install it each time
<jbailey> Did it trip something you were working on?  Like is this a Hoary/Sarge concern?
<Keybuk> no, someone asked whether there was any special meaning attached to it
<Keybuk> and I couldn't think of one other than "fuck me blind with a chainsaw"
<zul> hey
<zul> its quiet
<robertj> too quiet ;)
<robertj> do the ooo2 packages come from sid?
<tseng> um so
<tseng> do we need to move to oftc for the week?
<zul> wtf is he going on about?
<tseng> yeah dude.
<tseng> f'ing owned
<fabbione> zul: it's not the 31st of March everywhere in the world...
<zul> whoops
<tseng> zul: its not as good as the gnome planet switch.
<zul> completely forgot about it being the first tomorrow
<robertj> the dot.kde.org switch is pretty clerver as well
<tseng> robertj: planet is backwards too
* robertj can hardly wait for ooo2 base to get into Ubuntu
* lamont chuckles at debian #291952
* lu|away can't wait for ooo1.9 to not mangle his documents:/
<robertj> ooh its in
<robertj> wouldn't run last week
<lu|away> has run for me for a while
<lu|away> just likes to eat files
<robertj> is the jdbc for mysql driver packaged?
<mdz> infinity: that seems like an unavoidable consequence of changing the semantics of the package from being a specific version to a metapackage with an ORed dependency
<robertj> are libhowl-utils bork?
<mdz> infinity: at any rate, we've never supported apache 1.3 in Ubuntu, so yes, it is more important to get it right for apache2 than to support upgrades for 1.3
<infinity> mdz : Yeah, I got that impression.  The point becomes moot about 3 seconds after the CDs are gold anyway, so I'll just stop caring. :)
<mindwarp> After updating to the newest packages for amd64 ia32-libs_0.5ubuntu3_amd64.deb does not install: "error creating symbolic link `./usr/lib32/libGL.so.1`: No such file or directory
<mindwarp> too lazy to file a bug report, there you have it.
<diamond> nite folks.
<mindwarp> as a side note I do have the fglrx drivers installed, but I am guess 30% of the users will also so it probably should install without issue.
<zul> night
<bluefoxicy> " local attacker may potentially leverage this issue to trigger a kernel deadlock and potentially deny service for legitimate users. " up to and including 2.6.11.6
<bluefoxicy> oh, that's from like 13 hours ago, not 1 hour ago, my bad, you all probably know already.
<crimsun> url?
<bluefoxicy> crimsun: bugtraqe
<bluefoxicy> http://www.securityfocus.com/bid/12959?ref=rss
<crimsun> k
<fabbione> bluefoxicy: good morning to you too :)
<bluefoxicy> it's 12:30
<bluefoxicy> fabbione:  I need a small computer, laptop maybe, can you loan me one and get it here in 10 minutes?  :>
<bluefoxicy> I dont want to test my hacks on my desktop box
<bluefoxicy> actually i should have my laptop back in a week
<fabbione> are you on somekind of crack?
<fabbione> it's not like i have billions in my bank account :)
<bluefoxicy> fabbione:  I'm crazy, so close enough.
<thully> hi - I found a pretty bad issue with the Ubuntu RC - when I pressed the wireless button on my laptop, the wireless turns off.  However, pressing it again doesn't turn it back on properly.
<thully> Also - on a more minor note, some things (like laptop_mode and kdm on kubuntu) don't look like the rest of the startup messages
<thully> as in, they don't look like * Starting K Display Manager (kdm) [ok]  (for instance)
<pitti> Morning, folks
<kagou> hi pitti
<pitti> for the German guys around: http://www.heise.de/newsticker/meldung/58125
<infinity> Hey pitti.
<pitti> infinity: bad to loose our Debian account, isn't it?
<infinity> <blink>
<infinity> Did I miss an April fool's joke somewhere?
<pitti> infinity: didn't read  your mail yet? "01.04.05 08:31 Joerg Jaspert     Bits from the DAMs ( & Co)"
<infinity> Ahh. :)
<infinity> Very April Foolish.
<dilinger> pitti: i want my ice cream.
<daniels> pitti: where was that?
<infinity> Sadly, it's too obviously a joke.  What ever happened to subtlety?
<infinity> daniels ; d-d-a.
* daniels kicks pasc; the updates should happen quicker.
<schweeb> people interested in april fool's jokes should be directed to gnome and kde planets :)
* infinity kicks daniels... d-d-a is the only mailing list you're required to be subscribed to as a DD.
<daniels> infinity: i'm on it, but I can't be arsed waiting for offlineimap
<Keybuk> schweeb: Planet Arslinux is good too :p
<schweeb> Keybuk: I was involved in that
<schweeb> :)
<Keybuk> sweet :)
<schweeb> Keybuk: note the schweeb in the "the crew" list ;)
<schweeb> one of our guys isn't a fan of Fleck
<schweeb> and even went to the point of making his own private planet.gnome.org, with everyone but Fleck
<jdub> (twit.)
<Keybuk> fleck rules
<schweeb> his posts are pointless :)
* lu|away emails the fleck
<schweeb> hi luis
<schweeb> lol
<jdub> lu|away: hrm, i think he might get a few emails outta this ;) i mailed earlier
<jdub> a whole stack of mails pointing to a planet he's probably never read ;)
<lu|away> hehe
<schweeb> jdub: you should have seen it earlier, whiprush was trying to set the CoC in place in ars #linux earlier
<schweeb> after I went off on someone :)
<jdub> funny
<pitti> Hey carlos
<carlos> pitti: hi
<dholbach> hey
<pitti> Hi dholbach 
<dholbach> hey pitti
<fabbione> pitti: http://www.securityfocus.com/bid/12959/info/
<fabbione> pitti: please let me know asap if it's a 1st of apr fool or something i need to work on today
* fabbione goes offline for a bit
<pitti> fabbione: I didn't read about this on bugtraq/f-d so far, I have to investigate
<fabbione> pitti: ok
<fabbione> i need to go offline a bit
<pitti> fabbione: but this looks too complicated for a fool
<fabbione> cya later
<pitti> fabbione: sure, see you
<daniels> woah, looks *way* too complicated for april fools'
<bob2`> how often is Contents.gz regenerated?
<dilinger> ugh
<dilinger> that retry goto is ugly
<bob2`> oh, ew
<dilinger> anyways, that looks fixed in 2.6.11
<Keybuk> Linus (rightfully) likes goto
<Lathiat> gotos have their uses
<dilinger> i have nothing against gotos
<dilinger> i don't like that goto in particular
<Lathiat> just they tend to get abused
<dilinger> the function ends up w/ gotos in both directions.  it's fine until someone puts something in there that isn't handled when a retry is done.
<dilinger> and for an absolutely horrid example of goto fun, see do_generic_mapping_read
<dholbach> hey mvo
<mvo> hey dholbach 
<pitti> daniels: hey, got a minute? :-)
<daniels> pitti: i'm sshing into chinstrap now
<fabbione> ah much better
<brainZzZ> ya know, someone to make all of those little projects happen. ;)
<pitti> daniels: how could you know? :-)
<daniels> christ
<dilinger> shit
<dilinger> Registrations have closed - linux.conf.au 2005 is sold out!
<daniels> it sure is
<Lathiat> yeh sucks but such is life
<Lathiat> theres a waiting list for cancellations 
<dholbach> who changed left and middle click in nautilus?
<pitti> seb128
<dholbach> hrm
<dholbach> hm
<dholbach> ok
<pitti> dholbach: he was forced to... :-)
<dholbach> it's just i was used to it now, but what i expected, when spatial nautilus came out
<dholbach> so i have no real objections
<Keybuk> it forces users to retrain their kinaesthetic memory, which is bad
<Keybuk> I can understand it being the default for new users/installs, but upgrades should have kept the old style
<fabbione> MOTU's: #6619 the workaround is also in mdadm init script
<fabbione> it's an easy fix
<brainZzZ> but they also include former representative stephen j. solarz (n.y.), a liberal democrat who with former pentagon official richard perle is circulating a letter in congress and foreign policy circles seeking bipartisan support for a more ambitious policy.
<bob2`> I'm not sure if brainZzZ is a bot or just a really annoying human being
<Treenaks> bob2`: I think he's an implementation of polygen
<daniels> brainZzZ: ?
<brainZzZ> sorta dumb too, since bob2` is a bot and clearly advertises itself as such
* mode/#ubuntu-devel [+o daniels]  by ChanServ
<brainZzZ> lol
<daniels> bot it is
* mode/#ubuntu-devel [+b *!*clan@*.hsd1.wa.comcast.net]  by daniels
* brainZzZ was kicked off #ubuntu-devel by daniels (daniels)
<daniels> (triggers: calling someone else a bot when they see brainZzZ.*bot, /msg'ing me when I said brainZzZ: ?, and messaging me with some nonsensical crap also)
<HrdwrBoB> failed the turing test
<daniels> yeah, but the old adage about half of real irc users failing it applies here
<bob2`> hah
<Keybuk> IRCing While Intoxicated!
<dholbach> fabbione: added it to our todo, thanks
<fabbione> dholbach: no problem.
<dholbach> i have the feeling, we need more MOTUs... quite a lot more
<pitti> dholbach: man fork(2)
<bob2`> no, clone()
<mvo> yeah! clone(dholbach), that would be good :)
<Keybuk> bob2`: depends whether you want them to share resources or not
<Keybuk> could be some locking issues if they both tried to go to the toilet at the same time
<Keybuk> or answered SIGSEX simultaneously
<Keybuk> that can be a bit painful for the raiser
<dholbach> hahahaha :-)
<dholbach> you wouldn't want more of me around... i really can tell :-)
<mvo> haha
<dredg> dholbach: well, it's either more of you or more of everyone else.
<pitti> dholbach: hey, you could not just import the whole apt-get.org mess, but each and every crack .deb that google finds for you! :-)
<HrdwrBoB> better the devil you know
<dholbach> pitti: yeah... i guess i'd even import tucows or something if wine was readier, it's what i'd love to do... oh what delight!
* dholbach reminds pitti of the mud-wrestling action
<pitti> ah, right
* pitti prefers beach volleyball
<dholbach> whatever... you shall suffer if you spread more of those rumours :-)
<cvd> sabdfl here... just doing an update on CVD's machine, and it is spewing error messages
<cvd> lots about
<cvd>  &mdash; 
<cvd>  &mdash; 
<cvd> no...
<cvd> xchat doesn't want me to paste it in
<cvd> lots of xml parsing problems, it seems, in the gnome stuff
<Keybuk> oh, scrollkeeper stuff
<cvd> is that a known problem?
<Keybuk> blame thom, I think
<cvd> also, it's generating a lot of locale data, for every en_XX variant.UTF8 it seems
<dholbach> cvd: that's "normal", i think (locales)
* Keybuk thought that the parsing stuff was all sent to /dev/null these days though
<dholbach> cvd: are there any packages that scrollkeeper / xml-parsing stuff refers to?
<cvd> dholbach: no, it's scrolled past the scrollback limit now
<dholbach> cvd: anything interesting in /var/log/scrollkeeper.log ?
<cvd> dholbach: lots of registrations, no errors
<dholbach> hrm... then it could be something else...
<fabbione> pitti: anything new about that vulnerability?
<cvd> any reason esound-clients is not in main? hard to use esd properly without it
<cvd> now that we are back on esd from polypaudio
<Lathiat> we are?
<Lathiat> ah we are
<Lathiat> polyp got some issues?
<dholbach> cvd: it's just recommended by libesd0
<cvd> Lathiat: seems to be going nowhere upstream
<cvd> mdz: would you consider esound-clients for main?
<dholbach> cvd: sound should work without it i think
<cvd> dholbach: sound does, but it's hard to playa rbitrary sounds without esdplay
<Lathiat> does esd use alsa?
<dholbach> hmmm, ok
<Lathiat> (directly)
<dholbach> one day crimsun will give me a talk about sound/alsa/... and i'll understand it properly too :-)
<cvd> Lathiat: yes
<Lathiat> not doing it here
<Lathiat> and if i start it without /dev/dsp it barfs
<thom> Keybuk: no, certainly don't blame thom
<d3vic3> doko, ping 
<thom> good morning
<d3vic3> moin thom 
<mvo> morning thom 
<pitti> Hi thom
<pitti> fabbione: you have mail :-)
* fabbione hugs thom
<fabbione> pitti: thanks
<doko> d3vic3: pong
<fabbione> YAYAYAYA
<fabbione> wanna-build --list=building |grep -v universe |wc -l
<fabbione> 0
<pitti> on sparc?
<fabbione> sparc is there!
<fabbione> yes
<pitti> congrats!
<fabbione> thanks :)
<dholbach> fabbione: how many build failures?
<fabbione> dholbach: ?
<dholbach> fabbione: broken packages?
<fabbione> if all of main is built, build failures should be 0
<fabbione> but that's not completely true
<dholbach> ah ok.... grep -v
<fabbione> i had to cheat on 3 packages
<pitti> Hi Astharot 
<dholbach> this would have struck me: complete universe built fine
<fabbione> dholbach: no universe is building, it will not finish for hoary and it is deprioritize compared to main, given that there is only ONE sparc buildd
<pitti> hrm, what is the sense of splitting OO.o2 if the core+common are 73 MB, and writer and calc are tiny?
<dholbach> fabbione: yep
<fabbione> dholbach: on the otherside, the installer works fine here
<dholbach> fabbione: *GRATS* :-)
<dholbach> i built openoffice.org-help-fi-0.20021118 from apt-get.org - someone from the OOo crew will have to review it
<dholbach> given it's from 2002
<mvo> morning seb128 
<dholbach> hey seb128 
<seb128> hi
<pitti> doko: OOO2 is uninstallable
<pitti> doko: -debian-files is missing
<pitti> doko: in your repo, at least
<doko> hmm, the one from universe should work
<zyga> mvo: is there something wrong with gnome cvs?
<zyga> mvo: I'm trying to generate a diff but keep hitting a wall here :/
<mvo> zyga: I haven't noticed anything yet, why?
<zyga> freshly checkout worked... hmmm
<mvo> zyga: odd
<Burgundavia> jdub: ping
<pitti> doko: I'm spammed with lots of "This task requires a JRE" dialogs when trying to start Base
* zyga learns that updating po files can hurt badly :/
<haggai> pitti: can you review cdrdao for inclusion into main please?  It does a better job than cdrecord in several cases.  See #7877 for rationale
<pitti> doko: hey, OO.o2 bibliography db doesn't crash on ppc :-)
<pitti> haggai: for hoary?
<haggai> pitti: yes
<pitti> haggai: okay, I'll look at it
<haggai> pitti: thanks
<pitti> doko: and deleting a row in Calc doesn't crash any more either
<pitti> doko: so apart from the fact that it is *painfully* slow and a memory hog (just as OO.o 1), it works fine
* pitti hugs gnumeric
<pitti> haggai: can cdrecord do anything what cdrdao can't? (multi-session, El Torito, burn-proof, whatever...)
<haggai> pitti: quite a lot, but it doesn't do dao as well
<haggai> pitti: that's why we want both to be available.  k3b chooses the best tool for the job
<pitti> haggai: ah, neat
<pitti> haggai: what does "remove k3bsetup2 from the package" mean?
<pitti> haggai: isn't the setup program required any more?
<haggai> pitti: k3bsetup2 is an app that runs as root to 'fix' permission problems -> change cd burner group, permissions and suid cdrecord/cdrdao but we don't need it on a well set up system, like ours :)
<pitti> eek
<pitti> and with udev
<pitti> yeah, stomp it :-)
<haggai> exactly
<pitti> haggai: do you know whether cdrdao uses mlock() even without being setuid?
<pitti> haggai: our kernels allow this
<haggai>     if (geteuid() == 0) {
<haggai>       if (mlockall(MCL_CURRENT|MCL_FUTURE) != 0) {
<haggai>         message(-1, "Cannot lock memory pages: %s", strerror(errno));
<pitti> hmm
<pitti> the first line should just be dropped
<haggai> ok, good to know
<pitti> then cdrdao could get the mlock() benefit even with running as user
<haggai> cool.  I appreciate you thinking of that
<pitti> haggai: of course I didn't test this :-)
<pitti> haggai: but locking the page to prevent swapping seems to be a good thing
<pitti> haggai: our Warty kernel was patched to allow this, and 2.6.10 does it upstream
<haggai> heh :) well it can't be any worse than the default behaviour
<pitti> normal users can lock pages up to their ulimit
<pitti> haggai: the only regression could be that users get this error message if they request too much memory
<pitti> haggai: but this seems to be a cosmetic problem only
<haggai> yup
<pitti> bah, heaps of arch crap in the diff.gz...
<haggai> ouch yeah
<fabbione> pitti: CAN-2005-0867 was already fixed in hoary (-28)
<pitti> fabbione: oh, great
<pitti> haggai: I followed up to #7877
<zyga> mvo: how would you feel about adding joe-user-friendliness to update-manager?
<zyga> mvo: things like 'tell me why this stuff is important' and such
<mvo> zyga: per package? or globally?
<zyga> globally
<zyga> things like a glossary for my mom who never heard of 'package'
<zyga> mvo: I was also thinking of a gconf key that could disable tis
<zyga> this even
<zyga> like "Don't show me newbie stuff'
<pitti> Hi zyga, how's it going?
<zyga> pitti: hi, busy - I'm already late for work :-)
<mvo> zyga: ok for breezy, probably too late for hoary :( (because of the string changes)
* zyga wants OSS job :-)
<ups> does anybody think that in Firefox privacy.popups.disable_from_plugins should default to 2 ?
<zyga> mvo: everything I'm talking about is for breezy
<ups> (it blocks pop ups from plugins that have been exploited recently)
<zyga> mvo: along with app icons and similar changes
<zyga> ups: what about plugin popups?
<zyga> ups: flash seems to be abused lately 
<ups> zyga: like flash or java applets
<ups> yeah
<ups> popups from those 
<zyga> ups: then it should IMHO - I haven't seen one that was usefull 
<ups> it is
<ups> http://weblogs.mozillazine.org/asa/archives/007860.html
<mvo> zyga: oh, ok. then I'm all for it. we may use the introduction from synaptic? have you looked at it?
<zyga> mvo: no is that in the doc files or in the app itself?
<ups> zyga: they have released a extension which does this and also disable any user event initiated popups
<ups> (for testing)
<haggai> pitti: thanks a lot!
<zyga> mvo: the 'short introduction' popup in synaptic?
<mvo> zyga: in the app, the popup
<pitti> haggai: the O_EXCL patch might be too late for hoary, but I think the README.Debian change and the mlockall() are appropriate
<zyga> mvo: the text is okay but it should be more obvious and easy to see (preferably in u-m as it's more user friendly)
<mvo> zyga: ok
<dholbach> pitti: i have some sbin/ binaries in the apt-get.org packages, i'll mark those as "need security review", alright?
* zyga runs for work, bye
<pitti> dholbach: okay, thanks. any setuid ones?
<pitti> dholbach: (although it wouldn't make sense to put setuid bins in sbin/)
<dholbach> pitti: not that i'm aware of
<pitti> dholbach: ok
<dholbach> pitti: i'll prod you again, if i'm through with the list
<dholbach> pitti: thanks :-)
<haggai> pitti: yeah the O_EXCL patch is not trivial since it changes possible error return code paths too
<pitti> haggai: I fixed it in cdrecord long ago and it works fine there; however, this definitively needs some testing, and I also had a bug about it back then
<haggai> pitti: ok
<mjg59> thom: Hm. The backgrounded acpi lock removal probably ought to wait for a second or so before actually deleting the file
<gabaug> the new gdm background on Hoary....um...I was planning on introducing my gf to her newly dual booting Ubuntu system tomorrow, but I can't show her that :)
* mjg59 explodes all over dpkg
<thom> gabaug: tomorrow will be fine. look at the name of the theme in gdm config :P
<mjg59> So, uh, what /is/ today's gdm theme?
<gabaug> thom: ah, I get it w/o looking :)
<thom> mjg59: elmo,mdz,sabdfl doing the ubuntu circle of friends
<Mithrandir> *chuckle*
<Mithrandir> mjg59: gdmflexiserver -n
<thom> mjg59: http://www.planetarytramp.net/background.jpg
<mjg59> I need to provide a different /etc/acpi/lid.sh for the HPs. How can I do this?
<Mithrandir> I'm amazed you got elmo to agree to it.
<Treenaks> thom: aaaagh
<Gagatan> Mithrandir: april prank?
<Mithrandir> Gagatan: no shit
<mjg59> thom: Alternatively, can we have a hack in acpi-support's lid.sh that runs a script if it exists?
<thom> mjg59: that seems easiest. sure
<mjg59> thom: Rock, thanks
* pitti really likes the new gdm background
<pitti> "mdz is watching you" 
<dholbach> hehe :-)
<carlos> pitti: is it in the release candidate? or it's only an update that will disappear tomorrow?
<carlos> :-)
<sabdfl> it's just for this thpecial day
<pitti> carlos: I'm afraid it will be gone tomorrow :-)
<pitti> sabdfl: but it's nice to see you again :-)
<dholbach> it really rocks
<sabdfl> drunk and disorderly?
<pitti> sabdfl: is this in your house?
<sabdfl> nup. restaurant in mataro, last night big dinner
<pitti> ah, I remember
<sabdfl> jdub took the picture, halfway up a ladder
<dholbach> sabdfl: he has green-ish shoes?
<pitti> yeah, I already had too much alcohol, so I didn't remember at first :-)
<mjg59> thom: Any idea when that'll be uploaded? I need to prepare an iso
<thom> mjg59: what script do you need to be run? ;-)
<pitti> dholbach: that's all what is left from his previous greenish iBook
<Lathiat> can michael vogt be foudn on irc?
<thom> Lathiat: mvo
<pitti> Lathiat: mvo
<Lathiat> thanks
<Lathiat> mvo: ping
<mjg59> thom: How about making it vaguely sane - /etc/acpi/local/lid.sh.post?
<thom> mjg59: seems reasonable
<thom> mjg59: run at the end of lid.sh?
<mjg59> thom: If it exists, yeah
* carlos does a backup of the picture... :-P
<thom> righto
<thom> carlos: it's on the intarweb already :P
<mvo> Lathiat: pong
* thom should blog it, really
<carlos> thom: I'm thinking about bloging about it also :-P
<mdke> is the login on the website down again?
<Lathiat> mvo: just curious if you've seen/fied a bug in synaptic where it added a warty repository instead of hoary? (friend added universe today with add and it set warty instead of hoary, but i can't reproduce it here so wondering if it was fixed, can't see a bug report..)
<mvo> Lathiat: haven't seen that problem yet, is your friends machine up-to-date?
<Lathiat> mvo: was a cd install downloaded yesterday
<Lathiat> mvo: like i said i can't reproduce it here, just thought it might have been fixed or something, will have a closer look to see if its reproducible/happens with a dist-upgrade
<mvo> Lathiat: thanks, please let me know if you can reproduce it
<Lathiat> mvo: cus that would be a sucker of a bug :)
<Lathiat> i noticed cus she installed gstreamer0.8-mad and it was crashing muine, because it was old
<Lathiat> s/crashing muine/couldn't install muine, and was crashing rhythmbox/
<mvo> Lathiat: that would really be a sucker
<mdke> please can someone try to login on the website, I can't seem to login and i wonder if its down again.
<pitti> mdke: confirmed, I can't login either
<mdke> hmm
<mdke> elmo, ping
<pitti> elmo: the website login is down
<mdke> pitti, thanks for checking
<sabdfl> elmo: please bounce the authserver, we are updating LP
* mjg59 makes a note *not* to use today's ubuntu-artwork in this iso
* Lathiat grins at mjg59 
<mdke> what's up with it?
<Lathiat> mdke: april fools....
<mdke> on the wallpaper?
<mjg59> Yeah
<mdke> dammit
<Lathiat> a new ubuntu-calendar with that image would have been classy :P)
<Lathiat> being due and all
<mdke> got a screenshot?
<Lathiat> yeah
<dholbach> see you later
<mdke> bye dholbach
<dholbach> bye mdke 
<Lathiat> http://bur.st/~lathiat/Screenshot-Xnest.jpg
<mdke> ty :)
<mdke> lol
<mdke> sexy
<mdke> not sure if I preferred the naked guys or these ones
* fgx reboota con il nuovo kernel
<thom> mjg59: so, a 1 second sleep then rm the acpi lock?
* ogra lols about planet.gnome.org
<mjg59> thom: Yeah, that ought to do
<pitti> thom: BTW, did you ever consider diff -Nru ffox-0.9.3/ ffox-1.0.2/ > ffox-0.9.3/debian/patches/security_all.patch?
<pitti> ;-)
<thom> pitti: *giggle*
<thom> pitti: no, i like having a job ;P
<fabbione> pitti: ahaha
<thom> mjg59: Uploading via ftp acpi-support_0.21_source.changes: done.
* pitti tries not to think about sentences involving the words "gamin", "hatred", "beat", and "jdub"
<dredg> pitti: give in to the dark side
* quinn idly wonders why it was decided that nautilus should do the jumpey-window thing instead of defaulting to browser mode.
<thom> HrdwrBoB: nice hostname :P
<fabbione> ehhe
<srbaker> 'morning everyone
<diamond> guys, i'm looking for the previous version of mdadm (1.9.0-1ubuntu1), it's not on archive.ubuntu.com, is there somewhere else i can get it from? specifically i'm looking for the source
<pitti> diamond: http://morgue.ubuntu.com/
<diamond> pitti: ah hah! thanks
* fabbione goes and crashes for a bit
<kent> Can some one explain why I can hear music with totem etc in Hoary,  but if i try Ubuntu Device Database, then I cant hear any sound. It feels wrong to press the button for no sound, since sound actually works for me in all other programs :(  (Posting it here aswell, since perhaps some one here knows if its a problem with ubuntu device database.  (I have a ac97 btw)
<mdke> website still down
<robertj> kent: maybe gstreamer isn't working?
<robertj> ie. perhaps totem is using totem-xine?
<ogra_> kent, are your system sounds working ?
<robertj> and totem-xine perhaps plugins into alsa or oss instead of gstreamer?
<ogra_> kent, hwdb-client uses gnome_sound_play() for playing sound, so it works if your gnome sounds work too
<kent> robertj, totem is using xine, thats correct. But is muine also using xine? I can play music with muine.  But, as a side-note. Right now, if I select properties on an ogg-file, nautilus hangs. Dont know why :(  Perhaps gstreamer is the cause then?
<robertj> so it may be cutting out a middle man to get closer to the hardware, which might be good for dvd playback but might be harsh for some things where you want the middle man to do mixing and such
<robertj> I think muine is gstreamer only, hrmm
<pitti> seb128, our glorious fighter for "keep the list clean" :-)
<seb128> am I the only one to care ?
<seb128> just curious, sometime I'm wondering if I should reply or just let them use that like a bug list ...
<kent> robertj, I can play with muine. Im doing it right now. I will try to play some system sounds soon. I think I have it disabled right now.
<seb128> kent: the nautilus hang is due to libxine
<Lathiat> gnome_sound_play might use esd?
<ogra> Lathiat, it does ;)
<Lathiat> and something could be broken there i guess
<Lathiat> whereas muine uses gstreamer
<kent> gstreamer-properties is using alsa as output. Should it be using that? It might be that I have changed that some time before, I cant remember :(
<pitti> kent: it should output to esound
<kent> ah, I cant play sound with esd when i try with gstreamer-properties :(    So its esd thats buggy?
<seb128> ps ax | grep esound ?
<pitti> seb128: I appreciate that you care :-)
<Lathiat> seb128: grep esd
<seb128> pitti: thanks :)
<seb128> Lathiat: correct
<ogra> kent, everything in a default ubuntu should use esound, thats why i let hwdb-client test the sound there
<kent> seb128, esd is running:  /usr/bin/esd -n
<seb128> esdplay works ?
<kent> seb128, I dont seem to have esdplay on my system :(
<seb128> it's in esound-common or something like that
* ogra wonders if fabbionne will share the intrusive code with which he managed to conquer planet.debian.org for ubuntu :)
<kent> esound-common is installed and newest package (according to apt)
<seb128> -clients
<adobbie> sucks that esound is still used
<ogra> adobbie, improve polypaudio, so we can use it in the next release ;)
<seb128> you want to make pitti cry ? :)
<kent> seb128, ah,  that package was not installed :( Installing it right now.
* smurfix uploaded a new version of the keyboard decision-tree generating code
<adobbie> why can't gnome and others just use ALSA?
<pitti> seb128: why, I fixed polypaudio, it has to work!! :-P
<seb128> yeah, but we use esound :p
<ogra> adobbie, you dont understand the architecture of linux sound
<pitti> ogra: why, what's so wrong with using alsa and dmix?
<adobbie> ogra: probably not
<pitti> in theory, at least?
<ogra> adobbie, you need a mixing daemon
<pitti> ogra: alsa has dmix
<kent> hmm, I cant hear sound when I play wav's with esdplay :(
<ogra> pitti, that might work in theory :) 
<pitti> yeah, I don't talk about bugs in alsa :)
<pitti> but using alsa directly looks nicer, architecture-wise
<ogra> pitti, but as long as they ar there we cant use a kernel mixer ;)
<diamond> one thing alsa really needs is a simple way to choose a default device
<adobbie> ogra: do you need that for all sound devices?
<pitti> ogra: do you know of any actual blockers in alsa?
<ogra> pitti, not compatible with all soundcards ?
<pitti> HUH?
<pitti> ogra: we already use the alsa drivers
<ogra> pitti, we didnt test it extensively ?
<pitti> ogra: we just don't use dmix
<pitti> ogra: well, I don't speak about changing hoary :-)
<ogra> pitti, did you tra dmix on a PNP ISA soundblaster ?
<pitti> ogra: but for breezy we might very well consider trying alsa
<pitti> ogra: I tried it on a SB 128
<ogra> pitti, yeah....lets try it :)
<adobbie> you don't need any mixing daemons on decent hardware
<pitti> ogra: dmix is a pure software layer, it shouldn't be sound card dependent
<ogra> adobbie, you need some mixing architecture on top of the sounddevice to play more then one sound at the same time
<pitti> ogra: well, if the sound card hardware supports multiple channels, they can be used of course :-)
<adobbie> ogra: ALSA does that in the kernel doesn't it?
<diamond> ogra: well, sblive can handle 32 streams in h/w
<ogra> adobbie, with dmix, yes
<pitti> adobbie: if you configure it to do so, yes
<smurfix> Is anthing special needed to get the new version included in the next -current images?
<adobbie> pitti: I'm pretty sure that the default
<pitti> adobbie: no, it's not
<pitti> adobbie: you need an /etc/asound.conf to configure it
<ogra> diamond, i'm not talking about high end HW ;) (you know, i'm always the guy that shouts ISA on conferences if it comes to HW discussions ;) )
<pitti> adobbie: if it was the default, alsa apps would work without blocking
<adobbie> pitti: I don't have an asound.conf :)
<diamond> ogra: lol, fair enough
<pitti> adobbie: yeah, you have to create it
<ogra> pitti, dmix will require a fair amount of non gstreamer apps to be changed i guess...
<adobbie> pitti: so why can I play many streams at one time with no problems when I haven't configured anything?
<pitti> ogra: I think this would make a good UDU bof
<pitti> adobbie: I can't with alsa (only with esound/polypaudio)
<ogra> pitti, isnt sound mixing a jdub default BOF on every conference ?
<pitti> adobbie: my sound hw only offers one hw channel
<pitti> ogra: lol
<adobbie> pitti: what hardware are you using?
<pitti> ogra: remember, we also have to trash inotify and gamin and start to use sth completely different :-P
<pitti> adobbie: currently a cheap on-board sound chip
<ogra> yeah
<ogra> lol
<adobbie> pitti: do you know if it's the fault of the driver or the hardware?
<dredg> http://planet.gnome.org/
<dredg> hahaha
<pitti> adobbie: no idea
<ogra> dredg, planetkde.org 
<ogra> heheh
<dredg> nice
<pitti> adobbie: you can play multiple streams with alsa without configuration? neat
<ogra> big DNS shuffling today
<pitti> dredg: likewise, planet kde
<adobbie> pitti: I have SB Live Value, it doesn't get much easier than that with Linux
<diamond> adobbie: uh uh. the sblive can mix 32 channels in hardware. alan cox hacked the kernel driver to allow /dev/dsp to be opened multiple times
<pitti> diamond: even with OSS? or just the ALSA driver?
<adobbie> ALSA doesn't have a /dev/dsp unless you run the OSS emulation layer
<pitti> yeah, I know
<diamond> pitti: that was OSS. i'm pretty sure alsa allows the same thing without hacking
<pitti> diamond: yeah, could be
<adobbie> yeah
<pitti> adobbie: so dmix allows to emulate the same thing for sound cards with just one hw channel
<adobbie> cat /dev/urandom >/dev/dsp  as many times as you like noise
<seb128> elmo: loudmouth sync please
* pitti is astonished about the funny package names we have
<seb128> :)
<trulux> woo woo
<adobbie> pitti: it's unfortunate that hardware manufactures make Windows drivers but not Linux drivers
<adobbie> means Linux users end up with drivers that just don't cut it
<pitti> yeah
<pitti> adobbie: well, at least my video card enjoys the nvidia drivers
<pitti> adobbie: it's better than nothing
<adobbie> pitti: yep, that's one thing that's actually easy
<kent> ubuntu hardware database could come with a toggle-button for "Send this spec to the hardware manufactor so that they know we use it, and that we want it to work better in linux"  ?
* ogra thinks Mithrandir will like that one... http://hwdb.ubuntu.com/amd64.html
<ogra> kent, not yet.... 
<ogra> kent, and i think hey will kill me if i do this unconfirmed :)
<ogra> kent, but you get the idea of hwdb ;), at least _we_ know where improvement is needed
<adobbie> voluntary collection of system specs for users during install would be interesting
<adobbie> to get an idea of what hardware is most used by Ubuntu users
<ogra> adobbie, i dont want to force users :)
<pitti> ogra: well, you won't get reports about hw that fails at all, because users won't get to the point when they can execute hwdb
<ogra> adobbie, so its only an option by now
<ogra> pitti, but i get comments and the like....thats what the gui is for...
<torkel> ogra: pitty that we haven't had time to switch to ubuntu yet, that might have added another ~200 machines :-)
<ogra> pitti, it always depends on the state of failure, sure i cant detect a fucked RAID controller if you got / there ;)
<trulux> fabbione: could you make any microbenchmarking with the current linux-image?
<adobbie> hwdb not collect any details?
<trulux> fabbione: It could be fun
<ogra> pitti, but a non working WLAN device, bad sound quality, wrong X,mouse or keyboard detection...
<ogra> adobbie, it runs hwdb-xml -a 
<ogra> adobbie, run that from a commandline....
<trulux> fabbione: I could make some for you, just writing a paper and having too much junk running to make a clean one
<adobbie> ogra: looks like you would know about this stuff :)
<ogra> adobbie, all HAL data, everything i can read from your BIOS chip, meminfo, cpuinfo lsb-release and the comments you give through the test ;)
<mdke> website login still down :(
<mdke> any news?
<ogra> adobbie, oh, andi forgot, your current xorg.conf + log and your bootlog
<kent> ogra, is the ubuntu hardware database ubuntu-specific code, or could it be used on other distributions aswell? it seems like a great tool.
<adobbie> ogra: is that going to work with a 2.4 kernel?
<adobbie> as well as with 2.6
<pitti> adobbie: hal depends on 2.6
* Mithrandir chuckles at Magni as she saw the new gdm login
<adobbie> pitti: yes that's why I'm asking.  will the tool be of much use
<ogra> kent, it depends on ubuntus HAL, and its pretty useless without the hal patches...
<thom> (and hal only runs on a 2.6 kernel)
<ogra> yeah
<ogra> hmm, amd64 has 248 hwdb submissions, ppc only 37....
* diamond adds another one to the amd64 section
<diamond> ogra: nice work on hwdb-client
<ogra> diamond, thanks
<ogra> :)
<diamond> very smooth
<ogra> wait for breezy ;)
<diamond> my sound didn't work till i plugged in my speakers, but i felt it would be a bit harsh to blame ubuntu for that -)
<ogra> heh
<mdke> even ubuntu can't do everything
<lamont> so does someone already know about enigmail being ftbfs?
<adobbie> guess I won't test on my 2.4.30-rc3 vanilla kernel :)
<mdke> is there anyone else who can sort out the website server?
<ogra> adobbie, no, you shouldnt....
<pitti> Morning lamong
<pitti> lamont, even
<ogra> heh
<ogra> adobbie, bwt, why are you running 2.4 ?
<adobbie> ogra: because I don't see a reason to use an unstable development kernel
<ogra> adobbie, but on ubuntu 2.6 is quite essential, you loose a _lot_ of functionallity
<adobbie> depends on what functionality you use :)
<adobbie> my desktop is a Pentium II
* Lathiat wonders if /dev works without udev
<adobbie> there's not a whole lot here
<adobbie> ogra: I'm a picky cli lover
<ogra> heh
<mdke> not the standard ubuntu user ;)
<adobbie> no
<adobbie> only interest in Ubuntu is because Debian just isn't cutting it for me
<adobbie> can't exactly go around suggesting newbies use Debian
<adobbie> but I can do that with Ubuntu :)
<mdke> yep
<pitti> adobbie: my gf still uses woody on her box :-)
<lamont> kids->school
<pitti> adobbie: actually it's not even the final woody release, but was sid at that time
* mdke waves at froud
* froud waves back
<infinity> lamont : Which ftbfs is this?
<froud> Hello all, where is Ubuntu database manager being developed? In which repos?
* mdke points at ogra
<ogra> froud, currently only in the source package 
<ogra> froud, i'll make a baz repo after UDU
<froud> ogra:  Ok docs will be made in docteam svn, is that ok with you?
<zul> hey
<ogra> froud, sure
<froud> ok will post information for checkout in awhile
<Mitario> hi everyone
<froud> ogra: ubuntu update manager is gnome only or also will work on kde?
<froud> ogra: sorry
<froud> ogra: ubuntu database manager is gnome only or also will work on kde?
<ogra> froud, i had to add a .desktop entry to make kde happy (i'm not happy about it) baut it needs gnome_sound_play for example, so there are drawbacks :)
<pitti> ogra: use cat file > /dev/dsp for _real_ portability :-)
<ogra> froud, to be honest, i think the KDE users will need a good bunch of gnome librarys to make it work....i'm not sure if kubuntu installs these
<froud> ogra: kde make me happy. Ok so dependacy required if on kde. Is Kubuntu installing it by default or must kde user do install manually
<mvo> hey Mitario 
<ogra> pitti, i want to test esd and the system sounds ;)
<Mitario> mvo, hi :-)
<mvo> froud: kubuntu does not ship with update-manager by default
<pitti> ogra: just kidding
<ogra> froud, i dont know :)
<Mitario> mvo, why don't we make a qt/kde update-manager ;-)
<dholbach> hey ogra 
* Mitario volunteers, as long as there are kde/qt-python bindings
<ogra> froud, but since they dont want gnome libs in the default install i guess they dont ship it
<froud> mvo: but I understand the update-manager only updates gnome
<ogra> hey dholbach 
<mvo> Mitario: there are binding
<mvo> froud: oh, it will update just everything
<froud> ogra: ok I will document it as gnome only for now, we can extend for kde later
<ogra> froud, but update manager also is a gnome app, that will need the essential libs
<froud> mvo: ok
<ogra> froud, ok... (we'll need a kde dev to do that)
<froud> ogra: as far as I know it needs synaptic and apt
<ogra> froud, and the toolkit ;)
<mvo> Mitario: let's do that for breezy :) I would like to seperate the frontend-backend better
<mvo> froud: correct
<froud> Mitario: good idea
<Mitario> mvo, indeed indeed :-)
<froud> Mitario: any recent updates for docs on update-manager?
<Mitario> mvo, maybe we should create a wiki page where we discuss the features/api and such
<Mitario> froud, hm, i don't think so, the current ubuntu version is the latest i think
<mvo> Mitario: sounds good
<Mitario> mvo, actually what kind of 'backend' things do we have?
<Mitario> mvo, because update-manager is actually already a frontend for python-apt/synaptic
<froud> mvo: I also dont like the GDFL lic in the front page I will be patching a solution shortley
<mvo> froud: ah, good news! thanks
<froud> GFDL
<froud> ok back to work for me c ya
<froud> ogra: since this is gnome for now I will be using gnome doc conventions
<froud> later
<froud> c ya
<abelli> froud: ciao
* froud nods at abelli 
<Mitario> froud, bye, good luck!
<mvo> Mitario: abstracting some common stuff into common python objects that can be used by both frontends is what I have in mind. I think it's good in many ways already, just making it a little more abstract so that the amount of gui code that needs to be written is really minimal
<Mitario> mvo, yes, ok, i agree
<ogra> froud, ok with me
<Mitario> mvo, do we put it on the gnome wiki or ubuntu?
<mvo> Mitario: but adding a new frontend is a good thing(tm). it will make sure that we write good code :)
<mvo> Mitario: a kde frontend discussion on the gnome wiki?
<Mitario> mvo, hmm, well, was actually thinking about client-frontend seperation, but indeed, maybe not such a good idea ;-)
<Mitario> mvo, i have a kde hacker in 2ft of my workstation atm, so i just asked him about the python-kde bindings and if we have a glade alternative (for the ui)
<thully> hi - I've tried the release candidate - and I noticed that if I press the wireless button to turn off my ipw2200 wireless radio, and then press it again to turn it back on, it doesn't come back on properly
<mvo> Mitario: oh, nice. keep me updated :) I have no idea about python-kde beside that it exists
<lamont> infinity: 8493-8495
<Mitario> mvo, sure i will, i'll start the wiki page at w.u.c
<mvo> Mitario: great, thanks :)
<zul> hey pitti
<pitti> hey zul
<zul> how is it going?
<pitti> the n-th relogin today, and gamin is still the suck...
<Mitario> umm, the password reset dialog on the wiki gives me a http auth dialog for "launchpad"
<mdke> yeah website is still boned
<mdke> no one can reset it?
<Mitario> ah
<mdke> in desperation i'm sending a mail to webmaster@ubuntulinux.org
<Lathiat> mdke: whats wrong with the website
<mdke> can't login
<seb128> pitti: no need to relogin, killall nautilus gam_server 
<dholbach> see you later
<infinity> lamont : enigmail should probably be synced with Debian to get proper support for thunderbird 1.0.2 and Moz 1.7.6.
<infinity> lamont : neon, I will fix right now.  It's a simple fix.
<infinity> lamont : gd2, I'll look at tomorrow.
<thom> infinity: see the apache2 bug about removal with busted config not working?
<infinity> thom : No.  Do I want to?
<infinity> thom : #?
<thom> 8374
<fabbione> trulux: and compare the benchmarks to what?
<infinity> thom : Y'know, this has come up before...
<infinity> thom : There was a long thread on debian-devel where people argued that daemons that can't be stopped SHOULD cause the uninstallation to fail, so you know something about it.  Or some such.
<pitti> seb128: yeah, I just tried this
<pitti> seb128: but it doesn't help to make gam_server work again
<infinity> thom : If we've decided that's now bullshit, it's a 2 second fix to add ||true to the prerm.
<mdz> morning
<pitti> seb128: I'm at the point where killall gam_server does not make my icons reappear
<pitti> Hi mdz
<infinity> Mornin' mdz.
<mvo> morning mdke 
<mdke> :)
<ogra> hi mdz
<fabbione> morning mdz
<seb128> hi mdz 
<seb128> pitti: urg
<ogra> fabbione, youre not aggregated on planet.ubuntu yet ?
<infinity> mdz : See above, please.  Should a failing init.d 'stop' action bomb package removal, or not?... I have a feeling your answer will differ from the old debian-devel debate, which I'm cool with, just means a quick apache2 upload for Ubuntu. :)
<fabbione> ogra: i am waiting for elmo to to sync from jdub
<ogra> ah :)
<mvo> mdz: can I ask you about apt/python-apt now? or would you rather postpone it until later?
<seb128> pitti: the breakage is not only for the desktop :/
<infinity> mdz : (Assuming "failed" means "the daemon is still running", not "the script sucks")
<mdz> infinity: I don't remember the debate, but in general, I feel that breaking the upgrade is worse than leaving a daemon running
<mdz> s/upgrade/upgrade or removal/
<mdz> mvo: what about them?
<infinity> mdz : Check.
<infinity> thom : Reassign to me, I'll upload soonish.
<trulux> fabbione: mainline
<mvo> mdz: I would like to upload a new version of python-apt that fixes a refrence count problem in the depcache code and removes a unneeded "Init()" call. 
<fabbione> trulux: kinda pointless. we don't modify all the main subsystems at all
<fabbione> trulux: we have the same "code" if you want to put it that way
<mvo> mdz: and I would like you opionion on #8151 (I put a patch there to work around broken proxies in apt when the release.gpg is fetched)
<infinity> mdz : Oh, another one.  bogofilter has a "Maj" bug against it which is fixed in a newer Debian/upstream bugfix-only-type revision.  Any objections to me uploading said version?  (The one that's been around and tested for a week or so, not the one uploaded a day or two ago)
<froud> mvo: cvs up on update-manager and yelp the help to see if it all works
<trulux> fabbione: OK, I will have a look
<mvo> froud: will do now, thaks
<pitti> seb128: I didn't catch your last msg any more
<pitti> seb128: I know why killall gam_server didn't help any more, the old server was in eternal kernel sleep
<mdz> mvo: python-apt is fairly important; I don't want to change it post-RC unless it's to fix bugs which are critical for the release
<pitti> seb128: so it was unkillable, I had to reboot
<seb128> pitti: k
<mdz> infinity: is that the "doesn't rotate the transaction logs" bug?
<seb128> <seb128> pitti: the breakage is not only for the desktop :/
<pitti> seb128: yeah, for me neither
<seb128> pitti: ie: happens in /random/directory too
<mvo> mdz: the refcount think is pretty importend (and a easy/obvious thing). the init() is not that importend
<trulux> btw, anyone knows how to record a video streaming in mms?
<trulux> http://a953.v59721.c5972.g.vm.akamaistream.net/7/953/5974/3c99fd9f/wms.antena3tv.com:81/buenafuente/videos/buena5_33_56.wmv
<mvo> mdz: can I send you a diff for review? 
<trulux> that's so funny
<pitti> mdz: btw, I analyzed all read() and write() calls, the numerous EAGAIN errors (which are not directly intercepted) are not the reason for the breakage
<pitti> b0rk b0rk b0rk
<mdz> mvo: ok
<infinity> mdz : That'd be the one.  The fixed version doesn't create transaction logs by default. :)
<thom> seb128: is it just me, or is the pango source package a total horror show
<mvo> mdz: thanks
<pitti> seb128: but since it was in eternal sleep, it's a kernel bug after all, so we can just spank fabbione and go home :-)
<mdz> pitti: :-/
<mdz> infinity: what else is different about it?
<infinity> mdz : Two months of minor bugfiz development?... It could take a while to sort the diff.
<infinity> mdz : There haven't been any new bugs opened against it for ages, if that counts for anything.
<fabbione> pitti: uh what kernel bug?
<infinity> mdz : OTOH, no buntu user has complained about the bug, and I doubt it'd hurt to ship with it.  So, whatever seems the best compromise.
<pitti> fabbione: martin    7458  0.3  0.1   2520  1204 ?        T    16:27   0:01 /usr/lib/gamin/gam_server
<pitti> fabbione: mind the 'T'
* thom remembers how loathesome the packaged version of dbs is
<fabbione> pitti: fix gam_server... 
<fabbione> T    Stopped, either by a job control signal or because it is being traced.
<pitti> yeah
<pitti> fabbione: oh sorry, mixed that up with 'D'
<fabbione> D    Uninterruptible sleep (usually IO)
<pitti> fabbione: just tried to blame sb else... :-P
<fabbione> that is due to the fact that your hw sucks at I/O
<pitti> fabbione: yeah, 'D' is what happened to hald from time to time
<abelli> mvo: how do you thing about a synaptic's extension that let's you control (install, view, unistall... ) packages on multiple machines? is this already possible?
<mvo> abelli: only indirect with --set-selections and "Save selections2
<mvo> abelli: you can easily clone package lists
<fabbione> i guess compiling kdebindings is quite memory consuming
<fabbione> or there is a royal memoryleak somewhere
<abelli> mvo: oh right. thank you.
<seb128> thom: like glib/gtk 
* Mithrandir wonders how bad a mod_debian_archive plugin would be.
<thom> seb128: anyway, can i upload the fix for 8259 please? :-)
<Lathiat> thom: woo for firefox bug :)
<seb128> thom: sure
<thom> seb128: k, thanks
<infinity> elmo : Can we get 'neon' synced?.. The only two changes are a fix for an RC FTBFS and a one-line fix for a segfault.
<thom> Lathiat: uploaded; you'll need to restart firefox after you get the new pango
<seb128> thom: thank you :)
<Lathiat> thom: :)
<Lathiat> thom: has anyone filed a bug about italic text moving around when its highlighted?
<Lathiat> (that you know of off-hand)
<thom> Lathiat: i'm pretty sure there was one which i resolved ages ago because no-one could reproduce it anymore
<Lathiat> ah
<Lathiat> i might try dig it up, happens notably on slashdot for me
<thom>  /. is a law unto itself
<thom> there are stacks of rendering problems that only happen on /.
<ups> thom: that happens to me too, on any italic text on other sites as well
<ups> thom: any way i can help?
<froud> ogra: how to start hwdb-clinet from the prompt?
<trulux> mimms: segmentation fault
<thom> ups: become an expert on mozilla rendering and fix it
<ogra> froud, you shouldnt do that...but its possible with hwdb-gui
<thom> ups: i can't reproduce with 1.0.2
<froud> ogra: why shouldn't?
<maswan> thom: I can, right now
<ups> thom: i've got 1.0.2 too
<maswan> thom: mozilla-firefox: 1.0.2-0ubuntu2
<ogra> froud, it starts anothe program after the questionnaire (the sending part is separated...) i had bugreports of people closing the terminal before hwdb-send is run
<froud> ok, good to know
<ogra> froud, in fact i'm considering to disable runningthe gui from a terminal at all for hoary....
<ogra> froud, its worse enough to have a .desktop entry now (the button in dvice manager is better because it ensures the right hal version is installed)
<thom> argh, ok. i see it on one box but not the others
<ups> thom: i don't think i can become a moz rendering expert, but thought you should know that it is still present. doesn't bother me that much
<infinity> thom : BTW, not sure if you noticed above, but as the Mozilla guy, you should be aware that enigmail needs a bump to be happy with tbird 1.0.2 / moz-mail 1.7.6.
<thom> infinity: bleah
<infinity> thom : lamont already filed an FTBFS.  A new version is in Sid.
<thom> infinity: thanks
<thom> mdz: can i sync enigmail - new debian version just adds support for moz 1.7.6 and tbird...
<mdz> thom: yes
<thom> elmo: please sync enigmail from unstable
<mdz> thom: did you investigate / clear up whatever went wrong with the auto-torrenting for RC?
<fabbione> smurfix: ping?
<smurfix> fabbione: 
<thom> mdz: investigating yes, will be testing
<fabbione> smurfix: i have some issues building console-data on sparc (a machine keyboardless)
<infinity> lamont : I can't reproduce your libgd2 build failure on an up-to-date hoary/powerpc.
<fabbione> smurfix: it keeps failing console-data postinst
<fabbione> Looking for keymap to install:
<fabbione> NONE
<fabbione> Usage: install-keymap [ keymap_file | NONE | KERNEL ] 
<fabbione> [BOOM] 
<fabbione> smurfix: do you have any clue of what is wrong?
<fabbione> it started to happen 3/4 uploads ago
<infinity> lamont : Timestamp skews, probably, though.  Want me to add touch magic to debian/rules, or just ignore it?
<smurfix> fabbione: Huh, never saw that, didn't change anything in that corner of the code. You want me to look into it?
<fabbione> smurfix: that would be nice. note that it happens only in non-interactive mode
<fabbione> smurfix: if install it manually with a control terminal, it asks me to answer a question.
<fabbione> smurfix: problably on out buildd is configured properly
<fabbione> smurfix: but that should work nevertheless
<fabbione> smurfix: do you want a copy of the changelog?
<fabbione> meh
<fabbione> build log
<smurfix> fabbione: sure, mail me
<fabbione> on the way
<fabbione> mdz: am I go to upload a new kernel? 2 security fixes
<fabbione> mdz: very clear and non intrusive patches
<mdke> is it possible that an organisation as important and well organised as ubuntu can _still_ not have rebooted the website authentication server
<smurfix> fabbione: That's what they all say ;-)
<fabbione> smurfix: ehehhe
<fabbione> oh talking of which.. 
<fabbione> i need to sign your pic
<fabbione> now i have the time :)
<mdke> smurfix, btw is the german group organising some translations of the docteam docs in time for hoary release?
<fabbione> smurfix: hey that pic looks like you ;)
<smurfix> mdke: The guy you probably want to talk to is siretart
<mdz> thom: judging by the times he was around last night, elmo may not be awake yet, probably best to email your sync request
<mdz> fabbione: ok
<fabbione> mdz: thanks
<mdke> smurfix, not sure who to talk to... I sent an email to ubuntu-de but haven't had a response
<fabbione> smurfix: you almost look like a kid :P
<smurfix> mdke: as I said, /msg siretart
<mdz> lamont: why are you getting all of these test build failures in packages which built before?
<smurfix> fabbione: That pic is somewhat old anyway
<thom> mdz: ah. 'k
<fabbione> smurfix: is it ok if upload to the keyservers?
<smurfix> mdke: The German people use their Forum for a lot of their work and I'm not a Forum lover person
<smurfix> fabbione: sure
<infinity> thom : Want to throw my neon sync request in that same email? :)
<mdke> smurfix, ah i c
<fabbione> i should probably add a pic on my keys too.. so they will look more bloated :)
<infinity> mdz : So, the bogofilter bug; do we care?
<infinity> thom : Also, apache2 fix uploaded.
<smurfix> fabbione: Use your hackergotchi
<fabbione> smurfix: nah.. i think i will just live with 12109280918 uids :)
<thom> infinity: sure
<mdke> smurfix, siretart says he's not on the german team and hasn't done any translation
<fabbione> smurfix: uploaded.. it should propagate pretty fast
<smurfix> mdke: oh well, I'll ping the German forum then
<smurfix> fabbione: true
<mdke> smurfix, thanks
<doko> mdz: regarding an OOo.2 upload for hoary: advantages: builds with gcc-3.4/gij-4.0, so that it can stay in universe, powerpc build done und tested (by pitti and me), disadv: java components don't run, one patch to g++-3.4 still needed, doesn't affect any runtime library.
<mdke> smurfix, it wouldn't do to have french translations but not german ;)
<smurfix> mdke: You have an URL for the translation work?
<mdke> smurfix, http://lists.ubuntu.com/archives/ubuntu-de/2005-March/000783.html
<ogra> probably asking in #ubuntu-de would be sufficient, there are some ofthe forum readers....mdke, i know of no german dev who reads forums like smurfix said....
<mdke> lol
<mdz> doko: so you want to upload oo.o2(universe) and gcc-3.4(main)?
<mdke> ogra, here i come
<infinity> mdz : I can't speak for all of lamont's FTBFS bugs, but the 3 he pointed me to were all real, for some value of 'real'... neon's FTBFS is fixed with the sync I requested, enigmail is FTBFS due to tbird/moz updating, and libgd2 is FTBFS due to timestamp skews on lamont's buildd (I see this a lot on m68k), fixable, but probably not worth worrying about, since a retry will DTRT 99% of the time.
<doko> mdz: yes
<mdz> infinity: sure, they look real enough, but they also succeeded with the same versions a couple of weeks ago
<infinity> mdz : But their build-deps changed from under them, that's the issue for the first two.
<mdz> infinity: neon?
<infinity> mdz : For neon, kdelibs started depending on krb5 stuff that it didn't before, and neon build-conflicts with krb5-dev stuff.  The new version fixes that, by removing the build-conflict and explicitly turning off krb detection in configure.
<mdz> neon build-depends on kdelibs??
<infinity> mdz : It would appear so.  Or it build-deps on something that pulls it in.
<amu> q
<mdz> Build-Depends: debhelper (>= 4.0.0), libxml2-dev, libssl-dev, libz-dev, autotools-dev
<infinity> Oh, wait.
<mdz> I would be surprised (and appalled) if any of those pulled in KDE
<infinity> Maybe it ws in his chroot?... <looks at the report again>
<infinity> The new version is still the better way to do it anyway, but.. Hrm.
<ogra> amu, do you read/write on ubuntusers.de ?
<infinity> mdz : Ahh, yeah.  It was just installed in his buildd chroot.
<infinity> mdz : Feh.
<mdz> grr
<infinity> mdz : Oh well.  The sync request stands, as it has only that fix and a one-line fix for an SSL segfault.
<amu> ogra: sometimes, not regular 
<infinity> I need to learn to read more slowly, or stop taking his bug report titles (COnflicting build-deps) as gospel truth.
<ogra> ahh, mdke was looking for translators.....and we just recognized that there are not many german forum reading devs :)
<ogra> amu ^
<mdke> the ubuntu-de list doesn't get much traffic?
<mdz> infinity: I didn't see a sync request in my mailbox
<mdz> those should be CCed to me
<ogra> mdke, 820 mails since the start (i was the second subscriber so my archive is complete)
<mdz> daniels: ping?
<infinity> mdz : It was in IRC.  I also just asked thom to takc it on the end of his enigmail request.
<mdke> ogra, hmmm
<mdke> ogra, s/traffic/attention
<mdke> i might try another email, to locoteam leaders
<ogra> hmm, probably traffic == attention :)
<theine> the new GDM login screen's pretty neat I must say...
<mdz> infinity: both elmo and I prefer that those requests go via email; the workflow is easier that way
<mdke> ogra, froud has organised some african language translations
<ogra> yeah
<mdke> ;)
<infinity> mdz : Kay.
<froud> ogra: just Xhosa
<mdke> we need to represent europe
<amu> ogra: hehe, whats about putting it on rosetta?  
<mdke> amu, sorry rosetta is broke at the moment
<mdke> amu some of the vital documents are very short though!
<infinity> mdz : What about the libgd2 timestamp skew failure?... If we start fixing those, we'll probably have to touch a couple hunderd packages.  Should I just close it?
<ogra> amu, do any german users look at rosetta ? we need to announce to them that there is help needed
<mdke> ogra, these docs aren't in rosetta and probably will not make it in in time for hoary
<mdz> infinity: timestamp skews should be fixed; we've fixed all the ones which have actually occurred on the buildds to date
<amu> ogra: me z.b. :)
<ogra> amu, youre a dev, that doesnt count :)
<infinity> mdz : Alright.  I'll plug the appropriate touch magic into debian/rules, then.  I so rarely see timestamp skews on anything but really slow machines, I didn't figure Ubuntu would much care.
<mdke> ok anyway thanks for your help ogra
<mdke> i'm off
<thom> seb128: how does one update the timestamp on a transient window so it appears on top?
<seb128> thom: open it with a timestamp ?
<thom> seb128: (#8268, for reference)
<seb128> thom: or you can play with gtk_window_set_focus ()/gtk_window_set_keep_above () etc, mvo has played with that he probably knows better
<seb128> that's a nautilus bug
<seb128> thom: http://bugzilla.gnome.org/show_bug.cgi?id=170494
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=169364 in fact
<thom> cool, it's all yours :-)
<seb128> I reassign
<seb128> bah, comment conflict 
<thom> i think we mid-air collisioned the reassign
<seb128> yep
<thom> oh well :-)
<fabbione> pitti: ping?
<zyga> hey
<zyga> mvo: should I send patches or wait till breezy and something gets commited?
<mvo> zyga: what you prefer, I can review patches, but I will only commit after hoary
<zyga> mvo: I can wait, the diffs would have to be hand edited anyway 
<zyga> mvo: what are the chances for KDE version?
<pitti> fabbione: pooooonnngggg
<fabbione> pitti: too late..sorry
<pitti> fabbione: sorry, was away for a bit
<lamont> if kde is installed in the chroot, it's because something in that path fails to remove cleanly...
* lamont will have to investigate
<fabbione> pitti: nothing important... we were voting the name for the kernel release :)
<lamont> daniels around by chance?
<pitti> fabbione: how could I miss that.... what's the outcome?
<pitti> fabbione: Carnivore Carrot?
<abelli> sabdfl: ping
<fabbione> pitti: you will see it soon on -changes :)
<infinity> lamont : If he's not insane, he's in bed, as I should be.
<fabbione> daniels: fdclock is missing a Build-Dep on some cairo-xlib.h
<lamont> infinity: I've found with this crowd, it's not "what TZ are you in?", it's "what TZ are you currently executing?"
<abelli> wasabi: cia
<infinity> lamont : DId you figure out why KDE was sticking around?
<lamont> checking now
<mvo> zyga: for a kde version? not bad
* lamont lets that buildd finish with the new-and-succeeding libgd2 first
<infinity> lamont : Tell me it's the 'x*-common doesn't purge' bug that was fixed in Debian a while ago, so I can scream.
<fabbione> infinity: i don't think so 
<fabbione> we would have noticed ages before
<infinity> fabbione : One would think so.  Though, the bug lay dormant in xfree86 for several versions until it suddenly broke all the buildds.  Very weird.
<fabbione> infinity: it must have been triggered by something
<infinity> fabbione : I mentioned it to daniels and he said "we might have that bug"... Not sure if he ever actually looked into it.
<infinity> I'm hoping he did. :)
<fabbione> infinity: well.. changelog is there for a reason :)
<infinity> Changelog isn't helpful if the bug was never there to start with. (ie: you guys may have killed it with your xorg repackaging without noticing)
* Lathiat wonders why archive.ubuntu.com returns bad header lines every few times he updates
<lamont> Removing apache2-mpm-prefork ...
<lamont>  * Stopping web server (Apache2)...                                      [fail] 
<lamont> invoke-rc.d: initscript apache2, action "stop" failed.
<lamont> dpkg: error processing apache2-mpm-prefork (--remove):
<lamont>  subprocess pre-removal script returned error exit status 1
<lamont> infinity: that, believe it or not, is at least part of the root cause.
<fabbione> lol
<infinity> lamont : Well, I just fixed that bug too.
<infinity> lamont : Handy.
<lamont> infinity: good.  then I don't have to. :-)
<lamont> Purging font configuration of fontconfig...
<lamont> Purging category cid..
<lamont> Purging category truetype..
<lamont> Purging category type1..
<lamont> fc-cache: error while loading shared libraries: libfontconfig.so.1: cannot open shared object file: No such file or directory
<lamont> \
<lamont> giggle
<fabbione> lamont: bad!
<fabbione> libfontconfig comes for X iirc
<fabbione> but than.. 
<wasabi> abelli, ?
<abelli> ciao
<abelli> ...
<lamont> sudo rm -rf build-hoary-test/chroot-hoary-test/
* lamont capitulates
<fabbione> pitti: http://linux.bkbits.net:8080/linux-2.5/gnupatch@424cce15dqRorp5LwCSspurmm1KAsQ
<pitti> oh no, not again
<fabbione> pitti: well.. it's signed by one of our friends
<pitti> yeah, I just saw
<pitti> fabbione: 5 minutes after a hoary upload *sigh*
<fabbione> pitti: exactly
<Lathiat> that sucks
<pitti> fabbione: well, it won't be the last one until release
<fabbione> i am afraid not
<fabbione> not even the time to create the pre34 branch!
<|QuaD-> http://linux.bkbits.net:8080/linux-2.5/gnupatch@424cce15dqRorp5LwCSspurmm1KAsQ
<infinity> Gah, stupid apache2 init script.
<lamont> infinity: ross chroot pristene, neon given back, etc, etc.
* schweeb pokes jdub
<infinity> lamont : mmkay.
* lamont fears that today will be 'rebuild the chroots' day
<fabbione> |QuaD-: ?
<lamont> fortunately, I have a script.
<lamont> unfortunately, the script doesn't know about udev
<|QuaD-> fabbione: sorry :) was copy in putty, accidently pasted via right clicking the mouse :(
<infinity> Yeah, I automated chroot creation when I had an overheating buildd that I had to keep rebuilding while trying to figure out WTF was wrong with it.
<pitti> Kamion: ping
<lamont> infinity: I have 2 machines, with 3-6 chroots each
<lamont> s/2/12/
<smurfix> fabbione: can you log onto the chroot of that buildd and do
<smurfix> fabbione:       env PERL_BADLANG=0        /usr/share/console/getkmapchoice.pl 
<smurfix> fabbione: (install console-common first)
<fabbione> smurfix: in a minute.. yes
<smurfix> fabbione: It probably prints an error / warning / whatever
<smurfix> fabbione: with that postinst isn't able to deal with
<smurfix> s/with/which
<fabbione> smurfix: do you want the logs i guess
<smurfix> fabbione: I have the log, but it's not in there
<infinity> lamont : I only admin half a dozen or so, with 3 chroots each, but surely I get bonus points for them all being m68k...
<smurfix> fabbione: it's backticked into a variable and never actually printed
<thom> infinity: stupid points, rm
<thom> uh, "ym". :-)
<fabbione> smurfix: ok just a second :)
<lamont> infinity: on the insanity scale, yes?
<infinity> lamont : Well, it was an argument for the "everything should be automated" thing anyway.  On faster machines, I don't much care doing the same thing over and over.  On m68k, I kinda prefer to set-and-forget.
<fabbione> smurfix: see /msg
<smurfix> fabbione: Ah. So what's debconf doing thinking that Dialog is what we want?
<smurfix> fabbione: That's a buildd, that should be set to None, methinks
<fabbione> smurfix: no idea. but it has been like that since i bootstrapped the chroot
<infinity> thom : Just fixed the root cause of the apache2 bug.  D'oh.
<thom> what happened?
<smurfix> fabbione: So dpkg-reconfigure debconf and the problem goes away.
<fabbione> smurfix: let me try
<thom> infinity: (i hadn't looked at the bug at all)
<infinity> thom : In the ubuntification of the new init script, I missed a case where it would exit 1 when it should have exited 0. (no daemon running when stop() called)
<thom> ah, oops
<fabbione> smurfix: i will test later.. it's building packages for main right now
<infinity> thom : S'ok.  The other fix (not failing the prerm on init script failure) was probably weanted too, so now we have both. ;)
<smurfix> fabbione: shouldn't hurt, but better safe than ...
<fabbione> smurfix: exactly.. 
<fabbione> and since it's keeping up so nicely with main :)
<infinity> Alright.  Bedtime for me.
<Mitario> hi everyone
<thom> mdz: does the new bug page seem ok?
<pitti> bye guys
<diamond> mvo: heimdal-kdc fails to install on amd64. bug filed.
<mdz> thom: How about "Packages in the 'universe' component of Ubuntu"?
<thom> mdz: sure
<thom> mdz: hrm, note the URL you gave me is currently asking for username/password
<mdz> I should probably update the Ubuntu description to mention main; I think I can do that from the web interface
<mdz> thom: that's the URL that sabdfl gave me and swore an oath that it was correct
<thom> mdz: k. i'm out for a few hours now but mail if it needs changing and i'll do it when i get back
<sabdfl> mdz: hmm... i may have got the wrong url
<thom> sabdfl,mdz: dholbach put https://launchpad.ubuntu.com/distros/ubuntu/+bugs in his MOTU mail
<thom> is that more likely to be right?
<sabdfl> mdz: bradb wants https://launchpad.ubuntu.com/distros/ubuntu/+bugs which is not quite right but better
<thom> sabdfl: done
<froud> ogra: is there a web page which explains how the data collected by Ubuntu Device Database is used with reference to users privacy rights?
<sabdfl> thom: thanksbot
<thom> sabdfl: *g*
* thom -> cinema
<thom> (time to exercise what little of my german remains)
<froud> ogra: if not then I recomend we make a statement somewhere regarding the policy on this issue
<ogra> froud, i'll write something....its just hardware data that gets collected, no privacy data
<froud> yes, I see that from the code
<ogra> nothing you could track a user with
<froud> but we need to cover it, just in case ;-)
<froud> ogra: still it is private information
<ogra> except if the user wants it, he has the ooportinity to look it up by a unqe id he owns
<froud> can you mail me details about this unique id or point me to a URL
<froud> if this information is made publicaly available it does infringe certain rights
<ogra> froud, if the datafile is generated a md5sum is made of this file....the md5sum is also the filename and is stored in ~/.hwdb....if you want to look up your data you can find it with it, but the server isnt able to trace it back to you
<froud> ogra: is this database made publically available for anyone outside of Canonical where it can be used for research or commercial purposes
<ogra> froud, yes, it will be .... but there is no server for public use yet, it will be there some weeks after release...
<froud> ogra:  where is the server? URL please where I can check it
<mdz> seb128: are you here?
<froud> ogra: are you aware of the commercial value this database has
<seb128> mdz: yep
<ogra> as i said there is no server yet, its one cgi to make it possible to look up your own data and show some basic data, its at hwdb.ubuntu.com, but please dont make it public
<mdz> seb128: so 2.10.1 is delayed, but we do not want to delay Hoary any further.  what do you think is the best that we can do to get bugfixes into hoary?
<mdz> seb128: can we take CVS snapshots next week?
<seb128> 2.10.1 is delayed ? since when ?
<seb128> I'm not aware of that
<ogra> froud, its currently a collection of flat files, so it wont ope with a lot of users...
<mdz> seb128: jdub told me yesterday that it is delayed 1 week
<ogra> cope even
<seb128> jdub: thanks for saying me dude
<Lathiat> saving?
<ogra> froud, yes. i'm aware if its value, but what should i do about it :)
<seb128> mdz: we will probably get a good part of tarballs, maintainers are not aware of that afaik
<mdz> seb128: hmm, ok.  he did not say it was final, but "most likely"
<seb128> maintainer will roll tarballs this WE/monday
<ogra> froud, i wont start the real (SQL based) server before release, so this interim will be in place some time...
<seb128> dunno when he wants to announce that
<seb128> jdub: why delaying 2.10.1 ?
<froud> ogra: You just have to make your user aware of how what data is collected, how it impacts privacy, and how the data will be used.
<seb128> mdz: do we want to update stuff without code changes which have no tarball for the translations or not ?
<Lathiat> froud: it does mention no personal information is collected
<ogra> froud, dont you think the first screen of the app is sufficient for that ? it tells about all these things briefly
<dredg> ogra: so what happens if 2 users run the app on 2 identical machines? :)
<mdz> seb128: translations would be good, yes
<smurfix> dredg: unless the machines have no Ethernet, they aren't
<ogra> dredg, if they even have the same test results and the same comments, that actually great :)
<dredg> smurfix: that popped into my head as soon as i hit enter
<dredg> gah
<ogra> dredg, that saves us one entry in the DB, since the same applies to both ;)
<dredg> ogra: fair point :)
<froud> ogra: it does but we must address things in terms of privacy and provide a statement that invites the user to exit now if there are not certain.
<Lathiat> the applet looks swanky
<smurfix> dredg: Unfortunately (meaning that we probably will get complaints about that) the Ethernet address is included in cleartext
<ogra> dredg, but its unlikely that the bootlog and xlog data are the same anyway
<Lathiat> froud: it also gives you a chance not to send at the end
<ogra> froud, hmm...
<Lathiat> i guess a warning could be put there
<Lathiat> rather than the start
<froud> yes but it must be plain and obvious
* _mvo_ goes to play some hockey. bbl
<froud> ogra: while packaging and before sending the user should have a text message to prompt for final verification that they want the information to be sent. By clciking yes, they accept the terms of what ever policy an disclaimer you provide.
<ogra> froud, i think whats written on the first page is sufficient, you are always able to click canel
<ogra> cance even
<ogra> argh
<froud> Dont count on users reading, I did not
<zyga> hello
* zyga just logged in
<ogra> froud, your own fault...
<diamond> ogra: hum. the hwdb entry for my machine shows ram as being 507M instead of 512... is that expected?
<zyga> what the HECK :-)
<ogra> froud, its written there
<zyga> this is the official artwork? :> 
<dredg> zyga: yeah
<dredg> last minute change for haory
<dredg> hoary*
<zyga> :-)))
<ogra> diamond, what does cat /proc/memeinfo show ;) ?
<ogra> -e
<zyga> it sure looks good ;] 
<zyga> (to be there)
<zyga> but I sure hope it's going to go away ;] 
<froud> ogra: better to add a prompt at end of wizard, Accept or Decline
<dredg> meme info? :)
<diamond> ogra: huh. 507480 kB. no idea why
<ogra> diamond, i'm only collecting the data the kernel sees :) 
<diamond> ogra: fair enough
<zyga> BTW: who is on the happy picture/
<ogra> froud, i really dont like the idea.... if its not for legal reasons that force it, i'd like to leave it as it is...
<ogra> i think one hint that you submit your data online is enough...
<ogra> froud, it will scare a lot of users more then necessary
<smurfix> ogra: It does say no personal data IIRC, which kindof doesn't include the ethernet address
<ogra> smurfix, yup
<smurfix> maybe s/etheraddr/XXX/g would be a good idea
<ogra> smurfix, do you _really_ think thats necessary ?
<smurfix> Personally I don't but I remember the stink that went up when M$ basically did the same thing
<ogra> there is no ip or anything....
<ogra> neither routing information....
<smurfix> ogra: I know ... it's not me you'll have to convince if/when somebody decides to raise a stink about that. I don't know how likely that is either.
<ogra> smurfix, i dont even think it will get used or stored in the database, lets see, if i find the time before release i'll filter it out...
<smurfix> ogra: Fair enough. 
<ogra> heh, preventive programming
<smurfix> ogra: So is every BUG() call in the kernel, this is just a different class of bug ;-)
<ogra> heh :)
<froud> ogra: it is up to you. I just ask cause I thought it may be a trojan for potential problems in the future.
<froud> ogra: if it was me I would put clear Accept or Decline
<ogra> froud, i will face them if they encounter me, but id rather have 1000 flame mails, then scraing away 10000 users by a extra question...
<ogra> there are enough options to stop the process....
<froud> ogra: I don't think it will scare users if they have the clarity of a statement
<ogra> froud, it would make _me_ think twic if there were such a question....
<ogra> froud, my GF too she says...
<froud> ogra: and it should to. That is why if the user clicks Accept there is no place for argument and no place for trojan problem in the future :-)
<froud> ogra: just my 2 cents
<froud> later
<ogra> froud, ok...dont take it personally :)
* kain is away: ciau
<daniels> mdz: pong
<daniels> lamont: pong
<daniels> fabbione: eh, should be b-ding on libcairo-dev or whatever, probably it's missed out on an api change
<froud> ogra:  no, I don't, I can always come back and say, "I told you so." :-)
<ogra> froud, yeah, with every right ;)
<mxpxpod> I know I've asked this before, but is there a reason we're using pbbuttonsd instead of pmud for powerpc?
<daniels> mdz, lamont: unpong, going to sleep
* mode/#ubuntu-devel [-o daniels]  by daniels
<Lathiat> daniels: you like late nights dont you :)
* Lathiat coughs
<mxpxpod> thom: ping
<lamont> daniels: oops
<abelli> is it possible to install drivers at run time with the live cd?
<mdz> abelli: #ubuntu, please
<abelli> huh yeah sorry .
<doko> Kamion, mdz: ok to upload a merged gsfonts package?
<mdz> doko: minimal changes?
<doko> mdz: the two exchanged fonts regenerated, glyphs added with daf's scripts.
<mdz> doko: ok, go ahead
<doko> mdz: ok, any answer to the OOo.2 question?
<diamond> elmo: hey. sync request for hping3 from debian
<trukulo> hi people, good afternoon/whatever
<ogra> diamond, probably better you do it by mail, he didnt show up today 
<diamond> ogra: right, thanks.
<mdz> doko: if you can regression-test things in main which build with gcc-3.4, ok
<doko> well, I need only regression tests for things which build with g++-3.4. will do tonight
<mdz> lamont: I just received encrypted, unchanged copies of my key from you
<lamont> mdz: yeah - the keyring on my machine hadn't been freshened... so it didn't see the sig
* lamont has freshened the keyring now..
<lamont> from the stupid perl questions department... given @x=qw(a b); how do I append "c" to the list?
<ogra> with push
<lamont> danka
<lamont> danke, even 
<trukulo> daniels, you awake?
<ogra> yeah, thanks for the key, you were actually faster then me.....
* ogra still has 10 unsigned mataro keys lying around and waiting for a spare minute...
<Cube-ness> anyone know of the "kernels later than 2.6.8 panic (failed sync) in hotplug startup" bug? 
<Lathiat> woo new gnome splash is good
<mdz> lamont: is "@x = qw(a b c);" wha tyou're looking for?
<Cube-ness> is there some way i can see what all happens in the hotplug boot script thingy? i'd like to figure out just what is the problem here
<Cube-ness> i had to install a kernel form warty to get hoary to work
<lamont> mdz: actually trying to conditionally append
<jbailey> Cube-ness: Not trivially.  It chains between shell scripts, so even sh -x gets lost.
<mdz> ok, push then
<lamont>   foreach ${dist} qw(warty hoary) {
<lamont>     push(@take_from_dists,"${dist}${flavor}")
<lamont>         if -d "build-${dist}${flavor}/chroot-${dist}${flavor}";
<lamont>   }
<lamont> like that
<Cube-ness> i just wanna know what to blacklist so i can use a new kernel
<Cube-ness> i dont even get anything in any logs
<Cube-ness> it just jangs
<Cube-ness> hangs
<Cube-ness> sometimes it spits an oops or a panic
<Cube-ness> usually not though
<Cube-ness> hell, i wish i knew what is failing to sync.. and what that means?
<_froud_> ogra: a first draft in progress of the Ubuntu Device Database Manual source can be checked out (svn checkout http://www.ubuntulinux.org/wiki/TakingScreenshots) Do yelp on documen to view. It is just a start, but will keep you psoted.
<_froud_> whooops
<_froud_> ogra: a first draft in progress of the Ubuntu Device Database Manual source can be checked out (svn checkout https://docteam.ubuntu.com/repos/branches/froud/gnome/ubuntu-device-database) Do yelp on documen to view. It is just a start, but will keep you psoted.
<ogra> _froud_, great, thanks, i will read it...
<_froud_> ah much better
<_froud_> no need for much reading
<_froud_> just so you know where it is being developed
<_froud_> I will notify you once I have the draft complete, then is a good time for reading by you
<ogra> _froud_, keep in mind there will be some things not yet included in the endversion (like a button that opens your online data for you)
<_froud_> I will also ask other doc team members if they want to edit etc.
<_froud_> ogra: sure, we will do it inline.
<ogra> and probably a textfield with the id to copy paste it...
<ogra> _froud_, i really appreciate it, thanks :)
<_froud_> ogra: no worries I have a few apps in this state, document them as we go and make sure they will release with docs
<_froud_> must go
<CarlK> ogra - what is the name of the .wav that gets played for the audio test?
<ogra> CarlK, guess
<CarlK> test.wav
<ogra> near
<ogra> sound.wav
<CarlK> audiotest
<lamont> elmo around?
<CarlK> figured it was something like that
<Cube-ness> is there some way to get soem logging or verbosity fo rhte hotplug init script?
<Cube-ness> i'd like to see where it bites the duct so i can report some bug
<Cube-ness> dust too
<Cube-ness> hehe
<CarlK> you can make the scrip echo commands by changing the first line to #!/bin/sh -x
<Cube-ness> so i can do that to /etc/init.d/hotplug?
<CarlK> i just did
<Cube-ness> ok
<CarlK> im trying to find out what -e does, other than prevent -x from working
<Cube-ness> hehe
<lamont> -e says 'die if anything exits with non-zero status (fails)
<lamont> '
<Cube-ness> hopefully i can figure out where the prob is
<CarlK> lamont - any idea why -e -x doesn't work?
<lamont> it should
<CarlK> -ex does
<CarlK> "-e -x" does /bin/sh: - : invalid option
<Cube-ness> #!/bin/sh -ex -lax
<srbaker> -x implies -e
<Mithrandir> fabbione: amd64 xen ; http://article.gmane.org/gmane.comp.emulators.xen.devel/8437
<CarlK> ogra - Audio test, "Test again" clears the comments.. (anoying)
<ogra> CarlK, sorry, might be a wontfix for hoary....
<CarlK> i hear ya.. 
<CarlK> nother one: how come when I hit "partial" it disables "Forward" ?
<ogra> becaus we want more information from you what partial means ;)
<CarlK> I filled in the comment, still no Forward
<CarlK> ah, I have to pick Partil first, then fill in the comment
<CarlK> I am getting good at fillin in that comment ;)
<ogra> CarlK, yep... thats a bug i'll have to fix...
<CarlK> want me to bugzilla it?
<ogra> CarlK, nah, n need, its already filed...
<ogra> s/n/no
<ogra> but thanks for the offer :)
<CarlK> "connecting to server (timeout 30 seconds)" has been on my screen for about 2 min now
<ssbob> I've got a quick question about the Live CD
<srbaker> ssbob, no
<ssbob> How hard would it be to add back in "Copy to RAM" support?
<srbaker> no
<srbaker> hard
<ssbob> bummer, thanks
<CarlK> I wish there was a way to run the Live CD over a lan ;)
<Echylo> is there a beagle package available?
<CarlK> https://www.ubuntulinux.org/wiki/HoaryBeagleRunningHowto
<Echylo> thanks
<Echylo> could have find that by myself :)
<Echylo> :s
<CarlK> thanks for making me look that up - never knew it existed ;)
<Echylo> hmm
<Echylo> that doesn't work
<Echylo> I have universe checked
<Echylo> but it doesn't finds package beagle
<ogra> Echylo, mono is currently being rebuilt, wait some days and you'll probably find beagle in universe....
<Echylo> ok
<Echylo> is it smart to install it from source?
<Echylo> oh well
<Echylo> let me just wait :)
<ogra> no idea, i hav amd64 here and other tasks the playing with mono...but if tseng makes it, we'll have a easy installable package of beagle before release in universe
<ogra> (and i belive in tseng ;) )
<Echylo> :)
<Echylo> ok thanks :)
<jbailey> Anyone here running lvm willing to test a patch for me?  I've tested it on ppc with SATA, md and evms-managed md.  I'm about to test on ia32 with ide, but would like a test on lvm for completeness.
<Berserker> hi people! installer cant find info about partition table of my IDE HDD. But  on the other virtual terminal in the same time I can list it by `fdisk -l` and mount all partitions to any mountpoints..
<Berserker> what I should  do to install Ubuntu ?
<lamont> Berserker: that's really a question that's best asked in #ubuntu
<lamont> mind you, it sounds like you'll wind up fileing abug once you figure out what's going on...
<dholbach> hellas!
<mvo> hey dholbach 
<dholbach> :-)
<mdz> mvo: these missing refs in python-apt, what is their effect?  a memory leak?
* lamont goes to fetch kid from schoool
<mvo> mdz: worst case is that python throws a exception because it tries to free the "None" object. It needs a lot of calls to the affected functions but I really would appreciate if that could be fixed. 
<Mitario> hi everyone
<mvo> mdz: I think the patch is really safe, it was a stupid oversight on my part :/
<mvo> hi Mitario 
<mdz> mvo: go ahead (emailed you)
<mvo> mdz: thanks a lot!
<Mitario> is the wiki fixed? :-)
<dholbach> Mitario: i can log in
<Mitario> dholbach, i had a problem with resetting my password
<dholbach> Mitario: hrm, don't know anything about that
<Mitario> hrm, still shows me the http auth dialog
<Mitario> hmm, i can login to launchpad, but not the wiki
#ubuntu-devel 2005-04-13
<Burgundavia> anybody here?
<T-Bone> no
<T-Bone> we're all bots
<T-Bone> =] 
* roo_ exterminates
<Burgundavia> looking for someone to ask about nautilus
<Burgundavia> has the defaul behaviour changed?
<T-Bone> yes
<Burgundavia> s/defaul/default
<Burgundavia> to close the existing window?
<T-Bone> and that's a #ubuntu question i'd say
<T-Bone> yes
<Burgundavia> ok
<Burgundavia> well I figured I would ask before I reported a bug
<mvo> can someone make a proper english sentence from "forcing re-get of the signature file as requested"
<dredg> context?
<mvo> or is that good enough? 
<mvo> dredg: forcing apt to re-get the signature file and not sending proxy control messages 
<dredg> looks ok to me
<ogra> mvo, looks good from a german POV ;)
<crimsun> and to send?
<mvo> dredg: cool, thanks. any captialization?
<crimsun> where does the parallel structure break down?
<T-Bone> you mean "get apt to bypass proxy ("pragma: no-cache") to get the sig file again"?
<dredg> mvo: no
<ogra> hmm, they dont get lesser.... http://hwdb.ubuntu.com/nullswap.html
<T-Bone> ogra: did my yesterday's submission suggested you to look for that? :)
<ogra> T-Bone, no, i nearly read all of the submissions, i noted it on the first day...the rate is always been around 9% thats worrying...
<T-Bone> ogra: heh ;)
<T-Bone> ogra: depends on the amount of RAM and the intended workload of these configurations
<T-Bone> ogra: for instance, I don't have swap, this is meant and works absolutely fine
<ogra> i already recieved mails by people that werent aware that they dont use swap
<ogra> there are a lot of 128~256M machines in the list....
<T-Bone> huh
<T-Bone> then that's bad, yeah
<ogra> and even my 512 swap from time to time here
<adobbie> my computer would be toast without 400MB+ of swap
<adobbie> rather the programs trying to allocate memory
* T-Bone has hard time understanding how a computer can actually be useful with such an amount of swap. Even worse when the swap is bigger than the amount of RAM (expect very special cases with < 16MB RAM)
<Mithrandir> T-Bone: enough swap is useful for suspending to
<T-Bone> Mithrandir: that's a point I didn't think of, fair enough
<Mithrandir> (which is why I have ~2G swap on this laptop)
<dredg> T-Bone: i prefer apps that are not doing anything to swap out
<ogra> Mithrandir, http://hwdb.ubuntu.com/amd64.html
<ogra> :)
<Mithrandir> ogra: can we get links to all those pages on the front page, and more stats! :)
<ogra> sure, if we have more then flatfiles ;)
<Mithrandir> (what's the average clock speed for amd64 boxes, for instance)
<ogra> funny number, i had expected more http://hwdb.ubuntu.com/ppc.html
<ogra> Mithrandir, thats what we planned, but we'll need a DB first which i wont start before release....currently there is only this interim solution...
<Mithrandir> ogra: ook.
<dholbach> ok guys... i'm off to bed - have to help a friend moving tomorrow
<dholbach> good night
<ogra> night dholbach 
<mvo> night dholbach 
<ogra> whoops, there was a bug in the amd64 scipt....now its more realistic, thanks dholbach 
<Mithrandir> noooo! :P
<ogra> :-/
<ogra> still more then ppc :)
<Mithrandir> yeah :)
<dholbach> bye ogra, mvo :-)
<dholbach> ogra: anytime :-)
<ogra> night, sleep well :)
<dholbach> will do :-)
<lunitik> sabdfl: lots of complaints about the new nautilus behavior in #ubuntu  :(  ... you know if you like it, you can turn it on yourself... but most seem to dislike it  :(
<azeem_> who do I need to talk to for syncing universe stuff from unstable?
<azeem_> sbuild_0.35 might be nice to have in hoary, it's got the distribution checks disabled and should work better with Ubuntu
<Burgundavia> azeem_: #ubuntu-motu
<lunitik> azeem_: I think we are in freeze right now... so you'd have to wait a week or so...
<ogra> nah
<ogra> universe is open til the end
<crimsun> azeem_: just ask elmo
<ogra> yeah
<tseng> non-motu's need approval to sync
<ogra> then put          iton our sync list in the wiki
<azeem_> where's that exactly?
<tseng> wiki/MOTUTodo
<ogra> http://ubuntulinux.org/wiki/MOTUToSync
<azeem_> thanks
<thom> mxpxpod: ack
<mxpxpod> thom: hey
<thom> mxpxpod: hey hey, wassup?
<mxpxpod> thom: just wondering how the pmi is going?
<thom> mxpxpod: waiting with eager glee for gnome-power
<mxpxpod> I think we should replace pbbuttonsd with pmud in ubuntu
<thom> i hope we can bin all of them
<mxpxpod> that'd be awesome!
* mxpxpod hates pbbuttonsd
<thom> i think we can probably do so in not too long
<thom> hal+gnome-power is coming along nicely
<mxpxpod> that'd be suuuuhweet
<mxpxpod> thom: yeah, pbbuttonsd takes care of way too much
<thom> yeah
<thom> definitely
<mxpxpod> I wish the guy would modularize it so I could just load the pm stuff
<azeem_> ok, done
<blueyed> Is amd64 considered stable? Had some issues with a Gigabyte GA-K8N Ultra-9 and a 300gb SATA drive.
<blueyed> I'd like to try the latest daily.. (have used the RC now).
<thom> blueyed: works just peachily for me
<thom> (but it always has, pretty much)
<thom> blueyed: what issues are you seeing?
<blueyed> it installed with grub on hd2 and gave "error 17" - changed it to hd3 and it worked..
<adobbie> blueyed: and what is error 17?
<blueyed> the installation now is kind of very broken.. there were a lot of segfaults during the post-install run
<blueyed> filesystem not recognized..
<adobbie> blueyed: did you run memtest86?
<blueyed> no.
<blueyed> should it be installed?
<thom> blueyed: there'll be an option on grub for memtest
<thom> lots of random segfaults sound bad
<blueyed> thom, as a "boot" option? haven't seen it - but will try when rebooting. anyway I'd like to do a fresh install and need to burn the .iso therefor..
<blueyed> I'm getting help in ##linux. thanks.
* mvo goes to sleep now
<blueyed> just re-installed (using the same image), no errors.. all I've changed with the hardware was another SATA port on the board..
<adobbie> that's bad
<CarlK> ogra - can you make me an mp3 of sound.wav that should sound the same?
<ogra> CarlK, not now...
<CarlK> (I just made one with lame, and it sounds like my cat
<adobbie> ha
<adobbie> try setting 320kbps encoding
<CarlK> ogra - the goal is to play it on a MPIO mp3 player, which shold play it "right"
<ogra> CarlK, usecase ?
<CarlK> adobbie - I did
<CarlK> ogra - to know what the sample sound should sound like.  so far I her 5 slightly different soudns on 5 different boxes
<adobbie> CarlK: are you using the same speakers on all machines?
<CarlK> there is a high frequency "hiss" that doesn't sound like it should be there
<CarlK> yes - good set of head phones
<tseng> hm no daniels
<adobbie> sounds cards will sound different
<ogra> CarlK, play it on a frieds box, its no perfect recording or anything...i could also have taken a pig squeek recorded through a can phone, its just a test if your system sounds work
<adobbie> CarlK: any particular setup sound best?
<CarlK> adobbie - yes, but now I forget wich... wanted to figure out what I should be hearing before I comment on how it sounds
<CarlK> hmm, mabe the mpio doesnt like 320kbs
<CarlK> http://dev.personnelware.com/carl/temp/Apr01/sound.mp3
<blueyed> What about integrating pppoeconf into the install process (with network setup)?
<ogra> CarlK, sonds like the wav
<CarlK> good - thanks
<koke> http://koke.amedias.org/2005/04/02/spatial-mess-prevention/
<koke> give me opinions :D
<Burgundavia> thank you koke!!
<Burgundavia> koke: can you post that to the -devel mailing list?
<Burgundavia> so we can get some discussion on it?
<koke> Burgundavia: it's already in the way :)
<koke> oops, I sent it from the wrong address
<koke> http://lists.ubuntu.com/archives/ubuntu-devel/2005-April/006462.html
<koke> going to sleep now :)
<koke> bye all
<zul> hey
<daniels> lamont: patch merged
<zul> heh new nvidia drivers
<lamont> daniels: thanks muchly
<daniels> zul: AGAIN?
<daniels> phew, it's still 7174
<zul> http://www.nvidia.com/object/linux_display_ia32_1.0-7174.html
<daniels> yeah, 7174
<zul> ah...fabbione would have heart attack :)
<daniels> i'm packaging 7174 now anyway
<zul> ah
<adobbie> and I just got 7167 installed
* lamont finally gets his scriptage-foo right, rebuilds a boatload of chroots everywhere
<daniels> is anyone else seeing gnome-terminal leak more memory than ... anything ever should?
<daniels> mine seems to leak in the order of 500MB a day
<crimsun> will hoary/universe have security updates, too?
<robertj> heya all, I was just checking the listservs, did nautilus get browse mode enabled by default?
<Lathiat> robertj: no, spatial mode was hacked to close the window behind it when you open a new folder as if you where middle clicking (and middle clicking does what a left click did)
<robertj> oh, hrmm, I don't know how I feel about that
<Burgundavia> this is going to be a lively debate
<Lathiat> I think the biggest issue
<Lathiat> over any issues of whether its good or bad
<Burgundavia> tehre are threads on ubuntu devel and ubuntu
<Lathiat> is that it was done like what, 5 days before release now?
<Burgundavia> 7 actually
<robertj> Lathiat: that's not in hoary is it?
<Burgundavia> it will be
<Lathiat> robertj: it is
<Lathiat> as of yesterday
<Burgundavia> by hoary, I think you mean the released version
<Burgundavia> correct?
<robertj> Lathiat: HoMM3 combined with a wine regression has made that difficult for me to test ;)
<Lathiat> HoMM3?
<robertj> Burg: yeah
<Lathiat> ah, i meant in the archive
<robertj> Lathiat: heroes of might and magic 3 ;)
<Lathiat> which it is
<Lathiat> and i assume its for hoary
<Lathiat> since its gone in :)
<robertj> hoary is suppsed to be out Wed right?
* robertj checks HoaryReleaseSchedule
<robertj> NM, next Mondayish
<robertj> the 8th
<minghua> robertj: That's Friday :-)
<robertj> doh!
<robertj> ;)
<lamont> "week of [next monday] "
<robertj> yeah
<robertj> just not clicking
<robertj> I really dislike the idea of closing windows in spatial mode. What advantage does that give you over browse mode?
<HrdwrBoB> it's more intuitive
<robertj> HrdwrBoB: Why not just put it in browse mode
* lamont fails to understand the difference
<HrdwrBoB> robertj: if you want to, do
<HrdwrBoB> after using spatial mode for a few months
<HrdwrBoB> it's now much much easier
<robertj> lamont: Browse Mode wouldn't move the window or change it's size and would offer the usual browse menus and such
<lamont> robertj: and this is nautilus, or what?
<robertj> lamont: ?
<lamont> robertj: don't mind me - just rambling
<jdub> robertj: it was a sabdfl request. we'll see how it goes.
<robertj> lamont: oky, but yeah it's nautilus
* lamont notices that it's not actually late, it just feels that way
<robertj> lamont: it does feel late, I think its planet.gnome.org withdrawl
<jdub> withdrawl?
* lamont considers maybe one day actually thinking about using nautilus for something
<robertj> I miss reading them ;)
<daniels> robertj: planetkde.org
<robertj> hehe
<lamont> robertj: yeah - I hear jdub raped planet.gnome too, eh?>
<daniels> heh
<daniels> planet debian is just a full-page photo of elmo
<jdub> i can't believe people would use that word about a login screen joke
<robertj> most users have like 15 files and can't manage swapping between the file manager and one other window, never the less 5 windows
<robertj> but the same users are then going to close that window, go to the desktop, click the Filesystem, and start from scratch
<robertj> scary but true
<lamont> heh. planet.debian.org is now back to being planet.debian (swirl and all), but still says 'planet ubuntu'
<lamont> Setting up hotplug (0.0.20040329-16ubuntu17) ...
<lamont> grep: /etc/network/interfaces: No such file or directory
<lamont> bad hotplug
* lamont puts the final touches on flatlining all the chroots on all the buildd's and rebuilding them.  sigh.
<robertj> ooh that sounds like not fun
<lamont> OTOH, the scriptage is now much better,.
<lamont> adding breezy is simply a matter of 'sudo build-chroot buildd breezy; touch buildd.conf'
<lamont> well, given a breezy.buildd in the right place, that is.
<lamont> and an archive to back it up.. :-)
<robertj> breezy doesn't strike me the way warty or hoary do
<robertj> it seems like the forrunner of dandy dolphin or something
<adobbie> easy breezy
<robertj> breezy is never used around here except as a way to insult someone's intelligence
<robertj> or the wind "it's breezy outside"
<robertj> I'm all excited, got a new machine coming at work that will be happy running Breezy ;)
<jdub> http://distrowatch.com/stats.php?section=popularity
<jdub> look at those leads
<Lathiat> wow
<robertj> ooh, almost over the top
* mdz shovels more coal into the furnace
<robertj> would it be considered cheating to do a /usr/local/bin/everybody wget http://distrowatch.com/ubuntu ;)
<robertj> hoary has been interesting to watch, it's a big step forward but alot of it was stuff that wasn't planned and alot of the planned stuff isn't going to make it in
<tseng> jdub: ping
<jdub> tseng: pong!
<jdub> tseng: hey hey hey!
<tseng> hi jdub :P
<tseng> ill probably be putting packages up tommorow
<tseng> im almost finished making a mess of mono
<jdub> 1.1.x?
<tseng> well, i need to redo *
<jdub> ugh
<tseng> mono, gtk-sharp, gtk-sharp2, dbus-mono, muine, etc, etc
<tseng> monodoc
<tseng> im "finished" all thats listed
<jdub> far out
<tseng> tomboy and some others to go
<tseng> and they arent clean
<tseng> fex the mono packages have files in more than one package somehow
<jdub> so then we need to at least test f-spot, tomboy, beagle... anything else significant?
<crimsun> muine, too, but I suspect tseng's on that already
<tseng> im using muine right now
<tseng> yes we need to test all of those
<jdub> yeah, good call
<tseng> im not sure how sane it is to go into hoary at this point
<crimsun> well, you have 6 more days.
<tseng> since the packaging is sloppy
<crimsun> =)
<jdub> well, we can always throw it straight into breezy
<tseng> we can
<tseng> id be happier to target breezy
<jdub> and have maybe one series packages for hoary the people who really care
<tseng> but i am not freaking out about hoary anymore
<tseng> i spent alot of time complaining about how bad things were before doing anything :/
<crimsun> to be honest, it's more sane to aim for Breezy
<tseng> yeah
* tseng could use a people.u.c
<tseng> are those for sale?
<jdub> yeah, we'll sort that out for you
<tseng> sweet
<whiprush> I will also donate whatever space you need.
<crimsun> jdub: btw, the xfce 4.2.1.1 transition is complete
<whiprush> sweet sweet beagle.
<jdub> crimsun: eeehhhhxcellent :)
<tseng> i guess i will need to get elmo my gpg key, mako hasnt gotten to processing it afaik
<tseng> CoC
<whiprush> crimsun: awesome work on xfce, that rocks dude.
<crimsun> whiprush: jani did the misc plugins
<crimsun> but the turnaround was pretty good, a bit under 2 days
<whiprush> man, things really turned out well for the release.
<crimsun> yeah, a lot of people pushing.  :)
<whiprush> back around when inotify and gamin were blowing up I was crying like a little girl in the corner.
<tseng> hahaha
<crimsun> ya know, it totally didn't even cross my mind that the gdm screen was an april fool's
<crimsun> I just restarted gdm and thought, "hmm, oh well"
<whiprush> how old is mdz? he can't be older than 25.
<fabbione> morning
<jdub> crimsun: nutball :)
<crimsun> heheh
<daniels> whiprush: mdz is timeless
<jdub> mdz is made of stars
<schweeb> I spent a good portion of the day laughing
<jdub> we are all made of stars
<schweeb> between Fleck and the GDM theme
<whiprush> daniels: I like how you young kids end up accomplishing what you do, it does wonders for my self esteem let me tell you. :p
<tseng> daniels is like a whole year younger than me
<jdub> dude, daniels has barely left pre-school
<tseng> like a baby.
* crimsun chuckles
<schweeb> how old are you daniels? 19?
<tseng> robbing the cradle.
<daniels> jdub: hey, I'm in uni now
<daniels> jdub: that puts me anywhere between 18 and 60
<whiprush> jdub: you gotta be pushing 30 or so. 
<tseng> daniels: uni sucks
<schweeb> whiprush: yea, you guys are old
<jdub> whiprush: ohgeethanksman.
<whiprush> it's the goatee. Adds a few years. Has to be.
<jdub> heh
* schweeb guesses jdub is 27
<tseng> i was thinking 28
<tseng> but 27 is nice.
<jdub> and people were saying that when i was 16...
<schweeb> poor jdub ;_;
<daniels> jdub: and now, 24 years on, you look *younger* rather than *older*!
<whiprush> hey is UDU going to be flumotioned?
<jdub> whiprush: not enough upstream bandwidth
<whiprush> taped then?
<jdub> hopefully
<jdub> though
<jdub> see, it's not really a conference
<jdub> it's a developer sprint
<mdz> except for the not-writing-any-ocde
<mdz> -code
<jdub> well, there has been some of that :)
<whiprush> mdz: so was I right? You're 25-ish?
<mdz> ish
<schweeb> hehe
<daniels> schweeb: so yeah -- somewhere between 18 and 60
<schweeb> daniels: lol
<schweeb> well if you're a year younger than tseng, you're a year younger than I
<schweeb> so you're 19 :)
<daniels> ah, but tseng could be wrong
<tseng> i am not
<tseng> i stalk you.
<tseng> across oceans!
<whiprush> "well, I like your work daniels, I'd like to buy you a drink, what's your poison?" "Coke." "Oh ... I see."
<tseng> whiprush: hm coke
<tseng> whiprush: i met russel coker recently (another aussie)
<jdub> ah, see, here, you can buy alcohol at 18
<tseng> when asked if there is anything he doesnt eat
<daniels> whiprush: (note that the ... yeah, what jdub said
<whiprush> oh
<mdz> they have no laws in Australia
<whiprush> man
<tseng> he says "corn syrup"
<jdub> hahaha
<jdub> haha
<jdub> russell is funny
<schweeb> makes sense, as it started out as a prison colony :)
* lamont sleeps
<daniels> as opposed to america, which has much more noble beginnings :P
<tseng> and after dinner, of all the places to see in america
<tseng> russel wants to go to walmart
<whiprush> heh.
<whiprush> I've met many non-americans that want to go to walmart.
<whiprush> when I was younger we had some kuwaiti royalty visit our area. we took them to all the expensive malls and stuff. They didn't dig that. They dug walmart though.
<jdub> i didn't enjoy my last trip to the US. i hope i will enjoy another one in the future.
<whiprush> one sheik dude bought like 40 pairs of plastic sandals. 
<whiprush> oscon?
<jdub> yeah
<jdub> stayed in portland and sfo
<daniels> you stayed in the airport?
<jdub> heh, no
<whiprush> what sucked about it?
<daniels> i kind of enjoyed my last one, but the whole place kinda freaked me out; even canada did, albeit to a lesser degree
<jdub> it was very intimidating
<tseng> how so?
<jdub> needed a car to get everywhere (i don't drive)
<tseng> enovegemite?
<whiprush> ah, yes.
<jdub> sfo was okay in that regard
<jdub> except going to santa clara
<schweeb> oh man, you'd hate Michigan
<jdub> i had sushi after a business meeting
<schweeb> public transportation--
<whiprush> I felt the opposite in boston. you don't drive anywhere, you subway all over.
<jdub> and asked the waitress where "the station" was
<jdub> "the police station?"
<jdub> ...
<whiprush> hahah
<jdub> seriously
<tseng> whiprush: i took a bus in boston
<whiprush> "station to what honey?"
<jdub> everything is big
<whiprush> yeah.
<jdub> and corn syrup taste strange
<jdub> and all the chips are corn chips
<whiprush> our area is big on big stuff. The bigger the SUV the better around here.
<jdub> yeah, portland was scary for car size
<schweeb> whiprush: or my Cadillac :)
<jdub> i couldn't get a taxi smaller than a bus
<whiprush> I look forward to checking out sydney, never been that far out from home before.
<whiprush> germany was real jorge-friendly to me though.
<schweeb> mostly the beer, I'm sure
<tseng> yeah, wish i could be there
<whiprush> any country where you can drink beer at any time of the day is fine with me.
<schweeb> score one for schweeb.
<whiprush> jdub: how did you like the people?
<jdub> oscon was pretty good
<jdub> but very corporate foss hacker audience
<jdub> lots of nice people, but plenty of ego ;)
<whiprush> I'm hoping to get work to send me out this year for oscon.
<jdub> i'm speaking at oscon again :)
<whiprush> for ubuntu or gnome? or both?
<jdub> both. pretty wide topic area.
* jdub looks for the abstract
<whiprush> their conference rate is pretty expensive though.
<kagou> 'morning
<jdub> yeah, crazy
<jdub> very audience limiting
<whiprush> I dig the rougher, cheaper, unwashed cons.
<tseng> we just did a 1 day $5 security con here
<tseng> it was fun.
<whiprush> harshy's midwest linux show in ohio is a good balance.
<jdub> whiprush: you should come out for lca ;)
<schweeb> lca?
<tseng> linux conf .au
<schweeb> ah
<tseng> they dunk people in tanks of cold water
* jdub shivers.
<tseng> for fun and profit?
<Lathiat> hehe that was fun
<whiprush> well, I've got work sponsoring me for 2 stateside shows per year, or one abroad. I'm thinking guadec first.
<whiprush> although, repeatedly dunking jdub for dollar donations to the foundation might be work a trip.
<schweeb> whiprush: if I get this job, and eventually get into a position where I can ask for that, that'd be hot.
<jdub> Title: Running with Scissors: Life on the Bleeding Edge
<jdub> "Don't run with scissors!" Instead, take a holistic-safari-guided-tour of the
<jdub> bleeding edge with Jeff Waugh, covering some of the sharpest areas of innovationin the Open Source world: GNOME, Ubuntu, extreme release management, and new
<jdub> collaborative developer tools.
<jdub> 
<jdub> heh:
<jdub>  * Why is everyone raving about the fresh new taste of Ubuntu?
<dilinger> jdub: lca's full :(
<tseng> with added corn syrup!
<daniels> mmm -- come to lca and heckle me
<jdub> dilinger: ja.
<dilinger> i tried to register last night
* whiprush recalls the last video of daniels getting heckled.
<whiprush> the last kde conference?
<Lathiat> dilinger: yeh sucks huh :(
<daniels> whiprush: akademy?
<daniels> heh
<whiprush> that one dude had it out for you.
* Amaranth wants this video
<daniels> i think that was martin konold
<whiprush> yeah, iirc.
<Amaranth> http://ktown.kde.org/akademy/Daniel_Stone_Freedesktop_video.ogg <--this?
<whiprush> the look on the other kde guy's faces were awesome.
<Lathiat> its a shame LCA didnt expand when they could
<Lathiat> that said if it got much bigger, i think itd start t suck
<whiprush> they had that "oh man come on, give the kid some slack" look on their faces.
<daniels> Amaranth: yeah, that
<Amaranth> daniels: good, i already have it half done :P
<Lathiat> first thing i see in that vide is "X bling" :)
<Lathiat> man we need faster cheaper internet in australia
<Lathiat> someone i know in canada pays half the money i do for an ulmited like 400K/s net connection, i get 28GB of 50K/s for double the price!
<jdub> Lathiat: lca could expand any year, quite easily, but yes, that's precisely why it doesn't. :)
<whiprush> my only exposure to linux conferences has been LWE. And there was an obvious divide between the corporate stuff and the normal people.
<whiprush> It was almost like they had 2 seperate shows in one building.
<Lathiat> LCA is very non corporate
<jdub> yeah, and lwe is a trade show
<whiprush> I was so excited just to be there that I didn't care.
<lu|away> LWE is the suxxors compared to, well, basically any other linux conf I've ever been to
<lu|away> the energy level is high because of the big crowd
<lu|away> and you get lots of projects under one roof
<lu|away> but otherwise it doesn't have many redeeming features
<whiprush> I did get to fanboi 90% of planet gnome though.
<whiprush> + clee
<lu|away> hehe
<lu|away> you get 99% at guadec ;)
<whiprush> yeah.
<Lathiat> can't be as bad as my fanboying of linus, poor guy :)
<whiprush> gotta make a guadec
* Lathiat would love to goto guadec but the flights are just far t expensive
* lu|away wonders if he can still get tickets tonight to guadec
<whiprush> after udu all the only people left to fanboi for me are linus and asa. Then I can act normal.
<Lathiat> whiprush: :)
<Lathiat> i wish i could goto UDU as well, hah
<Lathiat> be at linuconfau but
<whiprush> luis is very fanboiable. I got to man the gnome booth when he went to lunch.
<lu|away> haha
<lu|away> we had a good time
<Lathiat> haha
<lu|away> glad to have met you, definitely
<whiprush> likewise.
<Lathiat> ive gotten over my fanboyism
<Lathiat> .. i think :)
<Lathiat> what i love about the free software community, most of the guys rock
<whiprush> it's a good kind of worn out. 
<Lathiat> every person i've ever bet bar one is really cool
<whiprush> I mean, I'm a gnome fanatic, but even after one day, I was like "man, I don't think I could do this everyday."
<Lathiat> and that one just seems to have it in for me for some reasona nd is otherwise ok
<whiprush> google's post-LWE party was excellent, it was all community based.
<whiprush> that was worth the trip alone.
<whiprush> the debian gents were really ubuntu-friendly.
<Lathiat> i just love the atmosphere with all the hackers etc, its great
<whiprush> yeah
<Lathiat> ah ubuntu-artwork update
<Lathiat> i dont know that i want to upgrade :)
<fabbione> smurfix: ping?
<fabbione> smurfix: i solved the buildd problem. the issue shows up due to the LANG= mismatching
<fabbione> smurfix: the buildd host was on en_DK that is a locale not installed in the buildd chroot
<fabbione> as you can see from the logs
<fabbione> that leads to the FTBFS
<jdub> far out
<fabbione> imho it should still be possible to build console-data even in that situation
<jdub> the nautilus change is going to be such a joke
<jdub> "Another issue: now that spatial-mode is more browser-like, you end up
<jdub> with windows that jump around rather strangely. IMHO, this feels buggy,
<jdub> even if it is intentional. Maybe a better solution would be to keep the
<jdub> same size and position as the parent window.
<jdub> "
<jdub> 
<jdub> HOORAY!
* jdub borrows a hulk smash from daniels 
<fabbione> ehehe
<whiprush> it is rather late to be making that wide a change imo.
<Lathiat> yeh same
<jdub> it's not really a huge change in itself
<Lathiat> any other issue aside, a few days out from release is thw worst time to make a change like that 
<fabbione> there we go
<Lathiat> because its very user visible and affects interaction alot
<jdub> yep
<whiprush> I use middle click quite alot, and this change really threw me off for a while.
<jdub> i use shift-double
<Lathiat> i only just learnt middle-click/shift-double the other day
<Lathiat> the other thing is that backspace's behavior isnt changed which is kind of redundant :)
<whiprush> the one problem with spatial is that you need to take time to "set it up" with the window memory.
<whiprush> that throws off alot of people.
<Lathiat> s/redundant/inconsistent
* Lathiat bashes his brain
<jdub> Lathiat: nor is shift-context-Open
<whiprush> so for the first 10 minutes on a new install it seems like windows just randomly show up in places.
<jdub> there are a bunch of side-effects like that
<jdub> i am hungry
<jdub> pia is playing 'paper mario'
<jdub> and has been most of the day
<jdub> even tickling isn't working
<Lathiat> paper mario?
<jdub> it's pretty disturbing
<jdub> Lathiat: whackass gimmick to sell yet-another-mario-gamecube-game
<jdub> (gamecube is my housemate's)
<Lathiat> ah
<fabbione> mdz: #7078, i get even another behaviour on my desktop
<fabbione> select(17, [16] , NULL, NULL, {0, 0})    = 0 (Timeout)
<fabbione> interesting
<doko> good morning
<zyga> morning :)
<zerokarmaleft> morning
<zerokarmaleft> does nvidia-kernel-common in the hoary repositories need to be updated from 1.6629 to 1.0.7167?  nvidia-kernel-common's version doesn't match nvidia-glx and nvidia-kernel-source...
<fabbione> zerokarmaleft: mostlikely yes
<fabbione> you need to update the entire nvidia* + linux-restricted-modules
<Mithrandir> fabbione: another goal for breezy: amd64 xen debs.
<zyga> xen?
<fabbione> Mithrandir: i need to get xen working on i386 first :)
<Mithrandir> zyga: virtual machine stuff.
<zyga> ubuntu will ship xen?
<Mithrandir> fabbione: you have six months. :P
<fabbione> Mithrandir: + x86_64 is still a port in progress
<zyga> Mithrandir: I know what it is - that's a good thing 
<zerokarmaleft> i'm compiling the nvidia kernel module with a custom kernel
<Mithrandir> fabbione: intel just released x86_64 patches.
<Mithrandir> as of yesterday.
<fabbione> Mithrandir: ah ok
<smurfix> fabbione: Hmm, true, but debconf getting confused about its frontend just because $LANG is wrong isn't sporting
<fabbione> Mithrandir: cool
<zerokarmaleft> and the build bails out b/c of the version mismatch between nvidia-kernel-source and nvidia-kernel-common
<fabbione> smurfix: i did test one change at a time. first the debconf (still failure)
<Mithrandir> fabbione: so they probably need some work, and they've just been submitted to $maintainer, but that means the ball is rolling
<fabbione> smurfix: and later the LANG
<fabbione> Mithrandir: right
<fabbione> zerokarmaleft: if you think something is doomed, please file a bug on bugzilla. component: linux-restricted-modules with all the details of what you are trying to do
<smurfix> fabbione: Hmm, what was your $LANG set to when you did the debconf thing?
<fabbione> smurfix: LANG=en_DK
<fabbione> from the host system
<zerokarmaleft> fabbione, sure thing...i've been scouring bugzilla to see if something similar was already posted
<fabbione> zerokarmaleft: but add all the info as possible, like errors and so on.
<fabbione> mdz: for what i can see here it's not gamin the problem, but nautilus
<fabbione> mdz: i am going to add info to the bug anyway
<fabbione> and i can reproduce it on my lappy in one shot
<smurfix> fabbione: strange. If I had too much free time I'd look further into that :-/
<fabbione> smurfix: that's ok. we can look at it for breezy
<fabbione> it's not mission critical
<smurfix> fabbione: true
<zerokarmaleft> fabbione, actually it seems to be working fine despite the version mismatch...dpkg was the only thing that complained, so it registers as a broken package 
<syn-ack> Man, this was mad nice, installing Gentoo from a GUI
<doko> mdz, Kamion: I assume an upload to fix the typo in the control file for #8510 is allowed?
<froud> ogra: you awake
<zyga> syn-ack: gentoo has a gui?
<froud> anyone know, is Ubuntu Device Database now part of the default install
<syn-ack> zyga: no, Im installing through Ubuntu. Sorry. this was obviously the wrong window. heh
<zyga> syn-ack: too bad ;)
* froud looks around the room for reviewers
<froud> The document Ubuntu Device Database is in svn @ https://docteam.ubuntu.com/repos/branches/froud/gnome/ubuntu-device-database
<froud> if anyone is interested to edit/contribute, go for it
<froud> for easy reading a HTML is at http://www.inwords.co.za/ubuntu/device-database/ubuntu-device-database.html
<mdz> doko: yes
<fabbione> mdz: it is more or less what i expected
<doko> mdz: the only build deps for main on g++-3.4 are amd64 only: the mozilla browsers (including mzilla, firefox, epiphany), thunderbird and enigmail. rebuilt these (except enigmail) due to an unrelated FTBFS), they are still working. the same fix is in the current Debian packages and applied upstream. From my point of view it looks safe to update.
<fabbione> mdz: if i change from dnotify to inotify (= less gamin work load) it takes much longer to reproduce the bug
<fabbione> mdz: even on the slowest machine
<mdz> doko: ok, thanks for testing
<dholbach> morning
<mdz> dholbach: morning
<dholbach> mdz: how are you?
<dholbach> everybody saw koke's nice patch to nautilus? http://koke.amedias.org/2005/04/02/spatial-mess-prevention/ ? looks like the better solution to me...
<jdub> yo dholbach 
<dholbach> hey jdub 
<mdz> dholbach: tired
<dholbach> mdz: i can imagine...
<dholbach> mdz: going to bed is no option yet?
<mdz> it wil be, shortrly
<mdz> shortly
<dholbach> i'm supposed to be helping a friend move... but he didn't tell me the adress yet...
<daniels> mmm, bed
<dholbach> so i have some more time for reviewing apt-get.org
<daniels> i'm exhausted
<mdz> that means you are removed from your obligation
<dholbach> mdz: until he tells me :-)
<fabbione> mdz: i am digging more and more into gamin and i don't like what i see.. at all
<SteveA> i want to produce a ppp package that includes my own patch as well as the debian and ubuntu ones.  i've prepared the patch so that it looks like the others in debian/patches/ of what i get from apt-get source ppp.
<SteveA> do i need to do anything special to get this patch included when i build the binary package?
<zyga> anyone uses ndiswrapper around here?
<Mithrandir> SteveA: if ppp uses dpatch, just put it in debian/patches and it should be applied
<dholbach> SteveA: when you edit debian/patches/00list (if it's in there)
<zerokarmaleft> zyga, i have before without problems
<fabbione> ARGH
<fabbione> mdz: gamin all of sudden decideds to stop monitoring the entire ~$USER
* fabbione starts to understand better what is going on
<zyga> zerokarmaleft: what was your wifi card?
<SteveA> dholbach, Mithrandir: there's no 00list in debian/patches.  i guess it must use dpatch.
* zyga is away
<dholbach> SteveA: is it in the build-depends-list?
<SteveA> dholbach: no
<SteveA> well, debhelper is.  is dpatch part of debhelper?
<dholbach> nope
<fabbione> SteveA: no
<dholbach> is there debian/patches ?
<SteveA> sure, debian/patches contains 31 files
<SteveA> nine of the start with NN_
<dholbach> then it uses another patch system
<SteveA> where do i start looking to work out how this stuff works?
<SteveA> debian/rules ?
<dholbach> yes
<zerokarmaleft> zyga, broadcom mmm i don't recall the model number...it was a pci linksys 802.11g
<SteveA> dholbach: okay, got it.  there's a script debian/scripts/lib that is called by debian/sys-build.mk to do the patching.  it uses all the files in debian/patches/ that don't start with chk-
<dholbach> SteveA: ahh, cdbs then
<thom> no, that's DBS
<dholbach> ah ok
<SteveA> the reason i'm buliding a patched ppp package is that i want to try out a sony-ericsson pcmcia gprs+edge card.  it works just fine, detected as a serial device.  however, its pppd always sets the server addr as 127.0.0.2.
<SteveA> windows pppd doesn't care.  linux pppd cares a lot.  sony-ericsson doesn't care.
<thom> Kamion: when you wake up, a friend just did a test install on a machine with a badly skewed hardware clock, and got all sorts of evil messages; would it be possible to send the clock to the date of the iso build or similar if we detect that the clock is badly out of whack? (not for hoary, natch)
<fabbione> hey thom
<fabbione> thom: do you have the power to sync planet.u.c ?
<dholbach> fabbione: jdub should have
<thom> fabbione: it's cronned
<fabbione> thom: jdub added my feed, but afaik either you or elmo needs to do some baz update
<thom> oh, right
<thom> meh
<thom> wait for elmo, i'm off out in a minute
<fabbione> thom: ok.. last question.. how do i get a blog to make a new line? just plain html in it?
<fabbione> or anybody else...
<fabbione> thom: thanks anyway :) have fun dude
<fabbione> dholbach: dude.. help me a sec :)
<thom> fabbione: plain html
<fabbione> thom: thanks
<trukulo> fabbione, pyblosxom ?
<fabbione> trukulo: yes
<trukulo> then as thom said, plain html, it's better if you just use paragraphs instead break lines
<fabbione> trukulo: yeps.. thanks i was told
<trukulo> i have one question: in recent studies, daniel stone has developed a new, faster boot process, that is avalaible in hoary. But my question is, if i just upgrade from warty, not fresh install, did i enjoy this faster boot too, or not?
<trukulo> because i think my boot is slower than in warty
<trukulo> or at least, sure that sid is much more faster than hoary
<trukulo> in my computer, of course
<Mitario> mornin'
<trukulo> morning Mitario 
<trukulo> daniels, you there?
<koke> jdub: would it be possible for me to be in planet ubuntu??
<jdub> koke: sure, mail me your rss url
<jdub> koke: if you have a hackergotchi, send an url to it, too
<koke> jdub: mailed :)
<toresbe> hey guys
<toresbe> how do I crosscompile to another arch from my ubuntu box?
<trukulo> jdub, can i be in planet ubuntu, even if i don't speak in english and in my weblog i only tell fun stories and jokes
<trukulo> ?
<trukulo> like mako
<trukulo> lol
<Mitario> who's the webmaster for ubuntu btw?
<jdub> Mitario: no one person is responsible for content/design/webmastership, really.
<jdub> Mitario: henrik is working on the new design
<Mitario> jdub, ah ok, because my wiki login seems to be broken
<jdub> trukulo: not sure our audience would appreciate :)
<trukulo> jdub, well, art is not always for mass public ;) so i agree with you
<seb128> hi
<trukulo> hi seb
<jdub> Mitario: hrm
<Mitario> hi seb128 
<jdub> yo seb
<Mitario> jdub, i did do a password reset, came to the password reset page, filled in my launchpad login on the http auth dialog and it said my password had been reset
<ogra> morning
<Mitario> i try to login, still same error
<Mitario> and i had some really cool page about updatemanager to add ;-)
<Mitario> brb, shower
<fabbione> mdz: i found the bug in gamin!
<fabbione> now let's isolate it even more
<ogra> yay fabbione 
<dholbach> go fabbione! go!
<Burgundavia> yay fabbione
<koke> elmo: do I already have my key in the ring?
<fabbione> seb128: 7078. i found the cause of the problem
<seb128> fabbione: oh ?
<fabbione> seb128: dnotify backend is broken
<seb128> oh
<fabbione> read my last 2/3 posts
<seb128> that's not the cause of the problem, I could have said that before
<seb128> turning off dnotify is a ugly workaround
<fabbione> seb128: it is. because polling more works fine
<fabbione> there must be a stupid case in the dnotify backend for which it jumps one dir too much up
<koke> seb128: what do you think about the nautilus patch??
<fabbione> therefor removing the entire $HOME from the tree
<seb128> fabbione: nice. BTW your comments should probably go on the upstream bug
<fabbione> seb128: feel free to copy/paste them. i don't have an account on gnome bugzilla
<seb128> k
<fabbione> i wonder.. what could be
<fabbione> we need to add more debugging output to that piece of code
<fabbione> seb128: is there anyway i can gdb the gam_server ?
<fabbione> or ask nautilus to use another gam_server instead of the default one?
* fabbione -> food
<dholbach> see you later
<seb128> fabbione: http://www.gnome.org/~veillard/gamin/
<seb128> fabbione: there is a page with the explanations to do that
<fabbione> seb128: yeah i read that page and that's how i could see gamin stop monitoring $HOME 
<fabbione> well i guess we need to either add a lot of GAM_DEBUG statements or find a way to dump more info
<fabbione> seb128: i got it to crash once 
<fabbione> but it is for sure a race condition
<seb128> that will be funny to debug :/
<fabbione> running it under gdb with one monitored dir, is not enough to reproduce the behaviour
<fabbione> seb128: bah.. it's pretty simple
<fabbione> we need to add a GAM_DEBUG for each line of the gam_server :)
<fabbione> a script could almost do that
<fabbione> but i need to take at least half day free today
<fabbione> i will be back online later today and all tomorrow
<seb128> k, thanks for the work on that
<fabbione> no problem dude
<fabbione> if you can manage to give me a GAM_DEBUG orgy on the server code, i will test it later
<fabbione> reproducing the bug it's very simple here
<seb128> k
<fabbione> cya around
<zenwhen> so sabdfl is actually Mark Shuttleworth?
<tseng> yes, actually.
<tseng> you may have seen his sly mug on your screen yesterday
<zenwhen> yeah
<Lathiat> eh yeh that was a good laugh :)
<zenwhen> just did.
<zenwhen> Its pretty awesome that he is so closely involved with the project and not just a money fountain.
<tseng> yes.
<Lathiat> indeed
<sjmorgan> is there any way to compile a specific part of a package such as kdebase? i want to compile konqueror with debugging symbols but without recompiling all the other stuff that comes with kdebase
<Robot101> not very straightforward unfortunately
<Robot101> take it up with KDE :P
<sjmorgan> urgh i didn't think it would be
<dholbach> re
<tseng> hi daniel
<dholbach> hey brandon, how are you?
<tseng> good, thanks
<zenwhen> is there a command to apt-get a specific version of a deb in the repos?
<Mithrandir> apt-get install package=version
<Mithrandir> iirc
<zul> morning
<dholbach> hey zul
<zul> hey dholbach 
<zenwhen> I really wish ubuntu-desktop didn't depend on gnome-games :(
<zenwhen> But I understand why it needs to.
<skyrider> Hi guys. Maybe this channel is not the best place for my question but we should solve this problem ASAP.
<skyrider> Some people from Russia wants to create official Ubuntu mirror in that country but they cant contact Ubuntu mirrors admins because mirrors@canonical.com doen't work:
<skyrider> elivery to the following recipient failed permanently:
<skyrider>     mirrors@canonical.com
<skyrider> Technical details of permanent failure:
<skyrider> PERM_FAILURE: SMTP Error (state 10): 550 <mirrors@canonical.com>: Recipient address rejected: User unknown in virtual alias table
<jani> skyrider maybe mirrors@ubuntu.com
<liran> does ubuntu will be also DVD?
<Mitario> is there anyone who can remove my wiki account?
<skyrider> jani: Maybe you are right, but e-mail on this page http://www.ubuntulinux.org/wiki/Archive definitly should be fixed.
<Robot101> liran: why? it fits on a CD. :)
<liran> i prefer a DVD
<Robot101> lol
<zenwhen> perhaps he wants a simple installation of both kde and gnome
<Robot101> he can download both CDs then :)
<zenwhen> but there is a dvd image
<zenwhen> I think his question was whether or not it will ship
<trulux> fabbione: ping!
<trulux> :)
<trulux> fabbione: I've been looking at the different revisions of the 2.6.10 images, and networking security hooks are still not enabled, is it planned for Breezy? It was right in Warty's kernels but now, it's not and I need to recompile my kernel just to have that enabled :(
<robertj> ooh sad, orinoco hardware lock problem still isn't fixed :(
<robertj> is this a known issue?
<zenwhen> My orinoco gold clasic works perfectly
<robertj> zen: my laptop used to have this problem when resuming from suspend
<pitti> Hi
<zul> hey pitti how is it going?
<pitti> great
<pitti> did a biking tour with my gf today
<zul> cool
<pitti> it really starts to get spring here :)
<zul> not here it suppose to snow today
<zenwhen> it is cold and rainy here
* zyga is back
<zyga> zerokarmaleft: ping
<zerokarmaleft> zyga, pong
<zyga> zerokarmaleft: my lspci says Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
<zyga> zerokarmaleft: windows driver loads okay (the one I've got with the card)
<zyga> zerokarmaleft: but nothing works really :/
<zyga> zerokarmaleft: maybe you could send me your driver if it is not a problem?
<pitti> Hi Astharot 
<Astharot> hi
<zerokarmaleft> zyga, i don't have it installed anymore since my router is right next to my box
<zyga> zerokarmaleft: too bad
<zerokarmaleft> zyga, but i think the drivers from linksys' website did the job
<zyga> zerokarmaleft: thanks, I'll check them out
<zerokarmaleft> brb
<zyga> I would have bought a linux supported card but this was a very unfortunate gift :)
* zyga notices big penguin logo on linsys' site and gets a warm fuzzy feeling :-)
<zerokarmaleft> i've got the same wireless chip as you, except revision 02
<zerokarmaleft> i think there are significant differences b/w rev 02 and rev 03, iirc
<zyga> zerokarmaleft: I'm going to try one of the drivers now
<zyga> zerokarmaleft: the first driver doesn't work
<zyga> last time both driver and hardware were 'okay'
<zyga> this time the card was not even detected
<zyga> well too bad ;] 
<seb128> Kamion: have you planned to update the po files on p.u.c for the installer ?
<zyga> zerokarmaleft: great, the card works :-)) kudos to you
<pitti> Hi ogra 
<ogra> hi pittq
<ogra> s/q/i
<zenwhen> found a good price on a huge lcd
* Treenaks misses calendar-april :P
<zyga> BTW: where is the new calendar?
<tuhl> why is ubunti not using ALSA for sound support?
<sabdfl> tuhl: it does
<sabdfl> tuhl: it uses ALSA for the low-level drivers, then apps are generally configured to use the OSS-compat interface that ALSA provides
<sabdfl> and under Gnome, apps should use ESD
<sabdfl> ESD -> OSS -> AlSA
<tuhl> sabdfl: the macromedia flsh plugin does not working with sound
<sabdfl> tuhl: can that be configured to use ESD?
<tuhl> I dOn#t see any sound config possibility
<crimsun> tuhl: that's because the flash plugin has a brain-dead dependency on a non-existent libesd.so.1
<tuhl> crimsun: ok 
<ogra> crimsun, so it uses esd normally ?
<tuhl> crimsun: any possibility to fix it?
<crimsun> tuhl: it has been discussed before, but I don't know whether there is a viable solution.  There is a workaround: as long as libesd0 is installed, simply ln -sf /usr/lib/libesd.so.0 /usr/lib/libesd.so.1  .  What an ugly hack.
<crimsun> ogra: it should work, but there's that issue above...
<ogra> yup, i saw it, but wasnt sure if it uses esd or /dev/dsp directly, thanks :)
<tuhl> crimsun: it is working now
<zenwhen> Hey. I was wondering why you guys don;t roll out a final update to synaptic in warty to include the hoary version, allowing people to just pop in the hoary install disk and do an upgrade from it when prompted.
<pitti> zenwhen: how you want to force all users to actually install it?
<pitti> zenwhen: okay, it could be made optional, but update_manager cannot be installed automatically
<pitti> zenwhen: after upgrade, the user has to start it explicitly (see Hoary upgrade notes)
<Jeeves_> Hi there, everyone.
<fabbione> trulux: pong
<fabbione> yo
<trulux> fabbione: hey, just rebuilding the kernel
<trulux> fabbione: btw, I will fill a bug for inclusion of http://pearls.tuxedo-es.org/patches/ssp-propolice/propolice_1.2-2.6.11-rc5.patch
<fabbione> trulux: enanchment -> breezy
<trulux> fabbione: right
<trulux> fabbione: is there any breezy goals page?
<fabbione> trulux: see the UDU bof page. there is a big kernel section. But do not edit the page, since they are frozen.
<trulux> ok
<trulux> fabbione: breezy won't suffer any unexpected issue with my patch, I have tested it well, and also I'm testing it here, everyday
<trulux> no performance hit, as we are talking on new syscalls
<fabbione> trulux: i will still need to check what it is
<Mowa> http://www.resellerads.com
* mode/#ubuntu-devel [+o thom]  by ChanServ
<fabbione> hey thom
* mode/#ubuntu-devel [+b *!wa@85.99.215.163]  by thom
* mode/#ubuntu-devel [-o thom]  by thom
<thom> ello
<fabbione> thom: if you have time, can you do that baz update for planet?
<fabbione> i think elmo is still hiding somewhere :)
<thom> i'm just about to go out again
<fabbione> thom: pfft
<thom> it's not exactly urgent, hey? ;-)
<fabbione> nahh
<fabbione> don't worry
<fabbione> i will still love you
<zyga> hmm
<zyga> what is the motivation of using three layers for sound support
<fabbione> zyga: 3?
<zyga> sabdfl mentioned that esd is on top of oss emulation of alsa
<fabbione> esd -> alsa (kernel) -> hw
<fabbione> yeah
<fabbione> that's for compatibility
<fabbione> but the OSS layer is transparent
<zyga> ah
<zyga> I was wondering about latency stuff and such ;] 
<fabbione> probably you can see it like this:
<fabbione> esd -> oss (alsa emulation) -> kernel -> hw
<fabbione> esd -> real alsa /
<zyga> what is the advantage of using esd?
<zyga> kde uses arts and gnome uses esd - all this doesn't play well in my experience
<fabbione> zyga: because not all hw allows more than one application accessing the hw
<zyga> I'm asking to understand
<fabbione> so if for instance you run xmms and it locks the card
<zyga> fabbione: so esd is like a portable mixer
<fabbione> you won't be able to listen to your incoming mail beep
<fabbione> zyga: kinda.. yes
<fabbione> + it provides a standard interface towards applications
<zyga> bu arts blocks the card in the same way that (possibly) esd would -- they both talk to alsa?
<zyga> s/bu/but/
<fabbione> so if for example a new sound thing will replace alsa
<fabbione> it will be enough to adapt esd
<zyga> I see
<fabbione> instead of 0239209208381374982634 apps
<fabbione> arts is similar to esd
<zyga> we just port one
<fabbione> exactly
<zyga> could arts use esd?
<fabbione> i dunno much about arts, but i think it is a replacement for esd
<Mithrandir> I think there's a backend for it
<zyga> so that k3b will still be able to say 'whoosh' while esd-backed xmms is playing?
<fabbione> (kinda gnome <-> kde thingy)
<zyga> pretty much but gnome and kde play well remarkably well
<zyga> but their sound backends dont
<zyga> (in my experience)
<zyga> hmm s/well/together/
<Mithrandir> zyga: you'd probably get horrible latencies, though, so unsuitable for multimedia but enough for boinks and beeps.
<ogra> sounds like its time for somebody to start a new f.d.o project ;)
<zyga> f.d.o?
<ogra> freedesktop.org
<Mithrandir> ogra: yet-another-sound-server?
<zyga> Mithrandir: so it's not possible to make one of the sound servers a really thin client (something like an api wrapper)
<ogra> you said they play well with each other except the sound :)
<zyga> so that only one real server talks to alsa
<Mithrandir> zyga: you could do it, but I imagine you'd have a fair bit of overhead.
<ogra> Mithrandir, nope, but a standarized interface
<ogra> the app backend ....
<trulux> fabbione: the patch? provides kernel-level helpers for SSP/ProPolice
* zyga doesn't know anything about esd or arts (or alsa even) api :/
<trulux> fabbione: kernel-level handling of process termination and stack smashing report
<zyga> Mithrandir: overhead from copying memory block from one place to another?
<Mithrandir> zyga: just having esd there gives you a fair bit of overhead.
<fabbione> trulux: i still want to see the code :)
<fabbione> trulux: and how intrusive it is
<zyga> Mithrandir: I heard that Jack is great for its low latency
<Mithrandir> zyga: with the kernel patches, so have I heard.
<zyga> the sad thing is that instead of having to port one app to the new alsa
<zyga> everyone ports each app to all available servers :/
<zyga> and they still bite each other 
<ggi> Does the current esd setup use ALSA's OSS emulation instead of ALSA itself?
<trulux> fabbione: I pasted the url to it
<trulux> fabbione: http://pearls.tuxedo-es.org/patches/ssp-propolice/propolice_1.2-2.6.11-rc5.patch
<fabbione> trulux: attach it to the bug please
<trulux> fabbione: OK
<trulux> :)
<trulux> it applies to 2.6.10 with no fuzz
<fabbione> mdz: ping?
<trulux> fabbione: what package? there's no linux-image, same as the bug on LSM I reported some time ago
<fabbione> trulux: use package linux
<fabbione> open a new bug
<trulux> fabbione: danke sehr
<fabbione> like we discussed 5 minutes ago :)
* fabbione -> dinner
<jani> do you think http://sourcecontrol.net/~jmonoses/dch.diff would be ok as a devscripts ubuntu1 patch? it automatically adds ubuntu1 to the revision when necessary if the --ubuntu flag is passed to dch
<SeanQ> Hi.
<SeanQ> I know we've hit a feature freeze and an "every-freeze" with Hoary, but can you make it potentially possible to actually add a network in 'network-admin'
<thom> jani: i take it you mean ubuntuN
<jani> well yes
<jani> it increments if there's already ubuntu
<jani> or appends ubuntu if last revision is debian
<jani> thom does firefox have lintian warnings?
<thom> jani: only the "wrong number for nmu" caused by ubuntu numbering afaicr
<jani> I am building NVU (from the same sources) and the maintainer says the warning it spits are the same in firefox
<jani> oh so nothing like image-file-in-usr-lib ?lots of them
<thom> (it's been a long time since i tried
<mako> tseng: dude, i did process your key.. weeks ago
<blueyed> about the installer: if I choose "leave network unconfigured" (due to lack of pppoesetup) I'll have no online repositories with the sources...
<blueyed> ..and I must be/get aware of pppoeconf by google.
<trulux> fabbione: https://bugzilla.ubuntu.com/show_bug.cgi?id=8551
<trulux> fabbione: going to fix libssp and then we are done with it
<dholbach> hey sivan!
<sivang> hey dholbach , what's up?
<zyga> pope is dead :-(
<LinuxJones> Hi guys can someone come to #ubuntu and kick Neas` please he's using tor and trying to dcc hack folks 
<dhonn> Nautilus has a back space bug
<LinuxJones> Any of the Canonical guys here atm ?
<Goshawk> please someone ban Neas` from #ubuntu
<weiner5> when instlling ubuntu do i have to prep my HD into /, /boot and swap partitions?
<dhonn> gnome-terminal has a backspace bug too.  When you hold backspace for a few seconds the terminal window starts to flicker
<zyga> dhonn: are you using transparent background?
<dhonn> nope
<dhonn> default
<zyga> dhonn: strange - I cannot replicate that issue here
<zyga> which version
<dholbach> weiner5: you better ask on #ubuntu
<dhonn> now I cant replicate it
<dhonn> nevermind then
<dhonn> it was glitching a few minutes ago. im going to try to replicate it
<dhonn> did you guys check out the nautilus backspace bug
<dhonn> im guessing the behavior is suppose to close the current foreground window then go up one folder
<dhonn> brb
<dhonn> ok back
<tseng> mako: cool thanks
<dhonn> who maintains ubuntu-artwork?
<dholbach> apt-cache show <package>
<dhonn> jdub around?
<dhonn> im use to rpm -qi <package>
<mdz> dhonn: that problem is already reported in bugzilla
<dhonn> i reported it
<dhonn> its a bug i hope
<mxpxpod> is there a network install cd?
<CarlK> yes.
<CarlK> kernel-headers-2.6-386: Depends: kernel-headers-2.6.8-2-386 but it is not installable
<CarlK> this is from yesterdays' hoary
<dilinger> CarlK: i think what you want is linux-headers-386.  kernel-headers* is debian's kernel headers
<dholbach> mxpxpod: hey, how are the coaster packages? :-)
<CarlK> thanks
<trulux> Gui/libgui.a(ws.o)(.text+0x499): In function `wsXInit':
<trulux> : undefined reference to `XF86VidModeGetModeLine'
<trulux> collect2: ld returned 1 exit status
<trulux> when compiling mplayer
<dhonn> Hey guys is it possible to include the older nvidia drivers in the apt repositories?  Later versions after 1.0-6111 crashes when the LCD is initialized.   All drivers work fine with a CRT though.
<skyrider> Hi guys. Few days ago some Russian programmer had found a critical security related bug in Mozilla Firefox. This bug could lead to exposure user data. Please see https://bugzilla.mozilla.org/show_bug.cgi?id=288688 (and its DUPs) for more info. Are you aware of that bug? When you plan to release new updated package fpr firefox? (fix is already in mozilla CVS).
<mdz> skyrider: you can send reports of security vulnerabilities to security@ubuntu.com, or report them to bugzilla.ubuntu.com
<skyrider> mdz: ok.
<mdz> skyrider: the bug is already in bugzilla in fact
<mdz> or will be shortly
<skyrider> mdz: oh, sorry for false alert :(
<mxpxpod> thom: ping
<dhonn> there is a problem with /etc/rcS.d/S40networking, where it hangs if theres no network connection,  CTRL+c allows you to bypass the hang but "ifup lo" wont initialize and you will have to do it yourself to get some applications to work
<dhonn> some of the applictions in Applications->System Tools should probably go under System->Admistration
<zyga> the pope is dead :-(
#ubuntu-devel 2005-04-14
<calc> mdz: awake?
<trulux> hey tritium 
<dholbach> hey tritium 
<tritium> hey trulux
<trulux> tritium: howya!?
<tritium> hi dholbach 
<trulux> tritium: http://www.tuxedo-es.org/blog/ finally updated!
<trulux> dholbach: hi :)
<tritium> nice, trulux 
<trulux> tritium: a friend bought R.Love's Linux Kernel Development 2nd edition for me
<trulux> ;)
<tritium> that's a nice friend, trulux 
<trulux> tritium: yeah, he is around your age, dunno, maybe a bit younger
<trulux> tritium: he managed me to get space at Telefonica R&D data center for my testing box
<trulux> ;)
<trulux> and access to some sparc machines
<tritium> cool, trulux
<dholbach> good night everybody!
<tseng> bye dholbach 
<dholbach> bye tseng 
<jdub> ahr
<ogra> ?
<tseng> jdub++
<jdub> hrm, somehow i was not collecting mail overnight
<ogra> ouch
<jdub> reading message jdub@mail.waugh.id.au:6 of 446 (5354 octets) .....
<jdub> d'oh
<tseng> :(
<ogra> hahaha, only 446 ?
* ogra loves the day after a long weekend without pc .... there are always four digits.....
<HiddenWolf> Rythmbox is giving me an error "Alsa device DEFAULT is already in use by another program" Does that ring any bells?
<trulux> anyone knows the trailer/teaser of star wars episode 3? :)
<jdub> mdz and anyone interested in usplash: http://www.kerneltraffic.org/kernel-traffic/latest.html#2
<tsume> is there a gnome 2.10 in hoary?
* trulux adds Fix config. syntrax in Linux-PAM 0.78 packages to TODO list
<mpt> tsume: yes
<trulux> tsume: yes
<trulux> :)
<tsume> I'm blind then, I think I'm running 2.8
* mpt kicks whoever thought it would be a good idea to make the "Invite" and "Remove" buttons in Gaim so fricking huge
<ogra> heh
<HiddenWolf> trulux: yup. OT tho
<HiddenWolf> Did anything change with Alsa in the last few days?
<tsume> mpt: whatever the trouble is, its alindeman's fault ;)
<dhonn> I noticed that on all distributions that firefox eats up on my computer 50% cpu when downloading a file.  The download dialog animation is at a very high refresh rate is what is causing it.  
<dhonn> perhaps we can tone down the refresh rate?
<ogra> tsume, System->about gnome
* tsume hmms
<tsume> I'm running 2.10, I don't know where I recieved the image of running 2.8 :)
<ogra> :)
<dhonn> there is a bug in the Help Documentation mentioning that Gnome is version 2.6
<mpt> tsume: Why alindeman? (doesn't seem to be related to gaim, if sf.net is any guide)
<HiddenWolf> dhonn: file a bug. :)
<tsume> mpt: Hes a netOp, and dmwaters says every trouble she has is alindeman's fault. Including netsplits, so dmwaters wallops everyone, and everybody msg's alindeman :)
<dhonn> i do
<ogra> tsume, and that explains the bad ui design of gaim ?
<mpt> jdub: Sorry for filing that invalid bug yesterday ... So that I don't do it again: Is there a good reason why I can't rename something in Nautilus just by clicking on its name and typing?
<tseng> alindeman is a coder on dancer ircd iirc
<mpt> oic
<HiddenWolf> ogra: no, crappy devs explain the bad design of gaim
<ogra> hehe
<HiddenWolf> imho
<tsume> ogra: yes! :)
<ogra> HiddenWolf, i dont thik they are bad....at least 80% of the app are great.....but the remaining 20% annoyances make 200% of the look and feel ;)
<jdub> mpt: that's very easily hamfisted, which leads to confusingly broken results.
<mpt> jdub: I don't remember ever hamfisting it on Windows or Mac ... What are you referring to in particular?
<mpt> You mean renaming /etc or something like that?
<HiddenWolf> ogra: true
<jdub> mpt: users misrenaming any file
<mpt> ...
<dhonn> hey jdub, i sent you a patch, @perkypants  I'm a metacity hacker, i fixed an issue with maximized window bug
<jdub> dhonn: a metacity patch? best to put those in gnome bugzilla, surely?
<dhonn> actually its for human/indubstiral
<dhonn> i sent a few patches to havoc
<dhonn> but thats for something else
<jdub> d'oh, crap -> i managed to revert back to the buggy version
<jdub> thanks
<tseng> jdub++
<dhonn> lol i noticed one time it was based on ClearLooks
<dhonn> or are you going back to ClearLooks?
<jdub> nah, sticking with the warty version for now
<dhonn> i love indubstrial lol
<dhonn> i sent a patch to havoc to allow the resizing without syncronization.  It would make window resizing seam very very fast, but visual tearing would occur
<jdub> hrm, doubt he'd accept that ;)
<jdub> might be good for low resource mode though
<dhonn> nope, he said 10 fps would be resonalble
<dhonn> right now syncronization is turned off at 1 fps
<dhonn> makes resizing very choopy
<jdub> oh right
<jdub> harsh
<dhonn> on a slow computer
<dhonn> or with firefox 
<dhonn> right now it matches macosx behavior
<dhonn> but you will notice that there is no tear in macosx when moving windows
<dhonn> metacity has tons of tear when you move a window
<HiddenWolf> wtf: "Alsa device DEFAULT is already in use by another program"
* HiddenWolf grumbles
<tseng> you already said that
<HiddenWolf> tseng: any clue what could cause it?
<dhonn> so we want tear when moving windows, but we dont want tear when resizing windows?  doesnt make much sense right now
<dhonn> man i got to go pick up my gf at work
<dhonn> later
<tseng> HiddenWolf: another app using the device.
<tseng> HiddenWolf: possibly esound
<tseng> what app is giving you that?
<tseng> you probably arent getting alot of help because, this isnt a support channel.
<HiddenWolf> Rythmbox is giving me that.
<HiddenWolf> I'm not looking for help. I want to know where and with what info to file the bug, so a dev will fix this and I can hear music. :)
<HiddenWolf> I have system sounds, but no sounds in any user app.
<jdub> HiddenWolf: at the risk of turning this into a support channel, run gstreamer-properties and ensure the output sink is set to esound
<tseng> there is no bug.
<tseng> or at least it sounds like a simple configuration issue
<HiddenWolf> All I did was restart my pc for the kernel update.
<tseng> he didnt ask about your kernel :P
<HiddenWolf> jdub: bingo
<tsume> is there a dev site for the packaging?
<tsume> and lists of current dev pacakges (done, needed, packaging)?
<thom> jdub: dude, ubuntu-artwork needs to update the homepage for hoary
<HiddenWolf> jdub: it was probably an update that overwrote my mixer settings. My line-in got muted again, etc.
<ogra> tsume, on the wiki look for MOTU, and "Developer Ressources" has links to the build logs
<tsume> ogra: you know if theres an RSS feed? :) and if theres not, can one be set up? :)
<ogra> tsume, talk to dholbach tomorrow, he has plans on rss stuff, but i dont know if he thought of build logs.... good idea
<tseng> ive been wishing for hoary-changes rss forever
<ogra> tseng, should be easy...
<whiprush> tseng: gmane has rss feeds for hoary-changes
<T-Bone> Kamion: ping?
<jdub> thom: yeah, or we need to change the home page
* jdub is going away for the day tho :|
<jdub> thom: i'll ping about this later tonight :)
<wasabi> Oh god.
<wasabi> Nice login screen
<mdz> calc: yep
<stratus> I've packaged beagle for hoary, cvs and 0.0.7, building 0.0.8.1 right now.
<stratus> cvs package is buggy and needs patching
<stratus> anyone interested?
<|QuaD-> stratus: i believe they have a 0.0.7 package, just haven't releasedit yet
<stratus> |QuaD-, it won't be on hoary but AFAIK it's a release goal for hoary+1 so i'm asking. I'm a DD and i've heard about MOTU...
<|QuaD-> stratus: talk to the ubuntu devs :)
<stratus> |QuaD-, have you read the channel name?
<|QuaD-> stratus: yeah, i meant don't talk to me :)
<|QuaD-> i hve no say :)
<|QuaD-> i just wanted to let you know there is already a package
<stratus> ok, thanks.
<|QuaD-> stratus: http://people.ubuntu.com/~jdub/hoary/
<stratus> |QuaD-, oic.
<T-Bone> ogra: around?
<T-Bone> ogra: submission id 5e9be082a06fe065366890600cfc6c15, vendor 4889 is HP i'd say ;] 
<zul> hey daniels
<tseng> whiprush: cool.
<tseng> beagle isnt going into hoary kids.
<whiprush> :(
<zul> ya think?
<tseng> i dont think, I know :P
<tseng> im not putting in a completely new mono stack with 5 days to go
<zul> well at least you admit you dont think ;)
<tseng> beagled has numerous memory leaks on mono 1.0.5
<tseng> or maybe one big one
<zul> im still trying to get use to tomboy
<dredg> tomboy++
<|QuaD-> tseng: how come?
<tseng> < tseng> im not putting in a completely new mono stack with 5 days to go
<tseng> does that not make immediate sense?
<|QuaD-> tseng: so i shouldn't expect mono 1.1.x?
<tseng> for hoary? no.
<|QuaD-> ok
<tseng> there is too much changing
<|QuaD-> thanks for the effort though :)
<tseng> i had to touch every mono package under the sun, im not comfortable pushing it anywhere without testing
<tseng> np.
<|QuaD-> now i just have to wait for breezy i guess :)
<tseng> im trying to do something that pleases upstream mono-project and debian mono, and users at the same time
<tseng> meh.
<tseng> im at my parents for the weekend, i probably wont be working on much
<|QuaD-> oh well :) 
<tseng> mako: your latest post rocks.
* mpt wonders why "Lock Screen" does nothing
<lamont> Kamion: you around?
<mxpxpod> why would my openoffice icons not be showing up in the gnome-panel menu?
<|QuaD-> mxpxpod: ask in the help channel
<mxpxpod> |QuaD-: in #ubuntu?
<|QuaD-> yeah
<SuperL4g> tseng: you around?
<tsume> okay, there something wrong with the installer on my laptop, are there any reported bugs for GRUB?
<tsume> its sticking at boot, this is a developer issue if its not installing right by default
<tsume> I can't exactly check bugzilla since I'm using chroot to the /target during install :)
<mpt> tsume: So you can do text-mode IRC but not not text-mode Web browsing? :-)
<tsume> mpt: oh.. I forgot about w3m :)
<tsume> oh wait, I forgot I have w3m even installing on the bsd server I'm ssh'ing to
<tsume> mpt: well, is there a problem with some laptops to your knowledge? (specifically toshiba?)
<mpt> "installing" as in right now?
<mpt> tsume: Well I have lots of problems with this Toshiba laptop, but that's another story
<tsume> I had ubuntu installed before with lilo, but I wish to use grub. I reformatted because fdisk messed up on calculating the correct space  and tried allocating 80G total when of course the harddrive has less when formatted
<tsume> mpt: I fixed the problems with the toshiba laptop(all of them)
<tsume> the last one is the boot manager
<tsume> the synaptic pad works great without lag ;)
<mpt> pad?
<tsume> yes
<tsume> the touchpad
<mpt> So what's a synaptic pad?
<tsume> modprobe psmouse rate=40 :)
<tsume> mpt: well I call it by what driver it needs :)
<tsume> mpt: I really want to use grub ;)
<mpt> There's only one grub bug mentioning Toshiba, and I don't think it's yours
<mpt> It's complaining that Windows 2000 doesn't boot
<tsume> mpt: I'm searching too, and I'm not seeing anything
<tsume> mpt: what does your device menu file for grub have in it?
<mpt> Oh, well I'll get back to work then
<mpt> See, I don't even know what a "device menu file" is
<mpt> I'm new here :-)
<tsume> mpt: its the file.. /boot/grub/device.something I think
* tsume thinks its not even setting up grub correctly
<SuperQ> hrm
<SuperQ> it'd be nice for a hoary maintence patch to include the 1.0.2 ipw2200 driver
<mpt> tsume: (hd0)   /dev/hda
<mpt> SuperQ: Hey, then my wireless might start working properly
<SuperQ> mpt: heh
<SuperQ> it comes with 0.19, which is much better than what warty came with
<SuperQ> but ipw2200 is under heavy development
<mpt> At the moment my laptop only gets a wireless connection in rooms where my colleagues' laptops don't, and vice versa
<SuperQ> mpt: I just grabed the kernel-source and built my own driver
<SuperQ> I still can't get WPA-PSK to work tho
<mpt> It jumped from 0.19 to 1.0.2 in six months? That's fast
<SuperQ> they were doing weekly releases 
<SuperQ> up until february
<SuperQ> when 1.0.0 came out
<SuperQ> now they're doing monthly releases
<SuperQ> 1.0.2 is supposed to fix WPA problems
<SuperQ> but I still can't get my card to associate
<fabbione> morning
<SuperQ> it can if I switch my AP into WEP mode
<schweeb> mornin fabio
<fabbione> hey schweeb 
<fabbione> mdz: ?
<bluefoxicy> well this is an interesting reason for comcast to return my e-mail:   Permanent Failure: 550_Mailbox_unavailable_or_access_denied_You_are_part_of_a_phishing_attack._Rejecting_command...
* Amaranth goes to bed
<lamont> bluefoxicy: that just means that your box got rooted. :-)
<fabbione> ok let's go back and hunt down this xen0 boot problem
<zenwhen> doing my weekly update from a daily disk
<zenwhen_> Hey is anyone around
<zenwhen_> The upgrade broke my Nvidia drivers
<zenwhen_> it says the kernl module version is wrong
<zenwhen_> is there a way bto force my nvidia-glx back to the old version?
<bluefoxicy> fabbione:  fabulous, ubunut is going to support xen?
<fabbione> zenwhen_: read ubuntu-users on how to do an upgrade or ask in #ubuntu
<bluefoxicy> fabbione:  i had gentoo on dom1 for a while, but xen doesn't like anything but vanilla apparently (won't even build with grsecurity)
<fabbione> bluefoxicy: i am evaluating it at the moment
<zenwhen_> fabbione: I am not having trouble doing an upgrade.
<zenwhen_> I am having an issue with a new package in hoary.
<bluefoxicy> fabbione:  I recommend you have fun, and then come back when Xen 3.0 is out and see if it's any better.
<zenwhen_> I cant exactly file a bug either
<zenwhen_> but thanks anyway
<fabbione> zenwhen_: a reboot is enough
<bluefoxicy> fabbione:  it's a wonderful system; however, making it work is troublesome, and it does not like non-vanilla kernels
<fabbione> bluefoxicy: yes i know thanks
<bluefoxicy> :)
<zenwhen_> fabbione: a reboot wasnt enough. Apparently the kernel module in linux restricted conflicts with nvidia-glx
<fabbione> zenwhen_: as i said before, you didn't upgrade all your system. You need to use the latest linux-restricted-modules together with the latest nvidia-glx
<zenwhen_> But I did.
<fabbione> no you didn't
<zenwhen_> Oh well.
<zenwhen_> sure did.
<fabbione> otherwise it would work
<zenwhen_> ... wow
<fabbione> since i did the packages and i use them myself on 4 out of 6 test machines
<fabbione> logout from X
<fabbione> go to console
<fabbione> rmmod ndivia
<fabbione> modprobe nvidia
<fabbione> and check the output from dmesg
<fabbione> it will tell you what version of the kernel driver you are using
<fabbione> so either the kernel module is the wrong one or you didn't upgrade nvidia-glx
<zenwhen_> the linux restricted modules for my kernel which is 2.6.10-4-686-smp are th newest
<zenwhen_> and just upgraded nvidia-glx
<zenwhen_> which caused the issue to begin with
<zenwhen> had to downgrade to 6229
<bob2`> debmirror seems quite confused
<bob2`> and keeps downloading the same satuff over and over
<gabaug> does Canonical spend a large amount of $ on bandwidth for package updates? It seems combining apt-get with BitTorrent would work great, especially considering the temporal locality of lots of users updating to the latest packages
<bob2`> a couple of people have tried integrating bt with apt
<bob2`> but no one's suceeded yet
<gabaug> bob2`: any pointers to their work/names?
<mdz> fabbione: 
<fabbione> mdz: i did some progresses on 7078. i am working on adding more debugging info to isolate what causes the problem
<mdz> fabbione: I read bugzilla, yes
<mdz> even on saturday ;-)
<fabbione> it's sunday here :)
<fabbione> btw.. the pope is dead
<mdz> yes, he was dead yesterday too
<fabbione> yesterday for you :P
<wasabi> At least we don't have to hear about Terri anymore.
<wasabi> Is that getting any out of US coverage at all?
<aj> wasabi: god yes
<calc> wasabi: now there will be years of pope is dead coverage
<wasabi> That's ok.
<wasabi> I can stand that. The fight about Terri, I couldn't stand.
<dholbach> goooooood morning!
<wasabi> , vietnam!
<dholbach> noooo wasabi that wasnt what i was going to say....
<fabbione> humpf
<fabbione> xen really doesn't like patches on top of vanilla
<froud> ogra: ping
<froud> for developer credits in the doc can anyone please tell me ogra's real name
<Mithrandir> 11:47 [OPN]  -!-  ircname  : Oliver Grawert
<froud> 10X
<Mithrandir> froud: /whois is good for finding out such stuff
<froud> Mithrandir: my whois did not return anything
<froud> probably cause I am using Konversation ;-)
<ogra> froud, morning :)
<froud> ogra: African Greetings
<froud> ogra: just about to commit finalized draft of document
<ogra> froud, such informations are in the changelog of the packages if kopete doesnt like me ;)
<trygvebw> wasn't the third ubuntu release going to be called grumpy groadhog?
<froud> ogra: not using Kopete
<ogra> oops
<froud> IRC via Konversation
<ogra> konversation indeed
<ogra> (sorry just waking up :) )
<froud> ogra: well just to let you know the doc is now at a stage where it could use your review
<froud> I will send you an email
<froud> You can add help button to the app ;-)
<ogra> yeah
<froud> the OMF with series id is also done as are the make files
<ogra> wow
<froud> ogra: so integration with scrollkeeper should work if you register it
<froud> You might want to look at the omf category though.
<ogra> i will :)
<HiddenWolf> Damn, there IS a bug somewhere with Alsa/oss
<ogra> T-None, its not hp :-P <property class="linux" subclass="cpuinfo" name="vendor_____" type="string">GenuineIntel</property>
<T-None> ogra: oh, that's it the CPU vendor then
* ogra wonders why ia64 adds this ugly subdashes to the kernels cpu information...
* T-Bone wakes up
<ogra> T-None, yup.... i'll write a correct parser for the data later in the process, currently i'm greppin through the flat file....subdashes are the last i had expected there :)
<T-Bone> ok
<ogra> but thanks, now i got a ia64 example to play with :-D
<T-Bone> ogra: btw, can i register hppa machines? :}
<ogra> T-Bone, sure, but i currently cant promise the datasheet will show anything :)
<T-Bone> lol
<T-Bone> it's likely that i'll submit a bunch of "amuzing" hardware submissions by the end of the coming week. I have half a dozen machines to setup in my data center ;] 
<ogra> yeah, go ahead :=) i'll take everything....
<T-Bone> and they are *not* regular pcs ;] 
<T-Bone> ok :)
<froud> ogra: sent
<ogra> yeah, thanks froud 
<froud> ogra: will this app move to gnome cvs
<ogra> T-Bone, would be nice to have the id's :)
<T-Bone> ogra: sure. I haven't looked much. Were is the ID stored on the local host?
<T-Bone> +h
<dholbach> hey ogra!
<ogra> froud, i doubt it, its very tied to our hal version ... probably if i sent all my hal patches upstream, but even then they are unlikely to accept the meminfo/cpuinfo patch (they already have half of this data through another way)
<ogra> and i have a problem to do a clean spec for the BIOS data that gets collected before next release...
<ogra> hi dholbach :)
<thom> ogra: 7a2c98b99d588c4ef04ccf3cf8d33ebe is also ia64, for the record :-)
<froud> ogra: ok, please feel free to make patches against the docs are just email me your comments etc.
<froud> c ya later
<T-Bone> ogra: btw, that machine has 2GB ram, ie 2048 MB. I wonder why it says 2046
<thom> T-Bone: heh, mine says 2045
<T-Bone> thom: lol, maybe that's consumable RAM. Self destructs after a given use? ;] 
<ogra> T-Bone, i read the output of cat /proc/cpuinfo, see yourself :)
<ogra> err meminfo indeed
<T-Bone> ah
<T-Bone> then you have full RAM - kernel size
<T-Bone> i suppose
<ogra> whatever meminfo offers...i have also the BIOS data (if available) to see the single ram banks....a real DB server will read that value later :)
<T-Bone> ogra: a simple workaround would be to round up the value to the nearest power of 2
<T-Bone> this is extremely visible on ia64 since ia64 kernels are *huge*
<ogra> T-Bone, i dont want to spend to much time on the server output yet, i still have some other important tasks that require to be done before release (i.e. i just switched server and client to bzipped transmission...etc), the server part is something for next month
<T-Bone> sure. that was just an idea
<ogra> T-Bone, very appreciated :)
<T-Bone> ogra: you're welcome :)
<ogra> froud ?
<ogra> hmm
<dholbach> hey seb128 
<seb128> hi
<fabbione> hey seb128 
<seb128> hi fabbione 
<dholbach> hrm... got disconnected - did anyone reply to the "FSL free enough?"-question?
<kain> I've removed (purged) every -it (my language) packages, done dpkg-reconfigure to generate an en_US locale, but gnome is still my language, what's wrong?
<kain> menu is in english
<kain> but the entries are still italian
<kain> mm... wrong xchat tab :)
<kain> sorry for that
<HiddenWolf> crimsun: thanks
<crimsun> HiddenWolf: np
<Liz> hello
<Liz> anyone awake who works with USB ports?
<crimsun> would you clarify that, please?
<Liz> a few days ago, i upgraded ..and lost all sign of USB ports in /de
<Liz> in /dev
<Liz> ive upgraded again just an hour ago, but still no usb 
<crimsun> are you running -33?
<crimsun> k
<crimsun> (reading your post to u-u now)
<Liz> any idea on where i can look to get them back?..be it taking out a file somewhere or something?.
<Liz> ahh..ok thanks
<Liz> i wasnt getting any reply in ubuntu..and froud said to try here
<Liz> to let developers know whats happening
<ogra> Liz, start here: grep USB /var/log/dmesg
<crimsun> yeah, I was about to type what ogra said
<crimsun> it's highly unlikely that the kernel is not finding any usb controller/devices
<ogra> yup
<crimsun> seems more to be an issue with pmounting/g-v-m
<ogra> except they are disabled in the BIOS
<crimsun> yeah, that would do it
<ogra> gamin probably...
<Liz> it picks up my usb there
<crimsun> heya sabdfl 
<ogra> ok
<sabdfl> hallaaauuu
<Liz> also shows up in device manager too
<dholbach> hey sabdfl 
<ogra> Liz, now look at your device manager
<ogra> hi sabdfl
<Liz> but when i cd to /dev dir, theres nothing 
<crimsun> Liz: what are you looking for in /dev, /dev/sda1 ?
<ogra> Liz, nothing like nothing, or nothing like no usb ?
<Liz> crimsun, yes..or anything sd*..and theres nothing
<Liz> ogra..my usb shows inn device manager
<ogra> ok
<crimsun> Liz: are you booting with the drive powered on and plugged in?
<dholbach> sabdfl: i'm nearly done with www.ubuntulinux.org/wiki/AptGetOrg, when pitti turns up, i'll tell him to security-review some packages and i'll need someone to look over license issues, but after that elmo will get green light from me
<Liz> crimsun, my miniusb drive?
<crimsun> Liz: yes.
<Liz> no
<crimsun> Liz: ok, so you boot, then plug in the minidrive and turn it on?
<dholbach> sabdfl: i'm particularly proud to have the privilege to invite joey hess into the MOTU crowd ;-)
<ogra> hehe
<crimsun> haha
<sabdfl> dholbach: :-)
<Liz> yes..its only a small storage device that kinda replaces floppies
<Liz> majority of uni students are using them..has more space on them
<crimsun> Liz: according to dmesg, is the storage device detected?
<crimsun> Liz: (after you plug it in)
<ogra> Liz, does this device show up in the device manager if you plug it in ?
<sabdfl> dholbach: great work on AptGetOrg
<dholbach> sabdfl: thanks :-)
<sabdfl> as for Joey, i'd recommend personalising that email somewhat :-)
<zul> yay i have my laptop working under ubuntu
<ogra> yeah, dholbach deserves a medal....(or a beer in UdU), sabdfl 
<dholbach> sabdfl: i'll advise him to take it with a grain of salt, nevermind :-)
<sabdfl> salt with his beer?
<sabdfl> ah
<ogra> heh
<Liz> crimsun..after plugged in..no
<dholbach> how perverse do you think i am? :-)
<sabdfl> so what do you guys think of the first baby steps of rosetta-for-the-distro?
<Liz> ogra, doesnt look like it..
<sabdfl> https://launchpad.ubuntu.com/distros/ubuntu/hoary/+translations
<Liz> i dont know where to look if it is
<dholbach> WOW rock
<crimsun> Liz: dmesg should report something about a mass storage device after you plug it in
<sabdfl> does google find https sites?
<dholbach> the only thing that will confuse people is "german", "german (germany)" and probably result in doubled efforts
<zul> crimsun: unless if its some weird ass usb storage device
<crimsun> zul: ah, true.
<Liz> crimsun, no, it doesnt show up there either
<Liz> i just plugged it in
<zul> Liz: what kind of device is it?
<Liz> http://www.pricerunner.co.uk/view-image?image=http%3A%2F%2Fi.pricerunner.com%2Fprod%2F207215009l%2FPretec_Super_Mini_i-Disk_Tiny_1GB_USB_20.jpg&returnURL=%2FProducts.jsp%3Fcategory%3D61%26model%3D215009
<Liz> that one
<Liz> they cal them super mini disk tiny's
<Liz> normally i plug it in..and it works
<zul> Liz: can you open up a bug on bugzilla and attach the output of lspci, dmesg, and lsusb -v -v -v and we will take a look at it
<Liz> but since the upgrade, its stopped working
<dholbach> sabdfl: do we have a doc that specifies what happens to and with the rosetta translations?
<sabdfl> dholbach: there may be stuff on the wiki, chat to daf if you need more
<sabdfl> at the moment, i think we've only imported main
<dholbach> no... timer-applet is universe
<dholbach> (the first i looked up)
<sabdfl> the trickiest bit relates to language pack updates
<sabdfl> just before the release, pitti and carlos and daf will generate final Base Language Packs
<dholbach> and the handing-over-to-upstream bit, but i guess that's planned for breezy, right
<dholbach> ?
<sabdfl> from then onwards, new translations will go into Language Update Packs that we will publish through hoary-security or hoary-updates every month
<dholbach> ah cool
<sabdfl> rosetta already support upstream translations
<sabdfl>  /products/foo/1.2.8/+translations should work
<sabdfl> for a 1.2.8 release of foo
<sabdfl> what we will work on is great web pages to allow people to merge translations between the distro and upstream, during the breezy cycle
<womble> Ubuntu is having real major issues with a Compaq Armada E500... partitioning is screwed, and I'm getting the *weirdest* stuff with the installer displaying stuff on whichever VC I'm on when it decides it wants to draw something... anyone got a few minutes to give me some debug tips?
<sabdfl> womble: hoary?
<dholbach> sabdfl: yeah... that would absolutely rock
<womble> sabdfl,  Sorry, yeah, the hoary RC.
<womble> I gave the warty installer a go too, but it didn't like the system either.
<Liz> zul did you want lspci -v ?
<womble> Oh, and the layout guesser is FUBAR, too -- it guessed my keyboard layout as Serbian (Cyrillic) -- which it sure ain't...
<sabdfl> womble: if you're able to provided detailed developer feedback, then we could point you at the folks who know most about the installer and laptops
<sabdfl> is this a current model on sale?
<womble> sabdfl, No, it's an old one, and I reckon I can give this "detailed developer feedback" stuff a go... <grin>
<womble> P-III 400MHz, 64MB RAM, 6 GB HDD.
<sabdfl> womble: ok, file bugs in bugzilla.ubuntu.com with as detailed descriptions as you can
<sabdfl> then point kamion or mjg59 at those bugs
<sabdfl> you generally want to file bugs on debina-installer or installer, when asked for a package or component
<womble> sabdfl, Guess I'll have to get a bugzilla account then... drat, another rarely-used password to remember...
<mjg59> womble: Feel free to add mjg59@codon.org.uk as a Cc on the bugs
<womble> mjg59, Just tried d-i rc2 and got a nice error message.  Posted it on #d-boot.  Got time to help now?
<mjg59> Sure
<dholbach> apt-get.org finished - i'm off
<crimsun> great work, dholbach :)
<dholbach> thanks crimsun 
<tseng> id like to recommend that all motu's /ignore HostingGeek, he's wasting a ridiculous ammount of time under the guisse of being loosely on topic
<tseng> havent managed a good reason to flat out ban him yet.
<ogra> tseng, just ignore him...
<Riddell> " The next meeting of the Council will be on Apr 13th 2005 at 0400 UTC"  is that correct, 4 in the morning?
<crimsun> I believe so
<crimsun> I believe it's a rotating schedule
<Riddell> jings
<ogra> Riddell, nope, 6:00 in the morning :-P
<Riddell> ogra: even worse, too late to stay up for, too early to get up for
<mjg59> Riddell: 0500 for the UK (we're not on UTC now)
* Riddell pats mjg59 and reassures that he does know how clocks work :)
<ogra> heh
<pitti> Hi guys
<ogra> hey pitti
<pitti> ogra: still at hacking?
<ogra> sure, always *g*
<ogra> (in fact i'm just having a lazy day and review the data a bit...and a bathtub waiting)
<pitti> dude, it's spring time and great wheather
<ogra> i know, the dogwalk comes after the bath :)
<T-Bone> ogra: might eventually submit an hppa entry in a few minutes, indeed :)
<ogra> yay
<ogra> T-Bone, give me the id if you submitted it :)
<T-Bone> sure :)
<ogra> thanks :)
<mvirkkil> It seems changes from the last 1-2days are missing from the wiki?
<lamont> womble: keyboard guesser - are you using the hoary-rc CD?
<lamont> because that's a known bug
<mvirkkil> Someone has f*cked the ubuntu wiki. All pages added in the last couple of days are gone, as well as all changes from the last couple of days.
<crimsun> confirmed.
<zul> c?
<zul> fudge
<mvirkkil> This just happened.
<mvirkkil> Like within the hour
<mvirkkil> I had just edited a page, a newly created page and went back to add some more stuff and the whole f*cking page was gone.
<mvirkkil> This sucks rocks.
<zul> mvirkkil: one of the cannical guys will wake up eventually and it will be fixed
<crimsun> I'd be angry, but I have mentos.
<mvirkkil> zul: I suppose. Well, I guess I'll do something productive instead of writing to the wiki ;-)
<zul> yeah you could :)
<Mithrandir> doko: I managed to get a backtrace from a fcdsl hangup now, want a bug?
<zul> but you could also blame Mithrandir :)
<doko> mithrandir: yes please
<Mithrandir> doko: which component?
<Mithrandir> zul: you can blame a lot on me, but I don't do anything to the wiki
<zul> Mithrandir: oh i know...your name just came up at the convient time
<ogra> Mithrandir, probably that is what you are to blame for ;P
<Mithrandir> :)
<fabbione> seb128: ping?
<pitti> cu later
<fabbione> seb128: well FYI, the dnotify code in gamin is a joke. It still uses the poll backend to perform the 3 most important operations.
<fabbione> seb128: i still can't figure out what goes wrong and where, but i think i am getting closer.
<doko> Mithrandir: may avm-fritz-firmware (if that exists), or else l-r-m
<Mithrandir> doko: already filed against l-r-m
<doko> seb128: I found the reason for not displaying accents ...
<abelli> sabdfl: ping
<superted_> During install, when your are prompted with "Choose a locale:" what are you choosing a locale for? (translating purposes, sorry if it is OT)
<zyga> PINE
<koke> sabdfl: ping too :)
<fabbione> ogra: you around?
<ogra> yup
<fabbione> ogra: i need to send my hwdb data stuff.. i just noticed that the gui is broken.. can i do it in console?
<ogra> nope....in which way is the gui brokn ?
<fabbione> ogra: in the Video section, it expects that the server is RANDR capable, that is not always the case
<fabbione> i can print the error if you want
<ogra> only fglrx afaik
<fabbione> and nvidia
<ogra> huh ? oh, not nv ?
<fabbione> nv = free = has RANDR
<ogra> ah, ok
<fabbione> nvidia = crap = no RANDR
<ogra> i'm using nv and assumed nvidia would behave the same...
<fabbione> Xlib:  extension "RANDR" missing on display ":0.0".
<fabbione> Traceback (most recent call last):
<fabbione> and so on
<fabbione> i guess you know the error
<ogra> yup, i know this
<fabbione> ok
<fabbione> next is the Audio part
<fabbione> it perfectly detects one of the 2 audio cards..
<fabbione> but it doesn't attempt any test on the second one?
<ogra> currently it only uses the default card ....
<fabbione> tsk ;)
<ogra> thats stuff for version2 
<fabbione> ok
<fabbione> well can i generate a config to send to hwdb?
<ogra> wher 80% of the tests shall be automated...
<ogra> hmm
<fabbione> since i know that all my hw is working
<ogra> wait a sec... testing
<fabbione> sure
<fabbione> no rush
<fabbione> sabdfl: did you see that we are #1 on distrowatch (6 months stats)?
<ogra> hwdb-xml -a > /tmp/hwdb_data.xml && hwdb-send
<ogra> should work
<fabbione> www.lanschmiede.net
<fabbione> ?
<ogra> hehe
<fabbione> i clicked ok..let see
<ogra> thats where i develop the server
<fabbione> sending data...
<fabbione> done
<fabbione> where do i check the amoung of crap i added to the db? ;)
<ogra> great, you find your id in ~/.hwdb ....
<fabbione> i have no ~/.hwdb...
<ogra> the server is only a inrterim solution, i'l write a real parser next week...
<ogra> huh ?
<fabbione> never mind.. it's a file
<fabbione> ok i can see the ID
<ogra> heh
<ogra> hwdb.ubuntu.com
<ogra> i'm currentl working on the client, so there is not very much server sided currently...thats for past release rime :)
<fabbione> hmm it shoes only cpu and ram?
<fabbione> is that correct?
<ogra> yup
<fabbione> ok
<fabbione> ogra: does the client check also for more than one gfx?
<ogra> not yet..
<ogra> currently i just wanted to have a base for the stuff, so it only does the minimal...
<fabbione> make sense
<ogra> hacking hal ate a lot of my time....
<fabbione> yeah..
<ogra> since its very sensitive terrain
<fabbione> yup i know
<fabbione> it was enough to play with hotplug for me
<fabbione> to say stop to COCAINE!
<ogra> heh
<fabbione> go straight to eroin before touching that stuff
<ogra> btw, hwdb will as first thing get a real online device manager and give access to x and boot data....in future releases you only have to apply the id to a bug to get all info ;)
<fabbione> ogra: ehehe
<ogra> no more "please attach lcpci -bla"
<fabbione> ogra: you might want to consider writing a kernel module to access all the hw directly :)
<ogra> hehe
<fabbione> ogra: well given that they submitted their data
<ogra> probably for v3 ;)
<ogra> fabbione, sure, but 3100 submissions in 5 days this is online.....i guess the bigger part of users will submit ;)
<fabbione> or we can add a pre-page to bugzilla/malone to submit the data BEFORE opening a bug
<ogra> i have constantly about 600 submissions a day
<fabbione> and use the hwid as secondary identification key
<ogra> yeah
<fabbione> no data.. no bugs
<kagou> hi
<kagou> why thunderbird 1.0.2 is not in hoary. It's a bug/security release ?
<fabbione> oh well.. ogra thanks for the info
<fabbione> i guess i am going to crash in front of the TV
<ogra> fabbione, youre welcome ;)
<fabbione> ogra: oh btw.. i might pass by Germany for the October Fest
<fabbione> not sure yet tho
<ogra> yeah
<fabbione> i am waiting some friends from italy to decide
<ogra> feel invited :)
<fabbione> eheh 
<fabbione> it's gonna be better to go out ;)
<fabbione> and have fun
* fabbione -> tv
<kent> kagou, I cant answere for the ubuntu developers, but as i know if they rather backport bugfixes than install new versions. Even though it might be mainly bugfixes, it sometimes they contains new code aswell, which makes for possible new bugs. And the pre-release time is all about getting those bugs away, not introducing new possible ones for the distribution.  But, that said, im not the one to answere. Just could not h
<kent> elp it. ;)
<bronson_> swsusp works great in Hoary!  It mostly just works.
<bronson_> I noticed a problem though...
<bronson_> If your kernel gets upgraded (something that happens automatically now) and then you suspend, you can't resume.
<kagou> thx kent 
<bronson_> You just lose your suspended session.
<bronson_> That seems rather a large problem to me.
<bronson_> Should I file a bug anywhere?
<seb128> fabbione: oh, cool
<seb128> doko: k. That will be fixed for hoary ?
<zyga> hey
<zyga> does ubuntu have a dedicated/supported xorg.conf creation utility?
<zyga> after last update my parents' desktop is broken
<zyga> (it seems it has reverted to lowest possible resolution)
<Robot101> doko: why even in nptl does the glibc's vfork function still call the real vfork syscall?
<T-Bone> ogra: seems like hppa submission will have to wait. hwdb-client, though installed, won't run
<ogra> oh ?
<T-Bone> complains about an ImportError
<T-Bone> varenet@Esperanza:~$ hwdb-gui
<T-Bone> Traceback (most recent call last):
<T-Bone>   File "/usr/bin/hwdb-gui", line 6, in ?
<T-Bone>     import gtk.glade
<T-Bone> ImportError: No module named glade
<ogra> oh
<ogra> no glade on hppa ?
<T-Bone> ii  libglade2-0    2.5.1-0ubuntu1 Library to load .glade files at runtime
* T-Bone wonders
<ogra> T-Bone, thanks, thats a bug, it needs a dependency on python-glade2 obviously
<T-Bone> that's what i was suspecting
<ogra> locally fixed :)
<T-Bone> that machine is a very good testcase: we don't have ubuntu-desktop metapackage, so any broken dep will immediately show
<ogra> ah, ok
* T-Bone install python-glade2
<T-Bone> much better!
<ogra> :)
<ogra> thanks again :)
<T-Bone> you're welcome :)
<T-Bone> sh: xrandr: command not found
<T-Bone> Traceback (most recent call last):
<T-Bone>   File "/usr/bin/hwdb-gui", line 66, in <lambda>
<T-Bone>     self.advance.connect("clicked", lambda w: self.adv(self.xmlfile))
<T-Bone> another missing dep maybe? :)
<zenwhen> I updated from a daily disk yesterday an am already 130MB behind on updates.
<zenwhen> Thats quick development.
<ogra> T-Bone, nope, that looks more serious
<zenwhen> But I sent in my hardware info ogra. :)
<Lathiat> zenwhen: heh
<Lathiat> zenwhen: its probably a kernel+xorg rebuild
<ogra> zenwhen, yeah, thanks :)
<zenwhen> Lathiat, yeaah
<Lathiat> they keep ranking my bandwidth in
<zenwhen> Hoary seems to get faster every week though. 
<ogra> T-Bone, which hal version are you running ? is that a current one ?
<T-Bone> ii  hal            0.4.7-1ubuntu1 Hardware Abstraction Layer
<ogra> ahhhhgrhrg
<ogra> sorry, i missed the xrandr message on top
<zenwhen> My hal-device-manager crashes right now. Not that I use it, really.
<T-Bone> ogra: hehe ;)
* T-Bone apt-get install xbase-clients
<ogra> T-Bone, nvidia card ? 
<T-Bone> ogra: no card, running remotely ;)
<ogra> T-Bone, or no x at all..
<ogra> ah
<ogra> heh
<T-Bone> ogra: that machine is supposed to be a server, you see ;)
<ogra> you cme up with some very special cases :=)
<T-Bone> ogra: i often do :))
<T-Bone> ogra: maybe you want to add that to the deps as well :)
<ogra> hehe, yup, never thought of such a case :)
<T-Bone> ogra: that's why i'm hear. I always do stuff other people would never try ;] 
<T-Bone> s/hear/here/
* T-Bone can't type
<ogra> hmm, i doubt xrandr will work over ssh...
<T-Bone> not over ssh
<T-Bone> export DISPLAY=foo:0
<T-Bone> and it works just fine :)
<ogra> great :)
<T-Bone> ogra: data sent, have fun!
<ogra> yeah <property class="linux" subclass="cpuinfo" name="cpu_family" type="string">PA-RISC 2.0</property>
<T-Bone> LOL
<T-Bone> there are two families: 2.0 and 1,1
<T-Bone> 2.0 is 64bit capable, 1.1 is not
<T-Bone> ogra: you're gonna like the memory information too ;)
<ogra> hmm, you obvoiusly cant buy them....
<ogra> ...they have no vendor
<T-Bone> LOL
<T-Bone> ah
<T-Bone> too bad
<T-Bone> i booted a 32bit kernel, it only sees 4GB, whilst there are 8
<ogra> heh, the meminfo is indeed nice :)
<T-Bone> ogra: i'll take care to submit the next one with a 64bit kernel :)
<ogra> T-Bone, thats quite funny....there is no hal info at all in the lshal output....only data based on my patches
<T-Bone> do you want me to send you the output of lshal?
<ogra> is there any ?
<T-Bone> yeah
<ogra> i'm quite sure it has only three devices computer, memory and pcrocessor...
<T-Bone> Dumped 4 device(s) from the Global Device List:
<ogra> yeah
<T-Bone> ogra: off by 1 :)
<ogra> i forgot a empty BIOS device :)
<T-Bone> right :)
<ogra> funny, so hal seems not to work for hppa
<superted_> anyone know how the beagle pacakages are coming?
* robertj gets done reading #8516
<superted_> im gonna translate "Kill switch enabled on ${iface}"
<superted_> what's a switch?
<Lathiat> superted_: basically 
<Lathiat> superted_: most laptops have a function to turn off the wireless
<Lathiat> superted_: usually a button (switch) or a key combination (say fn+f2)
<zenwhen> Does the person who builds Ubuntu's kernels chat in here?
<CarlK> does the Live cd have the same DEB_CONF=critical thing that the install does?
<Lathiat> zenwhen: theres #ubuntu-kernel
<HiddenWolf> CarlK: yes, but building a kernel is not a one-man-job. :)
<HiddenWolf> zenwhen, sorry ^
<CarlK> yeah, it is a one CPU job ;)
<dholbach> are there any details on the wiki b0rkage and to what extent changes to a site (that took me the most of 3 days) can be reverted?
<Astharot> ciao
<mvirkkil> dholbach: Any info on what actually happened?
<dholbach> mvirkkil: no, but i'll have to endure excruciating pain, if the state will not be reverted somehow
<mvirkkil> dholbach: How so?
<dholbach> mvirkkil: it took me the best of 3 days to compile everything listed on wiki/AptGetOrg
<ogra> mvirkkil, he worked like a dog the last three days to make a list for universe packages to import
<mvirkkil> Ugh...
<dholbach> now i'll always have a backup copy around
<mvirkkil> You wouldn't happen to have that somwhere in the browsers cache.
<ogra> mvirkkil, without that list we wont be able to ipmort the stuff...
<dross> :) #ubuntu was unable to help me, and I've asked this question before. I justforgot the specific pacakge name for the linux-2.6.10-5 source :)
<ogra> dross, search in synaptic
<dross> ogra: I'm in console mode
<mvirkkil> I happened to have a window open where I had the page I was working on, so I'll be able to copy-paste.
<dholbach> dredg: apt-cache search
<ogra> apt-cache search....
<dross> ogra: it wasn't in synaptic or dselect last time
<mvirkkil> dross: Use aptitude. / will pop open the box
<dross> hmm
<ogra> dross, it is...and this is not a support channel, please keep it in #ubuntu
<dross> no, I have the 2.6.10 source, but its not the one you guys told me to use last time
<mvirkkil> Any ops around?
<mvirkkil> we could use a good /kick
<mvirkkil> }:-I
<dross> mvirkkil: you must take after cafuego ;)
<kent> Doesn't the wiki have old versions of stuff saved? I thought that was one of the points in having a wiki?
<dross> kent: in the history/revisions
<mvirkkil> From the wiki point of view the changes never happened.
<dholbach> kent: it currently has the OLD state
<mvirkkil> They seem to have taken a backup copy from april 1st.
<mvirkkil> or something..
* dross wish mdz was here :)
<dholbach> "back to the future" or something
<mvirkkil> dholbach: Tell me a word that would be on the AptGetOrg page
<mvirkkil> (but not anywhere else)
<dholbach> a word that would have been in the NEW page?
<dholbach> and not on the old?
<dholbach> mvirkkil: or a word in general?
<dholbach> mvirkkil: i don't understand your request
<kent> dholbach, Im no expert, but I have seen that sometimes people use google's cache to bring back stuff from sites that have been slashdott'ed. But, perhaps google dont cache wikis? Thats one way that might get back stuff. (Just trying to help :)
<mvirkkil> dholbach: Never mind.
<dholbach> kent: the one in google's cache is older... motaboy already came up with it - thanks for trying :-)
<mvirkkil> dholbach: I have a version of the page from my browsers cache.
<dholbach> mvirkkil: oh... which timestamp?
<mvirkkil> 2005-04-01 11:50:33
<ogra> no good
<ogra> dholbach, what about your cache ?
<mvirkkil> dholbach: Don't you have it in your cache
<dholbach> i viewed it afterwards
<ogra> hmm
<mvirkkil> dholbach: You went to the command line, to the cache directory and grepped for it?
<mvirkkil> It was probably overwritten by a 'newer' version :-(
<dholbach> i'll see what i can extract
<mvirkkil> They resetted the wiki again I think!
<mvirkkil> Yup.
<dholbach> no unfortunately, it's all crap
<mvirkkil> They did it again.
<dholbach> mvirkkil: nothing changed for me
<ogra> https://www.ubuntulinux.org/wiki/FrontPage/recentchanges
<mvirkkil> dholbach: Had you made any additions since the last reset?
<ogra> its empty
<mvirkkil> Exactly
<mvirkkil> wtf is going on?
<mvirkkil> dholbach: You said the cache version is 'all crap'. What did you mean?
<dholbach> all the versions i opened afterwards
* mvirkkil feels sorry for dholbach 
<dholbach> mvirkkil: it's ok... if somebody tells me: sorry, but you'll have to do it again, i'll grab another cup of coffee and do it again
<dholbach> but i'd rather wait for a definitive answer
<mvirkkil> dholbach: You have a rare attitude.
<dholbach> mvirkkil: thank you :-)
<HiddenWolf> dholbach: thumbs up
<mvirkkil> dholbach: I guess there is no chance you could script the thing?
<mvirkkil> dholbach: I mean write a script to extract at least some of the info, and format it?
<dholbach> mvirkkil: i already did it to a certain extent, but i have to see if packages build and then review their copyright, look for suspicious stuff
<dholbach> i think it'll all go faster now
<dholbach> since i kept the sources around
<dholbach> but still it'd be pain :_)
<mvirkkil> dholbach: That's quite a project. 
* mvirkkil is impressed
<ogra> mvirkkil, dholbach is a inpressive guy ;) else he wouldnt be a MOTU lead :)
<mvirkkil> :)
<dholbach> stop it... you'll make me cry :-)
<ogra> hehe
<ogra> you deserve it :)
<ogra> (...no, not the crying)
<mvirkkil> dholbach: You should probably warn anyone you know to have visited the AptGetOrg page NOT to wisit the AptGetOrg page again before they have checked their cache.
<dholbach> mvirkkil: i already thought about collecting wiki mails (from those who are subscribed to the whole)
<smurfix> Oh, great, wiki login is fucked again
<dholbach> smurfix: if it was only the login
<dholbach> smurfix: i could live with that
<smurfix> dholbach: I saw
<dholbach> mvirkkil: i'll wait for the backup-answer
<smurfix> dholbach: the recentchanges page is not very reassuring either
<dross> hmm
<dross> oh I remember what I was needing to ask
<dross> who is the maintainer of the package cache servers?
<dross> are MOTU, or are they just the packagers?
<ogra> you mean the archive master ?
<dross> ogra: I had a idea yesterday to RSS the uploads as they go to the servers
<mvirkkil> BTW: Any talk about running a diskless ubuntu (ubuntu-ltsp)? Maybe collaborating with skolelinux (also based on debian)?
<ogra> or the package maintainers ? (that would be MOTU for universe) ....
<dross> oh
<dross> hmm
<dross> ogra: I don't know :)
<ogra> mvirkkil, there is something planned for UdU about it
<mvirkkil> ogra: Forgive my n00bism but what's UdU?
<ogra> mvirkkil, at least a BOF .... iirc
<dross> ugh
<ogra> mvirkkil, https://www.ubuntulinux.org/wiki/UbuntuDownUnder
<mvirkkil> ok.
<dross> mvirkkil: please stop with the buzz/fad words
<dross> mvirkkil: not only are you being hostile, but childish. This isn't #debian
<ogra> mvirkkil, https://www.ubuntulinux.org/wiki/UbuntuDownUnderBOFs (search for Thin Clients)
<dholbach> dross: HM?
<dross> ogra: I'm glad they finally updated the package I was wanting
<mvirkkil> dross: Could you please be more specific?
<mvirkkil> ogra: Thanks.
<ogra> :)
* dross thinks japanese conversations are much more polite. People know how to speak with respect, not dishonor
* mvirkkil confused
<dross> *dishonorment
<dholbach> dross: could you please elaborate on where mvirkkil was impolite?
<dross> mvirkkil: you made an inappropriate comment earlier.
<dross> mvirkkil: it was very impolite, and a shameable offense.
<mvirkkil> dross: About when someone came to the channel asking for help, and was repeatedly asked to leave and I wondered if an op might kick him?
<dross> mvirkkil: its not your place to state in the channel who needs kicking. It definitely could have gone to privmesg
<zenwhen> Hello Fellows :)
<mvirkkil> dross: Ahh.. I found the text. I was suggesting YOU should be kicked because you came to the channel asking newbie questions that weren't appropriate, but only AFTER I and others had helped you.
<mvirkkil> dross: If I offended you I appologize.
<mvirkkil> Damn. Didn't notice he left.
<pitti> Hi guys
<ogra> hey pitti 
<dholbach> hey pitti 
<blueyed> I'm having problems with powernow-k8: "transition frequency failed".. seems to be stalled at 1ghz (amd64 3000+, nforce4-ultra)
<blueyed> no ideas? I'm using 32bit ubuntu..
<zenwhen> The Livecd runs really well in VMware now
<blueyed> ..there is no BIOS option for cool'n'quiet. It starts with 1.8GHz after reboot, then drops to 1GHz and stays there.. 8/
<sladen> what's the situation on the Spatial mode patch?
<sladen> blueyed: this is a -user question
<pitti> seb128: here?
<seb128> pitti: hi :)
<blueyed> ok, sladen. Just thought this may be a general problem to solve. It means that a 1.8ghz will run at 1ghz only - all the time!
<sladen> blueyed: because it's not being used!
<sladen> blueyed: if you start something, the CPU frequency will go up as it's neededr
<toresbe> are there AMD64 Hoary lives?
<zenwhen> toresbe, yes
<toresbe> zenwhen: yay
<zenwhen> I tried the daily from yesterday on my amd64 machine and it works great
<toresbe> great
<toresbe> Just got a new machine
<blueyed> sladen, I've tested with burncpu - 100% cpu usage.. then new errors go to /var/log/syslog, but no frequency changing.
<pitti> night everybody
<toresbe> I feel so dirty, I'm used to abandonware :P
<mvo> night pitti 
<blueyed> sladen, and this happened with 32bit and 64bit kernel.
<toresbe> I'll just put it up for an overnight download, then 
<ogra> argl
<ogra> Program received signal SIGTERM, Terminated.
<ogra> 0x0000002a9662a6b5 in select () from /lib/libc.so.6
<pitti> night mvo
<zenwhen> my AMD64 machine is infortunatley not completely mine for the screwing with as I have a ton of people relying on me to keep it up as a fileserver for a project I am working on.
<ogra> wtf
<toresbe> zenwhen: got an url there?
<dholbach> bye pitti
<zenwhen> I am thinking about getting a new amd64 machine to use as a desktop
<toresbe> zenwhen: they rock
<zenwhen> http://cdimage.ubuntulinux.org
<ogra> if you start time and date admin xscreensaver gets aSIGTERM
<toresbe> zenwhen: so silent! <3
<toresbe> zenwhen: thanks :)
<zenwhen> I hit that site up for two new lives and a new daily install every weekend to do testing and get my desktop up to date.
<zenwhen> the ONY major issue I have run into is with the new Nvidia drivers.
<zenwhen> Which i wish had been left out of hoary, but thats not my decision.
<toresbe> tore@fortran:/shared/hd2/torrents$ wget -c http://cdimage.ubuntulinux.org/daily-live/20050403/hoary-live-amd64.iso --limit-rate=80k
<toresbe> --21:50:13--  http://cdimage.ubuntulinux.org/daily-live/20050403/hoary-live-amd64.iso
<ogra> seb128, do you have any insight in the gnome-system-tools code ? i'm wondering why a SIGTERM on xscreensaver gets triggered if you click ok
<toresbe>            => `hoary-live-amd64.iso'
<toresbe> Resolving cdimage.ubuntulinux.org... 82.211.81.176, 82.211.81.155
<toresbe> and I tried it again, and it worked
<toresbe> Connecting to cdimage.ubuntulinux.org[82.211.81.176] :80... connected.
<toresbe> HTTP request sent, awaiting response... 404 Not Found
<toresbe> what the hell?
<ogra> seb128, in time-and-date-admin
<zenwhen> odd
<seb128> ogra: no idea
<ogra> hrmm...bad, looks RC
<seb128> ogra: xscreensaver seems to restart fine
<ogra> seb128, not here...and a user reported it in the -users list....that made me look
<dholbach> hrm
<ogra> seb128, the daemon just stops f i click ok....gdb shows a SIGTERM...
<dholbach> ogra: does the backtrace tell you anything?
<ogra> dholbach, Program received signal SIGTERM, Terminated.
<ogra> 0x0000002a9662a6b5 in select () from /lib/libc.so.6
<ogra> thats all
<mvirkkil> ogra: Does strace tell you anything useful?
<mvirkkil> ogra:  Strace might give you an idea why that select() is being called
<ogra> oh
<ogra> select(4, [3] , [] , [] , {4, 915213})     = ? ERESTARTNOHAND (To be restarted)
<seb128> ogra: "bt"
<ogra> Cannot access memory at address 0x7fc0000000
<ogra> hmm...
<ogra> seb128, ^^
<dholbach> this can't be all
<ogra> i guess i'll have to compile a debug version....
<ogra> dholbach, what happens to your screensaver if you run time-and-date ?
<dholbach> time-and-date?
<ogra> System->Systemverwaltung->Zeit und Datum
<ogra> err Datum und Uhrzeit
<dholbach> ogra: no SIGTERM
<ogra> it runs fine ? 
<dholbach> process still running
<dholbach> same pid
<ogra> hmm
<seb128> same here, that's weird
<seb128> gdb gets a crash
<ogra> www.grawert.net/xss_bt.txt
<seb128> but the pid doesn't change
<ogra> www.grawert.net/xss_strace.txt
<seb128> same here
<ogra> weird
<ogra> could it be that t&d admin tries to restart it with uid 0 ? since it runs with that...
<seb128> restart what ?
<ogra> xscreensaver
<ogra> oh.... my .xsession-errors looks interesting...
<ogra> art_render_invoke: no image source given
<seb128> nothing to do with that afail
<seb128> afaik
<ogra> no, seems not related..
<ogra> already starts before my testing...
<ogra> hmm, but restarting with a sighup seems to work too, it even gives a nice message to stdout
<ogra> ogra@honk:~ $ xscreensaver -nosplash
<ogra> xscreensaver: 22:22:36: SIGHUP received: restarting...
<ogra> xscreensaver: 22:22:36: running as ogra/ogra (1000/1000)
<dholbach> good night everyone
<tseng> bye dh
<tseng> er.
<ogra> seb128, if i run  sudo time-admin, it works like expected, if i run gksudo time-admin, it breaks....
<seb128> ogra: perhaps that's due to the focus locking ?
<ogra> yup, thats what i suspect....i'll talk to mvo, he was hacking at it, wasnt he ?
<ogra> s/at/on
<sivang> seb128, ogra : 'sup dudes?
<seb128> hi sivang 
<ogra> hey sivang 
<sivang> what's up? any new interesting g-s-t bugs? :-)
<sivang> seb128: btw, I havn't forgot those release bugs we talked about, just didn't have enough time, will fix them before release thought
<seb128> which ones ?
<kernel_panic> hi
<sivang> seb128: the ones I reassigned to myself, some missing groups from profiles.xml and one username masking
<seb128> right
<seb128> hoary is this week
* ogra shivers
<sivang> I kno
<sivang> know
<sivang> but matt said it's was for 10th no?
<kernel_panic> I'm trying to install mozilla-firefox_1.0.2-0ubuntu2_powerpc.deb but the .deb seems to be broken
<sivang> ah oops
<sivang> that's this week :-)
<thom> kernel_panic: define broken, given it's worked for thousands of others
<kernel_panic> shoul'd I paste ~7 lines ?
<kernel_panic> s/'//
<thom> message them to me
<sivang> anyway people, night for now, see you too tommorow.
<thom> night sivan
<sivang> night thom ! :-)
<ogra> ciao sivang 
<sivang> night ogra 
<doko> seb128: the font fix will be in hoary, just sent you a diff so you can check it out
<seb128> k, thanks
<doko> Robot101: please ask jbailey about glibc
<roo__> are there plans to version bump abiword? (from 2.2.2)
<roo__> currently, it doesnt seem to support importing JPGs :/
<dredg> 5 days before release, there are very few plans to bump anything i reckon :)
<roo__> nevermind that the word processor doesn't handle the world's most popular image format ;)
<thom> it can't be that important if they get to version 2.2 before it does support it
<dredg> i'd argue that it's a word processor and not an image processor
<dredg> but meh
<mvirkkil> Any info on the wiki-b0rkage?
#ubuntu-devel 2005-04-15
<Amaranth> http://www.imagine-msn.com/Spaces/ <--notice anything familiar? :)
<robertj> is Evolution still broken?
<robertj> I'm getting wierd messages with extended unicode chars
<robertj> or sometimes just a blank dialog box
<tritium> robertj, evolution 2.2.2 will be out tomorrow.  Perhaps your problems will be fixed in the release.
<robertj> hopefully\
* robertj decides to do some symlinking just because
<robertj> sudo ls / >> /.hidden
<robertj> ;)
<mdke> have there been some really crazy issues with gam_server today?
<mdke> if its known i won't bother investigating
<mdke> i have a screenful of "scheduling while atomic: gam_server/0xffffffe6/6045"
<mdke> then "Kernel panic - not syncing: Aiee, killing interrupt handler"
<robertj> what's the news on the new nautilus config
<seb128> what about nautilus ?
<robertj> #8516, the closing windows when clicking
<bob2> mdke: you're using a recent kernel, right?
<seb128> robertj: no change according to the comments
<robertj> seb128: this really bothers me, this seems like the last-minute change that freeze periods were ment to stop
<seb128> feel free to comment on the bug
<seb128> Mark is taking this decisions
<seb128> in fact I don't like this broken spatial neither, and there is probably some corner cases that would need to talk/feedback
<jordi> Kamion: I take it nano 1.3.6 wasn't considered for Hoary?
<mdke> bob2, hi
<mdke> bob2, yes recent kernel
<mdke> bob2, ah good point, i have only had problems since i've been running the 2.6.11 kernel, rather than 2.6.10
<robertj> seb: is that mark - hbd address the right Mark?
<robertj> (just wanted to know if he was getting mail from the bug)
<seb128> right
<mjg59> seb128: Has the documentation been changed to match the code?
<seb128> no
<mjg59> seb128: That, uh, sounds like an issue
<seb128> that's not the only one :/
<robertj> is it realistic to expect an on-time release and still have time for the i18n folks to get in on it?
<seb128> there is no i18n to do
<seb128> we don't have a preference option for it
<robertj> seb128: my feeling is also that if we switch away from opening multiple windows by default the Places menu items need to change as well
<seb128> why ?
<robertj> seb128: isn't there a basic using gnome document though?
<robertj> seb128: because you get multiple windows
<mjg59> seb128: There would be i18n of the docs
<seb128> we are not clear if that require a UI option or not
<seb128> no documentation about this
<seb128> no reflection about the issues and the corner cases
<robertj> What do you know, the using Nautilus is for version 2.8 and seems to cover browsing only
<Amaranth> robertj: 2.8? spatial was introduced in 2.6, wasn't it?
<robertj> err 2.6
<Amaranth> robertj: That would mean that was for 2.4
<robertj> Amaranth: it says 2.6
<robertj> maybe that's just using gnome though
<robertj> oh there is more
<robertj> but its called 'Navigating Your Files and Folders as Objects' -> 'File Object Windows' 
<robertj> also, can someone trigger a file quota error message from their server in Evolution?
<robertj> I think that's what these garbled messages are
<mjg59> robertj: Yeah, there's a section for browsing and another for spatial
<robertj> that's a scary section name for a document like that
<robertj> mjg59: did you read my last comment?
<robertj> (actually I guess my first comment on that big)
<robertj> %s/ig/ug
<mjg59> robertj: I read the thread
<robertj> ahh just saw your comment ;)
<robertj> what do you mean by rever to upstream behavior?
<mjg59> left mouse button = open new window without closing old one
<bob2> hah, insightful commentary from "brandon hale"
<robertj> oh I was being bone-headed, you mean an option in the gui, I'm just being dumb
<tseng> bob2: on the spatial bug?
<tseng> bob2: i was too tired of arguing it on irc to put more thoughts on the bug I guess.
<robertj> tseng: please do cut and paste some choice ones so there is a canonical point of reference
<tseng> it was a few days ago
<tseng> i dont do logging
<robertj> ok
<tseng> basically it breaks things for everyone, or most imo
<tseng> people who are used to real spatial behaviour cant use it
<tseng> and people who are coming from windows are like wtf, windows are popping up and random positions with no navigation
<tseng> it would be better to default to browser if you are really targetting windows converts
<robertj> tseng: that's my feeling but IMO it's best to just revert it and look again the day after release
<tseng> thats true
<mdke> windows 2k uses that behaviour doesn't it?
<tseng> robertj: mark doesnt follow release plans
<tseng> robertj: he throws stuff in whenever he pleases, which is his perogative I guess.
<robertj> tseng: hehe, his $, his choice
<robertj> mdke: every Windows since 98 browses by default
<tseng> windows 95 had a psuedo spatial
<mdke> hmm
<tseng> its not even worth comparing, it was a broken model.
<robertj> Active Desktop actualy came with ie 4.5 right?
<mdke> my school must have put it in intentionally then
<robertj> or was it 4.0
<tseng> so lets ignore it.
<mdke> crazy
<robertj> and it gave you the option to go to "Web Like" mode or something
<mdke> oh yeah
<mdke> *shudders*
<jdub> that was a separate thing again
<robertj> hyperlinks, one-click, etc
<tseng> yeah that came with IE4
<robertj> but 98 defaulted to Brose w
<tseng> active desktop
<tseng> it was also not spatial, and also broken.
<mdke> good morning jdub
<jdub> morning
<robertj> jdub: guess what we are talking about ;)
<jdub> uh huh
<jdub> i've been reading
<tseng> (broken drag n' drop)++
* infinity giggles at the 'ugly strangers' post.
<astharot> ciao
<mvirkkil> Any news about why the wiki got b0rked?
<dross_> you guys are slacking still
<dross_> the nvidia driver is _still old
<mdz> dross: our release is in 5 days; we stopped upgrading software in the distribution "just because it's newer" about 3 months ago
<dross> mdz: what about in hoary?
<mdz> dross: I am talking about hoary.
<calc> hoary is the one coming out in 5 days
<mdz> yep
<dross> oh, heh :)
<dross> mdz: I didn't know that ;)
<mdz> and the nvidia driver in hoary is about 3 days behind upstream
<calc> hmm actually doesn't it release on wed (in 3 days)?
<dross> well.. they upgraded the nvidia driver a few days ago
<mdz> calc: no, we pushed up to friday
<schweeb> isn't fabbione trying to put the new nvidia in?
<calc> mdz: oh :\
<dross> in hoary
<calc> so will breezy be added on friday?
<mdz> calc: in order to catch GNOME 2.10.1 (scheduled for wednesday), which has now been delayed
* calc wants more blood
<dross> because last week or so there was the _old_ driver
<mdz> dross: I'm not seeing your point. are you experiencing a problem with the driver?
<dross> mdz: no :)
<schweeb> dross: if you're really desperate for it, you can always get the updated driver from nvidia
<schweeb> it's real easy to install...
* calc noticed that gnome 2.11 page still hasn't been added on gnome.org
<mdz> there is a small chance that we'll update to 7174, but it's more likely that we'll stay with 7167
<mdz> calc: breezy will probably be created sometime around release time, yeah
<calc> ok
<dross> mdz: curious, will hoary become a 'stable' and use only backported/old software?
<mdz> but there's no scheduled date for it at this time
<mdz> dross: every six months we produce a stable release, and only update that branch with critical bugfixes
<dross> mdz: there will be another 'unstable'?
<mdz> Ubuntu 5.04 (hoary) will be the second such release
<mdz> following Ubuntu 5.04, our development tree will be called 'breezy'
<mdz> which will go through a period of aggressive feature development, and then be stabilized, and then released just as Warty and Hoary were
<mdz> in October 2005
<dross> mdz: where did 'breezy' come from?
<mdz> dross: from sabdfl
<mdz> 'breezy badger'
<dross> mdz: will there be an easy way to upgrade from hoary to breezy without wiping the disk? or do I just need to wipe the disk clean?
* dross pets seperate /home partition :)
<infinity> dross : Wiping the disk clean should never be necessary, just as it isn't from warty->hoary.
<dross> infinity: I've never upgraded a deb based system
<dross> infinity: is it just a large update for the packages and thats it?
<robertj> dross: and a reboot
<infinity> dross : I have systems that started out as Debian slink, upgraded to potato, woody, sarge, warty, hoary...
<dross> sounds simple enough
<infinity> dross : With the exception of kernle upgrades, that's all been done without reboots.
* dross really doesn't like Toy Story :)
<schweeb> well, a rebot isn't strictly necessary
<schweeb> *reboot
<mdz> dross: everything is a package; a complete system upgrade is just a full set of package upgrades
<robertj> schweeb: does hoary not require an inotify enabled kernel?
<mdz> robertj: no, in fact inotify is disabled by default in the hoary kernel
<schweeb> inotify is... what mdz said
<calc> so is a new kernel being prepared?
<schweeb> inotify is in the kernel, it just requires you to add a kernel option
<mdz> calc: for what?
<calc> well for the IDEDMA_ONLYDISK issue
<mdz> what issue is that?
<calc> i think fabbione was working on one yesterday
<mdz> there is continually a new kernel update in preparation, what with the steady flow of security vulnerabilities being found upstream...
<calc> mdz: on amd64 and (i think ppc) if its set the kernel won't let you enable dma at all on ATAPI devices best as i can tell
<mdz> calc: hmm, I'm pretty sure it worked on my test box the last time I tried it
<calc> it gave me some message about operation not permitted (iirc)
<calc> as opposed to failed
<calc> and knoppix i386 on the same box let me enable dma
<calc> i still need to run the i386 hoary live cd on the box to see
<mdz> confirmed, it works fine here
<calc> on amd64?
<mdz> yep
<calc> hmm ok
<mdz> EPERM generally means that either you're using the generic driver, or the chipset-specific driver doesn't support DMA on your device
<calc> hmm interesting
<calc> perhaps it didn't load the right driver for my box
* calc takes a look
<calc> i actually had that exact issue before on warty with an intel box
<calc> it loaded the specific driver too late
<calc> gar
<calc> its doing it on via now too
<calc> i suppose it would useful to send a dmesg to bugzilla?
<calc> it stole the ide0 before the via driver was loaded
<infinity> Does anyone have a rationale for apache2-mpm-worker being the one in the ship seed?
<calc> which my optical drive is on the ide0
<calc> it loaded the via driver pretty late actually
<calc> around the time usb was loaded
<calc> should the generic driver ever get loaded before the chipset specific ones do?
* calc wonders if that is the same actual problem the ppc user was having as well
<calc> what is interesting is /proc/ide/via shows like it has the primary ide channel as well, but dmesg shows it couldn't get it
<mdz> generic should always be loaded last
<mdz> check the ordering of /loadmodules in your initrd
<dholbach> morning
<calc> ok
<calc> mdz: i don't see any reference to either ide driver in my loadmodules file
<calc> i can paste the contents somewhere if you would like to see
<mdz> calc: is your root on something other than an IDE disk?
<calc> my root is on sata_via
<calc> my optical drivers are on regular via
<calc> s/drivers/drives/
<calc> the sata_via is in the loadmodules file but the regular via is not
<dholbach> are there any news on the wiki yet?
<dholbach> maybe it's best to just start the work again
<tseng> dholbach: you must be kidding.
<dholbach> tseng: last time i did it in 3 days, now it should take 2, release is in ~4 - i guess there's no other way
<dholbach> tseng: i couldnt even sleep *grmbl*
<mdz> calc: that should work, then
<mdz> calc: just remove ide-* from /etc/modules
<mdz> and let hotplug load them; current hotplug in hoary loads everything in the proper order
<calc> ah so its just an upgrade issue?
<mdz> calc: right, we don't mess with /etc/modules on upgrade
<calc> ok
<calc> thanks for the help :)
<dholbach> tritium: hey michael
<tritium> hi dholbach :)
<dholbach> tseng: my memory seems to be quite good it seems - i didnt trust it, but when i re-rebuild the packages i seem to know which one would fail ;-)
<tritium> dholbach, How are you, Daniel?
<dholbach> tritium: couldnt sleep properly, so i got up again and re-worked apt-get.org stuff, i had finished like 12 hours ago
<tritium> Wow.
<dholbach> tritium: the wiki is now in the same state as 3 days ago... that's why
<dholbach> tritium: but i'm alright, thanks... how about you?
<tritium> I'm fine, thanks.  I'm very pleased with my Hoary reinstall.
<dholbach> :-))
<tritium> The suspend-to-ram is working solidly with nvidia as long as I use NVagp, even when I have pcmcia wlan card inserted.
<fabbione> morning
<tritium> morning
<dholbach> hey fabbione 
<Robot101> mdz: ping
<mdz> Robot101: pong
<Robot101> mdz: do you know if a CVE number has been allocated for recent IRC escaping problems in Gaim?
<mdz> no, I do not
<mdz> if it's public (and i assume it is since you're talking about it here), one must be assigned by Mitre in order to avoid duplicate assignments
<Robot101> aye, it is public. some tool spent 14 hours crashing people in #gaim, his idea of contacting the upstream developers, whilst we fixed it, and then mailed bugtraq later claiming we denied the problem existed and wouldn't fix...
<Robot101> so I should just upload the version with the fix and put the CVE number in later..
<mdz> Robot101: have you sent the patch to the Martins?
<Robot101> mdz: I can pull a patch out if you want - I was just going to push 1.2.1 (about to release) into sid & sarge. what version is hoary at?
<mdz> Robot101: oh, it doesn't affect woody or warty?
<mdz> Robot101: hoary has 1.1.4
<Robot101> mdz: this version of the IRC plugin isn't in woody... warty's a more likely candidate
<Robot101> what version there?
<mdz> 1.0.0
<Robot101> yeah probably
<mdz> I guess only pitti needs to be contacted, then
<Burgundavia> mako: ping
<jalrnc> does anyone know what's wrong with the wiki? recent changes have been lost
<dholbach> jalrnc: nobody seems to know
<Burgundavia> saw a post to ubuntu-doc, but no response there either
<jalrnc> I sent an email to the webmaster, still waiting for a response
<Lathiat> qwdqwdqwd
<mako> Burgundavia: oh!
<mako> Burgundavia: oi! even :)
<Burgundavia> hmm
<Burgundavia> thinking about names for talks
<Burgundavia> should I go funny or stay serious?
<Burgundavia> mako: still there?
<mdz> Burgundavia: I think he's eating delicious food
<Burgundavia> bah
<Burgundavia> no food eating for him
<Burgundavia> mdz: any reports of sound breaking recently?
<mdz> just the usual stream of misdirected reports
<Burgundavia> ok
<Burgundavia> lol
<fabbione> mdz: the next question would be: why doesn't trap all the ADD messages?
<dholbach> reviewing those apt-get.org packages makes me consider having MOTU-boot-camps all around the globe
<mdz> dholbach: that is not a bad idea at all
<mdz> dholbach: tie into LoCoTeams
<jdub> that's a rad idea
<jdub> we could line up UbuntuLove days to synch with them
<dholbach> mdz, jdub: i'll give the wiki some loving wrt to that once i finished reviewing apt-get.org AGAIN, cleaned universe-kernel* and had a look at the open universe bugs
<mdz> dholbach: I've been seeing some reports of the wiki being in a broken state right now, do you know anything about it?
<dholbach> mdz: no
<mdz> I haven't had time to investigate myself
<mdz> and this is something like the weekend for me
<dholbach> but i have huge PAIN, because i have to review everything again
<dholbach> it took me the best of 3 days
<dholbach> now i keep it on my own wiki
<dholbach> the current state of the wiki is of 3 days ago
<dholbach> and since our beloved communication-sharethelove-instrument saves everything in one huge blog, i think chances of recovering anything is ~0 :-/
<mdz> dholbach: everything again?
<dholbach> mdz: that's what i do atm... couldnt sleep
<dholbach> release is in 4 days, so i have to get a move on
<mdz> so you are also experiencing problems with the wiki?
<mdz> I emailed henrik earlier tonight and asked him to look into it
<dholbach> yes... as i said: the state of it is of 3 days ago
<dholbach> google-cache unfortunately is of around the same timestamp
<dholbach> i was finished around 13:30 utc and ogra said it must have been b0rked at 14:45-15:00 utc
<dholbach> (he grabs the wiki's css for hwdb.ubuntu.com)
<mdz> dholbach: I asked if you knew anything about it being broken, and you said no, so I thought that meant it was ok :-)
<dholbach> mdz: ah ok... i don't know anything specific about the breakage
<mdz> dholbach: please email henrik.omma@canonical.com with your observations; he is tracking website problems for us now
<mdz> I have noticed the traffic and alerted him, but have not had time to investigate myself
<dholbach> mdz: will do
<mdz> thanks
<mdz> dholbach: you are coming to Sydney, yes?
<dholbach> mdz: yes...  i'm quite glad to see you guys there, finally :-)
<mdz> dholbach: yes, it will be good to meet you
<dholbach> nice you say that :-)
<mako> Burgundavia: yes, back
<dholbach> mdz: mailed him
<mdz> thanks
<dholbach> mdz: i'll nevertheless continue reviewing, i guess i'll finish in 5-6 hours
<nasdaq7> who is coming to sydney?
<dholbach> nasdaq7: http://wiki.ubuntu.com/UbuntuDownUnderAttendees
<mdz> good answer
<nasdaq7> i thought kylie minoque
* dholbach cries silently
<mdz> that list is somewhat incomplete though
<mdz> I'm not on it
<nasdaq7> neither is kylie
<dholbach> yeah... all of you canonical guys should add themselves with their particular interests :-)
<infinity> mdz : You're on it.  It says "All Canonical Employees".
<dross> eww.. aussieland.. where they charge by the MB
<Lathiat> heh
<Lathiat> its true
<Lathiat> i just ran my stupid uni internet quota out again
<Lathiat> 4c/mb is nasty
<dross> I never want to live there, its a horrible place. What kind of country charges per quota
<dross> Lathiat: yep
<Lathiat> fortunately we have a local peering network in western australia where traffic is free
<Lathiat> and i have access to a machine on a fixed rate pipe
<Lathiat> so i tunnel through it
<nasdaq7> the aussies think australia is better than the us
<dross> Lathiat: I use 100 gigs a month, I'd have to make 500k a year to live there ;) 
<Lathiat> haha
<dross> nasdaq7: thats such bs
<Lathiat> like this person i know in canada pays $30/month for liek 400K/s unlimited internet
<Lathiat> i pay $60 for 50K/s 28GB
<dross> nasdaq7: I can uncap any cable modem in the US, this state rocks ;)
<Lathiat> and half that 28GB is "off-peak" (midnight-7am)
<dross> nasdaq7: I once tried uncapping this modem just for kicks, and obtained a 7Mbps/7Mbps
<dross> 3/1.5 is good enough for me however ;)
* Lathiat has 0.512/0.128 
<dross> Lathiat: pitty :)
<dholbach> don't we have #ubuntu-bandwidth yet? ;-)
<Lathiat> dross: quite
<Lathiat> im at uni atm, get better speeds like up to 1MB/s, i just pay through the nose for it :)
<Lathiat> at the other uni here i can get to internet2 for free
<dross> Lathiat: If I moved to aussielang, I would need to buy a dish and use that as a main internet connection ;)
<Lathiat> so that includes gnome.org and stuff
<Lathiat> not here but
<dross> Lathiat: hehe, internet2 is okay
<dross> Lathiat: I like the fact that most univs have I2 and transfer speeds are outragously fast
<Lathiat> yeh
<dross> most of them use AFS
<dross> AFS is much much better than nasty NFS
<Lathiat> i tried it
<Lathiat> its kernel panicy
<Lathiat> and has stupid authentication stuff
<lifeless> try sfs
<lifeless> it rocks
<Lathiat> nfs works fine as long as your server or the network don't go away :)
<Lathiat> or you need locking that doesn't break
<dross> AFS has always worked for me... :)
<Lathiat> mmm
<Lathiat> i want to look at lustre
<Lathiat> see if its any good
<Lathiat> (on a slightly unrelated note)
<dholbach> hey pitti 
<pitti> Good morning
<infinity> mdz : htmldoc from sid fixes #7928.
<pitti> dholbach: any luck with recovering your apt-get.org work?
<mdz> infinity: eh?
<dholbach> pitti: nope, mdz told me to mail henrik, which i did
<infinity> mdz : Oh, I just noticed the upload.  The bug importer hasn't gotten the close message yet, I assume.
<dholbach> pitti: but i guess chances are ~0 and i couldnt sleep, so i re-reviewed
<mdz> infinity: oh, it was just uploaded
<infinity> mdz : Or it was a tag, not a close, cause it's an NMU.  (does the importer catch that?)
<mdz> my apt cache said hoary==sid atm
<infinity> mdz : Yeah, it's shiny new.  Just a patch for that bug and nothing else too, which is handy.
<dholbach> pitti: so i can't provide you with as much work as i wanted to :-)
<pitti> dholbach: :-)
<pitti> dholbach: still, losing two days of work just because of a random server error is awful. Do you know the reason for this now?
<dholbach> pitti: no... unfortunately not, but since i heard that the wiki stores data in one HUGE blob, i feel slightly uncomfortable about it in general
<pitti> dholbach: hmm, moinmoin was able to revert "patches"...
* fabbione kicks gamin with a cluebat
<pitti> fabbione: Hi
<fabbione> mdz: it is clearly a huge race mess
<fabbione> pitti: hi dude
<pitti> fabbione: I already beat it to death
<pitti> fabbione: did you find out anything new?
<fabbione> pitti: can you please review the 3 race conditions from Chuck?
<pitti> fabbione: yeah
<fabbione> pitti: yes. check the bug log :)
<jdub> fabbione, pitti: i fear what DV will do if you say that to him ;)
<dholbach> pitti: zwiki is able too, but only if you don't revert to state-of-3-days-ago
<fabbione> i think i can workaround it
<pitti> fabbione: "workaround" = using only polling?
<fabbione> jdub: who is DV?
<jdub> fabbione: daniel veillard, author of gamin
<fabbione> pitti: if i understand the protocol correctly, a client asks gamin to monitor a dir
<pitti> fabbione: yeah, that's what you do in testgam
<fabbione> jdub: tell him, he needs to learn to write code
<pitti> fabbione: "mondir /foo/bar"
<jdub> fabbione: he also wrote libxml2/libxslt :)
<dholbach> pitti: so if you have a bit of free time, check   http://moz.gotdns.org/moniwiki/wiki.php/AptGetOrg   for the packages tagged as "needs security review"
<fabbione> pitti: i don't understand why gam_server takes the freedom of stop polling a directory without the client asking for it (1) and why it doesn't gets all the signals from dnotify (2)
<pitti> dholbach: I'll do
<dholbach> pitti: it's not finished yet... but i think in 5 hours or something, i'll have done it (again)
<fabbione> pitti: i am pretty sure i can workaround (1) and it might, as a side effect, fix (2)
<fabbione> but the real issue is (2)
<fabbione> jdub: i don't care what he did or not. the code is still crap
<fabbione> jdub:
<fabbione>  /* TODO: GQueue is not signal-safe, need to use something else */
<fabbione> static GQueue *changes = NULL;
<fabbione> this is inside the dnotify backend
<jdub> fabbione: i'm not disagreeing, just giving you more information
<fabbione> oh just as a side note..
<fabbione> dnotify is all signal based
<pitti> fabbione: did you see the nice race conditions when trying to use something like a semaphore?
<fabbione> pitti: no i can see the race because not all the "Add" signals are handled
<pitti> fabbione: that's probably not the cause of our bug (we hit it far too often for this), but it's still crap
<fabbione> pitti: just read the logs i got out of gam_server
<fabbione> pitti: our problem is more than one
<fabbione> pitti: as i explain in the bug report: (1) we don't catch all the Add signals
<fabbione> that leads gamin to remove a direcotry from monitoring for no reasons
<fabbione> (2) is why we don't catch all the add signals?
<fabbione> so i can see at least 2 bugs there
<fabbione> not one
<Burgundavia> somebody looking for me?
<jdub> fabbione: i'd recommend talking to DV about all of this, btw.
<fabbione> if he reads bug reports, he knows
<dholbach> Burgundavia: <mako> Burgundavia: yes, back     (half an hour ago)
<pitti> jdub: I already did
<Burgundavia> dholbach: thanks
<Burgundavia> mako: still here?
<pitti> fabbione: DV said to me that he had to evaluate"
<jdub> pitti: i know; referring to issues raised above
<pitti> this bug
<fabbione> pitti: well it makes gamin {d,i}notify backends useless
<fabbione> i am testing a workaround now
<pitti> fabbione: only having polling would be a quick fix if we don't solve it, but it certainly slows things down, doesn't it?
<fabbione> pitti: yes. gnome-panel will be slow to death at login time
<fabbione> pitti: and it will suck 100% of cpu for several seconds on a slow machine
<mako> Burgundavia: tag, you're in
<dholbach> mako, Burgundavia: why don't you just exchange phone numbers? :-)
<Burgundavia> dholbach: lol
<dholbach> Burgundavia: you wouldn't keep on missing each other then :-)
<Burgundavia> I got him
<Burgundavia> any #ubuntu chan ops here?
<Burgundavia> never mind
<Burgundavia> the problem left
<fabbione> pitti: well my workaround works
<pitti> cool
<fabbione> pitti: i need to check some other stuff too
<fabbione> and send out a patch
<fabbione> pitti: patch and explanations added to the bug.
<fabbione> pitti: note that i didn't fix the inotify backend
<pitti> cool
<fabbione> only the dnotidy
<fabbione> the patch looks intruive, but that's just diff fault :)
<Lathiat> oh so you fixed it?
<Lathiat> woo :)
<fabbione> Lathiat: no. i workaround it
<fabbione> the real fix is way more complex
<Lathiat> oh
<Lathiat> good enough :)
<fabbione> pitti: we need to do some possible memleaks tests
<fabbione> pitti: if i understand the code correctly, there are no issues
<fabbione> but you may never know
* pitti kisses fabbione 
<pitti> fabbione: I review the patch again and test it on my boxes
<fabbione> pitti: sure
<pitti> fabbione: I can imagine that directory registrations keep piling up if you e. g. kill -9 nautilus repeatedly
<pitti> fabbione: and some apps might not deregister their watches properly
<fabbione> pitti: that's what i was checking right now
<fabbione> it seems to leak 4K every 3 nautilus restarts
<fabbione> but gaminn code seems to avoid double allocation of mem if a path is already monitored
<fabbione> so that might be another leak, like allocated pool for clients not freed properly
<pitti> fabbione: well, 4K is acceptable IMHO (it's nothing compared to the other memleaks of gnome :-/ )
<fabbione> pitti: can you test on a non patched gamin, if restarting nautilus N time will increase the mem usage of it?
<daniels> gnome-terminal is horrific
<fabbione> ps axu |grep gam
<fabbione> fabbione  7740  0.1  0.2   2524  1336 ?        S    07:52   0:02 /usr/lib/gamin/gam_server
<pitti> fabbione: yeah, I do
<daniels> my g-t leaks about 500mb every day or two
<fabbione> the 1336 was like 1332 a few nautilus restarts ago
<Lathiat> daniels: ouch
<Lathiat> my gnome-t currently has a res of 15M
<Lathiat> i should watch to see what it gets up to
* fabbione switches to KDE
<pitti> fabbione: unpatched gamin leaks 4K on every nautilus restart for me
<pitti> so no regression here
<fabbione> pitti: ok.. patched, it leaks 4K every 2/3 restarts
<fabbione> :
<fabbione> )
<fabbione> here.. at least
<pitti> fabbione: it might be fruitful to sort out multiple registrations for one dir
<Lathiat> haha
<pitti> fabbione: although this is probably too complicated for Hoary
<fabbione> pitti: it does already afaics
<fabbione> pitti: the lists are quite complex
<pitti> fabbione: right now, nautilus registers both a dir and files in it
<fabbione> pitti: yes, that is correct and the answer is inotify
<fabbione> because dnotify doesn't know crap of inodes
<fabbione> and you need to monitor both
<fabbione> files even via the poll backend
<pitti> fabbione: oh, ok
<fabbione> except that inotify is utterly broken
<fabbione> both kernel and gamin side
<Lathiat> even 0.21 (kernel side)
<Lathiat> ?
<pitti> yeah, but that will be hopefully be fixed by breezy
<fabbione> pitti: hopefully
<fabbione> Lathiat: i did stop updating inotify at 0.20
<fabbione> Lathiat: so i dunno
<fabbione> inotify is quite intrusive patch
<Lathiat> quite
<fabbione> the main issue is that it fucks up the kernel ABI each time
<Lathiat> ah
<Lathiat> thats because kernel develoeprs don't beleive in a stable ABI :)
<fabbione> no that's because the ABI is only a distro problem
<fabbione> since we have tons of lusers compiling their own kernels
<fabbione> and complaining if they don't load across upgrades
<fabbione> mdz: are you still alive?
<HiddenWolf> fabbione: what would you do if he said no?
<SuperL4g> fabbione: some people are just gluttons for punishment :)
<fabbione> HiddenWolf: let him R.I.P.
<fabbione> SuperL4g: eheh
<SuperL4g> fabbione: I know this isn't the same thing... but people do it all the time on Gentoo with insane optimizations, and whine when stuff doesn't work.
<pitti> fabbione: you rock!
<fabbione> SuperL4g: yes i know
<fabbione> pitti: no.. i FUCKING ROCK!
<fabbione> pitti: i spent most of the weekend digging into that crap
<fabbione> pitti: do you want me to upload? or will you?
<pitti> fabbione: I have a readymade package here (with credit to you), but of course you can upload yourself :-)
<fabbione> pitti: go ahead
<fabbione> :)
<pitti> ok
<fabbione> i am too lazy to vi changelog
<fabbione> and type my passphrase twice
<fabbione> hmm pitti wait to upload
<fabbione> did you check the memleaking?
<pitti> fabbione: already uploaded, but it doesn't memleak
<fabbione> pitti: ok perfect
<fabbione> i get it to suck some more ram while running the Martin's loop
<fabbione> but nothing impressive tbh
<pitti> fabbione: I ran the while loop for about 5 minutes, gamin uses the same amount of mem as it used when starting it
<pitti> fabbione: it remains absolutely constant here
<fabbione> pitti: ok.. it has been running here for a while
<dholbach> after reviewing this chuck of shit again i think i'm now ready to go to bed
<fabbione> and it sucked approx 12/16K more
<fabbione> pitti: but i think it's acceptable
<fabbione> nobody will ever mv files around THAT fast
<pitti> fabbione: and compared to the size of the other gnome crap that's tiny :-)
<fabbione> exactly :)
* pitti -> breakfast, cu later
<dholbach> good night... 
<jdub_> hrm
<jdub_> From: Archive Administrator <katie@ftp-master.debian.org>
<jdub_> Subject: Processing of gamin_0.0.26-0ubuntu3_source.changes
<jdub_> fabbione, pitti: should i be scared? :)
<fabbione> jdub_: no
<fabbione> now i wonder why i didn't get any email yet
<aj> erm, ubuntu version numbers in debian is bad, is it not?
<fabbione> AH pitti uploaded to the wrong target?
<jdub_> fabbione: that's what i'm worried about, yeah
<fabbione> sorry i didn't noticed that
<aj> unchecked/gamin_0.0.26-0ubuntu3_source.changes
<aj> on ftp-master.d.o
<fabbione> jdub_: well it is a good fix for 7078
<fabbione> aj: can you kill it please?
<jdub_> fabbione: fixing that is a huge relief :)
<tritium> jdub, with usplash not in hoary, would you be interested in an ubuntu grub splash image?  I have a link to mine on my wiki page.
<fabbione> jdub_: well dude.. i didn't spend the weekend jerking :)
<aj> Distribution: hoary
<fabbione> right
<aj> killed, but it should've got rejected anyway in a few more minutes, i guess
<jdub_> tritium: not for the moment, we don't actually display grub at all unless you have other OSes installed :)
<fabbione> aj: thanks a lot
<tritium> jdub, okay :)
<fabbione> time to start some warty -> hoary upgrades tests
<fabbione> well this error makes me more happy that i am using 2 keys for ubuntu and debian
<fabbione> it would have been dropped at the gpg check
<aj> yes, it would've been rejected thrice over: hoary; source only; and no matching .orig.tgz in debian
<fabbione> right
<fabbione> jdub: in anycase you should talk to upstream and refresh his mind on the bug
<seb128> hi
<fabbione> hi seb
<seb128> hey fabbione 
<seb128> fabbione: rocking work on gamin, thanks :)
<fabbione> seb128: except that pitti uploaded to debian instead of ubuntu :)
<seb128> lol
<seb128> hi pitti 
<pitti> Hi seb128 
<seb128> pitti: Sebasti*e*n :p
<pitti> oops, sorry
<seb128> np 
<seb128> need to say it to mvo too :)
<seb128> is that Sebastian in .de ?
<pitti> yes
<enrico> hello.  I'll be online for a bit.  Anything urgent with the docteam packages?
<pitti> it's a very common name here
<pitti> Hi enrico, how's it going?
<enrico> pitti: not too bad.  Just quite disconnected
<enrico> (for someone it could be really bad, I reckon :)
<fabbione> pitti: do you realize you uploaded gamin to debian?
<fabbione> hey enrico 
<seb128> enrico: are you going to include the translation for hoary ?
<seb128> enrico: ie: I've send the french about page, I don't know who, but somebody has included the po file instead of the xml file to the package ... that's doesn't work ;p
<seb128> enrico: and the .po is not even on the right location, should be fr/about-ubuntu.xml, not C/about-ubuntu-fr.po
<enrico> seb128: is the deadline for that in 2 days, or later with language packs?
<seb128> the sooner the better
<seb128> ask to mdz
<enrico> ok
<enrico> I'll be back home on the 8th, and if possible I'd like to do this after that
<seb128> doesn't work
<seb128> 8th the CD master should be ready
<seb128> just let me know if I should ack the package as a workaround 
<fabbione> i think we will prepare the Golden the 7th or something
<enrico> seb128: what's "ack the package as a workaround"?
<seb128> apt-get source
<seb128> copy my stuff
<seb128> and hack the debian/rules to copy them 
<enrico> seb128: wouldn't be bad at all
<seb128> s/to copy them/to put them to the right place/
<seb128> nobody else than you works on this package ?
<seb128> I've noticed than the SVN has a couple of new translations
<enrico> seb128: afaik, I'm the only one so far that can do packaging in the group
<seb128> are you expecting some new ones ? Somebody works on that ?
<seb128> k
<enrico> I'd like to change that, though, as I now have a full-time job and I don't think I can keep up
<enrico> seb128: I've been disconnected and not reading lists, so I'm not updated on what's the current status of things :(
<seb128> k
<seb128> anybody to ping to have an idea if you are waiting on new translations before updating the package ?
<doko> seb128: did the patch work for you?
<seb128> doko: ups, not tried. A sec I'll do now
<seb128> pitti_: I'll do some translations updates today, could you run a langue-pack update this afternoon, some of them are outdated (due to the new version or 2.9/2.10 bug) and that would be nice to have an update on this plan :)
<pitti_> seb128: yeah, I planned this anyway
<pitti_> seb128: do you upload gdm?
<seb128> rock
<seb128> not planned no
<pitti_> okay, then I recompile it myself to get the tarball
<enrico> seb128: froud (Sean Wheller) is usually very knowledgeable of what happens
<seb128> k, thanks
<enrico> what's a language pack anyway?
<pitti_> enrico: it's a deb which contains all ubuntu/main translations for a given language
<pitti_> enrico: we strip mo files from the debs and ship them in per-language debs now
<enrico> oh.  And the documentations are in ubuntu main, I guess.  Is that done automatically?
<pitti_> enrico: yes
<pitti_> enrico: does the documentation use gettext?
<seb128> no
<fabbione> pitti_: did you read above?
<seb128> the about ubuntu and other stuff are xml files
<enrico> pitti_: cool
<pitti_> fabbione: yes, I just noticed and reuploaded to Ubuntu (sorry)
<fabbione> ehhee
<seb128> raahhhhh
<seb128> this broken spatial mode is lame
<pitti_> fabbione: dput on my laptop is configured for Debian, on my desktop it's Ubuntu (I mix that up from time to time)
<Keybuk> seb128: itym "spethial" mode ;)
<fabbione> Keybuk: somebody broken planet.d.o
<Mithrandir> fabbione: somebody's broken gluck
<seb128> bah
<fabbione> ah 
<seb128> doko: the ooo patch works fine
<pitti> Kamion: ping
<seb128> pitti: gamin upload, nice :)
<pitti> seb128: thank fabbione :-)
<seb128> yeah, he has done a rocking work on that :)
<pitti> seb128: I spent over four hours with debugging, but he was better
<doko> seb128: thanks for testing
<seb128> np
<seb128> don't forget the french translations for the menu items if you do an upload :)
<seb128> hi mvo :)
<pitti> Morning mvo
<mvo> hey seb128 
<mvo> morning all
<seb128> mvo: like for pitti, Sebasti*e*n :p
<pitti> seb128: you have the right to call me Mertin :-)
<seb128> ah ah
<mvo> morning pitti 
<mvo> seb128: I'll stick with seb, it's otherwise too long in the early morning ;)
<seb128> mvo: just saying that because you have written Sebastian for the translation commit yesterday :p
<mvo> seb128: *cough* ups
<seb128> you though I would not notice ? :p
<pitti> seb128: I suspect you have a procmail rule catching "Sebastian"
<mvo> meh, you have your eyes everywhere :) I'll take better care in the future
<daniels> heh
<daniels> just like Overfiend and Brandon
<seb128> mvo: :p
<seb128> pitti: I'm waiting for a working beagle to track them in fact :p
<mvo> haha
<pitti> elmo: what is the update interval of the rookery mirror? changelogs are lagging behind for about three days
<seb128> oh, speaking about changelogs
<seb128> mvo: is update-manager supposed to get changelogs for hoary packages ?
<mvo> seb128: yes
<seb128> it doesn't here
<seb128> I should open a bug
<seb128> oh, there is one
<pitti> seb128: as I said, changelogs are lagging behind (on changelogs.ubuntu.com)
<seb128> pitti: how much ?
<pitti> seb128: <pitti> elmo: what is the update interval of the rookery mirror? changelogs are lagging behind for about three days
<seb128> I don't remember getting a changelog displayed 
<seb128> ups, sorry
<seb128> k
<seb128> I update too ofter :p
<pitti> seb128: that's because you upload so often :-)
<seb128> often even
<pitti> seb128: same for my CVE overview, I still see bugs that were closed three days ago
<mvo> IIRC elmo said, that the sync will happen now 4 times a day and changelogs are generated at the same rate
<seb128> nice
<mvo> but it isn't right now :/
<pitti> mvo: from now on? or is this supposed to be like this for some time now?
<mvo> pitti: last week I think
<pitti> hmm, then this is broken
<astharot> buongiorno
<d3vic3> bonjour 
<mvo> pitti: 29.Mar is the latest update apparently
<pitti> yeah, that fits
<pitti> Hi astharot 
<astharot> hi MArtin
<pitti> astharot: why in lower case today? :-)
<astharot> pitti: because today I'm less important than other days eheh ;)
<mvo> it's looks like that is exaclty the date that elmo fixed the syncing of rookery 
<mvo> thom, elmo: could someone please have a look why the mirror on rookery is outdated?
<seb128> elmo: loudmouth sync please
<fabbione> i386 warty -> hoary upgrade is GO here
<fabbione> daniels: 2 possible issues
<daniels> fabbione: yep?
<astharot> someone can suggest me if my postfix-gld settings are good? :)
<fabbione> daniels: xfree86-common isn't purged by synpatic.. it's deinstalled but not purged
<daniels> fabbione: right
<fabbione> daniels: oh only that one
<daniels> ok
<fabbione> hmmm no
<fabbione> we might have issues with nvidia
<daniels> i'm wondering if it wouldn't be too invasive to delete it if it matches a certain md5sum
<fabbione> because of nvidia-glx symlinks to the latest version
<daniels> oh?
<fabbione> that might create a mistmatch between kernel modules and userland
<fabbione> i am going to check that in the next test
<fabbione> in the worst we can add an errata that nvidia users must reboot after the upgrade or something
<fabbione> i don't think there is any clean way out of it
<daniels> yeah, i discussed that with mdz
<daniels> there's nothing much we can do there
<daniels> if kernel module != userland, you're pretty screwed
<fabbione> right
<daniels> not just nvidia, really
<fabbione> also X asked me to confirm the resolution on upgrade
<daniels> fglrx as well
<fabbione> it's not a big deal 
<daniels> yeah, that sucks; i've been looking at ways to get around that
<daniels> to mark that we're coming from xfree86 and try to carry the configuration through as much as possible
<daniels> we're at the stage now where it should absolutely not do a single thing to your config on regular upgrades
<daniels> only on reconfigures/first installs
<fabbione> daniels: i think the problem is located in the migration template thingy that happens after the debconf question
<fabbione> i will try to look at it better in the next test
<fabbione> but i don't consider it critical at all
<fabbione> it's the only question that shows up during the entire process
<fabbione> Riddell: ping?
<d3vic3> erm, is there anything like vertical tabs in vim ?
<daniels> fabbione: yeah
<daniels> fabbione: i am checking it out, though :) i was looking at it today
<Treenaks> d3vic3: uh.. long lines of spaces might look like that.. and maybe there's a unicode char that does it?
<Treenaks> d3vic3: why?
<fabbione> daniels: i don't think a fix is worth the risk of breaking X
<daniels> fabbione: yeah
<daniels> i have two more fixes to make anyway
<d3vic3> I mean, tabs as in opening two  files at the same time, and having them side by side 
<Treenaks> d3vic3: :split filename
<d3vic3> oh yah 
<Treenaks> d3vic3: and afaik it's possible to split both horizontally and vertically
<d3vic3> thanks Treenaks 
<Treenaks> but don't ask me how :)
<d3vic3> lol 
<daniels> fabbione: oh, btw
<seb128> pitti: should I update g-v-m to 1.2.1 ? The changelog is pretty short (translations and some small code cleanup) ?
<daniels> fabbione: whenever we update nvidia-glx with a new upstream version, we need nvidia-kernel-common as well
<daniels> fabbione: i'm putting up 7174 packages for testing now
<pitti> seb128: if our patches still apply, yes
<pitti> seb128: if not, I can do it as well
<fabbione> daniels: right.. i forgot about that
<fabbione> daniels: please do so, but be fast. i can test them here
<seb128> pitti: k, I'll have a look and let you know, should be fine
<daniels> fabbione: yeah, I'm uploading i386 now, building amd64 on concordia
<seb128> pitti: BTW should I upload hal too, to fix the .da translation typo ?
<pitti> seb128: if you wish?
<seb128> k, I'll do
<pitti> seb128: you wanna win the upload race again, do you? :-)
<fabbione> daniels: ok, i can test i386 here. we will need to ask mdz or somebody to test amd64
<daniels> fabbione: yeah, I can test amd64 here
<seb128> pitti: yeah :)
<daniels> i don't think anything will break on top of 7167
<daniels> because it's very rare they do an errata release
<fabbione> we have 115 bugs with severity Maj or >
<fabbione> most of which from warty
<daniels> yeah :\
<fabbione> we need a bugzilla cleanup team 
<fabbione> badly
<pitti> fabbione: the other day I closed > 30 bugs in a matter of two hours
<pitti> fabbione: but they keep coming :-/
<pitti> fabbione: we could do a big bz cleaning and love day the day after the release
<fabbione> pitti: yes, i know. i am talking about old warty bugs that are actually fixed in hoary
<fabbione> that would reduce the parsing time of a few eons
<pitti> yes, that's what I mean
<fabbione> does Thommas Hood irc?
<pitti> Morning carlos
<carlos> pitti: morning
<seb128> hi carl
<seb128> hi carlos 
<carlos> hi *
<infinity> daniels : <whine>.. Make the trident driver not suck on my laptop </whine>
<fabbione> RUN TO THE HILLLLSSSS ... RUN FOR YOUR LIIIIIIFES
<pitti> ?
<pitti> fabbione: new kernel upload with fixed inotify? :-)
<fabbione> iron maiden.. never mind. i am on total crack today
<fabbione> wow 10 bugs in 10 minutes
<fabbione> all maj
<fabbione> that's a good rate
<pitti> fabbione: indeed. it took me half an hour to close one :-)
<fabbione> pitti: i think they are mostly from debian import thingy
<fabbione> 8609 is one of them for ex
<fabbione> pitti: and it took me 3 days to close 7078
<pitti> fabbione: well, I meant a real one :-)
<fabbione> yeah
<fabbione> wasn't 7078 a real one?
* fabbione wonders now
<seb128> pitti: the configure change is "mount_path umount_path" to "mount_program umount_program" ?
<pitti> seb128: erm, what do you mean exactly? this sounds a bit weird
<seb128> pitti: debian/patches/20_specify_programs.patch
<pitti> seb128: this allows to change /bin/mount and /bin/umount to other programs (pmount) with a --configure option
<seb128> pitti: you regenerate the whole configure ? in fact there is only one conflict to the patch one it
<pitti> seb128: the patch contains the configure changes
<seb128> the conflict is on the "ac_subst_vars=" line, 
<seb128> I know, just wondering how you update it usually
<seb128> you run the whole autostuff ?
<pitti> seb128: hmm, I don't know by heart any more, but I think I ran autoconf only
<seb128> k, thanks
<seb128> right, that seems to do the trick
<seb128> thanks
<pitti> bah, this damn wiki breakage also killed my USN
<daniels> infinity: Dude, you said trident.  Here's $5, get another laptop.
<daniels> infinity: Or spend a lot more than that, but get an X40. :)
* Lathiat grins at daniels 
<fabbione> daniels: i still have a laptop with a trident.. shuuush boy
<Lathiat> the magic is to buy hardware kernel hackers have
<Lathiat> and X hackers, and suspend hackers
<Lathiat> (if its a laptop)
<daniels> fabbione: that's your fault for not having an X40 :)
<infinity> daniels : Well, it works with vesa, it's just irritating. :)
<daniels> infinity: Heh.  CyberBlade?
<infinity> daniels : Nasty video corruption with the trident driver.  Oh well.  I don't care enough to worry.
<daniels> Heh.
<infinity> 9525DVD.
<infinity> Not that the DVD means much, since there's no DVD player in the machine.
<daniels> I blame fabbione; he has one, so he should fix it. :)
<daniels> Hah.
<Lathiat> haha
<fabbione> daniels: you know you just set a gdb break on your life span?
<fabbione> :P
* infinity should get going soon.
<infinity> Too much hacking with too little result makes Adam a grumpy boy.
<fabbione> i need to get some serious food today
<fabbione> it's 7 hours that i am awake and i still have to eat breakfast
<trukulo> daniels, one question: is boot on fresh hoary as fast as warty updated to hoary?
<fabbione> trukulo: yes it should be exactly the same modulo user crap
<pitti> fabbione: why do you get up at 4 am?
<seb128> pitti: bah forget about g-v-m 1.2.1 in fact, they have broken the string freeze
<fabbione> pitti: insomnia caused by stress
<trukulo> fabbione, so i don't understand, now hoary boot seems slower in my laptop than in warty
<fabbione> trukulo: you asked something different
<fabbione> trukulo: boot time of warty != boot time of hoary
<infinity> trukulo : The overall boot process may have slowed down due to mmapping larger binaries, or who knows what.
<pitti> seb128: so we just skip it for hoary?
<trukulo> fabbione, no, wait, i mean
<trukulo> hoary boot is supposed to be faster than warty, right?
<seb128> pitti: right
<pitti> argh, not another PHP vuln... *grumpf*
<fabbione> trukulo: it should be.
<fabbione> but there are too many vars to optimize that
<infinity> pitti : The imagesize one?
<fabbione> kernel, hw, etc.
<infinity> pitti : I'm working on patches for that right now.
<pitti> infinity: yeah
<pitti> infinity: oh, cool
<trukulo> so if hoary boot is slower than warty... it's because i didn't installed freshly?
<infinity> pitti : And hoary isn't vulnerable.
<trukulo> fabbione, i know, i know
<pitti> infinity: http://www.idefense.com/application/poi/display?id=222&type=vulnerabilities&flashstatus=true  that one
<trukulo> but i looked everything and didn't understand it
<pitti> infinity: neat, why not?
<trukulo> just wanna know if anyone has compared booting speed in fresh hoary, and updated from warty
<infinity> pitti : I'll upload fixed warty sources tomorrow and ping you to do a security announcement.
<pitti> infinity: cool :-)
<infinity> pitti : hoary isn't vulnerable because it's CVS updated to "almost 4.3.11, but not quite"... It includes those fixes, at any rate.
<fabbione> trukulo: that should be the same.
<pitti> infinity: you rock :-)
<fabbione> trukulo: but no.. i don't have numbers
<infinity> pitti : Tell mdz and sabdfl that.. <cough>
<trukulo> fabbione, and impressions at least? can you compare it, by eye?
<fabbione> trukulo: there are no impressions in benchmarking. either you measure or not
<fabbione> trukulo: plus i never reboots my machines
<fabbione> or almost
<infinity> pitti : Do you prefer mail, or being tackled on IRC when I see you?
<fabbione> and when they boot i do it remotly and waiting for a ping to come back :)
<pitti> infinity: IRC will be fine
<fabbione> anyway
<fabbione> time to cook food
<fabbione> later
<infinity> pitti : Alright.  I'll have packages for you tomorrow, then.
<dholbach> hey!
<dholbach> so you all heard what happened to the wiki?
<dholbach> ... heard the explanation?
<daniels> do tell!
<dholbach> Sorry about the wiki reversion. A data file from Apr. 1st was used to 
<dholbach> rebuild the system (which was getting very flaky). The re-build data 
<dholbach> structures were re-inserted on Apr. 3rd causing the changes made in 
<dholbach> those two days to drop out. However, those changes do exist in a backup 
<dholbach> copy and we will fish them out today (Apr. 4th) and merge them back in 
<dholbach> where possible. Sorry for any irritation we have caused.
<daniels> oops
<pitti> dholbach: oh, I just recreated my Linux USN which got dropped, too
<dholbach> pitti: i'll go on, rebuilding my list, must do it for my mental health :-)
<pitti> D'oh
<pitti> dholbach: but now that you know that the list can be restored, why bother doing it again?
<dholbach> hrm... not that i don't trust henrik and his crew, but it needs to be done soon
<Mithrandir> pitti: do you have any thoughts on who should run fsck on usb thumbdrives?
<dholbach> pitti: i think it will take them some time
<Mithrandir> pitti: pmount just mounts it and the kernel complains a bit
<pitti> Mithrandir: hmm, does vfat have a mount counter?
<pitti> guess not
<Mithrandir> pitti: I don't use vfat on my thumb drive.
<Mithrandir> (or at least not on the one with my gpg key and such)
<pitti> Mithrandir: I never thought about this TBH
<Mithrandir> pitti: we might want to think about it for breezy
<pitti> yeah, indeed
<pitti> Mithrandir: for ext2 etc. the check _could_ be integrated into pmount, but it will take awfully long, I guess
<pitti> Mithrandir: like, pmount --fsck /dev/foo
<Mithrandir> pitti: yeah, it should then give feedback to g-v-m or something, so it can pop up a "checking file system"
<pitti> yeah
<pitti> Mithrandir: added to my todo list
<Mithrandir> cool, thanks
<ogra> morning
<Mithrandir> hi ogra
<pitti> Moin ogra
<thom> fabbione: jdthood iirc (Thomas Hood)
* mvo is off to get some food
<seb128> mvo: hum, food, good idea :)
<mvo> :)
<pitti> ARGH, new mozilla vulns, too (hello thom :-( )
<thom> _more_?
<thom> geez
<pitti> infinity: still here?
<pitti> thom: infinity wants to join your "mozilla fix for warty" strike force, if you want :-)
<daniels> ok guys, *ANYONE* with an nvidia card, please whack 'deb http://people.ubuntu.com/~daniels/l-r-m/ $(ARCH)/' in your sources.list and upgrade, to test if the new drivers up there work.  this is hoary fodder.
<daniels> whether it works or fails, I'd love to know about it
<pitti> daniels: this is even newer than fabbione's crack?
<daniels> indeed
<daniels> they put out an errata release
* pitti upgrades
<daniels> thanks dude
<pitti> daniels: glxgears, glxinfo, tuxracer and mplayer work fine
<pitti> daniels: however, it failed at first because I still had the old module loaded
<pitti> daniels: what about adding "rmmod nvidia && modprobe nvidia" to postinst configure on upgrading?
<Kamion> pitti: yo?
<pitti> Kamion: AFAICS the "dhcp" source package is only in main because of the udeb, right? Is there any chance for breezy to build an udeb from dhcp3?
<pitti> Kamion: Good morning, BTW :-)
<thom> Kamion: did you see what i wrote at you over the weekend? (regarding skewed clocks during install)
<Kamion> pitti: udeb isn't used 'cos it's too enormous
<pitti> Kamion: the dhcp3 udeb you mean?
<pitti> hmm, ok
<Kamion> which I think continues to be a valid reason for Ubuntu, even if we care a bit less about size than Debian; make dhcp3-client-udeb smaller :)
<Kamion> thom: I saw similar-looking bug mail, dunno if that was from you too
<pitti> Kamion: oh, I just wondered, because the source package is in main, but all debs are in universe
<pitti> Kamion: bug mail> no, not from me
<thom> Kamion: no, not my bug mail
<Kamion> thom: #8496
<pitti> ogra: is your hwdb server down ATM?
<ogra> nope
<ogra> i'm looking at it
<pitti> ogra: I just tried to submit data from my desktop, it hangs at "Connecting to..."
<ogra> yeah, might be slow, i'm waiting for a review of some of my bzip server code to speed things up <hint>
<ogra> *g*
<thom> elmo: thanks for the enigmail sync
<thom> Kamion: <+quinophex> thom: no, it was a different error message
<thom> aaargh, evms is giving me dm-linear warnings and not setting up my /home
<thom> this is *not* good
<thom> (clean install)
<pitti> elmo: remstats sync, please
<elmo> pitti: nothing to sync?
<seb128> elmo: loudmouth sync please :)
<elmo> [NOT Updating - Modified]  loudmouth_0.17.2-1ubuntu1 (vs 0.17.2-2)
<elmo> ok to override?
<pitti> elmo: hmm, 1.0.13a-5 is in sid
<seb128> elmo: yep
<elmo> 07:24:27@newraff| ~ $m remstats -s unstable
<elmo>   remstats |  1.0.13a-4 |      unstable | source, all
<elmo> pitti: ?
<elmo> seb128: done
<seb128> thanks
<pitti> elmo: odd: http://packages.qa.debian.org/r/remstats/news/1.html
<pitti> elmo: ah, it's still in incoming
<pitti> elmo: sorry
<Robot101> seb128: does ubuntu patch gaim?
<froud> seb128: if you can join #ubuntu-doc for a few minutes to discuss i18n it would be good
<ogra> oh froud, while youre here....
<seb128> Robot101: hum ? no, basically we have the debian package
<seb128> Robot101: we had a patch for eds 1.2 IIRC, but that's not required with the current version
<seb128> why ?
<ogra> froud, i'd like to have a list of the collected data in the hwdb-doc and the bug url should get changed to malone or bugzilla instead of the mailing list....i'll mail you some changes....
<froud> ogra: send mail with wish list :-)
<ogra> froud, i'll do :)
<froud> ;-)
<Robot101> seb128: watch out for eds 1.2, it has some md5 functions which are called the same as stuff in the oscar prpl, so you could get odd crashes on AIM I think... some local symbols needed somewhere, but enabling them breaks the perl plugin
<Mithrandir> isn't the perl plugin broken already?
<Robot101> it's... er... bitrotting quickly
<froud> pitti: can you join #ubuntu-doc to discuss i18n
<Robot101> it works for some things :)
<pitti> yes
<ogra> mvo, ping
<mvo> ogra: pong
<ogra> ah, great
<ogra> mvo, we have a serious problem with gksudo
<pitti> carlos: Hi, can you please join #ubuntu-doc for a bit?
<mvo> ogra: tell me please
<ogra> mvo, if i run gksudo time-admin and click ok in the app, the screensaver daemon crashes....
<ogra> mvo, doesnt happen with sudo time-admin....
<ogra> mvo, the prob here is, he user doesnt recognize the screensaver crash if he runs it from the menu...
<ogra> s/he/the
<mvo> ogra: let me see if I can reproduce it
<ogra> mvo, just click "Ok" in the time-admin tool
<ogra> the Ok normally restarts xscreensaver cleanly....
<ogra> but ti doesnt come up again on gksudo usage....i suspect the locking code of gksudo colides with xscreensaver
<ogra> collides even
<mvo> ogra: "gksudo time-admin" and then clicking ok seems to work here. any additional steps I need to take? 
<mvo> ogra: let's go on /msg to not spam the channel too much, ok?
<smurfix> elmo: please sync gimp-ufraw
<ogra> mvo, nope, even seb128 could reproduce it yesterday
<seb128> mvo: you don't get a crash dialog, but try to lock the screen now
<mvo> seb128: oh, ok. no longer working
<elmo> smurfix: source package names in future pls
<elmo> smurfix: done
<smurfix> elmo: OK, I'll remember, thanks
<zyga> mvo: hey
<mvo> hey zyga 
<pitti> elmo: btw, can you please remove the b0rken cyrus-sasl and openswan uploads from the warty-security queue?
<elmo> pitti: how come?
<pitti> elmo: they are sitting there for ages
<elmo> ...
<pitti> elmo: you still know the "cyrus-sasl did not build for warty" mess?
<pitti> elmo: the libdb3 vs libdb4.2 FTBFS
<pitti> elmo: I tried to fix it, but it's nontrivial and universe only
<elmo> what about openswan?
<mdke> dholbach, ping
<dholbach> mdke:  pong
<mdke> wow
<mdke> 5 seconds
<dholbach> ;-)
<mdke> dholbach, listen, you are aware of the problems with the wiki
<mdke> ?
<dholbach> mdke: yes
<mdke> ok fine
<mdke> just checking
<dholbach> mdke: i'll msg you the text
<mdke> i thought as the top wiki contributor i should check that you knew
<mdke> :p
<pitti> elmo: similar issue, opensc never built for warty (because it b-deps on cyrus-sasl)
<pitti> elmo: lamont described the situation the other day
<CarlK> trying to test Daniel's
<CarlK>  1.0.7174 nvidia package, - is there an apt-get way of doing this? 
<ogra> CarlK, add his repo
<CarlK> added
<ogra> update and install
<koke> elmo: is already my key on the ring? (sorry for the insistence :))
<CarlK> apt-get install linux-restricted-modules-2.6.10-5-386 -is that all I need?
<dholbach> OH YES... i did it again - pitti: wiki.ubuntu.com/AptGetOrg
<pitti> dholbach: congrats :-)
<ogra> CarlK, just do an upgrade....
<pitti> CarlK: nvidia-glx as well, I suppose
<dholbach> elmo: after reviewing the apt-get.org stuff twice, there are some packages left which pitti will review for security stuff and some need license revision, apart from that "GO" :-)
<CarlK> woa... 76meg
<ogra> yeah, and a big applause to dholbach from everyone please, he really reviewed all the apt-get.org repos !!
<dholbach> ogra: twice
<dholbach> ;-)
<ogra> twice !!
<Robot101> so why isn't this stuff in debian already? :)
<pitti> it shouldn't :-)
<ogra> Robot101, make dholbach a DD ;)
<CarlK> what does it take to get apt to use a proxy? (squid is setup, just need to tell apt to use it)
<dholbach> ogra: hrm... i wouldnt sign all of them :-)
<CarlK> whoops, ill do this part in #users
<ogra> dholbach, me neither :)
<Robot101> CarlK: in /etc/apt/apt.conf, Acquire::http::Proxy "http://server:port/";
<CarlK> thats easy enougn - thanks
<ogra> CarlK, export http_proxy="http://your.proxy.org:8080" works too
<Lathiat> and ftp_proxy
<ogra> Lathiat, for http repos ?
<Lathiat> nah if you have ftp repos
<ogra> heh
<Lathiat> most http servers will fetch the for you
<Lathiat> s/http/proxy
<mdke> heh we're top of distrowatch 6 months :D
<Lathiat> yeh :)
<CarlK> shoudn't I see a nvidia splash as X starts?
<Lathiat> not if your not using the binary drivers
<ogra> and place seven for 12 months ;)
* ogra reboots to test the new drivers
<CarlK> is there a shell command that will report if I am using the binary drivers?
<pitti> CarlK: try "grep /etc/X11/xorg.conf"
<elmo> koke: there's still some problems, I'm afraid - I'm working on them with mako and will let you know as soon as it is
<pitti> CarlK: erm, "grep nvidia /etc/X11/xorg.conf"
<carlos> pitti: I'm back
<elmo> dholbach: mm, remind me where you put the list?
<carlos> pitti: do you need me?
<pitti> Hi carlos
<pitti> carlos: in #ubuntu-docs
<dholbach> elmo: http://wiki.ubuntu.com/AptGetOrg
<elmo>  MERGE ON PAIN OF DEATH
<elmo> *giggle*
<dholbach> elmo: DONT! TAKE! THOSE! :-)
<doko> d3vic3: zope-backtalk packaging looks ok
<fabbione> thom: thanks
<kernel_panic> hi
<kernel_panic> thom: hi
<pitti> seb128: so you will upload all gnome 2.10.1 stuff by wednesday?
<pitti> seb128: do you know whether all upstream packages contain all translations that have been submitted to gnome so far?
<pitti> seb128: I need to know whether I shall take Adi's or upstreams version of the Xhosa translations
<dholbach> pitti: from what i heard it'll be 2.10.(1/2) or something
<Kamion> pitti: msgmerge them?
<pitti> Kamion: Adi submitted them to gnome already
<elmo> thom: err, dude
<fabbione> yay for evolution-exachange! it's your birthday
<elmo> thom: that enigmail has a b-d on a newer-than-hoary thunderbird
<pitti> Kamion: however, msgmerge isn't a bad idea (I just need to integrate this into my scripts)
<dholbach> i'm off for now, doing the laundry *wave*
<thom> Mithrandir: are you not planning to update t-bird?
<thom> kernel_panic: hi
<kernel_panic> thom: as i said for the bug 8591 , the command I was running is "apt-get dist-upgrade"
<Mithrandir> thom: I am, I just haven't done yet. :(
<CarlK> ahh... thats the dist-upgrade command I was looking for !
<thom> Mithrandir: poor enigmail is in depwait waiting for you ;-)
<Mithrandir> thom: ok, doing it now, then
<d3vic3> doko, cool 
<d3vic3> doko, one more, fine ?
<thom> kernel_panic: hmmph. i just did an upgrade from warty to hoary with no problems at all
<thom> kernel_panic: had you made any major changes to your warty install?
<kernel_panic> thom: yet I'm trying a apt-get remove mozilla-firefox
<kernel_panic> thom: I just installed the warty 3 days ago 
<kernel_panic> thom: no major changes
<asdasd> yo
<thom> kernel_panic: well, worksforme and works for mdz
<Mithrandir> thom: building it now, I'll tell you how it works once it's done
* fabbione -> afternoon nap
<ogra> guys, have you seen that ? http://lxer.com/module/newswire/view/33934/index.html
<zul> morning
<thom> ogra: huh.
<pitti> ogra: hmm, odd
<crimsun> heh
<ogra> isnt it trademark protected ?
<Robot101> ogra: imagine-msn.com isn't microsoft's site afaict
<thom> Robot101: (C) 2005 Microsoft
<ogra> Robot101, copyright says something else
<ogra> heh, thom 
<Robot101> yes, but see whois
<Robot101> it could just be phishing hotmail/MSN passwords
<Robot101> it's not spaces.msn.com
<Robot101> which looks like the real thing
<ogra> Robot101, yeah it has the logo as favicon
<thom> Robot101: look at the favico for spaces.msn.com
<Robot101> oh ok
<pitti> seb128: any word about a string freeze? I have to import Adi's stuff and gnome xh translations and all that
* Robot101 was just being overly skeptical
<Robot101> in which case, bastards :P
<seb128> pitti: what string freeze ?
<pitti> seb128: I'm asking for one :)
<seb128> GNOME ? hoary ? desktop .. ?
<seb128> the strings are not changing
<Treenaks> mjg59: do you have any clue about "Smart Batteries" and ACPI?
<pitti> seb128: hoary/main
<seb128> but I'm updating translations this afternoon
<pitti> seb128: but primarily gnome
<seb128> the desktop is string frozen for some weeks
<seb128> ie: GNOME since 2.10.0
<pitti> seb128: okay, please prod me if you uploaded all new packages
<seb128> k
<ogra> Treenaks, hal has this information in the BIOS device.... you could hack something to detect it :)
<Treenaks> ogra: someone posted a driver on acpi-devel in January, but I can'd find anything newer than that
<Treenaks> ogra: and that driver conflicts badly with the ac_adapter and battery modules
<ogra> Treenaks, i saw that anywhere....but i doubt it is stable enough for usage
<Treenaks> oh well... it'll stabilize eventually :)
<mvo> ping ogra 
<ogra> Treenaks, sure, but unlikely before hoary ...
<Treenaks> ogra: I'm ok with breezy :)
<ogra> ah
<robertj> schwwet. Right click on a disk and select Duplicate in upstream gnome-cdburner
* mvo has a appointment with his optician  now
<pitti> elmo/thom: can I please have tcl8.3-dev in concordia's hoary-i386 dchroot?
<elmo> it's already installed?
<elmo> (hoary-i386)root@concordia:~ # dpkg -l tcl8.3-dev | tail -1
<elmo> ii  tcl8.3-dev     8.3.5-4        Tcl (the Tool Command Language) v8.3 - devel
<pitti> elmo: ah sorry, that was a build-conflicts
<pitti> elmo: nevermind
<pitti> bah, build-conflicts is so ugly...
<elmo> yes
<elmo> I wish they'd never been added to policy at all
<elmo> Kamion: ?
<kernel_panic> thom: I did "apt-get remove mozilla-firefox" and yet I've the new version of firefox installed ... weird, isn't it ?
<Mithrandir> how fun, the new mozilla just segfaults on startus
<Mithrandir> s/.$/p/
<thom> Mithrandir: moz-browser?
<Mithrandir> nah, thunderbird
<thom> ah
* Mithrandir tries uninstalling enigmail. :P
<thom> heh
<Mithrandir> nah, seems to work, probably just the running one which happened to crash
<Kamion> elmo: yo?
<elmo> Kamion: doesn't matter, sorry
<Kamion> 'k
<zul> oh that sucks...kernel 2.6.10 ftbs with gcc-4.0
<daniels> pitti: yeah, i dunno that we can do that though, because if you upgrade from within x, the refcount will still be 1 thanks to your current session
<pitti> daniels: yeah, I noticed that afterwards
<mdke> which kernel is shipping with hoary? 2.6.10 or 11?
<daniels> .10
<mdke> ok thans
<mdke> k
<dholbach> re
<pitti> Mithrandir: yay for tbird :-) I add the CANs to my list; could you add them to the changelog in the next update?
<pitti> Mithrandir: I'll mail them to you
<Mithrandir> pitti: sure, I just didn't see them on mozilla.org
<pitti> Mithrandir: they are in the detailled advisories
<Mithrandir> I'm lazy, I guess. :P
<pitti> Mithrandir: i. e. if you click on the link on http://www.mozilla.org/projects/security/known-vulnerabilities.html
<pitti> Mithrandir: no worries :-)
<Mithrandir> yeah
<pitti> Mithrandir: I have my override database for this, but it is nicer to keep them in the changelogs
<Robot101> pitti: gaim has some IRC escaping problems that are fixed in 1.2.1... 1.1.4 and 1.0.0 are almost definitely vulnerable... do you want a patch?
<pitti> Mithrandir: I mail you
<Mithrandir> pitti: thanks
<pitti> Robot101: I read about this, sure :-)
<Robot101> pitti: I had to wait for sf's crappy CVS to let me pull the appropriate diff out
<Robot101> I should be able to now :)
<daniels> ok, new l-r-m with nvidia-glx 1.0.7174 uploading now
<pitti> Mithrandir: oh, most of the detailed text don't have CANs, sorry :-) (just looked at the first one)
<pitti> Mithrandir: so I dig them out from the CVE database
<Mithrandir> pitti: I'll whatever you send me, so you'll be happy. :)
<CarlK> daniels - I have 2 nvidia boxes - you want any more tests?
<daniels> CarlK: sure, can't hurt at all :)
<daniels> it'll be about 1.5h before it hits the archive, all things considered
<daniels> my uplink is crap
<CarlK> if I install hoary from the current install.iso, add your repo url to /etc/apt/sources.list, apt-get update - then what?
<daniels> apt-get dist-upgrade
<CarlK> what about editing .conf files and such?
<daniels> oh right
<daniels> sudo nvidia-glx-config enable
<CarlK> lol
<CarlK> that could explain why nothing seemed to be working
<CarlK> root@tsp2b:~ # nvidia-glx-config enable 
<CarlK> -bash: nvidia-glx-config: command not found
<daniels> and install the nvidia-glx package, sorry
<daniels> with that, I'm going to bed; got a crippling headache
<CarlK> take care
<CarlK> drink some water ;)
<dholbach> daniels: hope you feel better soon
<Baby> hi koke
<dholbach> bbl
<pitti> Hi mvo, can you see again? :-)
<ogra> heh
<mvo> pitti: going to the optician is always depressing. but yes, I'm back :)
<seb128> mvo: have you get an updated translation for synaptic ?
<rjo> Where can I find the scripts used to generate the live CDs? I don't want to simply "customize" the images, bute regenerate them.
<mvo> seb128: not yet
<pitti> mvo: new Xh for synaptic is in your mbox :-)
<mvo> pitti: thanks!
<seb128> k
<seb128> mvo: could you update g-a-i for the french translation today ? :)
<koke> Baby: hi!
<mvo> seb128: I did a g-a-i upload today, hasn't it hit the archive yet?
<seb128> mvo: ups, I've not noticed it, sorry
<seb128> I've not updated today :)
<mvo> seb128: I'm not sure now, maybe I intended to upload it only :) let me check
<koke> about translations, is there any way to know which packages have ubuntu patches which introduce new strings atm??
<mvo> seb128: well, I think I only itended to upload :) I did it now
<seb128> thanks
* wasabi having an annoying Hoary/Gnome problem he should probably just file a bug against instead of complaining about.
<CarlK> Installed the April 1 hoary, the fools splash version ;), the only thing I have done was test the nvidia drivers, and it has decided to ignore the 3com nic, unless I modprobe it - anyone want to poke at it before I reinstall ?
<pitti> carlos: here?
<koke> pitti: I have a 07_translations.patch for rhythmbox with updated spanish strings
<koke> but it seems there are quite more packages with new strings
<pitti> koke: argh, I uploaded rhythmbox some two hours ago :-/
<pitti> koke: but just mail them to me
<pitti> koke: Ubuntu-specific strings?
<koke> pitti: I guess, it's 100% translated in HEAD
<koke> http://l10n-status.gnome.org/HEAD/es/extras/index.html
<pitti> koke: we don't use head, we use 2.10 so far
<pitti> koke: however, I have a script that can import from gnome
<koke> pitti: I know , but I don't see rhythmbox in http://l10n-status.gnome.org/gnome-2.10/es/desktop/index.html
<smurfix> Kamion: 
<mvo> elmo: do you have a idea why rookerys mirror is not up-to-date?
<elmo> mvo: gar, 'cos I'm a muppet
<aj> a pirate muppet by the sounds of it
<elmo> mvo: fixed - sorry
<Robot101> pitti: got a patch... address?
<elmo> (wrong name of sync script in crontab)
<mvo> elmo: thanks :) 
<pitti> Robot101: martin.pitt@ubuntu.com
<pitti> elmo: great, thanks
<zul> bbl
<Robot101> pitti: sent
<mdz> morning
<pitti> Good morning mdz
<ogra> morning mdz 
<mvo> morning mdz!
<Kamion> smurfix: pong
<thom> morning mdz
<seb128> hi mdz
<smurfix> Kamion: Where do the keyboard name translations live? #8378 notes that the Norwegian one seems to have misplaced a comma
<Kamion> smurfix: console-data/debian/po/, I think
<Kamion> msgid "cz-lat2"
<Kamion> msgstr "Tsjekkisk, cz-lat2"
<Kamion> that looks promising
<Kamion> might be others
<smurfix> Kamion: OK, I'll dig through them
<Kamion> surprised that po-debconf doesn't fix that up though
<Kamion> smurfix: thanks
<elmo> ugh
<smurfix> Kamion: does po-debconf know to count commas?
<mdz> daniels: ping?
<Kamion> smurfix: I've no idea. I thought that was half the point of the __Choices: thing, but I don't really know.
<mdz> seb128: so about how many 2.10.1 tarballs have been released?
<seb128> mdz: 5-6
<smurfix> Kamion: OK, fixed translations uploaded. Telling the __Choices builder to complain will have to wait a bit.
<ogra> has anybody here experience with manning books ? 
<mdz> "it also works fine, except that X totally locks up if I try to start kde or any kde program in gnome"
<mdz> that doesn't sound very fine :-(
<fabbione> mdz: when you have time, can you kindly set l-r-m bitch to daniels? kthxbye
<fabbione> (in bugzilla i mean)
<pitti> koke: thanks for the patch; btw, can you please send debdiffs in the future?
<CarlK> mdz - (about 2 hours ago) daniels: with that, I'm going to bed; got a crippling headache
<Kamion> smurfix: thanks
<smurfix> Kamion: NP
<ogra> argh....
<ogra> seb128, who made the german translation for my .desktop file ???
<pitti> ogra: probably me
<ogra> pitti, Gertedatenbank ??
<pitti> ogra: any better suggestion?
* ogra would have preferred Hardware Datenbank
<pitti> "Hardware-Datenbank" would be fine for me, too
<pitti> but it's still Denglish
<ogra> but its a bit more descriptive....i think
<pitti> ogra: feel free to reupload and correct it :-)
<koke> pitti: sure :)
<ogra> pitti, i have to merge that anyway, because the new source package misses my work from the last three days....
<ogra> pitti, but since its only the .desktop file....
<pitti> ogra: so much the better, then it's not a translations-only upload
<ogra> pitti, 'm just waiting for a go for the server code ;)
<pitti> ogra: oh sorry, do you need this for the package?
<ogra> but now i have to care for my GF a bit, its her b-day today
<pitti> ogra: I was busy with other stuff, but I can look at it in 5 minutes if you need 
<mvo> ogra: send greetings from the team then (at least from me)
<ogra> pitti, during the day would be fine....i'll need the new server for the bzipped data transfer :) even tomorrow would be fine, i just want 1-2 days to make sure its working fine
<ogra> mvo, i'll do :-D
<pitti> koke: uploaded, thanks
<mvo> zyga: thanks for your nice site about update-manager! that's really appreciated!
<pitti> ogra: oh, you switched from perl to python?
<ogra> yup
<ogra> and added bz2 compression
<ogra> pitti, i want it all in python...no code mixing :)
<mdz> Kamion: was the debbugs mirror on macquarie not being updated or something?
<mdz> there is a flood of bugs from debbugs today
<mdz> and many of them are several days old
<pitti> ogra: do you know about the cgitb module? 
<elmo> mdz: spohr's IP changed
<elmo> that possibly broke it
<pitti> ogra: it might be worthwhile to add this
<mdz> ah
<ogra> pitti, the one that spams my /tmp with logfiles in the defult setup ? ;)
<fabbione> elmo: due to dns cache expiration?
<ogra> pitti, i'll add it :)
<pitti> ogra: you can also have it log to the client for debugging :-)
<pitti> ogra: just a suggestion, that's in no way relevant
<elmo> hmm, except debbugs mirror should be mirroring off merkel, so I may be randomly making stuff up
<Kamion> mdz: spohr's IP recently changed; it's possible that macquarie only just noticed
<ogra> pitti, are you fine with the regex and input length checks so far ? i yes, i'll add them to the other online parts too...
<fabbione> elmo: at the time i did setup the mirror you told me to use spohr :)
<Kamion> oh, elmo said that
<Kamion> fabbione: the merkel mirror might not have existed, or something
<pitti> ogra: I'm still doing RTFM before evaluating your script 
<fabbione> elmo: also.. if you want to move the debbugs mirror as a system cron on a dedicate user, you can kill my script and my access to maquarie
<ogra> pitti, heh
<fabbione> Kamion: i really can't remember.. it was almost a year ago
<elmo> fabbione: eh, what access to spohr do you have?
<fabbione> elmo: i don't have access to spohr
<trulux> heya folks
<pitti> hi trulux
<fabbione> but the debbug mirror at the DC is done under my user on macquire? or whatever name
<elmo> fabbione: so how are you mirroring it off there?
<fabbione> elmo
<fabbione> i really don't remember
<fabbione> let me check
<fabbione> elmo: FROM=bugs-mirror.debian.org
<trulux> hey pitti 
<trulux> howya?
<fabbione> macquarie:/srv/debzilla.no-name-yet.com/scripts
<elmo> yah, that's merkel
* koke has to go...
<fabbione> elmo: if you want to run that stuff at system level, you can close my account to macquarie
<elmo> fabbione: yah
<fabbione> elmo: it's the only reason why i still have access
<fabbione> elmo: if you want to do it now, i will kill the cronjob
<Kamion> mdz: beyond the above, I don't actually have access to macquarie, so nothing to do with me :-)
<mdz> Kamion: oh, I thought it was you who set up the debbugs mirror etc.
<fabbione> mdz: i just handed over the debbugs mirror to admins@
<fabbione> mdz: no i did.. 
<mdz> ah, right
<elmo> fabbione: don't have time right now
<mvo> Kamion: do you know about the message from the installer "sed unsupported commend T" right after "Enable framebuffer" ? it scrolls by pretty fast (before the "Choose language" screen)?
<fabbione> elmo: ok..
<elmo> and I'm not taking responsiblity for it
* fabbione readds the cronjob
<elmo> my job is to admin, not take over orphaned services that people are bored of
<fabbione> elmo: that wasn't the meaning of handing over the mirror
<fabbione> i know how paranoid you are about people having accounts on machines
<fabbione> and since the crontab is the only reason why i have access there
<fabbione> ...
<Kamion> mvo: yeah, it's a sed command unimplemented by busybox, I'd been meaning to implement it - seems to be harmless AFAICT though
<CarlK> mvo - I have seen  "sed unsupported commend T" a few times - I am about to install, I'll grab a picture of it ;)
<Kamion> CarlK: no need, I've seen it too, I know what it is
<CarlK> k
<thom> mdz: are you running evms on any of your current hoary boxes? having any problems with it?
<mdz> thom: yes running, no problems
<thom> hrmph
<mdz> I'm not doing anything particularly fancy on hoary boxes, though
<mdz> no EVMS-root
<Mithrandir> do we support evms-root now?
<Mithrandir> and if so, can you resize /?
<mvo> Kamion: ok, I thought so, just wanted to be sure :)
<Mitario> lo veryone
<thom> i just have an evms /home which is a software raid 1 of two disks - and i get some weird dm-linear errors when i boot, and no /dev/evms/home , although /dev/evms/md/md1 is there and seems fine
<Mithrandir> thom: yeah, that won't work
<Mithrandir> no chance, can't fly, not with the bd_claim patch, unless evms keeps track of what goes where
<Mithrandir> use RAID5 instead. :P
<thom> Mithrandir: it worked until friday, at least
<Mithrandir> it shouldn't have.
<Mithrandir> or at least, I would imagine it shouldn't have.
<thom> so what does this bd_claim patch do, and why?
<Mithrandir> make it possible to claim a device multiple times.
* lamont lunches
<Mithrandir> which is very nice if you want to use legacy and evms partitions on the same drive.
<mvo> hey Mitario 
<Mithrandir> (else, scanning for partitions claims the device, so you can't find evms volumes on it afterwards.  AIUI)
* Mithrandir is off for dinner
<Treenaks> what's the average size of langpacks?
<mdz> pitti: can you do a quick review of qscintilla for main?
<mdz> pitti: and sip4-qt3?
<seb128> mvo: I've sent you a mail with the update-manager french translation update, could you update the package with it ?
<mvo> seb128: yes
<seb128> thanks
<seb128> (the mail with the typo fix)
<seb128> mvo: can you change that too
<seb128> msgstr "Ajoute un _cdrom"
<seb128> to msgstr "Ajouter un _cdrom"
* T-Bone boggles at that french translation of CD-ROM ;P
<pitti> mdz: I'm back, I do it now
<mdz> pitti: thanks
<mdz> we have an unfortunate situation with hpijs
<mdz> I asked elmo to import hplip for universe, without realizing that it superseded hpijs (main)
<mvo> seb128: mind to send it as a patch also? 
<mdz> I see little choice but to push forward with the hplip-built hpijs
<pitti> mdz: do you know anybody with an InkJet to test this?
<pitti> mdz: I don't :-(
<seb128> mvo: k, a sec
<mvo> seb128: thanks
<mdz> pitti: I do
<mdz> and it works fine here
<mdz> but we have received bug #8102
<mdz> our only other option is to re-version the old hpijs to supersede the hplip one
<mdz> infinity: around?
<seb128> mvo: should be fine now :)
<mvo> seb128: thanks
<mvo> seb128: I'll be away for ~1,5h now, but I'll merge and upload it when I'm back
<seb128> k
<seb128> pitti: when have you planned to update the language-packs ?
<pitti> mdz: qscintilla is fine for me
<seb128> mvo: do you mind if I update the package with it if pitti wants to roll the language-packs updates ?
<mvo> seb128: go ahead
<pitti> seb128: I want to upload -update packages still today, and final fresh base packages on Wed or Thu
<seb128> pitti: k
<seb128> mvo: k, thanks
<pitti> seb128: I can wait a bit if necessary
<mvo> but i'll be back soon and there is a pending xhosa translation 
<seb128> pitti: time for dinner here, in 1 hours that's fine with you ?
<pitti> seb128, mvo: that's fine, I'm here tonight and I can upload in ~ 2.5 hours, too
<seb128> cool
<seb128> thanks
<seb128> bbl dinner :)
* pitti usually goes to bed around 2300
<pitti> and no gf today :-)
<pitti> seb128: enjoy
<mvo> seb128, pitti: ok, will be the first thing I do when I come back
<pitti> mvo: sure, no hurry :-)
<pitti> mdz: sip4-qt3 is fine, too
<mdz> pitti: thanks
<elmo> seb128: ?
<elmo> seb128: g-c-m FTBFS, if you didn't n otice
<Riddell> did anything happen with the plan to have hoary-updates contain point releases of gnome etc?
<Kamion> mdz: turns out merkel's bugs mirror was broken due to spohr's IP change; I've fixed it now
<seb128> elmo: k, thanks
<mdz> Kamion: as in, just now?  meaning there are *more* bugs incoming? ;-o
<Kamion> mdz: right, I think just today's - scrollback suggests that aj kicked it manually last night, or something like that
<sabdfl> elmo: when we publish new packages, do we leave old ones in the pool for a few days?
<trukulo> ogra, you there? graveman is 0.3.10 now
<elmo> sabdfl: yes
<elmo> sabdfl: well, 24 hours, to be precise
<elmo> tho, they're also available from http://morgue.ubuntu.com/ after that
<mdz> elmo: is that the same as Debian?  I thought Debian waited longer
<dholbach> hi!
<elmo> mdz: debian has 1.5 days - but that's for testing
<elmo> *shrug* happy to bump it up for us, if anyone wants, I just started conservatively
<mdz> elmo: 24 hours is probably OK for us, given our default of doing apt-get update once/day
<zyga> mvo: ping?
<sabdfl> elmo: super, thanks
* mdke hugs pitti 
<mdke> #7616 is fixed
<mdke> thanks a million
<pitti> mdke: cool
<pitti> mdke: so it was a gamin bug artifact
<mdke> yuhuh
<pitti> mdke: can you please write that into bz and close the bug? :-)
<mdke> i wrote it
<pitti> mdke: these bugs were really a plague
<mdke> didn't close tho
<mdke> pitti, yeah i know :)
<zyga> hmm
<pitti> okay, I can close it myself :-)
<mdke> pitti, thanks and well done on it
<zyga> did something changed about how nautilus operates recently?
<pitti> mdke: thank fabbione, he actually wrote the gamin patch :-)
<pitti> zyga: yes, the spatial mode was disabled
<zyga> pitti: arghh...
<zyga> pitti: how to re-enable it?
<seb128> http://bugzilla.ubuntu.com/show_bug.cgi?id=8516
<pitti> zyga: some obscure gconf setting, please see the mailing list
<seb128> pitti: no, the spatial mode is "broken" rather :p
<zyga> pitti: would someone accept a patch that could add config option to re-enable it?
<mdke> pitti, i retract the hug
<seb128> pitti: that's a mix spatial/browser
* mdke hugs fabbione 
<zyga> pitti: I know some people hate it but some don't 
<zyga> (and it's about choices)
<seb128> zyga: there is already a bugzilla patch  for that
<Kamion> zyga: might be worth your while catching up on the discussion first
<seb128> zyga: feel free to read the bug/comment on it
<zyga> seb128, Kamion: thanks, I will
<pitti> mdke: why, does gamin break again?
<mdke> pitti, no j/k
<pitti> mdke: or do you rather want to hug fabbione? :-)
* mdke hugs everyone
<mdke> goddammit
<zyga> hmm I cannot find anything that re-enables the spatial mode 
<seb128> http://bugzilla.ubuntu.com/show_bug.cgi?id=8516
<seb128> read the comments
<seb128> or read the package changelog
<zyga> I've found 8528 and 8530 
<zyga> seb128: thanks alot
<seb128> np
<mdke> zyga, /apps/nautilus/preferences/no_ubuntu_spatial
<zyga> mdke: I've found that key but I had no idea that it actually fixes this
<zyga> schema is badly needed
<zyga> also IMHO it's kind of late to change the way nautilus works again but that's just personal opinion (and not addressed to you of course)
<seb128> zyga: you can comment on the bug if you want
<zyga> seb128: still reading
<zyga> seb128: I cannot add anything usefull at this point
<zyga> I agree that introducing a change in the default mode now is a mistake
<zyga> other than that I'm helpless
* zyga sets config key 
<seb128> zyga: k
<zyga> is the key name stable in any way?
* zyga thinks about schema and translation
<seb128> no reason to change it 
<haggai> pitti: I've been fixing the cdrdao sources up.  I also noticed it build-depends on pccts (currently in universe), but I can remove that by building against the internal pccts.  Which is easier for you?  Build with internal version or move pccts to main too?
<pitti> haggai: if the internal version works, then using this one is easier
<haggai> pitti: righty.  I already tested it and it does work
<pitti> cool
<pitti> haggai: no other external dependencies?
<pitti> ... which aren't in main
<haggai> pitti: no, there are only 2 and both are in main
<seb128> pitti: desktop icons issue fixed by gamin fix ?
<pitti> seb128: sounds like "yes", which bug?
<seb128> just reading the bug you have closed
<seb128> that would rock :)
<pitti> seb128: #7616?
<seb128> is there some other issues ?
<seb128> right, this one
<pitti> seb128: well, one reporter said yes, let's hope that the others do, too :-)
<seb128> :)
<pitti> seb128: I merged all similar bugs, but I still have a host of other hotplug bugs
<seb128> oh right
<froud> ogra: I was expecting a mail :-(
<mvo> ping seb128 
<dholbach> hey mvo
<mvo> hey dholbach 
<seb128> mvo: pong
<mvo> seb128: could you please re-send me the typo fix for update-manager? it looks like the attachment from you last mail was missing :)
<seb128> hum right
<seb128> not the last, look on your box you have a new one :p
<seb128> (I've just a new one)
* mvo checks mail
<mvo> seb128: thanks, commit (with "thanks to Sebasti*e*n Bacher" this time :p)
<seb128> :)
<seb128> thank you
<mvo> pitti: u-m and synaptic with Xhosa uploaded
<pitti> mvo: thanks
<trulux> any Perl master here?
<mdke> heh
<mdke> perl master :)
<trulux> mdke: Jedi?
<trulux> :)
<mdke> perl master is one rank up
<mdke> i guess
<trulux> right, hehe
<trulux> I'm hacking tinderbox to add source code auditing capabilities
<lamont_r> trulux: you're looking for a perl master in a python-biased distro devel channel??? :-)
<mdke> he shows signs of turning to the dark side
<trulux> lamont-away: lol, tinderbox is written in Perl, don't give me ideas or this summer I will need *too many* steroids ;P
<lamont_r> heh
<trulux> mdke: a powerful ally, another dark jedi, join us or die!
* mdke wanders off
<Kamion> trulux: perl> what do you need?
<trulux> Kamion: I'm messing with mozilla's tinderbox to include source code auditing capabilities, and I need to know how to do some stuff regarding files, outputting...
<trulux> Kamion: many time since I don't write anything with Perl, and I when I was doing, it wasn't so much
<Kamion> open FILE, '>', $filename or die "open $filename: $!";
<Kamion> print FILE $stuff;
<trulux> Kamion: I'm just doing it inspired on http://dev.gentoo.org/~solar/portage_misc/bashrc, just finished adding the hacks to make the frontend able to handle the "auditing" flags, etc
<Kamion> (or 'print FILE $stuff or die "print $filename: $!";' if you're being pedantically careful)
<trulux> Kamion: function package-pre-compile() {
<Kamion> close FILE or die "close $filename: $!";
<trulux> yes, I must be
<trulux> tinderbox is CGI, and Perl can be an asspain if talking on cgi security
<Kamion> I sincerely hope you're using taint mode already
<trulux> Kaloz: right
<trulux> s_files="`find ${S} -name '*.c' -o -name '*.cpp'`"
<Kamion> careful and competent programming makes Perl no less of an "asspain" than any other language, and often much less
<trulux> right
<trulux> the only visible work I did with perl was (http://sourceforge.net/tracker/download.php?group_id=54911&atid=475277&file_id=102127&aid=1031214
<trulux> :)
<mdz> lamont_r: ping
<dholbach> pitti: had some time for THE crack already? :-)
<pitti> dholbach: sorry, I didn't manage today
<dholbach> pitti: don't worry, just wanted to ask
<pitti> dholbach: tomorrow, I promise :-)
<dholbach> pitti: we don't need to have a thorough security analysis, i guess you're good/bad feeling suffices
<dholbach> :-)
<lamont_r> mdz: reading your mail now
<blahrus> anyone here running hoary rc?
<lamont_r> mdz: so we need to strip them from the packages in the archive, or need to do a rebuild of the packages and then extract them?
<mdz> lamont_r: the former
<lamont_r> any or all architectures?
<lamont_r> s/any/one/
<mdz> need exactly one extraction per binary package
<mdz> I expect they're all arch: any, but I haven't checked
<lamont_r> across all of main?
* lamont_r will plan to use arch=i386
<mdz> yes.  we'll likely strip some of them away, but start with all of main
<pitti> blahrus: I guess almost all folks here run ubuntu head
<lamont_r> or I could just do all 4 architectures, and let them overwrite each other...
<blahrus> pitti: head?
<pitti> blahrus: crack of the day, i. e. today's archive version
<lamont_r> blahrus: what evers currently in the archive
<lamont_r> s/ evers/ever's/
<mdz> lamont_r: i fyou can get it done via bulid-time extraction within the time allotted (about a day), that's fine too
<mdz> but that doesn't seem very feasible
<blahrus> got it, well I am just having an issue with sound, talked to Mithrandir yesterday a bit, and we couldn't fing the bug, its worked in all other versions
<lamont_r> yeah, probably not entirely feasable.
* lamont_r must fetch kid from school, then will be at home, circa 1630 MT
<lamont_r> and extracting from main at that point
<seb128> mvo: around ?
<mvo> seb128: yes
<seb128> I thought you uploaded a gksu patched for the random messages happening sometime
<seb128> you didn't ?
<seb128> I don't find it 
<mvo> seb128: it turned out that it was trickier than I excpected and mdz was not happy with the patch :/
<seb128> that's for https://bugzilla.ubuntu.com/show_bug.cgi?id=8650
<seb128> is that a dup for some other open bug ?
<mvo> seb128: patch is at http://people.ubuntu.com/~mvo/review/libgksu/libgksu1.2_1.2.5a-1ubuntu2.debdiff
<mdz> seb128: he made a patch to simply disable the message in all cases
<mdz> but there are legitimate cases where the message is appropriate
<seb128> hum, k
<mdz> the message is a symptom of a real problem
<seb128> right, but it's not really user friendly :/
<mdz> we should change the message sometime
<seb128> yep
<mdz> I thought there was already a bug open about that
<mdz> too late to translate it now, though
* pitti just uploaded new langpacks
<seb128> there is #7385 
<seb128> bah, that's for breezy
* lamont_r really heads off for home by way of the kids school
<seb128> mdz: what's your point of view for nautilus changes ?
<mdz> seb128: related to the sabdfl changes, or otherwise?
<seb128> the spatial changes required by sabdfl right
<seb128> are we just going to ignore the userbase ?
<mdz> I think that this was not the right time to make the change
<crimsun> (I agree with mdz, fwiw.  At the start of breezy, sure, but it's really late in the game for Hoary.)
<seb128> I agree too ...
<seb128> the changes have corner cases, we should have a general reflexion about that (with upstream if possible)
<kent> Actuallly personally  I have gotten used to the new way of Nautilus that changed in Hoary some day ago. But changing it with upstream would be great (Not that you should listen to me, but as a feature.. its not so bad actually. It seemed horrible first, but not any more.. :)  
<seb128> upstream seems to not be opposed to an option for such mode
<seb128> but with some reflexion on the corner cases, etc before
<Burgundavia> there is also no gui way to turning it off
<crimsun> personally, I've always closed the windows, but that's my preference, and I don't expect to enforce that on others.  My only beef is that it's quite late in Hoary's schedule.
<pitti> night everybody
<seb128> 'night pitti 
<mvo> ping daniels 
<dholbach> seb128: just want to confirm: gtk2-engines-industrial and gtk2-engines-mist are both provided by two source packages, removing them from (the source packages) gtk-industrial-engine and gtk-mist-engine should be ok, right?
<seb128> I've no idea of what you are speaking about
<seb128> oh
<seb128> no, let them
<seb128> need to figure that with jdub
<seb128> according to the debian maintainer the upstream work place is gtk-engines-industrial not gtk2-engines
<seb128> so we probably want to keep this one
<seb128> bah, workaround that for now if you want
<seb128> but we want to do the same as debian on this plan
<dholbach> so fixing gtk2-engines would be more appropriate?
<dholbach> stripping both binary packages?
<dholbach> ah ok... gtk2-engines is in main
<seb128> we are not going to change gtk2-engines binary packages now for hoary if that's the question
<seb128> do whatever you want to fix the engines for universe if you want
<seb128> I'll clear that with jdub/the debian maintainer but that's not for hoary
<dholbach> ok
<seb128> ie: I may undo your changes
<mdz> Kamion: here?
<seb128> but that's not an issue
<mxpxpod> jbailey: ping
<dholbach> seb128: no... he just pointed me to it
<dholbach> anyway... will think about it tomorrow
<dholbach> i'm too tired atm
<dholbach> good night everyone
<mdke> night
<Kamion> mdz: for about thirty seconds :)
<jbailey> mxpxpod: here
<mdz> Kamion: I need about 30 seconds worth of HoaryGoals status updates ;-)
<mxpxpod> jbailey: have you heard any more about libmpeg2 and the altivec stuff?
<mdz> Kamion: in particular kickstart and install-without-restricted
<mdz> Kamion: I'm already editing the page, so just a quick note via IRC is fine
<Kamion> mdz: kickstart is as far as I'm concerned done for hoary
<mdz> doko, jbailey: ping, re: breezy toolchain plans
<Kamion> mdz: the base-installer thing for install-without-restricted is still outstanding and is fiddly; I'm inclined to defer it with a note that you can make it work in expert mode, or in a derived distribution by changing base-installer
<mdz> Kamion: thanks
<jbailey> mxpxpod: Nope, I haven't been hacking on it.  It works better than it did in Warty, and we'll pretty much have to be happy with that for now.
* Kamion goes
<mxpxpod> jbailey: hrmm... it's still quite jumpy
<jbailey> mdz: doko and I haven't sync'd on it.  Can do that tomorrow morning.
<jbailey> mdz: I have things that I want to do, but not a comprehensive plan in the wiki yet.
<jbailey> mxpxpod: Right it sucks, but it doesn't crash.
<mdz> jbailey: the immediate need is to determine whether we'll be deploying toolchain changes before or after UDU
<mdz> jbailey: and, consequently, whether there's actually anything to talk about in this area at UDU
#ubuntu-devel 2005-04-16
<mxpxpod> jbailey: haha, ok
<mxpxpod> jbailey: I may take a look at what we can do for the breezy release
<daniels> mdz: pong
<doko> mdz, jbailey: yes, let's do that tomorrow. I'd like to see the glibc update first, independent from that toolchain updates, and once glibc has stabilized, start the C++ transition.
<jbailey> mdz: My preference for efficiency is to have glibc and gcc disruptive work done before so that after UDU people can work on their plans with the gcc and glibc bump done already.  If we do a toolchain BOF, I'd like to talk about the idea of making sure that everything in the archive (or at least main) is rebuilt with the new toolchain (to work around unreproducable ABI bugs, and such) versus the cost of killi
<jbailey> ng partal upgrades to some degree.
<mxpxpod> jbailey: anyway, I gotta get going
<mdz> daniels: any pending xorg changes for Hoary, or can we freeze it?
<jbailey> mxpxpod: If you have hack time, great.
<mdz> doko: do you think it will be achievable to do the transition before UDU?
<daniels> mdz: still a couple of pending changes that I'm hoping to finalise today
<mdz> I suppose I'll outline a BOF, and we can revise based on status as of UDU
<daniels> mdz: fix a small error in the Radeon DDC code so it works on Studio Displays (the whole display just stays off without it), further beat on the Debconfiscation
<mdz> daniels: what debconfiscation issues remain?
<doko> mdz: difficult, I'll give an estimate tomorrow
<jbailey> doko: Works for me.  Just need to sort out whether it should be built with gcc-3.4 initially, or done with the gcc-4.0 snapshot.
<daniels> mdz: #8562, for one
<daniels> mdz: other than that, it seems very solid
<toresbe> the livecd reboots if I kill X, right?
<mdke> daniels, do you know if #8543 is a valid bug
<blahrus> just wanted to let someone know . . . when I boot the amd64 live rc cd, starts doing it thing then says fails
<blahrus> install failes*
* mvo goes to bed now
<doko> mdz, jbailey: look at http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=submitter&data=aj%40andaco.de&archive=no , these are known issues
<daniels> mdke: i assume so, but I don't know why
<jbailey> doko: Oh wow.  That's insane.
<mdke> daniels, never heard of anything similar?
<daniels> mdke: there just aren't really many people using sis
<mdke> ahhh
<mdke> i c
<mdke> the guy who reported the bug is nice, he speaks no english and has never filed a bug so i'm trying to help him
<toresbe> killing X would cause the livecd to reboot, right?
<mdz> doko: oh, that's helpful
<mdz> doko: even better would be to break that down into main and universe
<mdz> daniels: I'm very iffy about debconfiscation changes this week; please limit it to simple and safe changes, and make today the last day for debconf changes
<koke> mvo: I sent an updated spanish translation to synaptic-devel@ some days ago, do you know if it has been commited?
<koke> it fixed a typo and some fuzzy strings
<mvo> koke: let me check
<toresbe> man... Ubuntu hoary is *beautiful*
<mvo> koke: not in yet, sorry
<mvo> koke: I will take care of it tomorrow
<koke> ok, thanks
<daniels> mdz: yeah
<mvo> koke: commited, thanks again!
<koke> great :)
<sjmorgan> it's tomorrow already?
* mvo really goes to bed now :)
<sjmorgan> time travel really takes it out of you
<toresbe>  I thought OOo2 beta was in Hoary
<elmo> it's in universe
<toresbe> ok
<toresbe> man, that's it...
<toresbe> this is so much cooler than Deb sid
<toresbe> I'm switching to Hoary, period
<Burgundavia> toresbe: generally, #ubuntu is for help relating things. -devel is for the actual developmetn of the distro
<toresbe> Burgundavia: yeah... but #ubuntu sucks :P
<Burgundavia> toresbe: this is not the correct channel for this
<toresbe> I know, sorry.
<diego> have you guys seen this: http://ubuntuforums.org/showpost.php?p=105180&postcount=13 . if multiple people are having this problem with the intel ipw2200 and a new upstream version that fixes the problem has been released (including me), wouldn't it be much better to include the new intel drivers in hoary despite it being so late in the development process?
<Burgundavia> diego: does it also break things?
<toresbe> hmmm
<diego> Burgundavia: it's possible that it would. i have not tried it as it is not easily available (which i'm afraid will be a problem for many people using ipw2200 in their laptops)
<toresbe> #ubuntu needs a bot to help with frequently asked questions
<toresbe> like #debian has
<toresbe> That would tremendously aide the usefulness of the channel
<toresbe> aid*
<diego> toresbe: i would not be satisfied by a bot's response right now if you're referring to me. if not, i have noticed that many of the questions of #ubuntu are answered at ubuntuguide.org
<diego> Burgundavia: what do you suggest i do?
<toresbe> diego: no, not at all
<toresbe> just a general remark, it seriously needs a bot
<Burgundavia> diego: I was just saying that it can't really be tested at this stage in the game
<toresbe> Does anyone here have the opportunity to host one?
<diego> Burgundavia: well they included the new nvidia drivers didn't they? how is this different?
<Burgundavia> convince a dev, not me
<diego> how do i know who is a dev?
<daniels> mdz: ok, I know what the sync ranges thing is, and I think that by far the safest option (the other one being incredibly invasive, and I wouldn't have time to do it properly for hoary) is to just set use_sync_ranges="true" when upgrading from xfree86; people can just run dpkg-reconfigure to have it DTRT if they care
<diego> daniels is a dev i think, but probably not a relevant one :)
<diego> daniels: do you know who i should talk to about intel wifi drivers?
<daniels> um, one of the kernel guys, but it was already decided for sure long ago that it wouldn't go in
<mdz> diego: https://bugzilla.ubuntu.com/show_bug.cgi?id=7135
<daniels> it's just too late in the game to risk breaking stuff; best sticking with what you know
<diego> what i know drops my internet connection every couple hours
<diego> that's pretty shitty if you ask me
<mdz> diego: it's a tradeoff, and if you're on the worse end of it, that's unfortunate.  it'll be updated quite soon and you're free to upgrade at that time
<diego> mdz: so you suggest i use the development release for 6 full months when what i want is something stable?
<mdz> diego: I'm not offering advice; I'm explaining the situation to you.
<Robot101> diego: you can use hoary and upgrade specific packages from breezy without much difficulty
<Robot101> diego: list both in sources.list and write APT::Default-Release "hoary"; in /etc/apt/apt.conf
<diego> is there a way that both the new and old intel drivers can be included, the current ones by default and the new ones with a modification to /etc/modules or something along those lines?
<Robot101> diego: upgrade/dist-upgrade/install will use hoary only then, but you can install stuff from breezy with: apt-get -t breezy install whatever
<mdz> and one of the _reasons_ I'm not doing that is because it would be off-topic for this channel *cough*
<diego> Robot101: thanks, i suppose i may have to settle for that :(
<Robot101> *whistles*
<diego> and regarding the parallel versions i suggested above, is it possible?
<Robot101> diego: mdz said it was off topic for here, but I don't know anyway. sounds unlikely.
<diego> i thought mdz was referring to his not giving me advice because it was off-topic, sorry
<mdz> both
<diego> i suppose i'll leave now...this just strengthened my belief that hoary is not ready to be released. thanks for your time
<robertj> can someone test something for me? Open up a Window, then open a folder in it so that it opens the new window and the old window is automatically closed. Add a new file to the parent, open the parent window, see if the parent has the new files
<mdz> diego: thanks for your feedback, though it would be better received with a bit less antagonism.  have a good day.
<toresbe> hoary-rc-install-amd64.iso: Permission denied
<toresbe> using wget to uninett
<toresbe> using firefox it works just fine! :|
<toresbe> oh, wait, local issue, duh
<toresbe> I'm sorry
<infinity> mdz : Ping.
<mdz> infinity: pong
<infinity> mdz : You pinged 6 hours ago? :)
<mdz> infinity: was probably regarding 8102
<robertj> is there any point in emailing Mark politely about the window closing thing or is it a done deal?
<mdz> infinity: read the few lines before the ping
<mdz> robertj: polite emails are generally well-received
<daniels> infinity: monash at 12:05?
<seb128> robertj: you can comment on the bug about this too
<infinity> daniels : Works for me.
<robertj> smb128: I already did
<robertj> has he seen the report
<robertj> I know he gets emails, so...
<seb128> k
<daniels> infinity: rad.
<tseng> jdub: azarah just posted our pet peeve inotify bug to the gamin list
<infinity> mdz : Ahh.  Oops.
<mdz> infinity: we need to determine as soon as possible whether the new version is busticated
<daniels> mdz: is the nvidia-glx/l-r-m upgrade hook useful for hoary?
<mdz> daniels: not for hoary
<daniels> mdz: ok, cool
<infinity> mdz : Do we know anyone other than the submitter with an HP inkjet printer?
<mdz> infinity: yes, there are oodles of them around
<mdz> I have one (works fine with the new hpijs)
<infinity> mdz : Oh, see that's a pain.  It's supposed to fail for everyone, dangit. :)
<daniels> the submitter's talking about an Epson printer
<mdz> infinity: I suggest posting a call for testing to ubuntu-users ("do you use an hpijs-based driver? (here's how you check...) does your printer still work?"
<mdz> oh, ok then
* mdz wears printer blinders
<mdz> infinity: still, this was an unintentional change, and we should try to get some feedback to make sure we're not screwed
<infinity> mdz : Err, yeah.  What daniels said.  hplip/hpijs shouldn't affect epson printers at all.. I hope?
* infinity is hardly a desktop printing expert.
<mdz> it only changed about three days ago, and there could be lurking problems
<daniels> it's probably worth digging 4ubuntu1 out of the archive to see if it works for him, or whether that's just a red herring
<infinity> Last time I used a printer any smaller than a Volkswagen Beetle was a long time ago.
<blueyed> I talked to sladen yesterday about this: powernow-k8 fails here with latest hoary, leaving the cpu down at 1Ghz.
<blueyed> IMHO a show stopper.. I'd like helping debug this.
<blueyed> kernel: powernow-k8: transition frequency failed
<blueyed> and kernel: ignoring illegal change in lo freq table-2 to 0x2
<sladen> blueyed: not technically a showstopper.  The system still runs.  It's to do with finding the frequency/voltage pairs, which IIRC are fetching from ACPI---hence probably down to a buggy ACPI DSDT
<sladen> blueyed: can you file a bug, with the /proc/cpuinfo /proc/acpi/dsdt and the errors you sent me on IRC that you're seeing in /var/log/syslog
<blueyed> ok, the system works, but (in fact) it does not run..
<blueyed> ok.
<sladen> blueyed: does not run?  You're using it at the moment, aren't you?
<blueyed> yes, but with running I meant 1.8ghz.
<blahrus> while we are talking about bugs, I think I have one
<blahrus> just not sure how to locate it.
<calc> hello
<calc> seb128: around?
<seb128> yep
<calc> seb128: i saw the thing about menu-xdg today
<seb128> what thing ?
<calc> does the gnome menu not properly collapse menu entries?
<seb128> the dup with the .local files ?
<calc> yea the dup
<calc> iirc Amaranth was having issues with that a while back but i thought he had resolved it
<calc> wrt his editor
<seb128> the menu works fine afaik
<calc> but it seems to still be happening with menu-xdg
<calc> if you have two menu entries named the same it shows as dups
<calc> eg in /usr/share/applications or /var/lib/menu-xdg  and the users dir
<seb128> but the menus are located on differents locations
<seb128> an user is not authorized to have the same entry ?
<seb128> or it should overwritte ?
<calc> the user one should override the system one
<calc> thats the whole reason eg Hidden= exists in .desktop
* calc runs to eat, bbia 15-30min
<seb128> I'm going to sleep
<seb128> calc: that works fine here with /usr/share/applications and ~/.local/share/applications/
<seb128> the use one overwritte the system
<Amaranth> yeah, gnome-menus 2.10.1 fixed that
<lamont> mdz: 8606 verified :-(
<lamont> seb128: you around?
* lamont ponders what to do with usr/share/applications/abiword.desktop                      gnome/abiword-common,gnome/abiword-plugins
<lamont> mdz: do we need to know what package the .desktop file came from?  (the above is the only main-main collision)
<lamont> 2 main-universe collisions
<lamont> 5 uni-uni, 1 multi-multi
<seb128> lamont: I don't understand the issue
<mdz> lamont: I don't know, check the source
<seb128> what are you doing ? .desktop collection for g-a-i ?
<mdz> lamont: I think the .desktop file must be named after the package for g-a-i
<mdz> seb128: yep
<seb128> nice
<mdz> lamont: abiword should be overridden to abiword-gnome I think
<mdz> whichever one is seeded
<mdz> lamont: we're going to need manual overrides; the seeds should provide hints in most cases
<lamont> pl
<lamont> ok
<lamont> usr/share/applications/glade-2.desktop                      gnome/glade-gnome-2,universe/devel/glade-2
<lamont> wonderful.
<lamont> anyway, I'll make it package/file
<elmo> have we done any automaied conflict checking, btw?
<elmo> or is that what lamont's doing?
<mdz> no, lamont is building an updated database for gnome-app-install
<mdz> automated conflict checking is a breezy sort of thing
<mdz> unless you have a handy conflict checker already written
<lamont> mdz: uh... I'm grabbing the files we need to do that - not sure how to do that final step (of actually building the beast)
<lamont> mdz: and we need all of main, or just desktop seed? (assuming all)
<mdz> lamont: look in the g-a-i source package
<mdz> lamont: main
<lamont> is there some magic dpkg incantation to just extract the data.tar.gz to stdin from a .deb?
<mdz> we don't want _all_ of main, but we'll use that as a starting point
* lamont has always used ar, you see..
<mdz> dpkg --fsys-tarfile
<lamont> danke
<mdz> that goes to stdout, actually, but I imagine that's what you meant anyway ;-)
<lamont> well, stdin for the otherside of the | yeah\
<lamont> :-)
<zul> evening
* calc back
<calc> Amaranth: ah i must not have restarted since i upgraded to 2.10.1
<seb128> calc !
<seb128> so the deal is
<seb128> menu-xdg-X-Debian-Apps-Net-galeon.desktop for the ~/.local
<seb128> X-Debian-Apps-Net-galeon.desktop for the /
<seb128> by example
<calc> so why doesn't it know to do that already since its in a subdir called menu-xdg under ~/.local ?
<seb128> any idea of from where the "menu-xdg" comes ?
<calc> or was that the part that was fixed in 2.10.1 ?
<seb128> no, that's the current system
<calc> subdirs under applications are for vendor dirs
<calc> like with applications/kde, etc
<seb128> right
<calc> gnome just uses a flat dir for some reason
<seb128> but is that wrong to prefix "menu-xdg" for the entry ?
<seb128> the menu does that for the Legacy stuff too
<calc> it might should work either way, not really sure
<mdz> lamont: how come #8606 didn't show up in hoary-test?
<calc> i don't recall if it mentions using prefixes for namespaces as well or not
<seb128> "The name of the subdirectory should be added as prefix to the desktop-file id together with a dash character ("-") So given a <AppDir>  /foo/bar and desktop entry /foo/bar/booz/Hello.desktop the desktop entry would get a desktop-file id of booz-Hello.desktop"
<calc> hmm
* calc wonders how he missed that last year
<lamont> mdz: good question
<seb128> calc: perhaps a spec update since ?
<calc> seb128: maybe i did read it and just realized it didn't pertain to what i was doing
<seb128> changing
<seb128> <AppDir>/var/lib/menu-xdg/applications/menu-xdg</AppDir>
<seb128> to
<calc> so gnome should be doing the same thing for both locations and ending up with the same filenames
<seb128> <AppDir>/var/lib/menu-xdg/applications</AppDir>
<lamont> mdz: will do another test build on an actuall DC buildd to be sure, dunno what's up.
<seb128> for debian-menu.menu
<seb128> seems to fix the issue
<blueyed> sladen, https://bugzilla.ubuntu.com/show_bug.cgi?id=8657 ( - accidently hit enter on the package input field)
<calc> seb128: oh!
<seb128> calc: no, because you <AppDir>/var/lib/menu-xdg/applications/menu-xdg</AppDir>
<calc> yea i see that now
<seb128> ie: the prefix gets dropped
* calc kicks himself
<seb128> and not for ~/.local/share/applications/menu-xdg/
<calc> seb128: thanks for the help 8)
<seb128> np
<lamont> 2543 .desktop files in main
<calc> i'll upload a new version to debian tonight
<seb128> just curious, do you read the menu-xdg menu from bugzilla ?
<lamont> modulo duplicates...
<seb128> s/menu/bug/
<seb128> or how have you found about it ?
<calc> not yet
<calc> i saw it on ubuntuforums (ubuntu-devel gateway) today at work
<seb128> k
<seb128> BTW thanks for the reminder :)
<seb128> I had not yet looked on the bug 
<calc> ok :)
<seb128> the menu works fine now :)
* seb128 is going to fix that :p
<calc> great
* lamont realizes he needs to run away for about 5 min
<lamont> moof
<Robot101> moofle
<lamont> -MimeType=application/x-abiword;application/msword;application/rtf;text/abiword;text/plain;text/richtext;text/rtf;application/vnd.ms-word
<lamont> +MimeType=application/x-abiword;application/msword;application/rtf;application/wordperfect5.1;application/x-applix-word;application/vnd.palm;application/x-palm-database;text/abiword;text/plain;text/richtext;text/rtf;text/vnd.wap.wml;applicatoin/vnd.ms-word
* lamont bets he wants the one from abiword-plugins, not abiword-common
<lamont> yep
<lamont> mdz: this expands the list of desktop files from 33 to >2500, just btw...
* lamont applies jdub's exclude list
<mdz> lamont: <mdz> we don't want _all_ of main, but we'll use that as a starting point
<lamont> well, all of main would be a starting point for what.. paring down, I guess.
<infinity> mdz : Our mysql-server does contain the suspect bit of code in the init script.  More irritating, though, is that our mysql-server needs at least 4 security updates on top of that, so I guess I have my morning cut out for me.
<mdz> yep
<mdz> infinity: hmm, I vaguely recall seeing some mysql security bugs go by which were filed as "important", and thinking "I should remember to import those into Ubuntu bugzilla..."
<jdub> lamont: i've got a bunch of the individual .desktop files we want to replace the groups with, so we can throw those in
<jdub> lamont: i can also give you the script i've already done
<lamont> jdub: want to take a gander at people.u.c/~lamont/List and see what we want to prune?
<infinity> mdz : Yes, well.  Consider them mentally imported now.  I'll patch for hoary and warty today, and ping pitti with the warty sources.
<lamont> scriptage would be nice
* Kamion pops in again for a bit
* lamont decides to find out what exactly g-a-i does
<jdub> lamont: it reads the files in a similar manner to the gnome menu
* infinity wonders if it wouldn't be a bad idea to quickly run through the sarge-security team's list of vulns and see how many apply to hoary.
<mdz> infinity: if you give me bug numbers, I'll bring them in so that we can track there
<lamont> I like the way the detailed description on the package provides no additional information beyond the short description or package name, other than to assert that it's "pretty"
<jdub> lamont: and uses X-AppInstall-Package to define the package name
<infinity> mdz : The most recent upload has no bug #, but it's CAN-2004-0957... The older upload fixed #299029, #299031, #299065.
<jdub> lamont: hrm, ok, give me a few minutes, my script already tags the desktop files and so on; just have to do some bizdev stuff here atm
* lamont runs g-a-i for the first time ever, decides that it does indeed look "pretty"
<mdz> infinity: they're all already in bugzilla
<lamont> jdub: no hurry - I have all night :-)
<jdub> i'll do a mirror update in the mean time
<infinity> mdz : I searched on "mysql" and got nothing back except the init script bug, so assumed they weren't.  Hrm.
<mdz> infinity: entering "deb<number>" anyplace bugzilla accepts a bug ID should work
<mdz> looks like pitti fixed it in Warty and closed it; perhaps he believed it didn't affect Hoary?
<mdz> oh, he wrote that he fixed Hoary too
<infinity> mdz : Yeah, he fixed hoary too.  I misread his changelog.
<infinity> mdz : So, we only need the one update.
<infinity> mdz : That's a relief.
<mdz> CAN-2004-0957 isn't mentioned there though
<mdz> ok
<mdz> infinity: be sure to notify pitti re: Warty
<infinity> mdz : I originally read his "taken from 4.0.23-4" in the changelog to mean he didn't have any patches beyond that, but that was just for a subset of the update.
<infinity> And, yeah, I'll notify him about the warty update.
<infinity> I have a PHP update queued for him too, so we have a date later. :)
<infinity> (PHP security hole?... NEVER..)
* robertj shivers and does a yum upgrade
<robertj> (stupid legacy box)
<elmo> woo!
<elmo> back to clean uninstallable/out-of-date
<elmo> can we stay there now, pls? :p
<elmo> is HIGHPTE a good thing?
<robertj> HIGHPTE?
<elmo> in kernel config
<infinity> elmo : It sounds like a good thing.  And, in practice, it's not provne to be a bad thing (I've used it plenty)
<elmo> cool
<infinity> It touches a whopping three tiny bits of mm-related code, doing pretty much exactly as the help text says.
<infinity> Which looks pretty harmless to me. :)
<lamont> mdz: 8606 - pilot error here...
<mdz> lamont: awfully suspicious, eh?
<lamont> mdz: well, there were some oddities on the machine that I picked because (a) it was not in the DC, and (b) has no network access.
<mdz> lamont: but it failed in exactly the same way?
<lamont> yes
<lamont> note that it was also !i386
<robitaille> lamont,  I have to ask: what is a pilot error?
<CarlK> http://cdimage.ubuntulinux.org/daily/current/MD5SUMS - has this really changed about 5 times in the last 2 hours?
<CarlK> robitaille - the person operating the computer is like a pilot flying a plane
<CarlK> robitaille - so it is a way of saying "did you make a mistake?" 
<mdz> CarlK: it has changed exactly once in the past 24 hours
<CarlK> mdz... something fishy is going on...
<robitaille> CarlK,  thanks.  so it's like a pebkac :)
<lamont> robitaille: the cause of many plane crashes
<CarlK> robitaille - if I knew what a pebkac was 
<robitaille> CarlK,  "Problem Exists Between Keyboard And Chair"...an old saying
<CarlK> yep
<CarlK> in mechanics talk: Nut behind the wheel
<bluefoxicy> dhcp took eternity to set up right
<bluefoxicy> :(
<lamont> mdz: verified that it does not try to talk on the network.
<lamont> robitaille: pebkac.  definitely
<lamont> bluefoxicy: huh?  it's not exactly rocket science...
<lamont> dhcp3 package, or some wonky embedded dhcp on some commodity gateway box?
<mdz> ->#ubuntu, please
<lamont> oops. sorry
<bluefoxicy> lamont:  install, then hack with vim until it shuts up about noth aving ethX configured or such, and the man page doesn't say anything that indicates that I can do anything but figure out the subnet on i.e. eth0 (from the ISP)
<bluefoxicy> lamont:  I was trying to set a mac user up
<bluefoxicy> so you know. . . . 
<OddAbe19> damn basket ball cancelling csi miami
<OddAbe19> it's ok though
<OddAbe19> csi miami sucks
<OddAbe19> whoops
<OddAbe19> wrong channel
<OddAbe19> sorry guys
<OddAbe19> didn't mean ti
<OddAbe19> too drunka
<jdub> grr
<jdub> has the whole website been losing things, not just the wiki?
<fabbione> morning
<elmo> jdub: yes
<jdub> elmo: hrm.
<jdub> elmo: ta.
<Lathiat> does it run on plone/zope?
<elmo> yes
<Lathiat> mmm, ucc had some annoying issues with that
<Lathiat> restarted zope and it decided to trash the entire database
<fabbione> humpf
<fabbione> lamont: ping?
<fabbione> does anybody remember what triggered the  trying to overwrite `/usr/share/info/dir.old.gz', which is also in package texinfo problem?
<elmo> oh, god, it's dpkg stupidity
<elmo> dpkg install-info vs. gnu install-info
<elmo> dpkg changed options, and it broke old automake scripts
<elmo> easiest solution is to just rm -f the file in debian/rules build - alternately, update all the autocrap
<fabbione> elmo: hmm ok.. i think something in the archive still has that bug
<fabbione> or it has been retriggered somehow
<elmo> #213524 has details, IIRC
<fabbione> i have noticed the problem on only sparc and only compiling gcc-4.0
<elmo> fabbione: hmm, that's strange
<fabbione> but it might be as well in our archive in one hidden package
<elmo> hmm, right, let me go update some contents
<fabbione> elmo: thanks
<lamont> universe/eb-doc on all architectures
<blahrus> Mithrandir: you around?
<lamont> amd64: base/findutils,universe/sound/speech-dispatcher,universe/libdevel/libmpfr-dev,universe/doc/eb-doc
<lamont> bummer about findutils. :-(
<lamont> that was as of Jan 28 03:47ish, London
<blahrus> anyone around?
* lamont sleeps
<fabbione> good night lamont
<jsgotangco> greetings
<blahrus> hey jsgotangco 
<jsgotangco> hi
<blahrus> you know much about ubuntu?
<blahrus> might be dumb question in this chan
<jsgotangco> ill try to answer as i can
<blahrus> mp3 play, test file plays the testsound under ubuntu device manger
<blahrus> nothing comes out.
<jsgotangco> hmmm i havent tried that at all maybe its the mixer settings?
<blahrus> nothing is mute vol is up
<blahrus> i am just stuck, and I have given up trying to get help in ubuntu chan, and it almost seems like a bug in hoary
<jsgotangco> let me try that out
<fabbione> lamont: actually the universe/libdevel/libmpfr-dev is in main
<fabbione> elmo: ^
<fabbione> so that would match the failure i get here
<elmo> the contents files are massively out of date
<elmo> if that's what you mean
<elmo> I'm working on it - but they have to be generated out of line with the rest of cron.daily, it's not entirely trivial
<fabbione> elmo: yeah i know that they are outdated
<fabbione> i was just answering back to lamont :)
<elmo> ok
<fabbione> elmo: he has that package in universe
<fabbione> but in reality it is in main
<fabbione> and gcc-4.0 build-dep on it somehow 
<fabbione> -> FTBFS
<fabbione> elmo: thanks a lot.. i am going to fix it right away
<fabbione> well let see if there are other packages too that needs the same love
<fabbione> so i can crash them all at once
<toresbe> fam broken in newest RC?
<Treenaks> fam?
<fabbione> we don't use fam
<toresbe> oh
<toresbe> ok
<toresbe> ah, now it works
<toresbe> I just needed libgamin-dev instead 
<toresbe> bah, but I do lack vgrabbj
<fabbione> elmo: how long does it take to build the Contents usually?
<elmo> I don't know
<elmo> they've been disabled since pre-warty release
<elmo> I'm running now, but it's cold-cache
<fabbione> elmo: ok.. i just noticed that there is always (or almost) 2 hours (between 01:00 UTC and 03:00 UTC) in which there are no uploads. Perhaps we could stop cron.daily during these 2 hours (once a week or so) to regenerate the Contents?
<elmo> no, I'm just moving them out-of-line
<elmo> so they don't affect cron.daily at all
<fabbione> ok
<fabbione> elmo: btw.. rebuilding that libmpfr seems to be enough
<fabbione> there is no dir.old.gz anymore
<fabbione> and i didn't relibcrappize the package
<elmo> hmm
<fabbione> drwxr-xr-x root/root         0 2005-04-05 06:58:28 ./usr/share/info/
<fabbione> -rw-r--r-- root/root     28390 2005-04-05 06:58:26 ./usr/share/info/mpfr.info.gz
<fabbione> drwxr-xr-x root/root         0 2005-04-05 06:58:27 ./usr/share/doc/
<fabbione> it's strange.. but it seems to make the trick
<fabbione> does it make any sence to you?
<elmo> does it automake-ize during build?
<elmo> but, no basically it doesn't make any sense to me
<fabbione> no it doen't
<elmo> oh, maybe scott fixed dpkg
<fabbione> ehhehe
<elmo> yah, looks like he did
<elmo> shiri 6:10 ~ % install-info --version > /dev/null
<elmo> shiri 6:10 ~ %
<fabbione> elmo: cool.. if you have a list of packages with that stuff, i can prepare the uploads today
<fabbione> s/if/when
<elmo> hmm, no, wait
<elmo> 214769 says old automake expects version on stderr
<SuperL4g> tseng: you alive at this hour?
<fabbione> i haven't uploaded yet
<elmo>         @if (install-info --version && \
<elmo>              install-info --version | grep -i -v debian) >/dev/null 2>&1; then           list='$(INFO_DEPS)'; \
<elmo> okay, colour me stupid - how does that depend on it being on stderr?
<fabbione> no idea really... i really don't get along with autocrap
<infinity> It's an inverted match.  It's also a fluke that it worked before.
<elmo> infinity: how do you mean?
<HiddenWolf> ugh, the new update-notifier icon is ugly as hell. What is it supposed to be?
<mdz> lamont: you get an email if the cloop builds fail, right?
<fabbione> mdz: morning.. he went to sleep already
<mdz> he reads scrollback
<mdz> has daniels returned?
<fabbione> haven't seen him yet
<fabbione> is there something that needs urgent attention?
<moquist_> elmo: got a minute?
<mdz> today (his local today) is the deadline for xorg debconf changes, and he has some pending
<fabbione> ah ok
<infinity> mdz : He's in town, dropping of some rental application forms, then on a train/bus back home to finish up the xorg upload.
<elmo> moquist_: yah
<fabbione> elmo: should i hold up the upload?
<infinity> mdz : At least, that was what I was told to say if you asked about him.  (We met up for lunch to fill out and sign the aforementioned forms)
<mdz> infinity: yep, that's what he said he was doing 4.5 hours ago; does he have an ETA?
<elmo> fabbione: I don't know, sorry - I'm far too tired to look at it coherently
<fabbione> elmo: ok, don't worry
<elmo> but FWIW, I don't think uploading it while we don't understand why it failed last time is a good idea
<infinity> mdz : Well, we parted ways about 12:30, and it's 3:30 now... Given how far from civilisation he lives, I'd say even under a worst case scenario, he should be home pretty soonish.
<fabbione> elmo: yes i fully understand that..
<fabbione> elmo: just for curiosity... can you confirm that the dir.old.gz is in libmpfr-dev on all arches?
<fabbione> elmo: i know i386/sparc do
<elmo> only sparc, according to ftp-master?
<fabbione> hmm
* fabbione checks if dpkg was uploaded around that time
<fabbione> perhpas sparc did build with an old version of dpkg
<elmo> should be in the log?
<elmo> if you have it
<fabbione> that's what i am checking
<fabbione> i don't have so old logs.. but i can more or less see it by upload dates
<infinity> mdz : I suppose one could figure another 30-60 mins for food at some point in there.  Do you want me to call and ask for an ETA, or are you just curious if he's going back to work this afternoon (which he said he would be, all night if he had to)
<infinity> pitti : I have that php4 upload for you, and I also have a mysql update.  Aren't you lucky?
<pitti> Hi folks
<fabbione> infinity: if you can call him, it would be very nice from you
<fabbione> morning pitti
<pitti> infinity: cool :-)
<infinity> Alright, let me wander outside with my phone.  I'm in a "quiet area" in a library.
<infinity> BRB.
<mdz> infinity: I wanted to review the changes with him before upload, and I am going to sleep soon.  fabbione can help with the review though
<mdz> night all
<fabbione> mdz: do you have any objections if i upload mpfr? it is just a plain rebuild to get rid of a dir.old.gz on sparc
<fabbione> elmo: i can see that sparc was just catching up during the time the upload was done
<fabbione> elmo: so it was just built with an old version of dpkg
<fabbione> on the otherside i have the feeling we are losing the concept of verioned build-dep here
<pitti> night mdz
<pitti> infinity: can you please send me debdiffs/put them somewhere?
<fabbione> elmo: can you be so kind to put the Contents-sparc.gz somewhere i can grab it?
<fabbione> elmo: just to see if there are more packages with that problem
<fabbione> elmo: since it was the only arch lagging
<elmo> it's still generating
<fabbione> ok thanks
<elmo> (I told you it was slow :p)
<fabbione> elmo: i do really trust you :)
<fabbione> jdub: ^^ same question as for mdz?
<infinity> mdz : If you're sleeping soon, you're probably out of luck.  Sounds like he's stuck in town.... Said he'll be home between 6 and 7, and doing the upload shortly thereafter.
<infinity> fabbione : That's around 3.5 hours from now.  Will you be around to do the review?
<fabbione> infinity: don't worry... i will be around
<fabbione> infinity: yes
<infinity> pitti : Working on it.
<fabbione> at least for the next 10 hours
<infinity> pitti : Still need to do test build and make sure nothing broke hideously.
<infinity> s/build/builds/
<jdub> fabbione: sure, approved
<fabbione> jdub: thanks, but too late anyway ;)
<fabbione> jdub: you know in italy silence is a sign of consensum :P
<jdub> ;-)
<fabbione> jdub: did you import the gamin fix in Debian?
<jdub> not yet, will do next week probably
<jdub> this week is completely doomed
<jdub> actually, i expect next week to be as well
<jdub> but we'll see ;)
<fabbione> jdub: remember of the freeze
<fabbione> no news from upstream?
<pitti> fabbione: I did not see any reply in the gnome bts
<jdub> haven't seen DV yet today
<fabbione> pitti: ok
<jdub> i'll encourage him to look when he's around
* jdub pings for good measure
<fabbione> jdub: s/encourage/lart/
<jdub> heh
<jdub> i'll be the diplomatic envoy of your flamage ;)
<fabbione> jdub: nah i am just kidding...
<fabbione> he might have seen my blogs anyway
<dholbach> good morning!
<jdub> hey dholbach 
<fabbione> dholbach morning 
<dholbach> hey you two!
<dholbach> how are you?
<fabbione> injecting coffee in my blood stream
<dholbach> fabbione: me too, will later visit mvo and work from his place
<pitti> Hi dholbach 
<dholbach> hey pitti
<fabbione> dholbach: heheh nice
<fabbione> mvo is a very cool guy
<fabbione> dholbach: when we met a long time ago we were sharing the same room
<fabbione> and since he has long hair
<fabbione> i used to call him Miss Vogt ;)
<dholbach> hahahaha :-)
<fabbione> he for sure couldn't be the man in our relationship
<dholbach> i'll "remind" him later ;-)
<fabbione> ehehe
<pitti> dholbach: grip has a vuln (CAN-2005-0706) which is fixed in sid; do you want to merge the fix? (or delegate the task :-) )
<pitti> dholbach: grip has ubuntu changes, so we can't sync
<dholbach> pitti: will do myself
<pitti> dholbach: just take the debdiff between 3.2.0-3 and -4 :-)
<fabbione> pitti: i am going to add the 2nd patch for the ext3 jdb race condition. did you hear anything from Herbert?
<fabbione> pitti: also
<fabbione>   * [SECURITY]  Fix possible futex mmap_sem deadlock:
<pitti> fabbione: no, not yet
<fabbione>     - Add patch stolen-from-head_futex.dpatch.
<fabbione>     (CAN-2005-0937)
<dholbach> pitti: CAN-2005-0706?
<fabbione> a CAN has been assigned
<dholbach> pitti: dredg already applied the patch
<pitti> fabbione: I saw, this CAN is already in my kernelsec.txt :-)
<pitti> dholbach: oh, cool
<dholbach> pitti: MOTU power! ;-)
<pitti> dholbach: well, my can review script is still running...
<fabbione> pitti: yes, it was missing from our changelogs
<dholbach> pitti: thanks for noticing :-)
<pitti> dholbach: rookery mirror was outdated, so there will be many changes today; sorry for the noise :)
<dholbach> pitti: don't worry, thanks for doing the job
<fabbione> jdub: ping?
<jdub> fabbione: pong
<fabbione> jdub: i might need to upload a new kernel for some important fixes today, can i have your blessing?
<jdub> fabbione: not with that information alone ;)
<pitti> dholbach: ah, now ubuntu-cve.html has grip, too :-)
<fabbione> jdub: it's to fix 2 race conditions in ext3/jdb that can cause serious data corruption
<jdub> fabbione: ok, that sounds good :)
<fabbione> jdub: + some hppa love, that is strictly isolated to hppa
<fabbione> jdub: so we don't really care if it is there or not
<dholbach> pitti: rock :-)
<infinity> Well, whattayaknow.  I didn't break it.
<infinity> pitti : php4 update is at http://lucifer.0c3.net/~adconrad/php4-warty/ for your perusal.  A debdiff is generated there between 7.6 and 7.7, if you're not in the mood to download the source package.
<infinity> pitti : That patch eliminates pretty much every infinite loop upstream could find in image.c, not just the two specific ones hilighted by the two CANs, hence the size.
<infinity> pitti : It wasn't well written to start with. ;)
<fabbione> isn't that *WEIRD* for php?
<Treenaks> fabbione: what? php is badly written? you must be kidding!
<fabbione> i am :)
<fabbione> it's the best code where to train your security skills
* pitti slaps fabbione 
<Gagatan> fabbione: troll
<fabbione> everything has a reason to exist in this world
<pitti> infinity: I'm taking a look at it soon, I'm still at breakfast
<fabbione> pitti: ehehe
<fabbione> Gagatan: i understand the truth can hurt.. but me a troll?
<fabbione> there is an abyss ....
<fabbione> 3216791 Apr  4 04:45 heimdal_0.6.3-7ubuntu1.diff.gz
<fabbione> 3321408 Oct 25 18:30 heimdal_0.6.3.orig.tar.gz
<fabbione> i wonder where the real orig is :)
<Gagatan> fabbione: heh.. 1st of April I put out a university-wide notice that we would ban use of PHP due to many security-issues the last years
<aj> Gagatan: and people thought you were joking? :)
<fabbione> Gagatan: i wouldn't consider that a 1st Apr fool joke
<fabbione> it's sad truth
<Gagatan> fabbione: yeah.. many wanted it to be true.. but not yet I'm afraid
<Gagatan> aj: we got a few long faces at least :) 
<dholbach> morning d3vic3 
<d3vic3> hey d3vic3 
<d3vic3> oops 
<d3vic3> morning dholbach 
<pitti> Hi d3vic3 
<d3vic3> hey pitti 
<pitti> Moin doko
<dholbach> brb
<fabbione> pitti: the 3rd patch doesn't even apply clean *shrug*
<jdub> Riddell: dude, why are we supporting noatun, kaffeine and juk?
<doko> morning all
<jdub> Riddell: and amarok
<bob2> isn't noatun abandonded?
<thom> jdub: are we gonna update /usr/share/ubuntu-artwork/home/ or point browsers somewhere else?
<jdub> thom: update, as soon as i get artwork from henrik
<jdub> thom: just going to put links to ubuntu resources, et.
<fabbione> pitti: we are lucky. it was only one very simple hunk that was rejected
<thom> jdub: cool
<pitti> fabbione: other code, or just whitespace foo?
<fabbione> pitti: on a line that was introduced in 2.6.11 that 2.6.10 don't have
<fabbione> nothing difficult
<fabbione> -               __journal_unfile_buffer(jh);
<fabbione>                 drop_reserve = 1;
<fabbione> the drop_reserve has been introduced in 2.6.11
<fabbione> but noone of the patch uses that
<fabbione> so it is ok to just remove the __journal_unfile_buffer(jh); from the code
<fabbione> hey Simira 
<Simira> morning, fabbione
<desrt> fabbione; gamin is sitll broken :(
<fabbione> desrt: did you logout, check that there are no gam_server running and login again?
<desrt> i killall'd gam_server gnome-vfs-daemon and nautilus
<fabbione> desrt: no, that's not enough afaik
<fabbione> you need to logout
<desrt> hm.
<desrt> what else needs to die?
<fabbione> be sure that nothing is runing
<fabbione> and login again
<fabbione> desrt: it's not a question of what is running
<fabbione> gam_server resurrects itself, and i am not 100% sure if it reloads the new one or not
<dholbach> see you guys later
<desrt> if you kill gam_server then you remove the last instance to the inode of the old server
<desrt> and the filesystem removes it from the disk at that instant
<desrt> s/instance/reference/
<fabbione> desrt: well it works here and on other machines with the way in which we did it
<desrt> i'll logout/in tho.  might work (but probably will be another day or so before i see the problem again)
<fabbione> so please try that way
<desrt> nautilus usually has to be running for a while before the bug crops up
<desrt> brb
<fabbione> otherwise just use the loop in the bug
<desrt> there's a bug?
<desrt> :)
<fabbione> 7078
<desrt> spiffy
<desrt> fabbione; test loop runs fine.  even when i take the sleeps out.
<desrt> i'll let you know if i get it again.  it seems to usually happen when firefox is saving
<fabbione> desrt: mostlikely you are hitting problem 1)
<fabbione> the missing Add/remove events
<fabbione> as explained that's not fixed
<desrt> ah
<desrt> is that a kernel problem or what?
<fabbione> nope.. the kernel is fine
<fabbione> it's gamin that loses signals
<fabbione> when the kernel sends a notification to gamin
<fabbione> it does that with a SIG33
<fabbione> gamin has problems to handle signals
<desrt> inotify is just a character device though, right?
<fabbione> it's also written in gamin code...
<fabbione> desrt: i didn't even bother to attempt to fix inotify backend for gamin
<desrt> oh
<fabbione> since inotify is disabled by default on our kernel
<desrt> i've used dnofiy from a program before.. it was... exciting
<fabbione> you need to enable it specifically
<desrt> anyway.  patch does seem to help a lot
<desrt> and if the other problem is out of your hands, then not much you can do
<desrt> thanks :)
<fabbione> the other problems are gnome/gamin
<fabbione> it's a design issue that i can't fix in a patch :)
<desrt> anything can be fixed if the patch is large enough :)
<fabbione> desrt: not if the patch needs to touch several projects :)
<desrt> then you just have to write a patch against the filesystem on a certain fileserver's harddrive
<fabbione> ehhe
<desrt> anyway.  i ought to get to bed now.  thanks again :)
<fabbione> no problem
<astharot> bonjour
<pitti> thom: do you know about the homograph attack status in epiphany? or is this a seb128 question?
<zerokarmaleft> fabbione, what's the issue with the inotify backend for gamin?
<fabbione> pitti: the 3rd patch doesn't change the abi. the function is used only internally in the jbd module
<fabbione> zerokarmaleft: the same problems as the dnotify. signalling is broken
<pitti> fabbione: so much the better :-) but even if it was public, it shouldn't break backwards compatibility, should it?
<fabbione> pitti: in theory no
<pitti> brb
<fabbione> is the wiki login fixed? or is it still borked?
<fabbione> hi daniels 
<daniels> hi fabbione
<fabbione> daniels: we need to look at xorg -10
<fabbione> can you put the interdiff somewhere i can look it up+
<fabbione> ?
<daniels> yeah, I'll get that up for you in a sec
<fabbione> daniels: cool
<fabbione> hi Md
<daniels> i need to quickly sort something out with my little sister though, i'll be back in about 15min
<fabbione> daniels: ok
<Md> I'm looking for somebody related to the ubuntu listserver (rince.africaninspace.com), I see that since about a week it's not able anymore to deliver mail to linux.it users
<fabbione> Md: i think jdub is in charge of it
<Md> let's try...
<fabbione> jdub: ?
* mpt scratches his head
<fabbione> Md: he is probably having dinner at this time
<pitti> Morning seb128 
<seb128> hi
<astharot> but why does canonical like africa? :P
<mvo> hey seb128 
<mpt> Aha!
<pitti> astharot: because sabdfl comes from South Africa
<mpt> Now I understand
<mpt> The Nautilus change happened on April 1
<astharot> ok... now a lot of things are explained, thanks pitti ;)
<thom> pitti: epiphany -> seb
<pitti> thom: ok
<pitti> thom: btw, do you know how to teach jigdo-file not to ask for the mirror?
<thom> pitti: once it asks once it remembers
<thom> or it has done here
<pitti> thom: hmm, not for me...
<thom> 9:44 ~/packages/httpd-2.1.2% grep Mirror ~/.jigdo-lite
<thom> debianMirror='http://192.168.1.13/no-name-yet/'
<seb128> what ? 
<thom> (yes, my mirror is OLD SKOOL)
<pitti> seb128: do you know how/whether the IDN homograph attacks were handled in epiphany?
<seb128> pitti: relaying on firefox beeing fixed IIRC
<seb128> since it uses firefox
<pitti> seb128: so epy even uses firefox's address bar?
<seb128> hum
<seb128> <chpe>  mpt: without a mozilla / firefox patch, all we can do is disable IDN completely. that won't do. with the patch, we  same as firefox  will show punycode instead of IDN
<seb128> I've that in my logs
<mpt> Which isn't quite true
<pitti> seb128: okay, fine
<mpt> It's not all they could do
<mpt> but they don't have the developer-muscle to do more
<seb128> mpt: you have not replied to chpe ...
<pitti> seb128: so epy probably uses the ffox functions for converting the text of the nav bar
<mpt> seb128: replied where?
<seb128> chpe was not speaking to you ?
<mpt> seb128: mpt is me, but I'm not in #epiphany right now
<seb128> mar 10 13:46:03 <mpt>   chpe: Well, that's a good start
<seb128> that's not now
<mpt> right
<mpt> I don't have my logs handy, so I can't remember whether or why I did or did not respond further :-)
<seb128> so don't blame them now behind, you didn't do that on the chan :p
<mpt> I'm not blaming them, I know very well they don't have enough developers to do lots of cool stuff
<mpt> seb128: Is bug 8548 a joke? It looks like one, but I'm not sure ... Maybe sabdfl's sense of humor is too subtle for me
<seb128> mpt: no, that's due to http://bugzilla.ubuntu.com/show_bug.cgi?id=8516
<mpt> seb128: Yes, I'm familiar with 8516
<mpt> unfortunately)
<Craww> http://www.whitehacker.com
<fabbione> daniels: ?
<daniels> fabbione: just uploading the sources to chinstrap
<fabbione> ok
<rburton> daniels: so i've just read the "changes in x.org head since 6.8.0" page, and am wondering how patched hoary x.org is
<daniels> rburton: pretty patched
<daniels> rburton: what specifically? :)
<rburton> daniels: MMX in render, and DMA in radeon RENDER
<daniels> rburton: we have everything from the ati, nvidia and i810 drivers, and also multiseat support
<daniels> we don't have mmx in render, or dma in radeon render
<daniels> too invasive :\
<rburton> darn
<rburton> that MMX patch was kick-arse
<daniels> yeah
<daniels> i'd love both for my own desktop
<rburton> if you ever make a custom x.org deb which is super-patched, i'll "test" a copy ;)
<snaggen> daniels, It seems like the 74xx nvidia modules are having some freezes in the render accel code... 
<daniels> snaggen: yeah
<daniels> rburton: heh, I might just do that
<snaggen> Since the upgrade I've had some random freezes, and on nvforum there seems like other people are having the to.
<daniels> mallum: hey dude!
<mallum> hey daniels :)
<snaggen> daniels, and todays upgrade didn't solve the issue :-(
<daniels> snaggen: it gives better general support though (working basic 2D/3D everywhere, no lockups when not using RenderAccel), sooo ...
<doko> is there a way to get statistics about fuzzy/translated/untranslated strings in a .po files?
<snaggen> OK. But it might be hard to find out this problem... but it is default off?
<daniels> snaggen: yeah
* snaggen realizes that the problem was between the keyboard and the chair, yet again :-)
<infinity> thom : ping.
* snaggen is back with no render accel, to see if this works better
<thom> infinity: ack
<infinity> thom : pitti and I have been talking.  Are you frightened?
<thom> infinity: mozilla/firefox warty stuffs?
<thom> (yes)
<infinity> thom : Given the laundry list of outstanding mozilla-* security issues, do you feel any urge to share the load?
* infinity is wary of people who say "yes" before hearing the question.
<infinity> thom : Do you have a list of collected patches that need backporting and such?
<infinity> thom : And any progress thus far?
<thom> infinity: (the yes was to "are you frightened")
<thom> infinity: yes, yes, not really
<thom> (in order)
<infinity> Alright, care to expand on the second "yes"?
<thom> sure, let me dig the list out
<fabbione> daniels: still uploading?
<daniels> fabbione: oh sorry, forgot to mention it -- chinstrap:~daniels
<fabbione> daniels: an interdiff no, eh?
<fabbione> ;)
<daniels> i'll make one now
<fabbione> nah i will do it here
<fabbione> it's the same
<daniels> frig
<daniels> wrong dif
<daniels> f
<daniels> let me scp from the right dir this time
<fabbione> daniels: ok...
<daniels> copying now
<mr_mojo> hi guys, where has the beagle package in universe gone?
<tseng> how do you mean, gone
<jdub> mr_mojo: it hasn't been uploaded yet - too much flux underneath it
<mr_mojo> E: Couldn't find package beagle
<mr_mojo> oh
<seb128> hey jdub 
<jdub> yo
<mr_mojo> do you know when it'll be ready?
<tseng> for breezy.
<jdub> mr_mojo: unlikely that it will be in hoary
<mr_mojo> can i install it seperate?
<tseng> if you want memory leaking, sure.
<jdub> not usefully at this stage, unless you build mono and up
<mr_mojo> i thought they'd fixed most of the leaking bugs?
<tseng> you cant just build mono, you need to purge it and build the entire stack
<mr_mojo> o ok
<thoreauputic> mr_mojo: re your sudden departure from #ubuntu : please read the code of conduct
<zyga> hmmm 
<zyga> leaks in mono or in beagle?
<mr_mojo> another quick question then, will firefox ever have the proper icon?
* zyga runs some mono apps
<jdub> mr_mojo: it won't
<tseng> mr_mojo: no, its restricted to use by builds from mozilla.org
<mr_mojo> i don't think mono itself leaks, i use tomboy and muine for about 18 hours a day lol :)
<tseng> we cant legally distribute our own firefox branded builds
<jdub> mr_mojo: have a look at their trademark licensing requirements - we are not able to comply
<mr_mojo> could you not 'liase' with mozilla and get it fixed?
<mr_mojo> sure
<tseng> mr_mojo: it certainly does, but id rather not argue
<jdub> mr_mojo: read the docs - we already have
<tseng> mr_mojo: and no, you cant liase with a clear legal trademark
<tseng> however silly it is.
<jdub> tseng: that's not entirely true
<jdub> tseng: some work has been done to find a policy appropriate for MOFO, debian, ubuntu, etc.
<tseng> hm
<tseng> time for work, bye jdub.
<jdub> ciao!
<mr_mojo> this is stupid from mozilla
<daniels> it's been debated endlessly
<Mitario> hello everyone
<mr_mojo> ok, call me stupid, but could you not just distribute the official builds?
<Mitario> mvo: around?
<thom> mr_mojo: no
<thom> mr_mojo: they only build on x86, and they're utterly unintegrated with the rest of ubuntu
<mr_mojo> like the msttfcorefonts works? an 'extractor' utility which takes the packaage and puts it in the right places?
<daniels> mr_mojo: again, 'only build on x86', and still utterly unintegrated (we have code patches to fix the themes, etc)
<daniels> it's really not a simple problem, else it'd be solved by now
<mr_mojo> well the themes are just a folder in the chrome, but i take your point
<mvo> Mitario: yes
<mr_mojo> considering probably someting like 95-99% of users will be using x86, would it not be worth using the official ones for x86 and unoffical ones for ppc etc (and hope the mofo builds for ppc?)
<mr_mojo> that's mozilla fonudation btw ;)
<jdub> mr_mojo: no, it is not remotely viable.
<daniels> and have firefox behave differently based on whether you're using i386 or another arch?  including a different icon?  suicidal.  and it's not even 95% these days.
<thom> mr_mojo: no, that's even stupider since the *whole point* of a distro is to be as consistent as possible cross platform; you're talking about creating innumerable problems for the sake of an icon
<mr_mojo> well i think you will suffer more from not having the proper firefox icon
<mr_mojo> it's got a huge brand built round it
<thom> mr_mojo: well, go talk to MoFo about resolving their trademark issues
<mr_mojo> i understand their trademark issues
<mr_mojo> they can't do anything about it really
<daniels> and neither can we
<mr_mojo> ive proposed a solution ;)
<thom> no you haven't
<daniels> the options are: a) use a consistent and obvious icon for everything, b) not have firefox on 4 of our 5 architectures, c) have firefox behave totally differently and have a different icon depending on which architecture you use
<daniels> 'i want to get a web browser, how do i do that?' 'click on the ... well, what sort of computer do you have?' 'i don't know ... a pc' 'i386 or amd64?' 'what?' 'when did you buy it?  how fast is it?  what does cat /proc/cpuinfo say?' '*sigh* never mind ...'
<mr_mojo> that's really unfair
<daniels> as well as an absolute nightmare wrt security updates
<daniels> how is it unfair?
<mr_mojo> you are slating me when i propose a solution
<daniels> not you in particular, it's just that your solution is totally unworkable
<thom> mr_mojo: no, we're pointing out the huge number of issues that your "solution" would create
<mr_mojo> now you are insane if you think ppc users won't know that they are running a ppc computer
<zyga> hmmm
<zyga> what's the problem with firefox?
<mr_mojo> you are overexaggerating stuff to put me down
<thom> zyga: we can't use the branded icon
<daniels> mr_mojo: why should it be different?  why do we suddenly need two sets of instructions for everything?  and can you explain the difference between i386 and amd64 to my mother?
<zyga> why not?
* zyga reads baclkog
<mr_mojo> no, because your mother should be using 1i386
<mr_mojo> i386*
<daniels> but she isn't, because the cheapest pre-built computers you can find today are amd64.  anything else?
<mr_mojo> what the heck?
<thom> zyga: http://lists.debian.org/debian-devel/2004/02/msg01877.html
<mr_mojo> do you know that amd64 runs i386 aswell?
<daniels> mr_mojo: yes, I do
<mr_mojo> why would she restrcit herself massively by choosing amd64 and losing lots of software over i386?
<thoreauputic> mr_mojo: for heaven's sake.... stop wasting their time
<mr_mojo> does she really need 64bit memory addressing?
<daniels> but I think this is utterly pointless.  if you want to seriously propose that we have a completely different web browser across architectures, go ahead, but don't be offended when no-one else is enthusiastic about it.
<mr_mojo> stop exaggerating!
<mr_mojo> its not a 'completely different web browser', it would be the exact same web browser, just you'd have the proper icon on x86!
<Treenaks> mr_mojo: depending on your definition of "proper"
<thom> mr_mojo: it's not the same web browser. we have stacks of patches to make firefox work and to fix issues that our users have. most of those will not go into firefox 1.0 branch because moz.org is not interested in landing those patches on a stable branch
<zyga> can we contact the author of the original artwork and ask him to give us permission?
<daniels> mr_mojo: the last thing I have to say on the topic is this -- imagine the case where we have 0.93 in warty, and 1.0PR1 is released, fixing security vulnerabilities, but breaking a whole bunch of other stuff.  do you update the build to the version and break other stuff, do you leave everyone vulnerable, or do you roll back to your own version using an unofficial icon?
<zerokarmaleft> it's just an icon...and as far as branding is concerned, strenthening the ubuntu brand should be a higher priority than promoting firefox a bit more with official icons
<thom> zyga: it's not his choice; read the two forum threads in the mail i linked to you
<zyga> thom: reading now
<thom> mr_mojo: anyway, this is utterly off topic; accept that we're not going to implement the solution that you suggest.
<mr_mojo> ok, so if this is such a huge nightmare problem how come nld9 has the real firefox icon?
* mode/#ubuntu-devel [+o thom]  by ChanServ
<thom> mr_mojo: you're off topic now, please stop
<mr_mojo> kick me
<mr_mojo> jesus
* mode/#ubuntu-devel [-o thom]  by thom
<fabbione> thom: you scared him :)
<thom> meh :/
<fabbione> <mr_mojo> jesus
<fabbione> at least he recognized who you are :)
<thom> heh
<thom> he should be more polite to his saviour, then :P
<fabbione> ok let me prepare the last (hopefully.. pitti eh?) kernel for hoary...
<daniels> fabbione: scaring one person > having a useless development channel
<fabbione> daniels: dude.. thom has been way too nice...
<fabbione> i am just too lazy to op myself
<pitti> fabbione: the absolutely last one or the really, really, really absolutely last one? or even more absolute? :-)
<fabbione> pitti: eheheh
<thom> pitti: dude, it's tuesday. by thursday there'll be three more critical issues
<daniels> heh
<pitti> thom: I never questioned this :-)
<pitti> thom: btw, did you try to jigdo today's i386 images? ppc works fine, but for i386 I get a template md5sum mismatch
<Treenaks> thom: you should run out of critical issues eventually, right?
<pitti> Treenaks: dreamer...
<fabbione> thom: after this upload (-34) i won't care less about 3 more gave security self-destructive bugs..
<fabbione> thom: it will be pitti's problem.. not mine :)
<daniels> haha
<fabbione> thom: he gave green light on empty queue :P
<daniels> yeah, hopefully both the kernel and xorg are frozen tonight
<HiddenWolf> Now that's the spirit. :P
<fabbione> that's enough for me
<fabbione> kthxbye pitti!
<daniels> pitti: so yeah, after -10, any xorg bugs are yours too :P
<daniels> or seb's, because they're really bugs in gtk
<fabbione> ahha
<pitti> kernel? huh? what's this?
<daniels> pitti: it's this thing that has device drivers and a memory manager or something
<daniels> maybe a scheduler too?
<pitti> daniels: nobody wants that; folks want firefox and flashy colorful GUIs
<daniels> they want a FULLY 3D-RENDERED DESKTOP
<HiddenWolf> daniels: right 
<pitti> with 17 channel sound
<HiddenWolf> pitti: better!
<fabbione> pitti: AH
<fabbione> see
<daniels> because solid JPEGs look so much better when it's your 3D engine blitting them from a GL texture than your 2D engine via a pixmap upload
<Keybuk> daniels: to run on my dual-opteron?
<Keybuk> *IN MY MIND*
<fabbione> the 17 chan sound comes for the kernel
<fabbione> pitti: you WIN!
<daniels> Keybuk: you did what to concordia?
<Keybuk> nah, just dreaming of my new desktop; sadly my arse doesn't earn quite as much as it used to, so it'll be a while before I can afford it :'(
<jdub> you should make your arse work harder ;)
<fabbione> Keybuk: and you still don't have a wife :)
<jdub> hell, it could be working at the same time your hands are ;)
<daniels> 'the hardest-working arse in open source'
<daniels> except not really; you got your crotch into the april fools' background, but what's your arse featured in?
<Keybuk> I did?
<HiddenWolf> daniels: yuk!
<zyga> ah the spirit of open source :)
<Keybuk> daniels: nope, I'm not on it :)
<daniels> Keybuk: yeah you are; on the far right
<Keybuk> you've been staring at somebody else's crotch, I'm afraid
<Keybuk> that isn't me
<daniels> oh?
<daniels> i've been misled
* HiddenWolf thought it was matt
<daniels> matt's on the left, in the blue
<JaneW> Hi thought that was Kinnison?
<JaneW> I
<JaneW> on the RHS I mean
<jdub> Keybuk: that is so your crotch.
<daniels> Keybuk: you don't own the slacker t-shirt?
<jdub> JaneW: the green shoe at the bottom left is me. :-)
<Keybuk> nope, I don't own a "Slacker" t-shirt
<JaneW> heh
<Keybuk> or a camera of that make
<daniels> yeah, jdub has phat shoes
* JaneW can't recall the pic that well now...
<jdub> i'm tempted to ship it as a bonus gdm theme
<jdub> five yesses, and i'll ship tit
<jdub> ship it
<Keybuk> ++
<daniels> much better to ship the picture of elmo running across the road
<daniels> i found that again, giggled
<JaneW> ship tit!?
<JaneW> would that be your own special green one? ;)
<Keybuk> http://www.netsplit.com/events/2004/barcelona/barcelona-003.html
<jdub> JaneW: scarily, i just got five private messages saying that yes, i should ship tit instead... hrm.
<JaneW> *grin*
<jdub> everyone knows that warty was the tit release, not hoary!
<dholbach> ship it!
<dholbach> :-)
<Keybuk> http://www.jamesh.id.au/photos/2004-12-Mataro/imgp0247.html
<Keybuk> ^ the owner of the Slacker t-shirt
* JaneW tries to decided what's worse a warty tit or a hoary tit... ;/
<daniels> ahar
* HiddenWolf laughs his ass off
<fabbione> JaneW: ahha
<jdub> man, i still haven't put my mataro photos up yet
<sladen> it's a dancing teddy pretending to ride an imaginary bicycle along a cycle track?
<JaneW> so who's the slacker then?
<jdub> ha ha
<Keybuk> JaneW: Jonathan Masters ... was a guest on the last day or two
<daniels> *giggle* http://www.jamesh.id.au/photos/2004-12-Mataro/imgp0248.html
<fabbione> ehhe
<fabbione> i think i have a few pics of elmo looking normal
<fabbione> but i am not going to publish them
<HiddenWolf> lol@fabbione
<Treenaks> fabbione: I have a few pictures of /jdub/ looking normal
<fabbione> not without a good revenue at least :P
<fabbione> Treenaks: i don't believe that :)
<Keybuk> I think I have a picture of every discovered jdub pose ...
<daniels> heh
<Treenaks> fabbione: http://foodfight.org/fotos/2004/12-04%20Ubuntu%20Conference/12-07%20Ubuntu%20Conference/?img_0001.jpg
<jdub> Keybuk: hah! unlikely!
<fabbione> daniels: how the tests are going?
<HiddenWolf> That must've been an inspiring presentation
<daniels> fabbione: in the install target now, about to run a warty->hoary upgrade test
<JaneW> is elmo camera shy?
<fabbione> daniels: ok
* Keybuk wonders whether we get projectiles^Wsweets in Sydney
<Treenaks> HiddenWolf: it was about seeds & germinate..
<fabbione> JaneW: yeah
<Kamion> JaneW: let's say not fond of cameras :)
<JaneW> heh, no better way to attract them..
* JaneW makes note to take as many pics as possible of elmo.
<Kamion> haha
<fabbione> JaneW: good luck :)
<daniels> elmo is about as fond of cameras as Kamion is of entertaining nicknames
<aj> Kamion has entertaining nicknames?
<fabbione> aj: yeah :)
* Keybuk gets a flashback of Kamion hitting the floor while trying to kick elmo
<fabbione> Treenaks: you have a bunch of nice pics there
<dholbach> our wiki rocks: now it says:  ['Welcome. You are now logged in.', 'Welcome. You are now logged in.'] 
<Treenaks> fabbione: like http://foodfight.org/fotos/2004/12-04%20Ubuntu%20Conference/12-07%20Ubuntu%20Conference/?img_0008.jpg ? :)
<dholbach> wonder what happens, when i log in again
<daniels> dholbach: yeah, that part is particularly special
<daniels> dholbach: the URL lets you craft your own welcome message IIRC
<fabbione> Treenaks: yeah :)
<daniels> Treenaks: bah
<dholbach> daniels: i didnt 
<daniels> someone saw that photo and asked me if I'd been stacking on weight lately
<dholbach> daniels: i just tried to login
<daniels> dholbach: no, but you can if you want to
<dholbach> daniels: i know, well i'll try later...
<dholbach> i'll be out... having lunch with mvo - see you later
<fabbione> pitti: you better start to baz get the kernel :)
<fabbione> -34 ACCEPTED
* mvo is away to have lunch
<daniels> frig
<daniels> fabbione: ping
<thom> foodfight.org is *such* an appropriate domain to be hosting mataro photos
<thom> ;-)
<pitti> deathbagp0rn.net
<fabbione> daniels: ?
<daniels> fabbione: how much do we care about migration?
<fabbione> thom: ahahah
<daniels> fabbione: i forgot that config gets called *twice*
<daniels> fabbione: here's how it goes
<fabbione> daniels: we do care and a lot
<daniels> preconfig: xserver-xorg.config called, xserver-xfree86 templates migrated -> xserver-xorg
<daniels> deconfigure: xserver-xfree86 removed
<daniels> postinst: xserver-xorg.config called again, xserver-xfree86 templates migrated -> xserver-xorg
<daniels> but they're seemingly busted
<fabbione> daniels: there is a check that avoids that explicitly
<fabbione> or there was at least
<daniels> yeah
<daniels> ok
<fabbione> the test checks if the templates exists
<fabbione> if they don't it doesn't perform the migration
<fabbione> that's how i implemented it the first time
<fabbione> and it was working
<daniels> yep
<daniels> i'm trying to figure out what's breaking it
<jdub> elmo: please update planet ubuntu
<lamont> mdz: win or lose, I get cloop mail
<lamont> and the cool part is, the line count says pretty well how it did. :-)
<jdub> yo lamont 
<fabbione> hey lamont
<fabbione> lamont: -34 is up
<lamont> fabbione: woot
<lamont> jdub: morning
* lamont has the kid run this am, according to the current plan
<jdub> lamont: mailed
<pitti> Ho lamont
<pitti> Hi, even
<daniels> ah phew, it's just apt being crap
<daniels> i think (crosses fingers)
<lamont> jdub: ENOMAIL
<jdub> lamont: should turn up soon
<lamont> ok
<fabbione> daniels: i will be back in 30 minutes or so
<fabbione> sorry 15
<daniels> fabbione: ok, i might be gone by then, i really need to get some fresh air and some food
<daniels> fabbione: but i'm pretty sure i've nailed it, and will put sources on chinstrap
<fabbione> daniels: we need to get -10 up today and we need to test it deeply
<fabbione> daniels: we need to test it again for each change
<daniels> fabbione: yep
<Lathiat> any more kernel or xorg rebuilds planned?
<daniels> just the one xorg
<fabbione> Lathiat: kernel just went up
<Lathiat> ah
<daniels> fabbione: i'm not planning any sleep, but just need some air and food.  it's really stuffy in here and I'm starting to get the same killer headache that screwed me last night.
<Lathiat> also is the patch to put an option for the quasi-spacial mode going to go in?
<fabbione> daniels: ok
<lamont> jdub: but it's in _sh_, not python. :-)
<daniels> lamont: it must be good!
<jdub> lamont: ber, bugger python for something like this :)
<lamont> hehe
<lamont> anyway, off to get ready and take kids to school.  back in about 90 or so.
<daniels> I AM THE WINNER
<lamont> jdub: you still gonna be awake then?
<daniels> fabbione: warty -> hoary upgrades ar ego
<lamont> daniels: of what? most-bloated-upload?  that'
<lamont> s haggai, dude.
<daniels> heh
<daniels> of 'beating horrible debconf shell hacks'
<lamont> you evil kid you
<daniels> fabbione: i put in 1600x1200 for xserver-xfree86, and got that, with sync ranges, in xorg.conf when i upgrade
<daniels> fabbione: no questions asked
<daniels> lamont: i try :)
<lamont> anyway, away with me.  back later
<jdub> lamont: yeah
<fabbione> daniels: what if you set to something like 800x600 ?
<fabbione> daniels: are you sure it's not re-probing?
<daniels> i'll test that one too, but should be ok
<daniels> i'm sure it's not re-probing, because this is amd64
<daniels> -> no ddc
<fabbione> ah ok
<daniels> also it was 16x12 10x7 8x6 ...
<daniels> not all the resolutions in between
<daniels> but i'll try 8x6
<fabbione> ehhe
<fabbione> ok
<fabbione> i am off for a little while
<daniels> ok, me too
<daniels> scping new -10 packages to chinstrap:~daniels
<daniels> fabbione: yeah, it works fine with 8x6 as well, and config/postinst now tells us a shitload more about what it's doing so debugging these problems won't be as hard in the future
<daniels> i'll be back later, y'all
<fabbione> daniels: ok
<HiddenWolf> lol. just set the terminal to do a transparant background, and it's giving me my wallpaper instead of the xchat background that is behind it. :)
<Treenaks> HiddenWolf: that's normal
<HiddenWolf> Treenaks: It's funny tho. :)
<HiddenWolf> transparant in my book is showing what's behind it. :)
<Robot101> it's fake transparency
<Robot101> it just hints the desktop
<HiddenWolf> *smile*
<SuperL4g> How do you edit the menus? or is there no way to do that?  I've got an icon I'd like to remove from the menu.
<Treenaks> SuperL4g: remove the program
<Robot101> open nautilus, go to location applications://
<Robot101> rearrange as you see fit
<Treenaks> Robot101: that only works in warty, right?
<Robot101> hmm, really?
<Treenaks> Robot101: yeah, but I thing someone pythoned up a menu editor
<Robot101> I thought it came with the new vfolder shizzle, not went away with it
<Treenaks> it went away with the new menu system
<Robot101> hokay
<thully> has anyone checked into the installer network configuration issues (wi-fi configuration can be an infinite loop if no hotspot is available is the largest one) I reported a while back... 
<SuperL4g> Treenaks: I installed this package from source code, so that's not that easy. :/
<SuperL4g> I thought that Acrobat Reader 7 would work on Ubuntu64, but there aren't any emul libs.
<Kamion> thully: no
<Kamion> not all of them, anyway
<thully> OK
<Kamion> I'm the only person doing this stuff, and I'm afraid I just have not had the time
<pitti> dholbach: I reviewed http://www.ubuntulinux.org/wiki/AptGetOrg
<Kamion> (that's code for "patches welcome", by the way)
<fabbione> daniels: -10 is not on chinstrap yet, is it?
<kain> can somebody shoot ubuntu in #ubuntu
<kain> ?
<roo_> who are the ops for #ubuntu?
<blueyed> done, roo_ .. :)
<roo_> thanks blueyed :)
<zul> morning
<pitti> I'm offline for ~ 1 hour, cu later
<shaya> whose in charge of the i386 kernel builds?
* netjoined: irc.freenode.net -> zelazny.freenode.net
<zul> shaya: kernel team
<shaya> the madwifi part of restricted doesn't work really (but in i686 build, works perfectly fine)
<shaya> but leaves one screwed after an install or livecd use (as that's i386 kernel)
<fabbione> hi zul
<zul> hey fabbione how is it gonig?
<mvirkkil> dholbach: Did you manage to restore the work you did on the AptGetOrg page in the end?
<dholbach> mvirkkil: re-reviewed them all :-)
<dholbach> hey ogra, tritium 
<tritium> hey dholbach :)
<mvo> hey dholbach 
<ogra> hi dholbach 
<dholbach> hey mvo, long time no see ;-p
<dredg> dholbach: you're insane. i salute you, i don't think i could have re-done it.
<dholbach> dredg: fortunately, i have a good memory for useless stuff :-)
* dredg laughs
<dholbach> dredg: so i remembered quite a few of them :-)
<dredg> i'll be sure to point out to the apt-get people that they and their packages are useless :)
<dredg> or did you in fact mean something else...? ;)
<dredg> er, apt-get.org that is
<dholbach> dredg: that was already diplomatic :-)
<dredg> indeed :)
<dredg> right, back to work. ttyl
<kagou> hi
<jdub> thom: is mod_security the kind of thing that every apache2 install should just have enabled by default?
<dholbach> elmo: pitti has finished the security review of apt-get.org, seems like a GO, if you could look at the few that seem to have license issues
<fabbione> daniels: you back?
<jbailey> BAH
<dredg> jdub: mod_security is bloody handy. especially for phpbb2 exploits, because you can acl off any request
<jbailey> I just figured out that I can't reproduce this syslogd hang on this box because ppc doesn't have nptl.
<seb128> fabbione: do you use the standard gamin output or you have hacked it to be verbose ?
<jdub> fabbione: apologies for sicking DV onto you, but this is probably the best way to deal with it ;)
<fabbione> seb128: i added a few more lines here and there, but just sending a kill -SIGUSR2 is enough to see the issue in the logs
<seb128> fabbione: just copy the log on rafb.net and point it to him
<fabbione> jdub: no.. nothing to be sorry.. this is stuff that you are supposed to be doing :)
<Simira> jdub: hey, got my mail about the ubuntu-no list?
<zul> heh ubuntu-no sounds funny...
<fabbione> anyway, clearly gamin is broken by desing
<Simira> zul: we decided not to go for no-ubuntu....
<fabbione> it would take me less time to rewrite it than to debug it
<zul> Simira: that would be funnier :)
<jdub> Simira: yep, glad you're here, we can sort out passwords and stuff directly :)
<fabbione> seb128: rafb.net?
<jdub> fabbione: i can't explain it :)
<Simira> jdub: sure
<fabbione> jdub: your problem.. not mine.. i am not the DD for gamin
<fabbione> :)
<seb128> fabbione: http://rafb.net/paste/, a stuff handy when you don't want to bother upload files somewhere
<fabbione> daniels: ping?
<bod>   mirrors@canonical.com                                                                                                             
<bod> as listed on http://www.ubuntulinux.org/wiki/Archive
<bod> is broken
<daniels> fabbione: pong
<fabbione> daniels: the -10 on chinstrap is the same as before...
<fabbione> you didn't upload the fixed one
<daniels> ok, uploading a new one now
<mdz> morning
<dredg> lo mdz 
<zul> hey mdz
<mdz> fabbione: does mpfr have many reverse {build-,}depends?
<daniels> fabbione: check chinstrap:~daniels
<seb128> hi mdz 
<daniels> mdz: morning
<lamont> moof
<fabbione> daniels: ok
<lamont> morning mdz
<mvo> morning mdz
<lamont> mdz: to rephrase my answer earlier: I get emailed the output of BuildLiveCD from the cronjob
<fabbione> mdz: gcc-4.0 build-dep on it. it's only a rebuild to get rid of dir.old.gz, but jdub authorized it
<lamont> so if you start the build, then no, I don't get email about it
<fabbione> daniels: downloading now
* kain is away: phumo
<mdz> fabbione: ok, sounds fine
<fabbione> mdz: it's harmless. no changes anywhere
<mvo> mdz: permission to upload http://people.ubuntu.com/~mvo/01_fix_permisson_and_session.patch?
<fabbione> daniels: i keep getting the same interdiff....
<daniels> fabbione: hm
<mdz> fabbione: did you scan for dir.old.gz in othre packages as well?
<mdz> mvo: what is the intent of the setsid?
<lamont> fabbione: if you didn't, I'll do it now.
<daniels> fabbione: do you have the two bug closers in debian/changelog and debug_echo() in .postinst.in?
<fabbione> mdz: elmo was generating a new Contents-*.gz, but i think he crashed before it finished
<daniels> fabbione: if so, that's the latest package which works fine with a warty -> hoary upgrade and doesn't ask any questions
<fabbione> daniels: yes i have the 2 bug closers, but i don't see any code change from the other interdiff
<mvo> mdz: there is a problem that time-admin restarts xscreensaver. when time-admin runs with sudo everything is fine, but when it runs with gksudo xscreensaver gets a SIGHUP when gksudo exits
<lamont> fabbione: making a pass over main now
<fabbione> daniels: i have debug_echo() yes.. but no changes related to debconf
<fabbione> daniels: nothing more of what we discussed this morning
<fabbione> lamont: thanks
<Kamion> hmm, "New Login" on the live CD is badness
* Mithrandir kicks X
<Kamion> not only do you get prompted for a username/password, but also when you quit the nested gdm you get prompted by xscreensaver for a password
<daniels> fabbione: all that's left is removing MIGRATE_XF86, which is purely cosmetic ... with this, the upgrade didn't ask me about the resolution at all, it just carried over
<lamont> Kamion: that's under the "don't do that" category, or was when I asked about it...
<lamont> classed as the same as 'lock screen'
<lamont> which is also permanent
<pitti> Hi mdz 
<fabbione> daniels: something isn't matching than. you mean the entire problem you described this morning was related to missing debug_echo ?
<lamont> however, ctl-alt-backspace cleans it up....
<dholbach> pitti: thanks for reviewing
<Kamion> lamont: or switching to ctrl-alt-f1 and 'sudo passwd ubuntu'
<pitti> dholbach: you're welcome
<daniels> fabbione: no, me needing to just sit back and think for five seconds
<lamont> Kamion: true
<daniels> fabbione: i knew there wasn't something quite right about the debugging output
<lamont> Kamion: or rebooting :-)
<mdz> mvo: ok, that makes sense
<daniels> fabbione: i saw 'Resetting all values' and realised it was still an old, old package
<mdz> mvo: I'm concerned that it could have unexpected consequences 3 days before release though
<fabbione> daniels: ok...
<daniels> (i changed Resetting to resetting)
<fabbione> daniels: yes i can see that
<daniels> doing a new test with the same logic that was there this morning worked ok
<daniels> so it was that that tipped me off ... i'm about to try intra-hoary upgrade, fresh install, and reconfigure tests
<fabbione> daniels: ok
<fabbione> lamont: please be sure to check it also on all arches
<fabbione> lamont: because it seems that the sparc problem was due to sparc lagging a few days...
<fabbione> so there might be packages that didn't have the treatment
<daniels> fabbione: intra-hoary upgrade and reconfigure are OK
<fabbione> ok..
<pitti> who can I bother with a broken jigdo template for i386?
* fabbione suggests to fasten all the seatbelts
<lamont> fabbione: certainly checking all architectures.
<thom> pitti: kamion
<pitti> thanks
<fabbione> lamont: thanks
<mvo> mdz: I agree with you, I'm not happy about it either. 
<pitti> Kamion: do you have an idea why the i386 jigdo template is broken today? md5sum does not match the .jigdo file. powerpc works fine
<mvo> ogra: could you please file a bug about the xscreensaver/time-admin problem so that the patch can be put into bugzilla?
<mdz> mvo: agreed; let's document the workaround there, and change gksudo after release
* netjoined: irc.freenode.net -> zelazny.freenode.net
<lamont> dpkg-deb: file `/srv/archive.ubuntu.com/ubuntu/pool/main/d/diveintopython/diveintopython_5.4-1ubuntu1_all.deb' contains ununderstood data member data.tar.bz2    , giving up
* lamont grumbles
<zul> dont be sad put on a happy face...happy happy people
<daniels> fabbione: clean install looks ok ... you got any testing/comments?
<fabbione> daniels: i want another warty -> hoary test, just be 1000% sure
<daniels> ok
<daniels> i'll do the third :)
<Kamion> pitti: which md5sum?
<fabbione> daniels: than i will be happy with that
<fabbione> yes please
<mdz> I'll do warty->hoary upgrades on powerpc and amd64 once it's in the archive
<fabbione> mdz: thanks. i will test here too 
<fabbione> mdz: on more machines..
<Kamion> pitti: but basically no, I don't know
<fabbione> mdz: with -34 i am happy enough with the kernel. i think we can start working on breezy features soon
<pitti> Kamion: okay, if it's not fixed by tomorrow, I cry again
<pitti> Kamion: maybe just a glitch in today's image, I try the ones from tomorrow
<mdz> doko,jbailey: here?
<zul> fabbione: wohoo! :)
<Kamion> pitti: ok, it would very much surprise me if it were a server problem though, nothing's changed there
<jbailey> mdz: Here.
<lamont> fabbione: starting with a 2.6.11pre12.0 kernel?
<fabbione> lamont: i was more up for a 2.6.12rc2 or something like that
<fabbione> but yeah
<zul> why...2,6.12rc2 was released
<fabbione> on that line
<zul> better sata supprot as well
<fabbione> uzul: i just recko that i am tired
<fabbione> he meant 2.6.10pre2.6.12
<lamont> pb is that 2.6.12rc2 > 2.6.12
<zul> heh
<fabbione> that would include rc2 :)
<lamont> so, no, I meant 2.6.11pre12.rc2
<fabbione> lamont: sorry.. i got it a few secs later
<lamont> after all, it is newer than 11
<fabbione> lamont: that's ok with me, given that we can let make-kpkg to understand that :)
<lamont> well, worst case, we call it 2.6.11.95 :-)
<fabbione> that would be easier...
<fabbione> seriously
<lamont> that is, linux-source-2.6.12_2.6.11.95-0
<lamont> I have no problem with that version number, as long as it becomes _2.6.12-1 before release. :0)
<lamont> prolly want to start with .90, just to have room... :-)
<jbailey> lamont: At least call it .96 and say that .95 is rc1.
<fabbione> why that?
<fabbione> it's a "fresh" start
<zul> jbailey: heh..you could call .99 the wayne gretzky release :)
<jbailey> So that you can look at the version number and guess what kernel rev it likely maps to.
<Kamion> mdz: please merge colin.watson@canonical.com--2005/casper--translations--0 up to patch-14
<jbailey> (assuming that the scheme will get reused again)
<daniels> mdz: this is the only other thing I can think of left -- https://bugs.freedesktop.org/show_bug.cgi?id=2150
<daniels> mdz: the patch looks ok, both from a description and code pov
<mdz> daniels: what real-world circumstances could be affected by that bug?
<pitti> lamont: would linux-source-26.12 would work? because you need a new orig.tar.gz when 2.6.12 final is released
<daniels> mdz: some laptops just go 'wtf' and refuse to work
<daniels> mdz: https://bugzilla.ubuntu.com/show_bug.cgi?id=6746
<daniels> seems to only be trident cyberblade
<daniels> most everyone else isn't that strict about vesa
<daniels> fabbione: ok, works fine for me
<lamont> pitti: sure
<lamont> linux-source-2.6.12_2.6.11.90.orig.tar.gz != linux-source-2.6.12_2.6.12.orig.tar.gz
<mdz> Kamion: merged and uploaded
<fabbione> daniels: warty -> hoary?
<daniels> fabbione: yep
<lamont> zul: dave draveky release
<daniels> fabbione: using 1920x1440 800x600 640x480
<zul> lamont: heh
<mdz> jbailey: do you have anything on your list for Hoary which justifies an upload this week?
<fabbione> daniels: ok.. you have my blessing for uploads at 2 conditions.. keep your damn mobile phone on... and put aside more money for beer if it breaks the shit out of *
<mdz> jbailey: if not, I think it would be good to get a head start on breezy stuff
<daniels> fabbione: haha
<daniels> fabbione: consider it done
<mdz> jbailey: since you and doko want to get at it before everyone else
<fabbione> daniels: ok
<pitti> mdz: I got a security update from astharot for racoon, which is in universe; however, the source pacakge (ipsec-tools) is in main; do you agree that I should write an USN in this case?
<mdz> daniels: I have a laptop with a trident cybersomethingorother but not 'blade'; it worked OK the last time I tested
<daniels> mdz: yeah, the cyberblade is a different chipset to the rest
<mdz> pitti: this is an awkward case :-/
<pitti> mdz: if I update without an USN, then the people could ask themselves why ipsec-tools was upgraded
<lamont> mdz: once we have an archive for it, and jbailey/doko tell me what they want in it, we can do that full rebuild for them anytime... although it would be nice to wait until after we finish the long-build-time package-thrash
<pitti> mdz: I would mention that it only affects racoon, which is actually unsupported officially
<mdz> pitti: for Hoary we should review packages in this situation, and decide if we should promote them or split them
<pitti> lamont: erm, of course. my brain already sleeps, as it seems
<mdz> lamont: what full rebuild?  a test-and-throwaway rebuild like for hoary?
<pitti> mdz: for hoary? breezy you mean?
<lamont> mdz: gcc-4.0 throwaway rebuild
<mdz> pitti: er, yes
<pitti> mdz: *phew* :-)
<Kamion> mdz: thanks
<mdz> lamont: we might as well take advantage of the builds we'll already be doing, and only do an explicit test for packages which don't get built
<mdz> lamont: many of the versions we'll be merging in will have gcc-3.4+ fixes anyway
<lamont> right
<jbailey> mdz: I just did the sysklogd upload, and I had arranged to be near an exchange server tomorrow to see if I could wipe out the various bugs that keep showing up in it.
<lamont> which compiler is default for breezy?
<daniels> fabbione: -10 is up
<fabbione> daniels: rocking
<lamont> daniels: you have a breezy goal to split at least the font source out of xorg, right?
<mdz> jbailey: sysklogd?
<jbailey> mdz: Miquel van Smoorenburg(sp?) reported a race condition where sysklogd could hang when a SIGALRM was received during a ctime call on an NPTL using machine.
<jbailey> mdz: The side effect after that is that anything that uses syslog(), which is synchronous, hangs until syslogd wakes up again.
<daniels> lamont: i have a breezy goal to split as much as is sensible out of xorg
<jbailey> Very short patch that masks the signals and restores them after the critical section.
<pitti> daniels: yay!
<daniels> lamont: we're looking at an upstream release date of august for the complete modular tree, so yeah, fonts will certainly go
<daniels> with any luck, there will be no 'xorg'
<fabbione> lamont: when in novemeber we did the X sprint.. it could have take us only a week more of work to get xorg splitted.. but we were told to wait for breezy
<Kamion> will we be able to pull stuff in before August?
<pitti> daniels: and libxpm will be thrown out to universe *hehe* :-)
<mdz> fabbione: it sounds like modular xorg won't be ready for breezy but perhaps for breezy+1; is it worth the effort to split xorg when modular is coming?
<fabbione> mdz: it was worth in november yes...
<fabbione> mdz: as you can see upstream delayed even further
<fabbione> :(
<fabbione> and we could have all gained a lot from it...
<daniels> right
<fabbione> SNMP
<daniels> so the current proposed release schedule has X11R7 on August 19th
<fabbione> it's daniels that his owned by X now :P
<lamont> fabbione: security is too your problem
<daniels> worst-case scenario, if it slips by a whole lot, we can just break out almost all the libraries and fonts and stuff and leave the server as is; the libraries are already a solved problem (and I already have the packages done)
<fabbione> lamont: that's why modular > monolitic.. see libxpm :)
<zyga> what is the purpose of splitting xorg into separate modules?
<fabbione> that lib will cost us several hundred megs
<mdz> silly keyboard shortcuts
<daniels> although, to be fair, libxpm isn't entirely the modular tree's fault:
<daniels> daniels@catsby:~/canonical/d-i/hoary-i386% apt-cache rdepends libxpm4 | wc -l
<mdz> anyway, let's talk about xorg for breezy later, and talk about xorg for hoary now
<daniels> 349
<Kamion> zyga: not having to download three gazillion megabytes of fonts when someone fixes a typo in xserver-xorg.postinst
<daniels> Kamion: (hypothetically)
<daniels> mdz: -10 is up with some small tweaks that fix the xfree86 migration issues mentioned
<zyga> Kamion: isn't it better to adopt xdelta or whatever it's called and actually download the difference ?
<daniels> zyga: no
<mdz> aha, it just reached me via hoary-changes
<jbailey> zyga: It's also all the mirroring, etc..
<daniels> zyga: it just doesn't make sense to me that a new version of fonts should get built when I change the Radeon driver
<zyga> hmm
<Kamion> zyga: er, very hard and poorly-understood solutions later rather than only moderately hard and fairly-well-understood solutions sooner, you mean?
<Kamion> zyga: (i.e. no)
<lamont> zyga: and the fact that compressed files don't xdelta/rsync very well, esp when they have timestamps in them
<daniels> zyga: it also seriously cramps development -- on my new shiny fast amd64, it takes 45min-1hr for a full rebuild, depending on load ... that's a friggin' long time to find out at the end that you made a typo
<zyga> I see
* fabbione goes for a little break while waiting for X
<Kamion> there's a good reason that e.g. the installer is lots of different modules rather than one honking big lump
<zyga> well downloading all the fonts over again does suck so I thkink that's positive
<lamont> fabbione: does that mean we get to break out the kernel build too/?? :-)
<daniels> on my laptop, it takes 2 hours; builds take about 4 or 5GB these days
<fabbione> lamont: i would love that too :)))))
<zyga> (as well as >> 50% of software for amd64 and i386)
<fabbione> lamont: we need to decide a few things before UDU
<daniels> zyga: this is one of the times when the main thing holding upstream back is the main thing holding the distributions back.  EVERYONE involved with X wants it to happen.
<fabbione> lamont: so that we can start working for breezy
<zul> fabbione: such as
<lamont> that reminds me - I have an email message to write this week,.
<fabbione> lamont: but let's do that in 10 minutes.. i really need to enjoy 10 minutes of air outside
<fabbione> uzul: the packaging system suckage?
<lamont> or was zul going to do his first pass and email...
<zyga> daniels: in that case I trust in the wisdom of others :)
<fabbione> lamont: it was your :)
<mdz> Kamion: let's roll CDs and do a test cycle once xorg is built, sound good?
<zul> lamont: still working on it..wasnt feeling well last night
<Kamion> mdz: installer stuff still underway
<lamont> fabbione: I kinda remembered it that way
<Kamion> I'm testing out a change for that bootable-flag bug
<mdz> Kamion: more than one xorg-build-unit worth?
<Kamion> translation updates too
<lamont> somehow didn't make it on the list though... fixing
<Kamion> it'll need an initrd rebuild
<mdz> lamont: one XBU ~= 3 hours or so, right?
<lamont> XBU?
<Kamion> I'll upload all the in-initrd stuff now
<pitti> X build unit?
<lamont> xorg build unit
<lamont> checking
<daniels> i'd say 3h would be the worst-case scenario
<daniels> i think the longest build out of the major 3 is 74min
<lamont> mdz: 90 min after source is in the archive, you should have all 3 arches in the archive
<lamont> xorg:                   01:14:19 (13 entries, sigma 00:06:09)
* lamont hands daniels a cookie with "Powerpc" on it.
<daniels> that means I've got about 180min to sleep before everyone discovers -10 is completely screwed
<daniels> g'night folks
<daniels> lamont: 74min19sec, unless I'm *really* tired
<lamont> daniels: hence the cookie
<daniels> oh, right
<daniels> well, pingable by mobile if it's totally snafu
<zyga> daniels: rebuild of xorg?
<daniels> zyga: yeah
<zyga> daniels: how much ram do you have?
<Kamion> any Germans around? I need a translation of "Kill switch enabled on ${iface}"
<lamont> zyga: that's a 2GHz G5 with 2GB ram
<zyga> last time I've rebuilt xorg (5 months ago) it took about 30 min on my laptop athlon 2000, 512
<Kamion> ("Kill switch" is a single noun phrase, not kill (verb) switch (noun))
<lamont> xorg:                   00:33:40 (12 entries, sigma 00:10:28)
<lamont> thats amd64
<zyga> maybe I had some modules turned off hmm...
<Kamion> zyga: it'd only be a valid comparison if you were building the full source package
<ogra> hmm, my mouse just stopped working in one of five mozilla windows, keyboard navigation works but i cant even move the scrollbar with the mouse, thom, any idea what this could be ?
<lamont> zyga: that build time also includes installing and removing all of the build dependencies
<mvo> Kamion: context for "kill switch"?
<zyga> lamont: okay that makes sense
<thom> ogra: "crack"
<Kamion> mvo: it's a switch on some wireless cards that makes the card stop working
<daniels> zyga: the amd64 has 1GB, matched-pair low-latency etc etc.  as kamion alludes to, we do other stuff.  unpacking a big tarball, applying patches, parsing and testing scripts, building the whole thing, building the entire tree again (after copying it) with the servers-only option, grouping it into packages after installing it, calculating dependencies ...
<thom> ogra: you can't move the mouse at all, or something's eating your button presses?
<mvo> Kamion: tricky one, let me think about it a moment
<ogra> thom, i can move the mouse, and it works fine in the other mozilla windows...
<Kamion> mvo: netcfg checks whether it's enabled (there's an rf_kill file in /sys that tells you) and warns the user that they might want to switch off the kill switch before continuing
<seb128> Kamion: today's iso is supposed to have the translations you have merged yesterday ?
<ogra> thom, just the one with the buzilla page seems to freak out, are there any strange javascripts ?
<lamont> as of 07:33 london this am (when rookery's mirror last updated), there were no usr/share/info/dir.old.gz files in main
<thom> ogra: not *that* strange
<lamont> universe scan going now
<Kamion> seb128: no, I haven't uploaded them yet
<seb128> k
<dholbach> lamont: scan?
<ogra> thom, i can <tab> through the entrys, even the up/down keys work....i just cant click anything or move the scrollbar
<lamont> dholbach: brute force walk through the archive looking for things that deliver dir.old.gz --> autoconf b0rkage
<lamont> s/autoconf/autocrap - don't remember which/
<pitti> jbailey: is the syslog hang triggerable by users?
<lamont> dholbach: wandering to -motu to dump a little work on y'all
<dholbach> lamont: great :-)
<mvo> Kamion: "${iface} durch Hardwareschalter deaktiviert" (other germans, what do you think?)
<jbailey> pitti: Yes, it should be.
<jbailey> pitti: Although, it's quite difficult to do.  There's not alot of instructions, and the sigalrm happens once every 20 minutes.
<pitti> jbailey: sounds like a local DoS then, and a necessary Warty fix ?
<jbailey> pitti: Mmm...  My first inclination is not to bother, since the user would likely fill up the harddrive first with the overuse of the 'logger' command before triggering it - which I think is a far bigger (and generally unsolvable) issue.
<ogra> thom, enter seems to work neither.....
<jbailey> pitti: But it's an easy enough fix, and for completeness it would probably make sense.
<pitti> jbailey: hmm, right
<jbailey> pitti: I've marked the bug as 'remind' for myself so that I can see whether glibc ought to just protect against this anyway.  If that winds up being the case, I think it's a greater candidate for a warty/hoary backport from breezy.
<ogra> thom, reproducable: my mouse stops working if the package selection pulldown pops up
<ogra> (enter key as well)
<thom> ogra: in the new bug page?
<ogra> yup
<ogra> thom, killing mozilla solved it...works with a new session...
<wasabi_> It has occured to me that gnome-volume-manager should moutnt hings 'sync'
<wasabi_> instead of async.
<wasabi_> Because I just broke the file system on my USB drive because of it. =/
<seb128> mvo: http://lists.debian.org/debian-l10n-french/2005/04/msg00186.html
<ogra> mvo, #8684
<seb128> mvo: can you use this french translation already ? They will probably do a review before sending it to you, but that should be better than the current one :)
<mvo> ogra: thanks
<mvo> seb128: ok
<seb128> thanks
<Kamion> mvo: ok, thanks, I'll use that; that should be German at 100%
<mvo> Kamion: thanks
<Kamion> damnit, I missed nb updates; lucky I only got partway through the translation upload run
<mvo> seb128: commited to svn, will upload tomorrow or tonight
<seb128> rock
<blueyed> I can run different sound output programs with the same user using gnome and kde simultaneously, but not with two different users. Is this a bug? (esd, both users in audio group)
<mdz> mjg59: re: #8490, do there exist laptops perverse enough to have software-controlled battery charge indicators?
<HiddenWolf> mdz: probably, must be cheaper than hardware. :P
<Keybuk> the hardware lights are usually on the battery themselves
<thom> mdz: but what crack ful patch ahve suse found to make it work?
<mdz> thom: "use apm"?
<thom> mdz: hrm
<thom> oh, for hibernate i don't see  a clean way of working round the problem, but i think we should request a reboot asap anyway...
<Kamion> mdz: sorry, one more casper translation for you, patch-16
<mdz> Kamion: done
<mdz> thom: yes, but not for hoary
<thom> mdz: nod
<ogra> elmo, graveman sync please
<elmo> [NOT Updating - Modified]  graveman_0.3.8-1ubuntu0 (vs 0.3.10-1)
<elmo> ok to override?
<ogra> yup
<ogra> thanks :)
<blueyed> about the sound with two different users (see above): should I file a bug report or is it not meant to work?
<mvo> mdz: do you consider #8668 (update-manager does not uses the synaptic proxy settings for getting the changelogs) worth fixing before hoary? I have a patch in cvs for it
<mdz> mvo: non-intrusive?
<mdz> mvo: also, I saw a bug about hoary-updates not having a pretty description in synaptic; I assume that is trivial and safe to fix?
<mvo> mdz: yes, the later is trivial and safe and already fixed
<mvo> mdz: pretty non-intrusive, I feel pretty good about it
<mdz> mvo: ok
<mdz> ogra: did you not realize that cdrdao is in universe?
<mdz> ogra: you'll need to revert that depends: change
<ogra> ok
<pitti> mdz: btw, haggai asked me to review cdrdao for main inclusion
<mdz> pitti: yes, but not its new build-depends
<pitti> uh?
<mdz> ogra: oh, graveman is in universe, never mind
<ogra> heh
<dholbach> cdrdao needs a changed "section"-entry as well
<pitti> mdz: haggai told me that he removed pccts
<mdz> Build-Depends: pccts, autotools-dev, debhelper (>= 4.2.0)
<mdz> that's the current version in hoary
<elmo> dholbach: dude
<mdz> it is too late to bring new packages into the desktop anyway
<lamont> mdz: turns out that speech-dispatcher (amd64) and eb-doc (all) are the only packages in the archive (as of 0733 today london) with dir.old.gz
<dholbach> elmo: what's up?
<elmo> dholbach: small problem - morgue candidates is binary based... it needs to be source pkg based
<dholbach> elmo: erm... ok - will add some kernel packages tomorrow, i'll give you the list then
<dholbach> elmo: thanks for telling me
<elmo> dholbach: I don't mind if you do it based on binaries for yourself, but just letting you know, I can only remove source packages, not partially remove some binaries, IYSWIM
<mdz> lamont: assuming they're both universe, feel free to pass the list to MOTU recommending no-change uploads
<dholbach> elmo: it's not only me who added to the list *blame somebody else* ;-)
<jdub> elmo: new flumotion on its way - it will obsolete the 0.1.6 source
<fabbione> lamont: did X -10 hitted archive yet?
<mvo> mdz: last question for today: http://people.ubuntu.com/~mvo/apt/apt-broken-proxy/apt_0.6.35ubuntu1.debdiff? should this enter or should we rather postpone it?
<elmo> jdub: thanks
<mdz> mvo: I may do an apt upload for translation updates; if so, I'll include that patch
<ogra> fabbione, didnt you tell me randr doesnt work with nvidia ? worksforme....
<ogra> or is this caused by the new driver ?
<fabbione> ogra: did you use any specific option in the configuration?
<mvo> mdz: thanks
<fabbione> i am still running 7162 here or something along that line
<fabbione> not the very latest
<ogra> fabbione,      Option          "NvAGP" "3"
<ogra>         Option          "IgnoreEDID"    "true"
<ogra>         Option          "RenderAccel"   "true"
<ogra>         Option          "NoLogo"        "true"
<fabbione> ogra: i don't use any nvidia option in my config.. let me try..
<schweeb> I've always been abe to use ranr in the past... I haven't tried lately (and am using X remotely now)
<schweeb> *randr
<fabbione> i need to do quite of a job to logout from this machine :)
<fabbione> schweeb: with nvidia binary drivers?
<schweeb> fabbione: yep
<fabbione> weird.. probably it's because of the dual head.. 
<fabbione> i will need to check with the new one
<fabbione> brb
<schweeb> that's a possibility
<schweeb> I'm using dual head remotely :)
<jdub> ogra: "NvAGP" "3" ?
<ogra> fabbione, i have a huge amount of nvidia based submissions that worked
<fabbione> ogra: sorry.. i can't test it
<fabbione> i forgot to screen gcc-4.0 build
<ogra> heh
<fabbione> ogra: let me try again
<fabbione> ogra: it still gives that python error
<ogra> fabbione, but it looks like its your system....since others submit fine...
<fabbione> Xlib:  extension "RANDR" missing on display ":0.0".
<ogra> strange
<lamont> fabbione: looks like it should enter this next run
<fabbione> and than the traceback
<ogra> jdub, whats wrong with 3 ?
<fabbione> lamont: at 33?
<fabbione> lamont: cool thanks :)
<jdub> ogra: what's the setting?
<fabbione> ogra: actually.. let me see how old is my system :)
<ogra> fabbione, but i guess you got libxrandr2 installed....
<fabbione> ogra: well if they are not and you need them for hwdb.. you should depend on them...
<ogra> fabbione, i was guessing its an x dependency...
<fabbione> ogra: it's installed..
<ogra> ok
<lamont> that is, all but amd64. :-(
<blueyed> c'mon, it should be possible to have two users of the audio group access /dev/dsp, shouldn't it?
<fabbione> lamont: uh? why amd64 is lagging?
<ogra> blueyed, as much as its possible to drive a car with two drivers....
<fabbione> ahaha amd64 owned by i386 and ppc
<lamont> amd64 barely missed (missed ccache), powerpc hit the cache, won
<lamont> amd64 will hit accepted at :35
<ogra> blueyed, you still only have one steering wheel
<fabbione> yeah but it lost the daily
<blueyed> ogra, so it is not meant to work?
<blueyed> but you could provide a layer to let both access it.
<schweeb> blueyed: that's what ESD is about
<blueyed> I thought that was esd for, and it seems to be, but only on a user level then.
<blueyed> schweeb, I'm using ESD.
<schweeb> yes, esd operates on a user level
<ogra> blueyed, KDE doesnt use esd (except kubuntu has changed that)
<schweeb> it'd get pretty complicated to do it otherwise
<blueyed> I'm using amoraK with the gstreamer engine and esdsink.
<blueyed> ogra, it also does not work with only gnome for both users.
<blueyed> couldn't you please try it at your machine (if you think that it should work)?
<ogra> blueyed, because the second esd cant start without a free dsp device
<blueyed> Yesterday in #ubuntu someone said that it is a hardware issue, but I don't think so.
<ogra> blueyed, it cant work...
<lamont> --> #ubuntu
<ogra> yop
<pitti> seb128: can you please mail me 002_bmp.patch?
<enrico> seb128: around?
<seb128> enrico: yep
<seb128> pitti: oh sure, sorry
<enrico> seb128: I've just committed an update of the docteam stuff
<enrico> seb128: I can't see, however, the translated quickguide
<enrico> seb128: and I can't understand why
<enrico> seb128: I'd like to fix that (or at least see that with someone) before uploading
<mdz> thom: please address #8685 ASAP
<ogra> jdub, Option "NvAGP" "3" #try to use AGPGART; if that fails, try NVAGP
<thom> mdz: jdub claims to be doing it - it's an ubuntu-artwork update
<ogra> jdub, admittedly a bit useless :-P
<thom> mdz: oh, huh. the latter bit
<seb128> enrico: how do you try to open them ?
<thom> fixing
<mdz> jdub: dude, we need to draw the line on this artwork business, seriously
<mdz> we agreed to stop artwork updates a week prior to release
<jdub> mdz: home page waiting on final design from henrik
<mdz> thom: can we point firefox to the about-ubuntu page?
<jdub> mdz: only one change left for other stuff - colours for wm-title/selection; i haven't seen cliff for days
<jdub> mdz: also, haven't got his first calendar image
<jdub> mdz: could you call him for me?
<jdub> he hasn't appeared on IM today either
<Kamion> the release checklist has "FINAL ARTWORK" for 7 days before release; Mark asked me to put that there in all caps and bold :)
<jdub> Kamion: (note that mark has also requested changes)
<mdz> jdub: will do
<jdub> the ubuntu-docs about html is really ugle
<jdub> ugly
<Kamion> jdub: (note that I think Mark asked me to put that there so that we could stop him making changes ;-))
<fabbione> thom: are you going to make another firefox upload?
<thom> fabbione: yes
<fabbione> thom: ok thanks.
<mdz> jdub: left voicemail
<thom> fabbione: why? :-)
<jdub> ta
<fabbione> thom: i will stop sparc to build the old version? :)
<thom> ah, heh
<dholbach> packing my stuff - see you later
<lamont> fabbione: now that _IS_ funny... ia64 beat amd64
<fabbione> since it's queued right as next package :)
<fabbione> lamont: ahah i saw :)
<dholbach> herzi: will have a look at hula-server, already downloaded it
<jdub> mdz, Kamion: heh, also, i plead april 1 :)
<thom> mdz: i can; if we're getting the artwork update shall i leave it with ubuntu-artwork in preference though?
<Kamion> jdub: haha
<mdz> thom: either way, as long as it's done today
<thom> mdz: right
* mvo is away to play some hockey
<enrico> seb128: yelp ghelp:quick-guide
<jdub> mdz, Kamion: just got another artwork request/delivery from mark :)
<seb128> enrico: /usr/share/gnome/help/ubuntu-quickguide/
<seb128> enrico: change it to /usr/share/gnome/help/quick-guide/
<enrico> seb128: uh?  ah.  boh.  trying
<enrico> seb128: do I need to do the same with the release notes?
<seb128> not sure, but that seems to work here
<elmo> enrico: any problem with upgrading docteam.u.c to svn 1.1?
<enrico> seb128: let's see...
<enrico> elmo: I think at least Sean is going to be very happy about it! :)
<enrico> elmo: (and I don't think anyone else knows the difference ;)
<elmo> enrico: k, cool
<enrico> seb128: works great! Thanks!
<seb128> np
<seb128> hum
<seb128> browsing from yelp the categories doesn't pick the translations ?
<enrico> seb128: committed the new change
* elmo boggles at hoary-changes traffic
<enrico> seb128: you need translated OMF from that
<seb128> arg
<seb128> is that planned ?
<enrico> seb128: I've asked Claude for a translated french OMF 2 minutes ago (he raised the same problem)
<seb128> cool
<enrico> seb128: no idea if that's planned.  I guess not, since they're not coming :(
<seb128> is that long to translate ? is claude doing it ?
<enrico> If tomorrow's going to be release, we'll have no time for it (I won't be online tonight)
<seb128> hoary is friday 
<seb128> but I guess we are not going change after tomorrow
<seb128> enrico: bah, the xml files are trivial to translation
<pitti> seb128: did you already start with gdk-pixbuf? it's the same pacakge for warty and hoary, and since I do it anyway, I can fix hoary as well
<enrico> seb128: trivial, if you know the language :)
<seb128> pitti: nop yet, trying to fix french stuff atm :p
<pitti> seb128: okay, then don't bother, I do it
<seb128> pitti: thanks
<seb128> ta
<mjg59> mdz: Christ, possibly
<lamont> mjg59: any clues why my vaio would occasionally (most of the time) claim to not have any batteries?  (it does)
<lamont> mjg59: kernel output during boot claims acpi says no bat1 and no bat2
<Kamion> lamont: please un-cron installer daily builds; I think it's time to say we'll do any further necessary ones manually
<lamont> ok
<lamont> Kamion: and livecd roots?
<Kamion> no, leave those
<mjg59> lamont: Hrngh. Unsure.
<mjg59> lamont: Does it have the same behaviour with Warty kernels?
<lamont> went back as far as 2.6.10-3, haven't tried the -2 that's still there as well
<lamont> don't know that I ever saw it with warty
<lamont> mind you, I also need to update the bios
<pitti> elmo: can I please have libpng2-dev libgnome-dev in concordia's hoary-i386 dchroot?
<thom> mdz: fixed firefox building
<mdz> thom: thanks
<thom> (they changed the way they handled setting the default homepage; the old patch was still there *sigh*)
<elmo> pitti: done  but please let me know when you're finished
<elmo> as libpng2 pulled out a bunch of useful packages
<pitti> elmo: thanks, will do
<pitti> urgh, sorry
<lamont> Kamion: d-i daily builds disabled until you say otherwise
<Kamion> thanks
<Kamion> mdz: FYI, I may be offline much of this evening (hopefully won't be, but there's a possibility)
<Kamion> mdz: with the exception of #8496, I think I'm more or less done
<fabbione> edriver-crappydevice
<fabbione> ops
<fabbione> Kamion: does the installer have 2.6.10-34 or it will require an upload from you?
<fabbione> never mind
<fabbione> i just saw hoary-changes
<pitti> elmo: I'm done, thanks
* pitti -> food
<mdz> Kamion: acknowledged
<fabbione> mdz: upgrading warty -> hoary with -10 now..
<fabbione> it took a long time to rsync archive today
<elmo> that's because EVERY CHANGE IN THE WORLD seems to be being uploaded atm
<fabbione> elmo: eheheh
<HiddenWolf> haha, sure feels that way
<fabbione> lamont: people still doesn't have amd64 buildlog... is everything ok?
<lamont> fabbione: yea
<lamont> the log had, um, an issue or two.
<Kamion> elmo: not my fault everyone doesn't just speak English
<fabbione> Kamion: isn't time to fix this problem? ;)
<fabbione> anyway .. after this batch upload sparc is definetely lagged again
<mdz> Kamion: I hope the acquire::gpg::options code is solid; apparently it hasn't been tested all this time
<lamont> ok.. how do I get openfirmware to spit out the paths on the machine?>
<Kamion> mdz: it's Acquire::gpgv::Options::=--ignore-time-conflict, btw
<Kamion> mdz: and I won't be able to finish that bug for CD-ROM installation; apt-cdrom does not honour that config option
<Kamion> mdz: I think (a) it hasn't been tested since we moved apt-setup to the first stage, (b) one problem visible on netboot was masked in CD installations, because we turn off some of the signature verification there
<fabbione> mdz: X is go here (multiarse too)
<mdz> Kamion: it would be better to disable authentication for the CD case entirely
<mdz> fabbione: are binaries in the archive now?  if so I can start my upgrade tests
<Kamion> mdz: I wish I *could*
<fabbione> mdz: yes. they were there one hour ago or so..
<fabbione> mdz: sorry i wrote it here, but didn't underline it
<mdz> Kamion: that should be safe to arrange
<Kamion> mdz: if you can see how I can make apt-cdrom just sod off and ignore auth, please do, but I can't seem to do it with the current code
<mdz> Kamion: I'm saying that it should be trivial to add that capability to it
<mdz> I'll talk to mvo about it when he returns
<Kamion> well, I'm about to make base-config use apt-cdrom -o Acquire::gpgv::Options::=--ignore-time-conflict (I had to do it for apt-get anyway, for the netboot case)
<Kamion> so I'll be reassigning the bug to mvo in any case
<mdz> lamont: new cloop builds with latest xorg, please
<mdz> Kamion: I'm surprised it doesn't work, to be honest
<fabbione> night everybody
<ogra> ciao fabbione 
<dholbach> bye fabbione 
<Kamion> mdz: it's clear from the code that it doesn't
<lamont> mdz: starting
<lamont> ubuntu, kubuntu started , x3
* ogra reboots to the new strawberrys
<lamont> seb128: you still around?
<seb128> yep
<thom> aargh, firefox i hate you
<lamont> mdz: ready for a screwball regression in the hoary livecd?
<lamont> vs warty
<lamont> s/regression/"regression"/
<lamont> warty live automounted any NTFS partitions from hard drives (read only, since the kernel doesn't support RW).  hoary live does not.
<ogra> still no 1280x800@60 Hz in the monitor selection with nvidia for me :-/
<mdz> lamont: it is neither screwball nor a regression.  It's a Morphix feature that casper doesn't implement.
<mdz> it never has
<mdz> though it's planned for breezy
<lamont> right.
<sjmorgan> can i ask a question in here that's related to me attempting to get a bug fixed and could mean a problem with breakage in the main repository?
<mdz> sjmorgan: sure
<sjmorgan> ok cool, when i do apt-get build-dep gedit i get "E: Build-dependencies for gedit could not be satisfied."
<sjmorgan> and im not sure whether its a problem at my end or what
<thom> sjmorgan: works fine for me
<sjmorgan> hrmm interesting
<sjmorgan> it worked for me as well but i just --purge'd a load of -dev packages and was expecting it to pull int just what i needed
<dholbach> lamont: according to apt-file: dirmngr, eb-doc, findutils, libmpfr-dev, speech-dispatcher contain usr/share/info.*gz - did you tackle the other ones?
<sjmorgan> int/in
<dholbach> lamont: erm... usr/share/info/dir*.gz
<sjmorgan> there doesn't seem to be an apt-get verbose style option
<dholbach> lamont: i was supposed to take care of eb-doc and speech-disaster
<Kamion> meh, stupid bugzilla
<sjmorgan> it would really help if it actually told me what it isn't able to satisfy
<Kamion> it won't let me clear the "QA Contact" field
<mdz> sjmorgan: that typically means that you have some wacky stuff in sources.list / apt.conf / apt/preferences
<Kamion> but "Reassign bug to owner and QA contact of selected component" works
<lamont> mdz: my brother suggests a FAQ entry for hoary-live-using Windoze admins who want to mount their users filesystems...
<sjmorgan> hrmm well the only thing i've changed since i installed this machine is sources.list
<sjmorgan> so i'll try uncommenting unofficial repositories
<mdz> lamont: I'd rather just implement the feature
<lamont> mdz: I meant for hoary
<sjmorgan> urgh, still gives an error
<ogra> sjmorgan, did you sudo apt-get update ?
<sjmorgan> jah
<dholbach> lamont: i can do dirmngr as well (it's in universe)
<mdz> sjmorgan: having unofficial repositories in sources.list can easily cause that sort of thing
<sjmorgan> i uncommented all of them and it still doesn't work :/
<mdz> sjmorgan: apt-get -o Debug::BuildDeps=true might be enlightening
<mdz> sjmorgan: you want to _comment_ them, not _uncomment_ them
<sjmorgan> sorry i meant commented
<mdz> having packages installed on your system from unofficial repositories can do that as well
<sjmorgan> or ununcommented :)
<sjmorgan> ok that helps
<sjmorgan> there's at least one -dev package with broken dependencies
<sjmorgan> The following packages have unmet dependencies:
<sjmorgan>   libgtksourceview-dev: Depends: libgnomeprintui2.2-dev (>= 2.7) but it is not going to be installed
<sjmorgan>                         Depends: libgtk2.0-dev (>= 2.4) but it is not going to be installed
<sjmorgan> E: Broken packages
<sjmorgan> or rather broken in my case
<mdz> not unless it appeared in the past 2 hours
<mdz> there are zero broken dependencies in hoary at the moment
<mdz> (hoary/main, that is)
<Kamion> (we have automatic checks for these things)
<sjmorgan> yeah i didn't think there would be
* dholbach nods sighing deeply towards mdz
<Kamion> sjmorgan: have you tried 'apt-get -f install'?
<Kamion> also, apt-get isn't very good at displaying what the underlying error really is
<sjmorgan> doesn't seem to help
<mdz> dholbach: only 132 in hoary/universe
<sjmorgan> i tried -f build-dep as well
<mdz> dholbach: from a visual scan, they seem to be mostly Debian kernel stuff which should be removed
<Kamion> faced with that message, I would try 'apt-get install libgnomeprintui2.2-dev' and 'apt-get install libgtk2.0-dev', and iterate until it told me what the real problem was
<lamont> dholbach: the only ones I saw as of 0733 this AM (london) were the ones I told you.  If there are others, they should be fixed too
<dholbach> mdz: yes... i'll take care of that, but i hoped we were in EVEN better shape :-)
<seb128> bbl dinner
<mdz> sjmorgan: this can easily be caused by having packages on hold, or anything else which inhibits the normal behaviour of the problem resolver
<dholbach> lamont: i'll update apt-file, just a sec
<sjmorgan> ahh i know what the problem is
<mdz> dholbach: I think you're in great shape
<sjmorgan> you're right, it was a package i installed from an unofficial repository
<sjmorgan> fontconfig
<sjmorgan> libfontconfig
<dholbach> mdz: maybe i'm looking to closely :-)
* mdz bows rigidly
<sjmorgan> now, how to fix it without breaking stuff :S
<dholbach> :-)
<pitti> dholbach: you can't be picky enough :-)
<sjmorgan> is there a way to overwrite it with the older version?
<sjmorgan> dpkg -fi maybe
<mdz> sjmorgan: this is now officially off-topic ;-)
<sjmorgan> --force-* rather
<sjmorgan> :-(
<dholbach> sjmorgan: /etc/apt/preferences and pinning will maybe help you there
<sjmorgan> ok cool
<sjmorgan> i'll see what i can do
<mdz> dholbach: nooooo
<sjmorgan> thanks for your help guys
<dholbach> mdz: no?
<Kamion> apt-get can downgrade or sync to a particular target release without the need for such complicated and easily-broken mechanisms as pinning
<mdz> /etc/apt/preferences is like using explosives to open a jar
<mdz> there are situations where it's the only way, but should otherwise be avoided at all costs ;-)
<dholbach>  /me pipes innocently
<sjmorgan> sudo apt-get install libfontconfig1=2.2.3-4ubuntu7 looks like the trick
<dholbach> lamont: findutils and libmpfr-dev are in main, they should be taken care of - i'll do dirmngr
<lamont> dholbach: what are you looking at to decide on those packages?
<lamont> sounds like you're looking at the march 28 contents files, which haven't been updated yet....
<lamont> (fetch the binaries and you'll probably find that the files aren't there anymore...)
<dholbach> lamont: grmbl - i'll look through the buildlogs
<lamont> oh. My bad - those files are from _January_ 28th
<dholbach> lamont: there is no cronjob updating those?
<mdz> elmo,dholbach: removing kernel-latest-2.4-i386 should resolve a bunch of unmet deps in universe; they're just Debian metapackages depending on kernels we don't have
* thom wonders idly how firefox has set its homepage to a url that isn't referenced anywhere in the source package
<dholbach> mdz,elmo: i talked to the kernel guys - they said they only wanted to have the newest debian kernels in - everything else should be purged - i'll have a look at the reverse depends, before making the morgue list and the sync list
<lamont> thom: neato
<Treenaks> thom: sed + awk magicks
<dholbach> mdz,elmo: latest 2.4 and 2.6 for our supported archs to be exact
<dholbach> lamont: is anything speaking against generating a Contents file in regular intervals?
<Kamion> dholbach: it takes longer than cron.daily's allotted time - elmo said he was working on decoupling that
<dholbach> Kamion: oh i see
* dholbach has to learn more about the internals
* dholbach should maybe note them on the wiki at some stage :-)
<thom> mdz: you'll love this
<thom> mdz: the firefox homepage is localizable. every single mozilla-firefox-locale-foo package needs to be fixed
<pitti> yay
<jdub> thom: good lord...
<pitti> fortunately most of them come from a single source package
<pitti> so it shouldn't be as hard as it sounds at first
<thom> pitti: cool
<thom> pitti: i'm grabbing locale-all now to make sure i'm right
<pitti> thom: IIRC the debs from -all don't even ship homepages
<dholbach> lamont: you were right - we're all set
<pitti> thom: although, the home pages could be in the xpi
<thom> pitti: -en-gb did
<thom> it's in the xpi
<pitti> crap
<pitti> that means all xpi files have to be changed
<pitti> ?
<thom> yup
<herve> hi, the motu needs an autoconf/gtk/gnome magician to fix gcompris
<pitti> and they aren't diffable, thus another orig.tar.gz, yay
<mdz> thom: AWESOME
<blahrus> hey, I think I have found a bit of a bug in ubuntu amd64
<blahrus> I am unable to get and sound card to work.
<ogra> mvo, ping.de thinks my mailserver is a dialup *g*
<thom> mdz: i, um, knew you'd be thrilled
<dholbach> ogra: he's still at sports, i think
<blahrus> the audio test in ubuntu device databse plays the sound, nothing comes out, vol is up and not muted
<ogra> dholbach, gah...
<pitti> blahrus: all relevant audio channels are up? the gnome mixer might not display all
<pitti> blahrus: "pidof esd" shows a number?
<blahrus> let me check
<blahrus> pitti: no number
<pitti> blahrus: then esd has died for you
<blahrus> hum . . .. 
<pitti> blahrus: try to start "esd" from a shell
<blahrus> pitti: how do is start it
<blahrus> ahh nm :)
<pitti> blahrus: just "esd"
<blahrus> pid.c: daemo already ruinning
<pitti> blahrus: if it exits immediately with an error, we are interested in seing the error
<pitti> uh
<astharot> aff
<astharot> pitti: if you answered to my message I didn't read :P
<pitti> blahrus: but still pidof esd doesn't show anything? odd
<pitti> blahrus: "ps aux | grep esd"
<lamont> mdz: ubuntu all done
<lamont> mdz: kubunt done on i386, ppc, compressing on amd64
<blahrus> pitti: just returns a blank line
<pitti> astharot: I said that I never write uploaded names into USNs
<astharot> ok
<pitti> blahrus: rm -r /tmp/.esd
<pitti> blahrus: then "esd" again
<astharot> pitti: btw, I was just kidding!
<blahrus> pid.c: daemo already ruinning
<pitti> blahrus: ls -lda /tmp/.esd*
<pitti> blahrus: btw, does it really print "ruinning"
<pitti> :-)
<pitti> blahrus: it's ruining your nerves, I suppose
<blahrus> pitti: I removed that whole dir . . . . 
<blahrus> pitti: yea my nerves are at end with this.
<pitti> blahrus: it should be recreated on startup
<lamont> back in a few
<pitti> blahrus: in fact it's existence is probably the cause that it doesn't start again
<blahrus> pitti: well the dir is gone, and esd wont start
<blahrus> tired a killall, and it says no process
<pitti> blahrus: do you have another user logged in atm?
<blahrus> nope
<blahrus> fresh boot
<blahrus> just kinda freaked out when I opened the mixer
<Kamion> yay, not offline for the evening after all
<pitti> blahrus: sudo rm -r /tmp/.esd*     -> big hammer :-)
<blahrus> k
<blahrus> no such file or dir
<pitti> blahrus: try rm ~/.esd_auth
<pitti> blahrus: for me, esd startup is slightly more verbose ("/tmp/.esd/socket
<pitti> This socket already exists indicating esd is already running.
<pitti> "
<pitti> )
<blahrus> alright that removed
<pitti> blahrus: it doesn't show you more than just "already running"?
<blahrus> start esd again?
<pitti> yeah
<blahrus> says it already running
<blahrus> would you like to log into the box?
<blahrus> just a spare box I was messing with
<pitti> blahrus: please /msg the complete output before
<blahrus> I love ubuntu on my laptop thought I would give it a try
<pitti> blahrus: I /msg you, it's a bit off-topic here
<blahrus> thanks :)
<thully> hi - I just noticed an issue with Hoary RC - I clicked on an "About Ubuntu" link somewhere (forget where, it wasn't on the System menu) and got redirected to file:///usr/share/ubuntu-artwork/home/index.html
<thully> which says "The Warty Warthog Release"
<jdub> thully: that'll be fixed in the next u-a update
<thully> OK
<mdz> thom: at least they're all in one source package now, right?
<mdz> lamont: wow, amd64 was last?
<thom> mdz: yeah
<Kamion> mdz: new install CDs done; they don't contain the last few uploads I did though (base-installer, base-config)
<thom> i'm mangling some perl together
<Kamion> but they should have everything else
<mdz> Kamion: I was about to fire off live builds, or are you going to do it?
<Kamion> mdz: I'll do it now
<mdz> Kamion: ok, both ubuntu and kubuntu please
<Kamion> are the new rootfses ready?
<mdz> lamont said the last one was compressing 30 minutes ago
<mdz> so I assume so
<Kamion> Ubuntu started
<dholbach> ha... have already 2 requests from (female) friends that want the april-1st-gdm-login-screen again :-))))
<zyga> dholbach: ask them for a female picture in return and compose another login screen ;] 
<lamont> kubuntu,ubuntu done x3 a while ago
* lamont is back
<mdz> Kamion: I'm doing amd64 and powerpc warty->hoary upgrade tests now (including the xorg-driver-synaptics upload I just did)
<Kamion> Ubuntu daily live done, Kubuntu daily live building
<mdz> /usr/share/gnome/help/stickynotes_applet/uk/stickynotes_applet.xml:204: element figure: validity error : ID stickynotes-using-left-fig already defined
<mdz> scrollkeeper complained about that during upgrade; not sure if it's an issue for new installs
<mdz> we really should just throw that output away; it's logged anyway
<seb128> mdz: I'll fix it
<mdz> seb128: thanks
<thom> meh: perl -pi -e 's#(homePageDefault=).*#$1file:///usr/share/ubuntu-artwork/home/index.html#;s#(browser.startup.homepage=).*#$1file:///usr/share/ubuntu-artwork/home/index.html#;s#(browser.throbber.url=).*#$1file:///usr/share/ubuntu-artwork/home/index.html#' browser-region/region.properties
<Lain82> Hello, I want to know if a graphical configurator tool exist on Ubuntu ( sorry for my bad english ...)
<kent> Lain82, well, this is a #ubuntu question.
<Lain82> ok ! sorry, I ask it here because I want to know if a project exist ...
<mdz> Kamion: new isos are crawling down (hoary-live-amd64 took 16:45)
<mdz> I'll do a full test cycle when they arrive
<thom> pitti: so, we don't have to reupload a new orig; *but* we uncondtionally change the homepage everytime for all the language packs
<thom> is that a bad thing?
<pitti> thom: change to a localized Ubuntu home page, or to the English one?
<thom> well, we don't have localized home pages yet, do we?
<pitti> we might have in the future
<thom> sure
<thom> at that point, we can do something fancier
<pitti> for hoary, it's certainly fine
<pitti> to hardcode the english one
<thom> pitti: i'll send you the diff for debian/rules in a second
<Kamion> mdz: ok, I probably won't be able to do any testing until tomorrow now
<Kamion> mdz: Kubuntu daily install building for good measure
<Kamion> god, that ntfsresize/udev interaction bug is creepy
<Kamion>   263 publish-release
* Kamion muses on how to split that up sanely
<Kamion> Kubuntu daily install done
<blahrus_> mdz, I tested all mixer levels
<mdz> blahrus_: please follow up to bugzilla
<blahrus_> done :)
<mdz> Kamion, elmo: cdimage rsync is not up to date; it's showing me 20050329 for /current/
<mdz> ]  rsync -aP --exclude '*ia64*' --exclude source rsync://cdimage.ubuntu.com/cdimage/daily/current/ | grep 'iso$'
<mdz> -rw-rw-r--   646940672 2005/03/29 17:49:05 hoary-install-amd64.iso
<mdz> -rw-rw-r--   626288640 2005/03/29 17:59:34 hoary-install-i386.iso
<mdz> -rw-rw-r--   659660800 2005/03/29 18:30:15 hoary-install-powerpc.iso
<thom> mdz: i'm just about to upload mozilla-ffox-locales-all fyi
<mdz> thom: sounds harmless enough
<Kamion> mdz: WFM
<mdz> maybe it's only one of the mirrors in the rotation?
<mdz> yep
<mdz> if I try a few times, I see both a 2005-03-29 set and a 2005-04-05 set
<Kamion> yeah, 82.211.81.176 is out of date
<thom> mdz: nod; firefox is uploaded also and that should be all the fixes we need to get locales nailed
* Kamion curses bloody stupid lack of rDNS
<mdz> 82.211.81.176 is the out-of-date one
<Kamion> thom: what machine is 82.211.81.176?
<mdz> that probably explains why my rsync took so long; my isos may have been a week old
<Kamion> it is not any of the ones I'm currently triggering
<elmo> Kamion: mcmurdo.ubuntu.com
<Kamion> elmo: do I need to start triggering it?
<elmo> please
<elmo> I thought I'd asked you, sorry
<Kamion> elmo: ok, done - FWIW the current list is syncproxy, mirnyy, frei, durville, mcmurdo, orcadas
<mdz> stopping my rsync, since it's apparently overwriting half my isos with old ones
<Kamion> well, done when baz finishes
<elmo> Kamion: that matches /etc/rsyncd.conf on little, so should be good
<mdz> Kamion: you're also triggering an update, right?
<Kamion> elmo: bash: /home/archvsync/cdimagesync: No such file or directory
<mdz> or trying to
<elmo> details
<elmo> fixed, syncing
<Kamion> yup, seems ok
<Kamion> (er, yeah, assuming two concurrent syncs won't break shit ...)
<elmo> no, it's got locking
* lamont grumbles at l-r-m, makes a note to suggest that the firmware blobs be broken out into their own packages that l-r-m (Build-?)Depend on for breezy
<elmo> eh, why?
<lamont> because I hate 48MB downloads
<lamont> esp since l-r-m really only tends to change abi-versions, and not much else, it seems
<elmo> why is the source so insanely large?
<lamont> binary blobs of firmware for all the various binary-blob drivers, I believe
<lamont> or maybe not firmware
<lamont> maybe binary driver
<thom> binary drivers
<lamont> thom: yeah - forgot for a second that the firmware is in main
<Kamion> thom: I trust the random capitalisation in "ubuNtu-artwork" in your m-f-locale-all changelog was a typo? :)
<thom> Kamion: yeah
<thom> :-)
<pitti> thom: your own derivative of ubuntu? :-)
<Kamion> or, rather, a typo confined to the changelog ... :)
<thom> Kamion: indeed; tired eyes. the code itself is a-ok
<thom> pitti: *g*
<elmo> new archive.u.c in the mix, pls shout if anyone sees any problems
<mvo> seb128: any news from the frensh translation? was it reviewed again or should I upload what I have now?
<seb128> mvo: lemme check
<seb128> hum, is there an issue with the debian mails ?
<elmo> if your mail goes through gluck, yes.  if not, not that I'm aware of
<seb128> I don't know how the @debian.org are handled by the debian machines
<seb128> but it was working fine this afternoon, so I guess that's not due to gluck
<seb128> mvo: there is a diff for the po here: http://lists.debian.org/debian-l10n-french/2005/04/msg00190.html
* pitti does not see his debbugs replies either
<seb128> mvo: do you want me to merge it ?
<seb128> 
<doko> jbailey: ping
<mvo> seb128: if it applies cleanly I can merge it 
<mvo> seb128: does it look sane? my frensh is a bit "rusty" ;)
<mdz> Apr  5 21:58:37 kernel: EXT2-fs warning: mounting fs with errors, running e2fsck is recommended
<mdz> Apr  5 21:58:38 casper: Scanning for swap devices...
<mdz> Apr  5 21:58:38 casper: Found /dev/hda4
<mdz> Apr  5 21:58:38 casper: Using swap devices:  /dev/hda4
<mdz> Apr  5 21:58:38 kernel: attempt to access beyond end of device
<mdz> Apr  5 21:58:38 kernel: dm-1: rw=0, want=3932232, limit=3270656
<mdz> Apr  5 21:58:38 kernel: EXT2-fs error (device dm-1): ext2_get_inode: unable to read inode block - inode=246022, block=1966115
<seb128> don't relay on mail to join me so, I use my debian alias which seems to have issues
<mdz> lamont: ^^ hoary-live-powerpc
<Kamion> unfortunately all my @debian.org mail goes through gluck
<mdz> lamont: could be a media problem, but please check the cloop output
<seb128> mvo: yep, looks fine
<jbailey> doko: here!
<Kamion> hmm, klecker still seems to be set up to do bsmtp ...
<elmo> kamion: I wouldn't try it
<pitti> night, guys
<elmo> unless you have an account there
<elmo> gluck should be back soonish
* lamont looks
<Kamion> elmo: I do, as it happens, although it, er, could be argued to be an abuse I guess
#ubuntu-devel 2005-04-17
<elmo> I didn't mean abuse, I more meant exim rejecting all the mail as -ENOUSER
<elmo> but I guess you have an account through qa
<Kamion> qa's merkel now - maybe through rm, don't remember
<lamont> Setting up gnome-panel-data (2.10.1-0ubuntu1) ...
<lamont>  /usr/sbin/laptop-detect: line 6: test: : integer expression expected
<lamont> desktop configuration
<lamont> Resolved address "xml::/etc/gconf/gconf.xml.defaults" to a writable configuration source at position 0
<lamont> well, that looks cute
<Kamion> anyway, echan :)
<lamont> but it's not as fatal as the I/O errors
<Kamion> lamont: bah, I thought that laptop-detect thing got fixed ages ago
<thom> i don't remember anyone reporting it as a bug?
<thom> (and i don't remember seeing it)
<mvo> seb128: patch does not apply cleanly at all (22 of 26 HUNKS failed) :/
<lamont> rsync: readlink "/build/livecd.mnt/lib" failed: Input/output error (5)
<seb128> mvo: probably encoding issue
<lamont> rsync: readlink "/build/livecd.mnt/media" failed: Input/output error (5)
<lamont> that's my favorite part..
<seb128> mvo: just commit the first po, we have the language-pack for updates
<elmo> lamont: what host is this?
<mvo> seb128: ok
<lamont> royal
<lamont> ~buildd/public_html/livecd/ubuntu/current/*.out
<elmo> meh
<elmo> did you move the live stuff?
<mdz> lamont: can you losetup && e2fsck the final image?
<lamont> no
<lamont> well, when adare died.
<mdz> oh, never mind, you saw i/o errors already
<elmo> lamont: check oh dmesg
<elmo> s/oh/out/
<lamont> wah wah
<lamont> >2GB, I expect.
* lamont checks
<mdz> lamont: how exactly did that build manage to exit successfully after that?
<lamont> du -s chroot-livecd/
<lamont> 1591916 chroot-livecd/
<lamont> set +e in a function doesn't affect the caller does it?
<elmo> no
<mdz> lamont: file a bug for thom about the laptop-detect thing
<lamont> mdz: problem with the livecd identified, rolling a good one now.
<mdz> thanks, ping me or Kamion when it's done to roll new isos
<thom> lamont: can you include  /proc/pmi/info from the chroot, please
<lamont> -rw-r--r--  1 buildd root   2146500608 Apr  2 06:46 public_html/livecd/ubuntu/20050402/livecd.ubuntu-20050402-powerpc.fsimg-1024
<lamont> -rw-r--r--  1 buildd root   1674555392 Apr  3 06:37 public_html/livecd/ubuntu/20050403/livecd.ubuntu-20050403-powerpc.fsimg-1024
<lamont> what's wrong with that picture?
<thom> (in the laptop-detect bug)
<lamont> thom: is a chroot on royal, but sure
<Kamion> er, 'set -e' or 'set +e' in a function does affect the caller
* lamont runs e2fsck on the image just because
<lamont> Kamion: yeah.. I gather that now...
<lamont> grumble
<Kamion> $ sh -c 'foo () { set -e; }; foo; false; echo hello'
<Kamion> $ 
* lamont fixors the script
<Kamion> mdz: the other cdimage.u.c seems up to date now
<lamont> amusingly, the kubuntu livecd should be fine
<lamont> ppc ubuntu live building now
<mdz> Kamion: thanks; I've been syncing from the good one meanwhile
<elmo> Kamion: it's still syncing
<Kamion> oh, /daily/ is there anyway
<elmo> yah, it's in kubuntu
<elmo> do we really need ubuntu and kubuntu source ISOs?
<elmo> shouldn't they be fairly identical?
<Kamion> yeah, I should probably turn off Kubuntu source ISOs
<elmo> hmm, I suppose not, if you're only including source for what's on the CD
<Kamion> uh
<elmo> or is that source for everything?
<Kamion> mm, no, just source for what's on the CD
<Kamion> why exactly it's now *four* source ISOs I don't know
<lamont> so, uh, livecd script updated on all 4 architectures
<lamont> elmo: I want 500GB drives on all the livecd-fsbuild hosts. :-(
<lamont> yeah, that's want, not need. :-(
<HiddenWolf> lamont, x86 / a64 / ppc and ia64? itanium won't be official, right?
<lamont> HiddenWolf: ia64 has machines in the data center, and it's one of those cut/paste things...
<lamont> ia64 won't have official images for hoary
<HiddenWolf> lamont, cool
<lamont> HiddenWolf: neither will sparc or hppa
<HiddenWolf> lamont, no offence, but why offer ubuntu on the very limited and crowded ia64 arena?
<lamont> HiddenWolf: I don't set policy
<lamont> which is short for 'dunno'
* lamont has ideas, but they all involve vast amounts of supposition
<HiddenWolf> Hm, ok. Was just wondering wether there is a good reason for it.
<lamont> HiddenWolf: while there are build machines, the hoary/ia64 is not sponsored by Canonical.
<doko> hmm, DistroWatch doesn't list Ubuntu/Kubuntu as having asian language support. is this really true?
<HiddenWolf> doko, it should have
<doko> jdub: you seem to have the best DistroWatch contacts ^^^
<Kamion> doko: depends on the Asian language; not all have installer support
<HiddenWolf> lamont, out of sheer curiousity, is there any info online about the server setup?
<dholbach> yes: Ubuntu Linux - the new number one distribution on DistroWatch :-)
<lamont> wiki.ubuntu.com/DeveloperResources??
<HiddenWolf> dholbach: has been so for two days. slowpoke. 
<dholbach> i was citing :-)
<lamont> HiddenWolf: which says nothing about your question
<HiddenWolf> lamont, nm then. Don't want to get spanked for going OT *again*
* HiddenWolf hides
<lamont> HiddenWolf: basic answer about the buildd machines: really fat beefy {P4,amd64,G5} machines with plenty of memory, etc, x3.  and x3 minimum-price-point HP ia64 machines.
<HiddenWolf> lamont, thanks.
<HiddenWolf> Night people
<lamont> dholbach: http://distrowatch.com/stats.php?section=popularity
* lamont wonders when Ubuntu will be 2x mandrake on the 1-month column
<Burgundavia> next week
<Burgundavia> after the release
<dholbach> :-))))
<dholbach> ok pals, i'm off to bed - good night
<ogra> night dholbach 
<mdke> night
* thom goes the hell to bed
<lamont> hrm.. first clue should have been that ppc beat amd64.  must remember that
<dilinger> that reminds me, i should order some cds
<mdz> amd64 install good, amd64 live good, powerpc live b0rken, powerpc install pending
<zyga> wow, ubuntu is quite popular :>
<mdke> you betcha
* mvo needs sleep
<Kamion> mdz: what's up with powerpc live?
<mdz> Kamion: cloop was borked, lamont said he was building a new one
<mdz> powerpc install is in progress, waiting for kubuntu to finish downloading and I'll test ubuntu/i386
<mdz> and by then I assume the new powerpc cloop will be ready
<lamont> should be done sometime soonish
<lamont> feh - still installing
* zyga says goodnight
* Kamion clears out his cdimage task list
<mdz> yay for non-blurry update-notifier icon
<mdz> live-i386 is good
<lamont> ppc cloop is rsyncing into the image
<lamont> how much of 2.10.1 is left?
<mdz> we've got all the 2.10.1 we're going to accept
<lamont> woot
<seb128> mdz: uploads frozen tomorrow ?
<mdz> seb128: no more uploads without approval starting tomorrow
<seb128> k
<lamont> compressing
* Kamion ponders three more translation uploads
<Kamion> only one language, though ...
<mdz> powerpc install is good
<lamont> [ 9]  Block# 32753 size      0 ->     84 [compression ratio 100%, overall:  27%] 
<lamont> ppc livecd cloop is good
<lamont> well, done in any case
<lamont> and the right size, etc.
<mdz> I'll start CD builds
<mdz> thom: ping?
<mdz> thom: firefox is still showing the Warty page
<mdke> is there a channel for launchpad?
<Kamion> #launchpad
<mdke> doh
<mdke> thanks Kaloz 
<mdke> thanks Kamion 
<CarlK_> I did a server install, then apt-get install xchat - it installed 64meg of stuff, including xorg-common, but X wasn't one of them.  Is this normal?
<lamont> mdz: is there anything else that we know is going in?  or are we down to the final testing rush?
<mdz> lamont: doko has an oo.o upload going in shortly
* lamont giggles.
<aigarius> I am preparing to burn several hundreds of Ubuntu 5.04 install cd's to give away at a conference in 10 hours. Because of schedule slip, i understand that i will not be able to burn release cd - only rc install cds. Are there any critical bugs in theses CD that I should know about?
<mdz> tomorrow we'll do a build which should be damn close to final
<lamont> that's all of the huge packages the4n
<mdz> aigarius: just please don't label them "ubuntu 5.04" because they aren't
<lamont> aigarius: if you burn them before release, please be sure and label them as pre-release
<mdz> CarlK_: yes
<aigarius> sure, i will. and we will instruct people to update after installing. anything else?
<mdz> aigarius: the release candidate is quite solid
<lamont> Kamion: just oh btw, repartitioned the G3 so that /boot is early on.  boots just fine now, thank you
<CarlK_> mdz - ok, no bugzilla then
<lamont> Kamion: so sounds like some erratta for the CD, maybe.
<mkedwards> aigarius: regression in NVidia graphics chip detection relative to array-7, at least on livecd
<mkedwards> (appears to guess ATI instead of NV)
<mdz> lamont: errata like "we don't support G3 machines"? ;-)
<mdz> mkedwards: worked fine here
<lamont> mdz: no.  erratta like the 'use the whole damn disk' doesn't work on certain archaic G3 machines, you must manually partition things and put /boot in the first 2GB
<mdz> I would be very surprised if the pristine RC live CD did anything like that
<lamont> LOGIN SCREEN!!!
<mdz> lamont: I know; they have other problems, though, and I'm happy to not declare official support for them
<mkedwards> mdz: quite pristine.  Go700 chipset.  Trying to narrow it down now.
<Kamion> mdz: plenty of G3 machines are newworld and ought to be supported
<aigarius> we will only use ubuntu install cds. we have our own live cds made from scratch. I think that i will get its main developer to debconf to share some of his revelations. their live cd boot faster then my pristine debian system :(
<lamont> mdz: it was the newest iMac that the surplus store had, though... :-)
<mdz> aigarius: which live CD?
<Kamion> mdz: don't make the same mistake that the front page of our web site does in confusing G3 with oldworld :P
<aigarius> it is not in public circulation yet
<aigarius> called 'Cute'
<mdz> any machine which doesn't do LBA properly is archaic in my book
<Kamion> lamont: I have no idea where errata ought to go yet ...
<lamont> mdz: wondering what other problems G3s-of-color have....
<mdz> lamont: haven't you been trying to get that one installed for about a week now?
<lamont> mdz: yes and no.
<lamont> first tried it with hoary about a week ago.
<lamont> well, month ago.
<lamont> CD drive is NFG - read errors
<mkedwards> mdz: what log should I look at to try to understand why it guessed Radeon 7000 for my Go700?
<lamont> so last week was (1) figure out netboot (having installed a ppc machine maybe 3 times, all with warty), and (2) curse that it didn't make second-stage boot
<lamont> today was the next chance I had to really look at it since last weekk
<mdz> mkedwards: sudo discover --disable=serial,parallel,usb,ide,scsi  --format="%V %M\t%S\t%D\n" video
<lamont> the fact that it boots just fine from the netboot, but not from disk, finally led me to notice that / was 14GB (not the stock hard drive, which would be < 2GB anyway...), then manually repartition and install.
<lamont> mucho happier.
<Kamion> it's basically just the same problem that old BIOSes have, we haven't withdrawn support for older i386 systems just because of that
<lamont> yep[
<seb128> mdz: the default handler for rtf files should be oowriter, not abiword, right ?
<mdz> we don't make things work properly on them by default either
<mdz> seb128: since oowriter is installed by default, and abiword is not, I would say yes
<seb128> k, just wanted to be before changing it, thanks :)
<mdz> Kamion: certainly anyone in that situation is on their own as far as making their install work
<lamont> mdz: right.
<Kamion> mdz: sure; though I'd still consider it a bug even if not a high-priority one, and would accept patches to make it work better
<lamont> which really means the errata item needs to say 'if your bios doesn't support reads > 2GB, you'll need to deal with that (duh).  kthxbye'
<mdz> Kamion: sure, we accept patches for hppa too; that doesn't make it a viable platform ;-)
<Kamion> whereas I don't consider "doesn't support PReP" or whatever to be a bug
<lamont> mdz: hey! :-)
<mdz> I'll be re-testing the new powerpc live CD shortly
<mkedwards> mdz: OK, brb
<mdz> everything else looks good
<Kamion> mdz: so, uh, you tell me where the cutoff point for proper LBA support on powermacs is, eh? 'cos I bet it doesn't align precisely with G3 -> G4 :-)
<mdz> Kamion: it sounds like it's probably not even an issue, since they come with tiny disks from the factory
<aigarius> is there somewhere a list of bugs that are fixed/to be fixed after the RC was made?
<mdz> no
<mdz> unless "you could read bugzilla" is a reasonable answer ;-)
<aigarius> 'you could read svn log' would be a better one ;)
<Kamion> mdz: yeah, I don't think it's a huge deal; ultimately the right answer is probably a partman finish.d script that complains about the situation, assuming that anyone ever figures out how to detect the relevant machines from software
* lamont will need to head to fire meeting in about 20 minutes or so
<Kamion> aigarius: in the meantime, try the hoary-changes mailing list archives
<aigarius> Kamion: thank
<aigarius> s
<aigarius> :)
<lamont> Kamion: yaboot, for example, could notice that the offset is unreasonable, warn about it, and then try to launch the kernel...  That doesn't fix it, and means you have to reinstall, but it's a start
<mdz> a hypothetical svn log for the entire distribution would be more data than bugzilla, I imagine
<Kamion> lamont: it's better if it goes earlier, so that you can fix it at the partitioning stage rather than having to wait for the whole first stage install to finish before you get told about the problem
<mdz> lamont: does your G3 boot the hoary live CD?
<lamont> oh, definitely
<lamont> mdz: that would kind of want a reliable CD, no?
<mdz> lamont: oh, you didn't fix that problem?
<Kamion> we must put together a casper netboot option at some point :)
<lamont> mdz: no.  I netbooted the installer
<mdz> Kamion: don't laugh; I'm seriously considering implementing thin clients that way
<lamont> MemTotal:        61812 kB
<lamont> and I don't think livecd would be a wise plan...
<Kamion> mdz: oh, that wasn't really intended as a laugh ...
<Kamion> I think it would be really useful to have
<mdz> lamont: that's what swap is for!
<Kamion> but I assume it'd need nbd or something to be sane
<mdz> Kamion: casper + nbd would be a nice alternative to NFS + tmpfs
<lamont> mdz: I did attempt a livecd boot.  After 90+ minutes, I gave up.  But the CD was logging lots of I/O errors/timeouts
<lamont> so it might actually work
<lamont> gimme a netboot casper, and I'll go for it
<lamont> the other issue is that there is no local ppc mirror, and the bits I have are the RC cd.
<mdz> Kamion: I think we need to correct the bit in Mark's draft release announcement about the speed of the installer; with archive-copier I assume it's quite a lot slower than Debian's
<ogra> mdz, hwdb client will need to have another two uploads before release...one for small bugfixes and one if the help is completed
<tritium> today's xorg -10 update rewrote my xorg.conf, despite it being hand-customized, and reverted to "nv" driver.  My hotplug blacklist was also blown away, as I normally blacklist intel_agp in order to use NvAgp
<Kamion> mdz: fewer questions do speed stuff up, and I think it might be faster than a standard Debian desktop installation because the latter installs both GNOME and KDE
<Kamion> but yes, it's true that archive-copier slows things down
<Kamion> where's the draft release announcement
<Kamion> ?
<Kamion> nm, found it
<Kamion> mdz: I'll see if I can do timings tomorrow maybe
<mkedwards> mdz: discover got it more or less right.  But xorg.conf got Radeon 7000 VE.  Editing it (and adding an appropriate VSync/HSync range and resolution) gets me 1920x1200.
<mkedwards> mdz: the odd thing is that it didn't even get the PCI ID right.  0:5:0 vs. 1:0:0.
<Kamion> mdz: the debdiff from dosfstools 2.11-1 -> 2.11-2 looks entirely sensible and minimal; should we sync?
<mkedwards> mdz: NVIDIA Corporation NV31GLM? [Quadro FX 700 Go]        XFree86 nv
<daniels> mkedwards: do you have a 7000 VE in your machine?
<mkedwards> daniels: nope, no ATI anything.  Dell Precision M60 laptop.
<daniels> are you using the live CD?
<mkedwards> yep.
* daniels frowns deeply.
<mkedwards> regression relative to array-7.
<daniels> yrsh
<daniels> yeah, even
<mkedwards> (which got the nv right, but gave me 1600x1200)
* lamont grumbles that the ppc install (RC) doesn't have everything required to debootstrap --variant=buildd
<Kamion> lamont: what's missing?
<lamont> who added pkgstriptranslations to hoary.buildd, anyway, I wonder
<daniels> mdz: ping
<Kamion> heh
<lamont> esp given that installing it and enabling it gives bad results
<Kamion> I think you told me to
<lamont> wouldn't surprise me
<Kamion> I generally don't touch *.buildd without explicit request
<lamont> stupid buildmaster
<Kamion> anyhow ... bedtime
<lamont> g'night
* lamont drops a chroot on his ppc box
<mkedwards> I love the fact that I don't need ModeLines in xorg.conf.
<lamont> (which required finding debootstrap and dupload, but hey...)
<lamont> building debootstrap, libertating duplaod.
<lamont> oops.  time to run to fire meeting.
<lamont> back in a few hours
<lamont> mdz: cell should work reasonably
<mkedwards> daniels: ddcprobe doesn't seem to be picking up resolutions above 1280x1024
<Kamion> oh yeah, my mobile's also on in case of emergency, though it may be running out of battery soon
<daniels> mkedwards: hm?
<mkedwards> daniels: outputs oem, vendor, product, memory, list of modes, then "edidfail"
<daniels> that's not it liking modes above 1280x1024, that's either your card or your monitor telling us it can't to ddc
<daniels> s/to/do/
<mkedwards> daniels: (I'm now on to trying to figure out how to autodiscover 1920x1200)
<daniels> ddcprobe's code hasn't changed at all in weeks, substantially in months
<daniels> it'll autodiscover 1920x1200 if your card likes us
<mkedwards> daniels: array-7 found 1600x1200, at least.  xorg seems to be able to find a 1920x1200 mode when told to in xorg.conf.
<daniels> right
<mkedwards> daniels: hmph.  There isn't even a PCI 0:5:0.  How'd that get written into xorg.conf?
<daniels> if it's saying edidfail, it's out of our hands; the xorg.conf thing is my fault (wrong bus id/wrong driver), but edidfail is not
<daniels> don't ask
<mkedwards> DDC detected a DFP:  ....  EDID Version: 1.3
<mkedwards> (**) NV(0): *Default mode "1920x1200": 193.2 MHz, 74.5 kHz, 60.0 Hz
<mkedwards> Looks like a completely happy Xorg.0.log.
<mkedwards> daniels: do you use ddcprobe or something like it to generate resolutions for xorg.conf?
<mkedwards> daniels: I note that a previous tester with an NV31 also had issues (Google "ddcprobe edidfail")
<CarlK_> daniels - are you still hosting the nvidia package, or is that now in daily-install or where?
<mkedwards> daniels: let me know if there's something I can do to help.
<mkedwards> daniels: I am even equipped to overlay a replacement package on the LiveCD and test.
<daniels> mkedwards: we use ddcprobe to build the list of resolutions, yeah.  the nv driver and ddcprobe use two different methods to probe (the former uses i2c channels on the card, the latter asks the bios very nicely), so the former succeeding and the latter failing are not unheard of.
<daniels> CarlK_: it's now in daily install, and in the archive
<daniels> mkedwards: i'm just building a replacement cd now to test the xorg.conf stuff
<mkedwards> daniels: OK, any chance it'll do 1920x1200?
<mdz> daniels: pong
<mkedwards> daniels: (that's the native resolution of the laptop LCD on the M60)
<mkedwards> daniels: it should be harmless to put in the list of resolutions, since xorg will exclude it anyway if it's inapplicable, right?
<mdz> daniels: the current daily live CD worked fine for me x3; no PCI ID regressions this time around
<mdz> daniels: I've no idea what happened in mkedwards case; the RC was known to be OK in that respect as well
<mkedwards> mdz: hand-editing xorg.conf got me the M60's native resolution.
<mkedwards> mdz: it's a reasonably popular business laptop.
<daniels> mkedwards: it should do 1920x1200 just fine
<daniels> mkedwards: could you please send me a /var/log/Xorg.0.log from that machine?
<daniels> (the laptop)
<mkedwards> mdz: by the way, whom do I contact about a support contract for our 3,500 worldwide sales staff?  :)
<daniels> if so, I can reproduce it locally
<mdz> mkedwards: support@canonical.com
<mkedwards> daniels: the successful one, I presume?  :)
<daniels> mkedwards: preferably, but it's not hugely important
<mkedwards> daniels: I don't think the one with the ati driver will do you much good.
<daniels> well, no
<mdz> mkedwards: take a look at the /etc/X11/xorg.conf inside the cloop image; see if it says 7000 VE and 0:5:0
<daniels> mdz: what I suspect is happening is that generating the new configuration is massively failing
<daniels> mdz: if I can get the log, I can use the XRESPROBE_RIG stuff to simulate that here and see if it's failing and why
<daniels> mkedwards: which cd were you using, exactly?
<mdz> he said earlier it was RC
<mkedwards> RC livecd i386
<mkedwards> daniels: sent
<daniels> ok, rc will probably fail like that
<daniels> could you please try a daily live?  it should be fixed there
<daniels> rsync -azurvP cdimage.ubuntu.com::cdimage/daily-live/current/hoary-live-i386.iso ./hoary-live-i386.iso
<mkedwards> mdz: yes, it's the one inside the cloop
<mdz> Kamion: if we can the new dosfstools tonight, yes, otherwise, I'd rather not
<mdz> daniels: why would RC fail like that?  what's interesting about his setup?
<daniels> mdz: nothing interesting, just a bug fixed in -9
<mdz> daniels: it didn't fail for anyone else in this way
<mkedwards> daniels: rsync'ing
<mdz> so _something_must be different about his setup
<daniels> mdz: it's very specific to 1920x1200
<mdz> daniels: ok
<mdz> that's what I was looking for
<mkedwards> daniels: thx
<daniels> yeah, that bug seems to be fixed now
<mkedwards> daniels: rsync will take 13 hours or so.  Will test tomorrow AM PDT.
<daniels> judging by the fact that rigging xresprobe with that log gave me a config with 1920x1200
<daniels> mkedwards: it shouldn't actually take quite 13h, since it will fly through the middle, but thanks; much appreciated
<mkedwards> np
<tritium> daniels, any thoughts about intel_agp being removed from my blacklist after today's upgrade?  Does it have anything to do with the agpgart changes going on?
<daniels> tritium: er, I don't know, sorry
* dilinger blinks at #8287.  you can resize ntfs?  eww..
<tritium> hotplug wasn't even upgraded today
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals | No more uploads to hoary/main without approval
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals | No more uploads to hoary/main without approval (ask mdz or Kamion)
<mkedwards> will also try on powerpc (laptop and iMac); use RC?
<mdz> mkedwards: if you're going to test, please use the latest dailies
<mdz> tritium: nothing we've done would modify your hotplug blacklist
<tritium> mdz, that's what's so puzzling
<mkedwards> mdz: OK, same rsync except ppc?
<mdz> mkedwards: 'powerpc', yes
<tritium> That, and that my custom xorg.conf was overwritten.  I'm sure the md5sum had changed.
<daniels> tritium: if the md5sum had in any way changed, it wouldn't have overwritten it
<daniels> unless you asked it to with dpkg-reconfigure
<daniels> in which case it's very nicely backed it up
<daniels> as /etc/X11/xorg.conf.yyyymmddhhss
<tritium> that was my understanding, but I'm not kidding.  It happened...
<daniels> hm
<daniels> i've never seen that happen
<tritium> I had blacklisted intel_agp, and added "NvAgp" option into my xorg.conf.  All that was gone today.
<daniels> if it was happening, I'd lose my highly-customised xorg.conf
<daniels> on both my laptop and desktop
<tritium> First time I've seen it too.  No problem, I re-did the changes I had made.
<Riddell> mdz: can I upload gwenview with fixed timestamps and kdebase with a couple of menu changes
<mdz> Riddell: yes, if you do it right away
<Riddell> mdz: kdebase will take 15 mins
<mdz> Riddell: today should be the last day for anything but fixing major regressions
<ogra> mdz, did you get my message before ?
<mdz> tritium: perhaps your filesystem was corrupted, restored from a backup, or you aren't logged into the system you think you are ;-)
<mdz> tritium: that's one too many weird things going on in /etc
<tritium> mdz, as trange as it sounds, it really did happen...
<mdz> ogra: yes, I did, and I am very serious about stopping uploads.  we have a release to make
<ogra> mdz, i know, but the help is not complete yet, i could live with the small bugs left, but not without helpfile in place
<tritium> I only get proper suspend-to-ram with nvidia driver, "NvAgp", and intel_agp blacklisted.  When I rebooted, it was using "nv", and those changes are what I found.
<mdz> ogra: it needs to go in tonight
<ogra> urgh...
<mdz> the release was originally scheduled for tomorrow; there was plenty of time to plan for this
<ogra> mdz, i didnt even plan a help file, but since froud wrote one i need it at least to reflect the actual app...(one screenshot is missing and one chapter is wrong)
<mdz> ogra: it will be ok without the help file
<mdz> as you say, we never planned on it
<mdz> the time for unplanned features is long past :-)
<ogra> mdz, ther is a button that starts yelp currently....
<ogra> mdz, let me see if i make it to clean frouds file, then it'll be ok
<mdz> I don't see a help button
<mdz> oh, argh, you made a new upload
<ogra> sorry :/
<robertj> #8516 New Spatial Bug has been reopened, is there any news on that?
<tseng> news would be on the bug
<tseng> thats the point of having a bug tracking system :P
<robertj> tseng: well I read it and it went from being resolved wont fix to reopened but no mention or why...
<tseng> so someone reopened it
<tseng> that doesnt mean much.
<CarlK_> daniels - nvidia box (toshiba 6100 laptop), nvidia-glx-config enable, ctrl-alt-bakcsace, got the nvidia splash, login box, logged in, now have a brown screen and a mouse.  no walpaper, no menus
<daniels> you probably need to reboot, or at least sudo modprobe nvidia
<tritium> CarlK_, why aren't you coming to #ubuntu first to ask?  I can help you...
<CarlK_> woa... 2+ min later and it's up
<CarlK_> P4-2ghz, 512meg... never seen something like that
<robertj> CarlK: time to upgrade!
<CarlK_> lol
<CarlK_> time for dinner - 
<CarlK_> I was testing the "In order to take full advantage of the changes, X needs to be restarted." and it is true - thats all it took - module is loaded, (II) NVIDIA X Driver  1.0-7174  Tue Mar 22 06:48:37 PST 2005
<tseng> bug 8548, you have to be kidding
<tseng> "this is busted and we know it, so lets release it like this and fix it later"
<robertj> is that the intel wifi?
<jblack> Hey guys. Is there some sort of problem with acpi? I keep getting random popups in x saying acpi this, that theother. syslog and dmesg are also going bonkers, using up about 90% of the cpu
<tseng> robertj: the what?
<robertj> nevermind, someone was complaining that his intel chipset wifi died every 3 hours without the most current drivers
<robertj> tseng: this particular issue really gets my goat :(
<robertj> I think the reason it is so irritating is that Mark hasn't really said much about it AFAIK
<tseng> he did, on the bug I just said
<tseng> and you went on some tangent about intel wifi
* tseng shrugs.
<robertj> oh I didn't realize it was him who reported it
<robertj> tseng: I marked it as a dupe of #8516
<robertj> tis the other leg of the elephant no?
<tseng> um, not really
<tseng> but its bedtime, cya
<robertj> off to bed, night all
<zul> evening
<lamont> moo
<jsgotangco> moo?
<lamont> jsgotangco: is traditional greeting
<jsgotangco> errr in this channel?
<lamont> well... no
<jsgotangco> moo
<zul> just for farm boy
<lamont> toche
<zul> heh..
<zul> inotify sucks..
<lamont> duh
<lamont> thought inotify was your middle name?
<jsgotangco> there's a nice laptop test by a contributor on hoary preview at osnews
<zul> ooh...the "power" of inotify http://www.kernel.org/pub/linux/kernel/people/rml/inotify/glib/
<zul> lamont: nah...its super amazing dude
<zul> crud...wifey is calling me to bed..
<jsgotangco> *grin*
<zul> at least i got to watch dr. who tonight...later..
<jsgotangco> bye bye
<lamont> heh
<fabbione> morning
<lamont> morning fabbione 
<fabbione> morning lamont
<fabbione> crap gcc-4 is FTBFS on sparc
<ogra> hey fabbione 
<lamont> fabbione: join the club
<fabbione> lamont: it can't find some libcairo something
* fabbione wonders what doko broke this time
<fabbione> argh no
<fabbione> it's the usual problem
<infinity> doko never breaks anything.  It's against his religion.
<infinity> Well, he breaks ABIs randomly for kicks, but that's about it.
<jbailey> libcairo is probably for java.
<infinity> Most of the crazier build-deps are.
<jbailey> What?!?  You don't generally think gcc needs to pull in X? =)
<fabbione> libcairo is there
<fabbione> but apparently 0.3.0-1 has been lost somewhere
<fabbione> at least for sparc
<infinity> I'm rather irritated by gcc needing to link to everything under the sun, yes. :)
<infinity> (mostly irritating when you install the gcc-snapshot packages, which include all the java stuff, hence requiring all the dependencies)
<infinity> Also, the part where the java portion of the build takes twice as long as the rest of the suite is annoying.
<infinity> It'll surpass the testsuite soon.
<theine> Hi, can anybody tell me how the ipw2100 patch that's applied to the Ubuntu kernel sources differs from the ``official'' one from ipw2100.sourceforge.net ?
<theine> is this documented somewhere?
<fabbione> theine: it is documented in the source package. debian/external-drivers and debian/changelog
<fabbione> iirc only patches to allow suspend/resmue have been applied to it
<theine> fabbione: great, thanks for the info
<elmo> hmm - how much space would I need to leave to one side to usefully do test installs?  
<lamont> elmo: 2GB is plenty, I would expect
<lamont> my fresh ppc install has 1.5GB, after building a chroot
<lamont> the chroot pile is 200MB, so 1.3GB is about what the install used
<lamont> (much of that archive-copier, mind you)
<CarlK_> a fresh install uses 1.4G
<lamont> CarlK_: which architecture?
<CarlK_> er, thats what df shows when it is done 
<CarlK_> i386
<lamont> jdub about?
<mako> ---> http://spaces.msn.com/members/spaceslogo/
<mako> dude, that guy is organizing a write-in campaign to MY EMAIL ADDRESS
<CarlK_> I think it frees up 200m at the end, so you may? need 1.6, but I am not sure
<CarlK_> and now, bed tiem
<CarlK_> night all
<spiv> mako: At least our logo doesn't have fat people ;)
<mako> yeah dude, our models are at least HOT
<lamont> dunno.. that redhead...
<lamont> mako: so you've been getting a bit of email?
<mako> lamont: you have no idea... but no, not more than usual :)
<lamont> meaning boatloads, I expect
<daniels> mako: lucky you!
<infinity> mdz : Around?
<infinity> mdz : DO we care about purely cosmetic issues (in manpages, no less, not some spiffy desktop product) this close to a release, or should I tag it as 5.10 and move on?  (cf: #8629)
<fabbione> daniels: hey dude
<daniels> fabbione: g'morning
<lamont> daniels: about when does jdub usually show up?
<mdz> infinity: post-hoary
<daniels> lamont: dunno, sorry; it's 1404 now, so he should be conscious
<infinity> mdz : Moving on, then.
<m_tthew> mako: somewhere in that pile of mail is an item from me re: hoary CDs that would appreciate some attention post-release but pre-ship. :)
<mdz> infinity: if you have no severe bugs, please spend time on live + install testing
<infinity> mdz : I have no burner here, but I do have a mess of security bugs to keep me happy.
* infinity glances at thom and pitti.
<infinity> The only installation problems I ran into with a recent hoary install daniels burned for me were related to my crap hardware, and not worth fixing, IMO (well, certainly not attempting it right now).
* dieman notes that 3 in-place warty->hoary upgrades at work on nis/nfs clients worked great so far.
<dieman> or it might be 4, rather.
<infinity> mdz : And none of those were regressions from the warty install, which worked even worse on my craptop. ;)
<fabbione> morning mdz
<Lathiat> i should get the iso and do some testing
<mdz> morning
<Lathiat> has it been mirrored?
<fabbione> mdz: how is the situation?
<mdz> fabbione: looks pretty good
<mdz> lamont fixed a problem with the powerpc live build
<mdz> and all of my (basic) tests were successful, {i386,powerpc,amd64}x{install,live}
<fabbione> mdz: rocking
<dieman> damnit
<dieman> i forgot to file this amd64 bug i had :)
<dieman> luckily i think it only affects my machine
<dieman> (8-way iwill board)
<mdz> jdub: do you have an artwork upload coming or not?  we are out of time
<infinity> dieman : You still need to misappropriate one of those in my direction.
<dieman> ok
<dieman> as soon as i transcribe it from this blurry photo
<dieman> from the failed d-i install.
<dieman> i ended up using an older cd that worked.
<lamont> mdz: emailed
<mdz> lamont: hmm, I think we should probably omit the KDE stuff
<fabbione> at the first shot i lost the kitchen, the washing machine and the drier + 3*2KW lines
<daniels> ouch
<lamont> mdz: I think I did
<fabbione> all the computers seems to be ok
<lamont> unless I missed some in that middle list...
<mdz> lamont: >   akregator.desktop
<mdz> >   amarok.desktop
<mdz> >   amor.desktop
<mdz> >   ark.desktop
<mdz> >   atlantik.desktop
<mdz> >   atlantikdesigner.desktop
<mdz> those are all KDE
<jdub> lamont: yo
* jdub reads up
<lamont> grumble
<jdub> why would we omit the kde stuff? it's in main
<lamont> jdub: doubles the number of packages?  increases confusion?
<lamont> Help is kde too
<jdub> the list isn't confusingly long, and they're all applications
<lamont> gwenview.desktop:Categories=Qt;KDE;Application;Graphics;
<lamont> juk.desktop:Categories=Qt;KDE;AudioVideo;
<lamont> laptop.desktop:Categories=Qt;KDE;X-KDE-settings-power;
<lamont> lskat.desktop:Categories=Qt;KDE;Game;CardGame;
<lamont> noatun.desktop:Categories=Qt;KDE;AudioVideo;
<lamont> quanta.desktop:Categories=Qt;KDE;Development;
<lamont> thinkpad.desktop:Categories=Qt;KDE;X-KDE-settings-system;
<lamont> websearch.desktop:Categories=Qt;KDE;Find;
<mdz> lamont: I'm marking up the list now
<jdub> sure the names are all silly and they don't have descriptions, but hey :)
<lamont> they encourage the uninitiated gnome user to stray into forbidden paths.
<mdz> jdub: because it doesn't make much sense in gnome-app-install, which isn't .even used in kubuntu
<jdub> mdz: why doesn't it make sense? they're in main. they're supported. they're applications.
<lamont> mdz: note that k3b was an intentional choice to leave in
<jdub> the only things that worry me are:
<jdub> - number of kde games in separate packages
<jdub> - number of kde music/media players we've managed to add to main
<jdub> i'm pretty happy with the list, and plan to upload it once i've done the icons this afternoon, btw
* lamont removes gimp-2.0.desktop, under the theory that the Exec=line should get somewhere.
<jdub> (as well as the custom .desktop files for multi-binary packages)
<lamont> btw, evolution-mail.desktop (whichever package delivers that) still executes evolution-2.0
<mdz> lamont: marked-up list sent
<jdub> if you guys have suggestions for changes/exclusions, please mail them to me
<mdz> lamont: there should be one and only one entry in g-a-i for evolution, and it should operate on the 'evolution' package
<lamont> easy enough to toss evolution-mail
<lamont> which is evo --component=mail
<lamont> &*^)& greylisting...
<lamont> mdz: you want to either sendmail -q, or resend?
<mdz> Apr  5 22:38:19 localhost postfix/smtp[31759] : 9E4873BF7E: to=<lamont@mmjgroup.com>, relay=mail.alcor.net[68.168.78.100] , delay=15, status=sent (250 Message received: 20050406053543.NXHD4618.mta13.adelphia.net@mizar.alcor.net)
<lamont> Apr  5 23:43:32 mmjgroup postfix/smtpd[5104] : NOQUEUE: reject: RCPT from mta11.adelphia.net[68.168.78.205] : 450 <lamont@mmjgroup.com>: Recipient address rejected: Service is unavailable; from=<mdz@alcor.net> to=<lamont@mmjgroup.com> proto=ESMTP helo=<mta11.adelphia.net>
<lamont> and the next time that either (1) they retry, or (2) you resend, it'll not get rejected
<mdz> it's in my ISP's queue, not mine
<mdz> I'll resend
<mdz> sent
<lamont> thanks
<infinity> daniels : ping.
<daniels> pong
<infinity> I need your amd64 again.
<infinity> (but I forgot the hostname)
<lamont> mdz: bme == epiphany-browser
<daniels> home.fooishbar.org
<infinity> And port? :)
<lamont> database-properties == libgnomedb2-common
<mdz> lamont: same answer as for evolution, then
<daniels> dunno
<mdz> scratch database-properties
<jdub> guys, those don't matter much
<lamont> bme == bookmarkeditor
<jdub> they won't display anyway
<mdz> scratch bme
<JaneW> hi mdz...
<JaneW> up late?
<froud> African Greetings
<mdz> JaneW: sleep is optional for the rest of the week
<JaneW> mdz: as they say in Afrikaans 'sterkte'
<elmo> janew: that means you too, you slacker
<daniels> sleep?  wassat?
<elmo> ;-)
<JaneW> meaning strength to you
<mdz> thanks
<lamont> gnome == gnome-session (skip?)
<mdz> yes
* JaneW promises to stay up all night too, in solidarity...
<jdub> lamont: it doesn't matter, it won't be seen in the gui anyway
<lamont> grep Exec gpilotd-control-applet.desktop 
<lamont> Exec=gpilotd-control-applet
<lamont> mdz: really want to nuke k3b?
<ogra> froud, sorry, i was forced to bring in the docs today, so i added the missing bits myself...hope thats ok for you
<lamont> laptop == kde, gone
<jdub> lamont: dude, it's not shown in the gui anyway
<froud> ogra: no worries. Send me a patch
<lamont> jdub: yeah, yeah
<lamont> mdz: nmapfe is not a CLI
<jdub> why are you going through these by hand?
<SuperLag> Do you guys have any .debs of MySQL 4.1.11 stashed away in your bag of tricks?
<ogra> froud, yeah, i'll do, but first i need some hours of sleep ;) 
<lamont> jdub: seemed like a good idea
<froud> ogra: sleep we just woke up
<ogra> heh
<jdub> it's a waste of time
* froud sips coffee
<lamont> mdz: moz-firefox is the .desktop, firefox is a .png :)
<jdub> get some sleep, i'll add the icon sucking stuff to d-s and upload g-a-i-d once they're done
<mdz> lamont: yes, nuke k3b and nmapfe
<jdub> huh?
<froud> ogra: it's fine. I did not get to the document because of i18n stuff on ubuntu-doc
<jdub> why are you suggesting the removal of valid applications from the list?
<ogra> froud, ... i think its a great documentation as it is now.... thanks for doing it :)
<mdz> jdub: what I need from you most of all right now is to flush any pending artwork ASAP
<mdz> I need final artwork in the archive tonight before I sleep
<froud> ogra: my pleasure
<jdub> mdz: no can do
<jdub> mdz: no cliff for colours, mark is mocking up a splash tomorrow morning
<mdz> they're both past their deadlines
<froud> ogra: next is to put it through i18n
<jdub> mdz: i will be up for UK morning, and will work on final artwork (including undelivered stuff from cliff) with mark
<froud> ogra: when you send your patch I will create a POT file for translations
<mdz> jdub: dude, we are building the release tomorrow
* JaneW needs coffee, brb
<mdz> this is _it_
<jdub> meanwhile, you guys are picking through desktop files by hand when i'm running a script over them
<jdub> tomorrow UK time
<JaneW> BTW if anyone has anything that I can do to help ease the loud, just shout!
<elmo> dude, it _IS_ UK morning
<mdz> jdub: let's not talk about the g-a-i thing right now
<jdub> ie. mark will be around within 1hr
<froud> JaneW: coffe and donuts would be nice :-)
<ogra> froud, there are very strict rules for uploads now, i dont think we'll get it in... :-/
<fabbione> JaneW: thanks :)
<lamont> Mozilla.desktop:Exec=mozilla-1.7.3
<lamont> ew
<froud> ogra: no but at docteam we need to make POT files anyway
<froud> so th eRosetta team can get it
<JaneW> froud: where are you? (coffee and rusks I can do)
<daniels> froud: hoary is in deep deep deep deep deep deep rather polar freeze
<froud> If the POT goes in the upload the Rosetta guys will see it
<jdub> mdz: if we're both doing it, it probably needs talking about
<froud> daniels: not for hoary
<mdz> jdub: we're not both doing it. lamont is doing it
<froud> daniels: after
<daniels> froud: right
<jdub> mdz: ok, so lamont and i are doing it.
<jdub> mdz: even so, it's a waste of time
<mdz> jdub: I want you to stop doing it, and get artwork sorted
<froud> JaneW: JHB, Northcliff
<jdub> mdz: dude, far out
<ogra> elmo, i forgot a -sa in my former upload, could you move hwdb-client_0.6-0ubuntu1 out of the way ?
<jdub> mdz: can't do artwork, don't have a mark or a cliff
<jdub> mdz: can do desktops, have a nicely efficient script doing it for me instead of manually picking through
<ogra> elmo, it seems to block -0ubuntu2
<mdz> jdub: we are in non-blocking mode on that stuff; if it is not ready, then we are done
<froud> ogra: did the xml validate
<elmo> ogra: no, uploads are being manually approved now
<mdz> I approved hwdb
<ogra> elmo, ah, ok
<JaneW> froud: cool, I went to Northcliff primary...
<jdub> mdz: so given that we must wait on artwork right now, and there is not much left to do on g-a-i-d...
<lamont> mdz: tossed you the revised list
<lamont> jdub: started with your script... mdz had me prune it
<mdz> lamont: looks perfect; can you build a package with that list and test them?
<jdub> ...
<elmo> meh rsync-ing from rc to current daily was so not a win
<mdz> elmo: and now we have a new openoffice build to deal with :-P
<infinity> pitti : Check you mail wrt MySQL this morning?
<pitti> Good morning
<froud> morn
<pitti> infinity: already at it :)
<pitti> infinity: okay, so we don't know anything for sure by now
<jdub> elmo: something up with a.u.c?
<jdub> Got a single header line over 360 chars [IP: 82.211.81.138 80] 
<elmo> uh
<infinity> pitti : Yeah, that's the current status.  OTOH, he's pretty sure it's meant to (re)address that vuln.  I'm hoping to hear more back from him, though.
<mdz> pitti: morning
<ogra> hey pitti 
<mdz> jdub: that's a new one
<jdub> i get the same through my proxy
<mdz> working fine here
<ogra> elmo, did you recognize that mdz approved my upload ? (sorry, dont want to get on your nerves, just to be sure)
<elmo> ogra: eh?
<ogra> <elmo> ogra: no, uploads are being manually approved now
<ogra> <mdz> I approved hwdb
<ogra> <ogra> elmo, ah, ok
<mdz> ogra: the approval process is software-driven now
<ogra> ah, ok
<mdz> as of about an hour ago ;-)
<pitti> Hey ogra, hey mdz
<elmo> jdub: looks fine to me, and as mdz said, never seen that error before
<elmo> is it reproduceable?
<jdub> yep
<infinity> pitti : http://dev.mysql.com/doc/mysql/en/news-4-1-11.html -- search for CAN-2004-0957
<mdz> that error means exactly what it says; if you're getting it and we aren't, you're getting a response with different (and weird) content
<jdub> with or without squid proxy
<infinity> pitti : Upstream certainly seems to think they're (re)fixing it.
<mdz> jdub: -o debug::acquire::http=true
<jdub> whoa
<pitti> infinity: oh, I see; or, rather, fixing another attack vector to the same vuln (I think the previous patch is correct, too)
<pitti> infinity: what was the URL of your packages again?
<pitti> infinity: just a pity that there is no referenced bug #
<jdub> mdz: i'll mail the output
<elmo> jdub: cc me, pls?
<jdub> ok
<infinity> pitti : Ah-ha.  There's a reference in the 4.0.25 changelog.
<mdz> pitti: what is the status of langpacks; are they up to date with the archive?
<infinity> pitti : Also, http://lucifer.0c3.net/~adconrad/mysql-security/
<jsgotangco> wow pretty active here lately
<jsgotangco> *grin*
<infinity> pitti : Oh, no, the reference in the 4.0.25 changelog just points to the old bug that (they thought) was fixed in 4.0.21... No new comments on it since then.
<mdz> jsgotangco: it's that time of year
<jdub> jsgotangco: that crunch you can hear is the sound of an ubuntu release :)
<mdz> that sound like grinding teeth
<infinity> pitti : So, yeah.  Looks like they just found another hole matching that CAN, or something.
<jdub> jsgotangco: got my mail re: ubuntu-ph?
<froud> jdub: what about ubuntu-ph?
<Lathiat> is there a more official iso than the 0405.1 daily build? (going to do some testing and abuse)
<jdub> froud: the list
<mdz> jdub: try separating stdout and stderr
<infinity> mdz : How much do we care about file conflicts between main and universe?
<jsgotangco> jdub: yess thanks very much *grin* i know you;ve been busy
<mdz> infinity: if they can be resolved by changing only universe, I'm OK with that
<mdz> not worth changing main at this point
<jdub> mdz: 
<jdub> ETag: "77007b-262-bed8680"^M
<jdub> ^M
<jdub> ^_<8b>^H^@u+NB
<jdub> 
<jdub> (...)
<pitti> jdub?
<mdz> that bit is perfectly reasonable
<infinity> mdz : Can be, yup.
<mdz> that's a gzip header
<jdub> there doesn't appear to be anything strange about the output
<jdub> thought the above may have been misinterpreted by apt
<mdz> maybe some non-printable characters in there?
<mdz> it's supposed to be printing only the header, not the data
<jdub> well, that makes the output very strange ;)
<mdz> at any rate, given that we haven't been flooded with complaints about it, I expect it's a problem on your network/isp/etc.
<paulproteus> I've been dist-upgrading to Hoary.  It seems to have broken resume on my iBook G4, consistently for the past week.
<paulproteus> I've been trying to keep quiet, hoping it would fix itself.
<mdz> doko: do we need an oo.o-amd64 upload?
<paulproteus> It might be two or three weeks, actually.
<mdz> typically the best approach when you see something wrong is to check bugzilla, and if it isn't already reported, report it
<mdz> it's now too late to fix it, even if we knew how
<Lathiat> is the ubuntu-artwork package being updated to get a new mozilla homepage?
* jdub wgets instead, sees it works fine
<jdub> Lathiat: yes
<Lathiat> also the screenshot in the quickguide should probably be changed to match
* paulproteus mutters something about having to create an account
<jsgotangco> hehe
<infinity> mdz : Too late to get printer driver fixes in, I assume?
<mdz> infinity: unless it's blindingly obvious and fixes printer breakage for half our users, I think I'd rather not
<infinity> Blindingly obvious, yes.  Fixes things for only a tiny subset of users, though.
<mdz> infinity: debdiff?
<infinity> The only downside is that they can't work around it without rebuilding.  (downloading a new PPD can't work around bugs in gs's C..)
<infinity> mdz : http://lucifer.0c3.net/~adconrad/gs-esp/3-4.diff
<infinity> Already fixed in gs-gpl.
<infinity> mdz : Still waiting to hear back from the user that it fixes both his issues, but I know it fixes one glaring bug without him even responding.
<infinity> OTOH, LJ1012 users are probably not so common. :)
<mdz> gdevpx.c sounds awfully generic
<mdz> (i.e., probably has an affect on other drivers as well?)
<infinity> Yes, but this change has been in gs-gpl 8.x for ages.
<infinity> (It affect all printer that speak PCL XL, but only a few of them cared about the badly-formatted output, apparently)
<infinity> OTOH, there is a workaround in the form of "don't use gs-esp", so it's not the end of the world.  It just happens that we install gs-esp by default.
<infinity> (The other half of the bugfix would be to include a new PPD in sopme package, somewhere)
<infinity> As the LJ1010/1012 doesn't work with curent hpijs, but works with gs + pxlmono + new PPD.
<infinity> mdz : I'm inclined to put it off if you feel in any way unsure about it, only because I hate printers. :)  But the user(s) may appreciate a fixed package.
<infinity> mdz : One can work around it with "use gs-gpl, and download this PPD here (url)" though.
<mdz> infinity: my default state is unsure
<mdz> and inertia is high at this stage
<infinity> Understandable.
<infinity> I'm trying mainly to focus on security stuff, I just happened to hear back from the user today on this one, so decided to spend a few minutes on it.
<infinity> pitti : There, Christian sent you Sergei's explanation.  Is that good enough for your security update?  (want me to update the changelos to be more verbose while I'm at it?)
<pitti> infinity: saw it, cool
<pitti> infinity: yes, that's fine
<pitti> infinity: however, please ask mdz to ack the upload for hoary
<infinity> pitti : Of course.
<infinity> pitti : Shall I just upload the warty-security one once I've rewritetn the changelog?
<pitti> infinity: I'd like to take a peek on the new changelog entry :-)
<pitti> infinity: you did not change any code any more?
* infinity rewrites it now.
<infinity> pitti : Nope, just using the patch from 4.0.25 in both packages.
<infinity> pitti : I'll just rewrite the changelog, so it's obvious that we know we're "re-fixing" this. :)
<mdz> daniels: #8706?
<fabbione> mdz: it doesn't happen here.. standard config with updates
<mdz> fabbione: someone in this channel was saying the same thing earlier; I'm not sure whether the same person filed the bug or not
<daniels> mdz: this doesn't make sense to me, though
<fabbione> mdz: neither to me
<daniels> mdz: nothing at all changed in that regard between -9 and -10
<fabbione> xorg.conf is always generated
<daniels> it hasn't happened to me on either of my machines, or to anyone else
<fabbione> i wonder if they did remove it in the hope to get it regenerated
<fabbione> mdz: i386 install is GO both normal and multiarse
<mdz> fabbione: thanks
<fabbione> testing live now
<mdz> fabbione: can you check whether doko's oo.o changes require a new oo.o-amd64?
<infinity> pitti : New changes at: http://lucifer.0c3.net/~adconrad/mysql-security/warty/mysql-dfsg_4.0.20-2ubuntu1.5_source.changes
<fabbione> mdz: i don't have an amd64 :(
<fabbione> i can check the sources, but that's it
<mdz> fabbione: I understand, but it should be possible to tell from the source
<fabbione> mdz: i can try modulo electrician showing up
<fabbione> mdz: half of my house is without power atm
<fabbione> and when he will arrive i will have to shutdown everything
<pitti> infinity: looks good
<pitti> infinity: however, can you please add any external URL as reference?
<FabLivei386> mdz: this one looks good too
<infinity> pitti : To the CAN, or the (old) MySQL bug, or?
<pitti> infinity: to the changelog entry
<infinity> pitti : I have no reference other than my INBOX for the original fix being wrong.
<pitti> infinity: hmm, ok
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals | No more uploads to hoary/main without approval (ask mdz or Kamion) | Test the current daily live+install CDs - THIS MEANS YOU
* infinity rebuilds the hoary sources.
<infinity> mdz : Permission to upload this fix to hoary?  http://lucifer.0c3.net/~adconrad/mysql-security/hoary/
<infinity> pitti : Shall I sign and upload for warty, then?
<pitti> infinity: yes, please
<infinity> Done.
<mdz> infinity: the patch is identical to the one used for warty?
<infinity> mdz : Yup.
<mdz> infinity: ok, go ahead
<infinity> And they're both off.
<infinity> Now to drive myself insane with mozilla some more.
<daniels> mdz: hm, I think I have a better idea about 8706 now
<daniels> thinking about it
<fabbione> mdz: eta 50 minutes to get the source here for amd64 :/
<fabbione> mdz: but i am on it
<mdz> pitti: I didn't see your answer; are the langpacks up to date?
<mdz> fabbione: hmm, could be done on chinstrap
<mdz> fabbione: the question I think is whether the changes in oo.o itself go into arch: all or arch: any packages
<fabbione> mdz: true enough...
<fabbione> mdz: the interdiff between ubuntu1 and ubuntu2 shows changes to some .cxx files too. so i guess it is also arch: any
<fabbione> ++++ transex3/source/merge.cxx  2005-03-22 12:04:03.436363784 +0100
<fabbione> how can you call a dir TRANSEX ???
<Treenaks> fabbione: at least it's merge.cxx, not goatse.cxx
<jsgotangco> haha
<fabbione> Treenaks: ehehe
<pitti> sivang: I'm trying to disable the login name editing in g-s-t (#6387). When doing the same with the user id, did you ever encounter this: when starting the new users-admin, it exits with "invalid password"?
<pitti> this is driving me crazy
<sivang> pitti: hrm
<sivang> pitti: no IIRC, have you used to exact same code I used on disabling the UID field?
<pitti> yeah
<Kaloz> re
* Kaloz waits for hoary final
<Mithrandir> Kaloz: friday.
<Kaloz> i know
<Kaloz> i'm ready with the stuff to start nubuntu :p
<pitti> "n" == ?
<Kaloz> i deceided to go with that name :p
<Kaloz> pitti: it was going to be "u"buntu, but nubuntu is nicer :p
<Kaloz> pitti: "n" as "nano"
<Mithrandir> pitti: no-buntu, no software, so bugfree
<fabbione> mdz: my understand is that we need another ooo-amd64 build
<Kaloz> pitti: eg. embedded ubuntu :p
<fabbione> ah Mith
<mdz> oh, good, Mithrandir is here
<mdz> just in time :-)
<fabbione> Mithrandir: perhpas you know... 
<Mithrandir> mdz: damn. :P  What's up?  u8mg?
<mdz> Mithrandir: oo.o-amd64
<fabbione> doko did some changes to ooo1.3 on i386
<Mithrandir> "some changes" meaning "bump to 1.3.4"?
<fabbione> Mithrandir: my understanding from the interdiff is that we need to rebuild amd64 too
<Mithrandir> ok, that's easy.
<infinity> Kaloz : I like Microbuntu better.  Just makes it hard to talk about if you can't type the symbol (as I can't).
<fabbione> Mithrandir: nahh.. let me put up the interdiff for you
<Mithrandir> is the i386 one in the archive?
<infinity> Kaloz : Does make for a neater logo. :)
<jdub> nanubuntu == mork-and-mindy-stylins
<Kaloz> :p
<fabbione> Mithrandir: http://people.ubuntu.com/~fabbione/interdiff
<Kaloz> infinity: nah, as we already have kubuntu, nubuntu sounds better
<Kaloz> infinity: and anyway, i would like to have ubuntu on a CF or pendrive with all the toys :p
<Kaloz> infinity: maybe with grsecurity, too =)
<Mithrandir> fabbione: nothing hard there; I'll do it post-breakfast when I get to university where I have a 100Mbit rather than a 2Mbit line. :)
<sivang> pitti: I can try and check this later on today, if you like, would you send me a diff against the C code? 
<pitti> infinity: buntu .. hmm, not that bad...
<infinity> buntu, even.
<fabbione> Mithrandir: ok for me
* infinity doesn't speak unicode on IRC.
<sivang> pitti: btw, make sure you are disabling the login when *modifyin* , it's a diffrent branching but can be tricky to spot
<sivang> pitti: as opposed to "creating" a new user
<Kaloz> please let me choose the name of it :PP
<sivang> pitti: maybe this is causing the problem?
<pitti> sivang: I did, of course
<sivang> pitti: ok, I will try to check and report bug
<sivang> pitti: s/bug/back/
<mdz> lamont: ETA for new oo.o builds in the archive?
<mdz> one of these days I will have to learn wanna-build so I can get at this information myself
<lamont> mdz: 6-7 hours for i386
<lamont> is not in wanna-build
<mdz> argh :-(
<pitti> mdz: can you please ack the two trivial, but important patches in https://bugzilla.ubuntu.com/show_bug.cgi?id=7430 ?
<lamont> is flat file on each of the buildds
<mdz> pitti: ok
<elmo> mdz: 'lonneke -a $arch $pkg' will give you the w-b info
<elmo> mdz: but as lamont says, on-going build status needs access to the actual buildds ATM
<lamont> build started at 0709 on vernadsky
<fabbione> elmo: congratulation for that fancy name :)
* mdz makes the launchpad face
<pitti> mdz: "ok == you will look", or "ok == ack"?
<mdz> pitti: ack
<pitti> thanks, sorry
<mdz> apparently we can't build proper candidates for another 6-7 hours anyway
<mdz> that oo.o upload was supposed to happen at 0000 UTC
<elmo> last oo.o build on that class of buildd took < 4 hours
<mdz> it would have been done by now
<elmo> hmm, doesn't take ccache into account tho
<pitti> sivang: I attached the preliminary patch to #6387
<Mithrandir> mdz: is the ooo I need to use for ooo-amd64 in the archive?  I can't build the ooo-amd64 before that.
<dholbach> good morning!
<mdz> Mithrandir: apparently not
<mkedwards> Foo.  This rsync would not take another 7 hours if I had actually put the RC image in the directory before starting.  :-(
<mdz> Mithrandir: perhaps it will be there not long after breakfast, though
<Mithrandir> mdz: ok, goodie.
<mkedwards> elmo: you were saying that rsyncing from the RC to current daily is not a win?  How so?
<pitti> Hi dholbach 
<dholbach> hey pitti
<mdz> pitti: you'll need to ping me or elmo after uploading to get the upload accepted
<mdz> lamont: likewise
<lamont> roger
* lamont is still a little bit out - but I know I'll beat oo.o. :-)
* infinity wonders if he'll ever see build logs for that mysql upload...
<pitti> mdz: I still try to fix #6387 before uploading, but I will do
<pitti> infinity: not for warty
<infinity> pitti : I know, I meant for hoary.
<pitti> infinity: I did not see a warty-security upload, btw
<infinity> Though, I'd like to see a mechanism where a package's security build logs are made available after the security release is announced.
<infinity> pitti : Erm.  It was ACCEPTED, according to katie.
<infinity> pitti : 40 minutes ago.
<infinity> mdz : Do all uploads require some form of manual intervention, post-ACCEPT right now?
<sivang> pitti: thanks, already looking at it
<dholbach> morning sivan!
<daniels> amd64 install+live are ok here
<Lathiat> daniels: daily build or is there some other build hiding somewhere?
<daniels> daily
<lamont> mdz: about to upload
<dholbach> hey mvo
<thom> mdz: yes, it will. jdub needs to fix the -artwork package as we discussed
<mvo> hey dholbach 
<mvo> morning all
<lamont> mvo: morning
<jsgotangco> hi
<pitti> Moin mvo
<mdz> thom: I ended up patching -artwork because nothing had been done; did the two of you talk about this earlier?
<jdub> thom: doing atm, then waiting for further artwork bits hopefully coming soon
<jdub> mdz: yes
<jdub> mdz: i don't roll new releases for every change
<jordi> mvo: even if it's not going in hoary, did you play with nano 1.3.6?
<mdz> jdub: I was explicit that it needed to be done today (which is now yesterday)
<jdub> mdz: i did mention that there was more art coming from mark
<mdz> it's better to make multiple uploads than to delay one change in favour of another
<pitti> mdz: btw, I need to build a clean set of langpack base packages before the release, but after all gnome and other packages are uploaded
<pitti> mdz: when do you think is the latest safe time for this?
<pitti> sivang: I have it working now (stupid side effect with gksudo, not related to the patch)
<mdz> pitti: now
<mdz> ASAP
<lamont> mdz: uploaded
<mvo> jordi: no, not really
<pitti> mdz: okay, then every string change from now on will be lost (but it shouldn't be many any more)
<mdz> pitti: there will be no more string changes
<mkedwards> The VGA console on this system is down-shifted by three lines (so the last three lines, generally including the current shell prompt, are missing) and the top three lines are "pinstripes".  Any idea what package this should be reported against?
<pitti> mdz: erm, do all 180 or so packages need to be ack'ed manually from elmo/you?
<mdz> pitti: yes and no; it's easy to do them as a batch
<mkedwards> this is on RC LiveCD (same on array-7), Dell Precision M60 / NVidia Quadro FX 700 Go
<pitti> mdz: patch for #6387 is ready and tested, btw (attached to the bug)
<daniels> mkedwards: should be reported against whoever made your video card
<daniels> mkedwards: switching to a different console (or X) and back should fix it
<lamont> mdz: need anything else before I go catch a couple hours sleep?
<pitti> mdz: it's exactly like 18_disable_uid.patch for s/uid/name/
<mdz> pitti: why is it set to sensitive in one place, and non-sensitive in the other?
<infinity> mdz : Did/do those mysql uploads require manual intervention?  pitti said he hasn't seen the warty-security one yet, despite me getting an ACCEPT over an hour ago.
<mdz> lamont: I don't see your upload in the approval queue yet
<pitti> mdz: senstivive for a new user, non-sensitive for editing
<daniels> mkedwards: s/video card/& BIOS/
<pitti> mdz: before, it was sensitive every time, which allowed to edit login names
<mdz> infinity: mysql-dfsg is there
<mkedwards> daniels: tried that; didn't help.  (It's like this from the very beginning of console text after the splash screen.)
<mdz> pitti: ah, ok
<lamont> mdz: is in UploadQueue for another 3 minutes
<mdz> pitti: (ok = I understand)
<pitti> mdz: it's the save solution for hoary
<infinity> mdz : Err, yeah, same thing.
<pitti> mdz: editing login names can be reconsidered for breezy, but I don't dare to allow this for hoary
<daniels> mkedwards: blah
<mkedwards> daniels: haven't seen this effect on any other linux distro, including Knoppix and Kanotix LiveCDs; not blaming, just trying to identify what's different.
<daniels> mkedwards: in that case, to put it bluntly, your video BIOS is complete shit, and there's not much we can do about it
<mkedwards> daniels: of course it's shit, by the time both NVidia and Dell have monkeyed with it.  :-/
<lamont> daniels/mkedwards:  is really a #ubuntu discussion
<mkedwards> lamont: sorry
<mdz> pitti: this was only a normal bug; it was not even on my radar for release
<pitti> mdz: it was sivan's bug until two hours ago, he asked me to take them since he doesn't have time
<pitti> mdz: so it wasn't on my radar either
<mdz> pitti: ok to upload, I suppose we must do something about it in order to prevent users from making their systems unusable
<pitti> mdz: yeah, that was my feeling
<pitti> thanks
<lamont> mdz: should be in ACCEPTED
<lamont> mdz: and mvo has the code, dealing with merging it back in, etc, etc.
<lamont> thanks mvo
<fabbione> ah finally some good news
<fabbione> it was nothing wrong with the power in my house
<fabbione> the central lost one phase
<jordi> mvo: we've only had a report of nano having problems with Vietnamese
<jordi> and it could be a font problem, who knows.
<mdz> lamont: approved, thanks
<mkedwards> lamont: was actually trying to choose a package against which to file this.  For whomever it hits, it's a pretty serious bug; renders text consoles basically unusable.
<lamont> mkedwards: right.  and this would be the channel to discuss your patch that fixes it...
<mdz> fabbione: that's good
<pitti> mdz: I uploaded system-tools-backends and gnome-system-tools with the ack'ed changes
<fabbione> mdz: yeah.. it's a reliefe :)
* pitti creates langpacks now
<fabbione> mdz: specially when half of my machines didn't have power
<lamont> mkedwards: (lots of developers in #ubuntu as well..)
<mdz> pitti: both approved
<lamont> mdz: off to bed unless you need anything...back online in 3-4 hours
<mdz> lamont: night
<lamont> g'night - thanks
<fabbione> night lamont
<pitti> thanks
<pitti> night lamont, sleep well
<mvo> night lamont 
<smurfix> Another day, another day when I can't login to the wiki :-/
<fabbione> smurfix: the secret is to never logout :)
<mdz> and to always use ubuntulinux.org
<dholbach> two days before release isnt about the wiki, it's about fixing packages ;-)
<smurfix> fabbione: The secret is for firefox to never crash, and for my printer to never wedge the USB
<fabbione> ehhe
<smurfix> fabbione: both haven't been mastered yet :-/
<mkedwards> OK, on next reboot I will try vesafb (this appears to be the vga16fb problem discussed in January)
<daniels> SSSSSSSSSSSSSEEEEEEEEEEEEEEEEEBBBBBBBBBBBBBBBBB
<pitti> daniels: your panel broke?
<thom> smurfix: hey now, firefox never crashes
<daniels> badly
<daniels> and I'm stuck in an infinite loop of 'I've detected a panel already running, and will now exit.'
<infinity> pitti : Do you have your own independent list of mozilla-* CANs that warty is vulnerable to?... I want to make sure I don't miss any while I'm doing this.
<pitti> infinity: yeah, it's noted on http://people.ubuntu.com/~pitti/ubuntu-cve.html, section "Unfixed issues in main, release Warty"
<infinity> pitti : Spiffy.
<pitti> infinity: yeah, this list is an invaluable help for my daily security review
<infinity> pitti : From some preliminary parsing of rejectec hunks, and some eyeballing of patches, this shouldn't be TOO bad.  Especially since it's all I'll be doing for a couple days, I suspect.
<pitti> infinity: rock on :-)
<infinity> pitti : May i suggest putting the Unfixed issues section at the top, rather than the bottom? :)
<thom> go firefox. it's your *ahem* birthday
<pitti> infinity: I will redesign this page anyway after the release, i. e. split it up into several pages with an index
<pitti> infinity: until now I just made it working, but not good-looking :-)
<thom> (incomplete translations mean buttons become unclickable, woohooo)
<pitti> thom: gulp
<infinity> thom : Awesome.
<Treenaks> thom: GREAT!
<thom> pitti: if you have a second and have firefox open, go to File->Import
<fabbione> and Mark.. i would like to apologize for the misunderstanding about the ticket to london
<fabbione> ops
<fabbione> ECHAN
<pitti> thom: I have the de translations installed, btw
<thom> pitti: that was what i was assuming
<pitti> thom: I get this import dialog, what now?
<thom> do the buttons on the bottom right have text on, and can you click them/
<pitti> thom: both buttons (cancel and go on) are translated
<thom> you have a working translation then. en-gb gives me a pair of blank, unclickable buttons
<pitti> thom: they have translated text, and both work
<pitti> fuck
<pitti> sorry
<infinity> pitti : Also, your list is much longer than the one thom gave me. :/
<thom> infinity: well, it would be. i've not had chance to update the list i had :P
<pitti> why this SOAB doesn't fall back to C *whine*???
<infinity> pitti : I'll have to do this in stages, probably, just so people can see some movement on the issue, rather than wait for one giant upload with 734 CANs.
<thom> pitti: no clue, much suck
<pitti> infinity: yeah, definitively
<pitti> infinity: the easy patches first
<infinity> That's no fun.
<infinity> The hard ones look more interesting.
<thom> (the really cool part is with some firefox themes (like industrial) because there's no text, you get *no* button *at all*!)
<pitti> infinity: it would rock if we could do the first advisory on friday or so :-)
<pitti> thom: this seems to utterly broken, what's your quickfix plan? :-)
* pitti hides
<mkedwards> it's either vga16fb or fbcon that's busted; I'll revisit it on next boot.
<mdz> pitti: mysql-dfsg for warty-security is ready
<pitti> cool, thanks
<pitti> mdz: but I build the langpacks first, I guess
<infinity> pitti : I'll try to triage according to percieved severity, rather than "easy" versus "hard"... You should have some fixes soon, yes.
* pitti darkly remembers a "NO SLIP" timeline for Rosetta...
<mdz> pitti: just letting you know, since infinity said you hadn't seen it
<thom> pitti: i'm changing my flights to go to san francisco first and smacking every single employee of MoFo involved with the browser about the head
<pitti> mdz: helena was empty at the time he asked
<thom> infinity: you doing firefox or mozilla?
<pitti> mdz: WTF?
<pitti> pitti@jackass:~ $ helena
<pitti> pitti@jackass:~ $
<mdz> pitti: I think helena is confused
<mdz> it shows empty for approvals as well
<mdz> just look at accepted/*.changes for now
<mdz> amber I think should still work
<pitti> mdz: oh, ok, it's in the accepted queue. nevermind
<pitti> ARGH
<pitti> I do a hoary/ppc install now and found a regression
<pitti> xserver-xorg never asked me for my resolution, and it was always correct
<pitti> now the installation does ask me
<pitti> DAAAANIELLLS
<pitti> daniels: ^ ???
<mdz> pitti: how long has it been since you did a test install?  does it happen on the live CD also?
<pitti> mdz: last install was about a week ago
<pitti> mdz: didn't try live yet, rsync is at 84%
<pitti> mdz: will do when it's ready
<mdz> pitti: I'm not aware of any changes which could cause that; hmm
<pitti> the defaults are fine, I just have to press enter, but this shouldn't happen
<daniels> pitti: hm
<daniels> fresh ppc install?
<pitti> daniels: yeah, with daily/current iso
<mkedwards> daniels: would you expect 1400x1050 to work in the current daily livecd?
<daniels> mkedwards: yeah
<daniels> pitti: hm.
<daniels> pitti: the only way it should prompt on a fresh install is if $NRES is 0
<pitti> daniels: I try ppc/live and i386/install later
<mvo> mdz: I would like to upload update-notifier with translation updates only (diff at http://people.ubuntu.com/~mvo/review/update-notifier/update-notifier_0.39.debdiff)
<mkedwards> daniels: should be able to test with a projector with that (physical) resolution tomorrow.
<daniels> mkedwards: cool
<pitti> daniels: 1024x768, 800x600, and 640x480 are marked
<pitti> by default
<pitti> daniels: 1024x768 is the tft resolution, so far this has always been picked without questioning
<pitti> asking, even
<daniels> 1024 being marked means it didn't work.
<pitti> daniels: erm, why not? it's the only sensible resolution on the iBook
<daniels> sure, but 1024x768/800x600/640x480 is the default
<mkedwards> Should I expect WEP to work from the livecd?
<mkedwards> ieee80211_crypt_wep: could not allocate crypto API arc4
<mkedwards> eth1: could not initialize WEP: load module ieee80211_crypt_wep
<mkedwards> lsmod reports module, though.
<daniels> pitti: what does 'sudo xresprobe ati' tell you?
<daniels> pitti: assuming you're using ati rather than nv
<mkedwards> oops, sorry, that should have gone to #ubuntu
<pitti> daniels: yeah, the ibook has ati
<pitti> daniels: which path? installation is not yet finished
<daniels> pitti: does sudo xresprobe ati, say 1024x768?
<daniels> pitti: ugm
<daniels> you should still be able to get a console
<pitti> daniels: I have a console, but "xresprobe: command not found"
<pitti> daniels: it's already at registering docs
<daniels> try chrooting into /target
<pitti> daniels: dpkg -S $(which xresprobe)
<daniels> pitti: it's in the xresprobe package
<pitti> daniels: erm, it's not installed
<daniels> what the fuck?
<daniels> xserver-xorg depends on xresprobe
<daniels> if you've hit xserver-xorg postinst without xresprobe being installed, something is SERIOUSLY, INCREDIBLY BROKEN
<pitti> daniels: isntallation is finished now
<daniels> well, catually, it recommends xresprobe
<daniels> do you have /target, or are you in the installed system?
<daniels> if the latter and xresprobe is not installed, you need to seriously scream about it
<pitti> daniels: no target, installation is finished, was already installed system before
* pitti seriously screams
<pitti> daniels: Bummer
<pitti> daniels: Recommends: xresprobe
<pitti> daniels: care to s/Recommends/Depends/ then?
<daniels> no, it doesn't depend on it
<daniels> but the installer is/was set up so that xresprobe was installed before xserver-xorg
<daniels> if this is not happening, something is seriously wrong
<daniels> Kamion: ping ^^
<pitti> daniels: I assume that it would have worked with xresprobe; nevertheless I could install the package manually
<daniels> pitti: right
<daniels> but if you have to, that's fucked
<daniels> to put it bluntly
<pitti> daniels: it's not on the CD!!!
<daniels> seeds are broken
<mvo> mdz: don't know if you got that one before you disconnected: I would like to upload update-notifier with translation updates only (diff at http://people.ubuntu.com/~mvo/review/update-notifier/update-notifier_0.39.debdiff)
<mdz> mvo: the translations will be stripped out anyway; they need to go into langpacks
<daniels> mdz: what happened to the seeds?
<pitti> mvo, mdz: erm, I'm just at assembling the final import archive for building the langpacks. shall I wait a bit and do it again?
<pitti> mvo, mdz: this really takes a while since I have to pull translations from gnome and old stripped ones, too, and merge them all together
<pitti> daniels: I try ppc/live now
<mvo> pitti, mdz: I would like to upload it so that those translation make it into the langpacks
<mdz> mvo: another upload means that pitti must wait an hour to roll new langpacks
<pitti> I don't mind personally, but the 160 packages need to be approved and built
<mdz> and I need to sleep
<pitti> mdz: can elmo approve them, too? (I suppose yes)
<mdz> pitti: he can, but he only went to sleep 2 hours ago
<pitti> uh
<mvo> ok
<pitti> mdz: modulo the missing xresprobe package on the ppc/install cd, installation is fine
<pitti> mvo: we can put it into the first update deb after release, too
<mdz> I plan to stay awake until Kamion gets here; he can approve uploads as well
<mdz> but we must draw the line somewhere
<mkedwards> daniels: is it worth my trying xrandr to get 1200x1920 while I'm at it?  (this is a "pivot" style monitor)
<mdz> the whole point of langpacks was to be able to update translations after release
<pitti> mdz: <pitti> mvo: we can put it into the first update deb after release, too
<mdz> and one reason for this was to avoid the disruption of last-minute updates like this
<pitti> yeah
<daniels> mkedwards: 1200x1920? ... uhm
<daniels> mkedwards: only the nvidia binary driver really supports rotation
<daniels> mdz: is it possible to get at the cd build logs so we can find out why xresprobe is not on the powerpc install cd?
<mdz> mvo: let's update it after release
<mdz> mvo: for now, focus on testing the CDs as much as possible
<mdz> daniels: yes
<daniels> mdz: can you please put it on chinstrap or something?  i still don't have access to little
<mdz> apparently it's been missing since 20050403
<pitti> mdz: yeah, that fits, my last install was on 0401, and it worked then
<mdz> daniels: little is not general-access; it's only for CD builds
<mvo> mdz: ok. rsyncing the cds right now
<daniels> mdz: yes; i used to have access to it
<mdz> hmm, make that 20050401
<mdz> daniels: temporarily
<mdz> 20050404 had xresprobe on powerpc
<daniels> in any case
<mdz> 20050405 didn't
<mvo> mdz: should the dvd tested too?
<smurfix> mvo: I'd tell mako todo that, he has the bandwidth to actually download them ...
<daniels> mdz: 8706 is minor, but fixable
<daniels> mdz: (the problem with 8706 is that *everyone* is going to fall to 60Hz if/when we do an xserver-xorg update)
<daniels> i suspect it's a candidate for the first time we need to do a major fix?
<daniels> (and the first upload to breezy)
<mdz> daniels: in what version was in introduced
<mdz> the prospect of changing the debconfiscation in a security update fills me with disgust
<daniels> -10 and yes, me too
<mdz> since we have demonstrated repeatedly that every time we change it, it breaks
<mdz> in one way or another
<daniels> this is not breaking as such
<daniels> mercifully
<daniels> no-one will not get a display because of it
<fabbione> touch: cannot touch `/var/lib/update-notifier/dpkg-run-stamp': No such file or directory
<fabbione> E: Problem executing scripts DPkg::Post-Invoke 'touch /var/lib/update-notifier/dpkg-run-stamp'
<pitti> mdz, daniels: ppc/live is go (_including_ xresprobe :-) )
<fabbione> mvo: ^^
<mdz> daniels: until they upgrade?
<daniels> pitti: good news, thanks
<mvo> fabbione: where did you got that?
<daniels> mdz: actually, never mind me
<fabbione> mvo: purging update-notifier
<mvo> fabbione: let me check
<mdz> daniels: I don't see anything interesting in the log, but it's in chinstrap:~mdz for your perusal
<mvo> fabbione: interessting, can reproduce it only on one of my machines. will look into it now
<fabbione> mvo: :)
<thom> mdz: can i do a four line translation update that gives en-GB users buttons in firefox wizards?
<thom> (sorry, i only realised the cause late last night)
* pitti reboots to test new langpacks with all apps
<mdz> thom: how long has this bug been around?  first I've heard
<thom> mdz: it was filed about 3 weeks ago; i couldn't reproduce it until the other day when i got an en_gb langpack for the first time
<thom> it's not necessary by any means
<mdz> thom: sounds like a candidate to roll into the first post-release translation update via hoary-updates
<thom> mdz: ACK
<jdub> seb128: computer:/// doesn't close when you open a folder... :|
<enrico> seb128: everything ok with ubuntu-docs and ubuntu-quickguide?
<Lathiat> backspace doesn't close-behind either
<seb128> jdub: if you are traying to say that this patch need some serious reflexion and sucks atm I agree ...
<pitti> yay
<jdub> seb128: just another corner case :|
<pitti> seb128: new langpacks rock now
<pitti> seb128: with all gnome 2.10 translations, and also hibernate/suspend etc.
* pitti uploads
<seb128> pitti: cool :)
<seb128> jdub: I know, we have a ton of these, and that's why we should not put the bogus mode by default
<mdz> pitti: langpacks?
<mdz> ah, yes
<pitti> mdz: I tested them before uploading
<pitti> thought that was a good idea that close to the release :-)
<daniels> mdz: hm, aiui this isn't quite as bad as I thought
<seb128> enrico: lemme try
<daniels> mdz: right, it will write out the sync ranges it picked up from DDC
<mdz> pitti: I saw "uploading" and was confirming that you meant langpacks
<pitti> mdz: ah, right
<daniels> mdz: powerpc is too big
<daniels> + Trying to add xresprobe...
<daniels>   @dep before checklist = xresprobe
<daniels>   @dep after checklist = xresprobe
<daniels>   $cd_size = 4528694, $size = 17838
<daniels>   Adding xresprobe to CD 2 ...
<mdz> dammit, that's supposed to be an error
<pitti> mdz: all langpacks uploaded
<pitti> mdz: with the new langpacks, CD sizes will shrink again since the update packages are tiny again
<fabbione> mdz: Kamion mentioned that it debian-cd doesn't error on size.. it just starts another CD and he needs to check that manually
<Lathiat> daniels: ha ha woo
<daniels> ssh, ssl-cert, tcl8.3, unifont, w3c-dtd-xhtml, xaw3dg and xresprobe are on cd2 on powerpc atm
<mdz> fabbione: I know, that's a bug
<pitti> hm, the other CDs are pretty tight, too
<fabbione> it's all fault of the 33748 kernel flavours for ppc
<pitti> darn, I left at least 20 MB spare space when I added langpacks, what was going on there?
<fabbione> and the worst is that there is no workaround
<pitti> mdz: I will ask Kamion to build a new set of CDs after the langpacks are built
<mdz> I didn't think powerpc was so tight before
<daniels> powerpc's always been on a knife edge, no?
<mdz> pitti: what value did you use for the size of the CD when leaving 20M?
<pitti> mdz: 650*1024*1024, after cross-checking with Kamion
<pitti> i. e. I filled up to 630 MB
<mdz> pitti: Kamion has debian-cd set up to use something <650M
<pitti> hm, I asked him whether it was 650*1000 or 650^1024
<daniels> CD 1 filled with 612140294 bytes ... (limit was 614046105)
<pitti> erm, 600*1024, even
<pitti> mdz: current ppc is 631 MB (661094400 bytes)
<mdz> 659404800 is the size of the ISO
<pitti> mdz: so if the next round of CDs still doesn't fit, I throw out some langpacks
<pitti> ?
<mdz> pitti: you should be able to calculate whether it will fit
<mdz> pitti: that, or remove thunderbird
<mdz> I see no particular reason to put thunderbird on the CD
<mdz> pitti: langpacks approved
<pitti> thanks
<pitti> mdz: I calculate, but it takes a while
<mdz> pitti: I would rather remove thunderbird than langpacks, to he honest
* pitti nods
<mdz> or possibly even emacs
<pitti> MUHAHA
* seb128 slaps mdz
* pitti pats vim
<mkedwards> mdz: do you know whether the debian-installer/framebuffer=false trick to disable vga16fb probing will work on the livecd?
<daniels> mkedwards: should do, yes
<mkedwards> daniels: thx, will test and document on wiki (is there a hoary errata / tips & tricks page)?
<daniels> not that i know of
<mkedwards> bottom line seems to be that some hardware (especially laptops/DVI LCD) will fumble on vga16fb, others on vesafb.
<seb128> enrico: "Unofficial Ubuntu 4.10 Starter Guide" .. 4.10 ?
<mdz> seb128: I use emacs, but i don't mind downloading it
<seb128> that's on the yelp frontpage
<enrico> seb128: ?
<seb128> mdz: same here in fact
<enrico> How come it's there?
<seb128> enrico: open yelp, there is "Unofficial Ubuntu 4.10 Starter Guide"
<daniels> mkedwards: seems to be very few, thankfully
<pitti> mdz: new langpacks should save about 11 MB
<pitti> mdz: ^that's for ppc
<enrico> seb128: do you have ubuntu-faqguide installed?
<enrico> seb128: that package should NOT be around anymore
<pitti> mdz: saving is way bigger for i386 and amd64
<seb128> ii  ubuntu-faqguid 0.2-1          The Unofficial Ubuntu Guide
<enrico> seb128: I can't test that, as I'm not running Hoary
* seb128 dpkg -r
<enrico> seb128: that package should NOT be in Hoary.  If it is, it must be removed NOW
<seb128> fix the issue
<seb128> it is not
<enrico> At least the last 3 ubuntu-docs packages I uploaded aren't building that anymore
<seb128> I've probably it installed on my system for a while
<enrico> seb128: ok, good
<seb128> you have not conflicted with it
<daniels> seb128: any ideas on the panel stuff?  i have a running panel, and one that's continuously trying to start.  i get 'i've detected a panel already running, and will now exit', and every time i click ok, a new one comes up.  wasn't triggered by an upgrade or anything crazy like that.
<seb128> so nothing has removed it :)
<enrico> seb128: ok, makes sense
<seb128> daniels: gnome-session-remove gnome-panel
<mdz> pitti: CD 2 will only be filled with 4546532 bytes ...
<seb128> daniels: have you get a panel crash or something ? Sometime you run in a such situation
<daniels> seb128: now I have no panel running at all
<pitti> mdz: then this should be fine
<mdz> yep
<seb128> daniels: gnome-panel & :)
<daniels> seb128: ok, that's better, thanks
<enrico> seb128: I'm probably making a new upload, as new translated OMF files came in
<seb128> np
<seb128> enrico: there is a type fix for the french one, a sec
<daniels> argh!!!
<daniels> seb128: it's back!
<daniels> seb128: no crash this time, just the dialog boxes
<mdz> daniels: that happens to me when the panel crashes, but it only displays the dialog about 3 times
<mdz> after which it straightens itself out
<seb128> daniels: after doing what ?
<mdz> it's better to use 'close' rather than 'restart' with the panel, since it is respawned
<seb128> restarting the session
<daniels> seb128: g-s-r g-p, g-p &|
<seb128> g-s-r g-p, killall g-p, g-p &
<daniels> that *seems* to be better thus far
<pitti> infinity: mysql is in hoary now?
<mkedwards> will vga=ask force vesafb?
<infinity> pitti : Yes.
<seb128> enrico:     <version identifier="0.9" date="2005-02-28" description="First release for Ubuntu 5.4 Hoary"/>
<pitti> infinity: great, thanks
<seb128> enrico: that's "5.04", not "5.4"
<seb128> enrico: that's weird in this way because you have only line right and one wrong on the yelp frontpage
<Kamion> mdz: still up?
<mdz> Kamion: ah, yes, was just mailing you
<Kamion> mdz: sorry I'd gone to sleep by the time you replied to me about dosfstools; can we still sync that?
<enrico> seb128: what file?
<Mithrandir> is the new ooo in the archive?
<Kamion> I'm just catching up on mail
<enrico> seb128: so, all OMF files are to be fixed
<seb128> enrico: debian/about-ubuntu-*.omf
<pitti> Hi Kamion 
<enrico> seb128: release notes as well
<seb128> right
<Kamion> mdz: re #8287, the possibility that devices might be shuffled about asynchronously post-parted-commit still scares the shit out of me; I think a udevstart there would be simple, safe, and squash some bad bugs
<mkedwards> OK, I'll try various things tomorrow.  Sorry to be a pest about this whole text console thing; I'm rolling a livecd application demo for the day job's marketing department, they're pretty hot to trot.
<mdz> Kamion: I think it's too late for that kind of change
<mdz> and I don't see how it could have any bearing on the bug
<mkedwards> daniels: thanks for all the help.
<mdz> Kamion: I am treating this as final release prep; dosfstools doesn't make the cut
<mdz> Kamion: I regret bringing in the new upstream; we should have stayed with what we had
<Kamion> yeah :-/
<daniels> mkedwards: er, no worries
<mdz> we are still waiting for some builds, so if you feel strongly about it, we might be able to sneak it in, but we have enough to deal with already I think
<Kamion> the two possibilities I see for how it might affect #8287 are (a) ntfsresize reopens the device node assuming it won't have changed, rather than just keeping it open for the whole operation
<mdz> Kamion: I sent you email with a status update
<Kamion> or (b) ntfsresize was originally operating on a *different* NTFS partition
<mdz> upstream seemed to say that it kept the fd open
<mdz> I could see how it could be bad if it closed and reopened, but it would have exactly the same problem without udev
<mdz> the major/minor won't change
<mkedwards> typing blind into broken text consoles isn't the sort of thing I want to turn loose on the salesdroids.  :-/
<infinity> Ouch, that dosfstools bug is pretty crippling. :/
<mdz> mkedwards: fortunately, not a single other user has reported such a problem, so it seems quite specific to your hardware
<mkedwards> I'm impressed that ctrl-alt-Fn seems to work consistently, though.
<mkedwards> mdz: http://people.ubuntulinux.org/~mako/ubuntu-traffic/u20050121_22.html
<mdz> infinity: crippling in a sort of way which has no bearing on the usability of the Ubuntu installer or desktop, yeah :-P
<Kamion> I'm just fetching the source now to see what it does
<daniels> mdz: frigged-up laptop video BIOS
<infinity> mdz : Yeah, obviously.  Crippling for the package, not the dist.
<kent> Once i read something about Hoary comming with a quickintroduction to Ubuntu linux on after the first install.  Is this somthing that will happen for Hoary and can I test it now?
<mkedwards> mdz: per cjwatson, not so uncommon with LCD displays.
<mdz> mkedwards: with the possible exception of every LCD display we've tested with
<mdz> mkedwards: it's really not worth arguing about; it's far too late to do anything about it.  it needed to be reported a couple of weeks ago
<mkedwards> mdz: not really disputing that.  :)  not meaning to argue; just hunting a workaround, which I found in that thread.
<Kamion> "we"? (I have an LCD that demonstrates that problem)
<Lathiat> hrmm its a shame warty didn't pop up the upgrade dialog like hoary does
<Kamion> er, at least *a* problem, I haven't followed exactly what mkedwards is referring to
<mdz> Kamion: I have three, and they don't.  did you talk to daniels about this previously?
<Kamion> I boot with vga=771 and get on with my life, and it's fine
<daniels> Kamion: let me guess -- craptop?
<Kamion> no, because it's not an X problem
<Kamion> it's been that way forever (including warty), so not a regression. yes, craptop.
<Kamion> er, the slightly-less-craptop
<daniels> mdz: *fb is a kernel issue, and in this case it's a hardware issue.  as it says in the kernel traffic link, every possible solution will look like arse in at least some situations.
<mdz> Kamion: I thought that one was fine except for the corrupted boot logo
<daniels> Kamion: cheap imitation craptop?
<pitti_live> mdz: live/i386 rocks
<Kamion> daniels: yes
<Kamion> mdz: no, you have to boot with vga=771 or else the installer's display overflows the screen
<Kamion> and the corrupted boot logo is some other machine
<Kamion> the installer's boot screens document the issue; I'm not particularly bothered by it except to try to prevent it getting worse :)
<mkedwards> mdz: 80x24 would be rather safer than 80x30 (issue with VGA emulation and 128KB boundary)
<Kamion> mdz: ok, ntfsresize appears to check the return value of open() properly, so indeed it should notice if the device disappears while it's trying to open it
<mkedwards> daniels: Dell M60's a craptop in some respects, but not particularly cheap nor imitation.  :)
<Kamion> mdz: I guess we can fix it first thing for breezy
<pitti> seb128: did you deliberately not fix nautilus' behaviour when pressing backspace/selecting parent folder from menu?
<pitti> seb128: this kind of sucks
<tseng> pitti: its a forced change by sabdfl
<mdz> Kamion: synced dosfstools; might as well have something to do while oo.o builds
<mvo> Kamion: my older thinkpad need a vga=771 option too (but as you said, it's documented in the boot help)
<mkedwards> in any case, as I said, I now have two reasonable workarounds (vga= and framebuffer=false)
<tseng> pitti: instead of reverting it to fix the obvious lameness, he says "lets do it different in breezy"
<mdz> I need to get to sleep now
<mdz> Kamion: you have the info from elmo about the approval process, right?
<pitti> tseng: I know the sabdfl decision, I just don't know whether he also spoke about the backspace behaviour
<pitti> sleep well, mdz
<seb128> pitti: no, in fact I didn't even know have backspace when I've made the change ...
<mkedwards> mdz: btw, livecd is the best thing since sliced bread.  Thanks.
<tseng> pitti: he spoke about making an obvious way to go to the parent folder, for breezy.
<tseng> bug 8548
<seb128> pitti: and some way have no the "shift way" to modify stuff. Ie: you can't middle click to the places menu
<Burgundavia> that was filed out of 8516
<seb128> pitti: so the option is to give no way to user to keep the current folder open (which is not cool) or to let both opens ...
<pitti> seb128: backspace is the same as "parent folder" in the menu
<infinity> Well, I'm about to get kicked out of the library again, so g'night...
<pitti> night infinity 
<mkedwards> night all
<Mithrandir> night infinity
<seb128> pitti: let me set the broken mode, a sec
<tseng> bye.
<infinity> pitti : You'll see mozilla updates by Friday at the latest.  Big ones, I hope. :)
<pitti> cool
* infinity -> home/food/bed.
<seb128> pitti: right, that's a corner case bug
<mdz> Kamion: hope so
<mdz> night all, thanks
<seb128> 'night mdz
<mvo> night mdz 
<thom> infinity: oi! answer the question first!
* Mithrandir wonders where the ooo 1.1.3-8ubuntu2 i386 build is
<thom> night mdz
<infinity> thom : Err, "the question"?
<daniels> infinity: night dude
<infinity> thom : Did I miss something?
<Kamion> mdz: yes, I have the info
<thom> infinity: are you doing mozilla or firefox or both together?
<daniels> infinity: post-hoary food on weekend
<Kamion> to misquote Adam McKenna, "WAY TOO FUCKING MUCH COMMUNICATION"
<infinity> thom : Both.  And Tbird.
<thom> infinity: fair enough
<thom> i shall find something else to do then
<smurfix> nautilus-cd-burner exits when I click on "insert another disk" -- not the behavior I'd expect
<infinity> thom : Most of the issues affect both, so it doesn't make sense doing them seperately.
<infinity> thom ; And some also affect Tbird, so..
<thom> nod
<Kamion> mdz: oh, dosfstools appears to have got synced
<pitti> Kamion: darn, I just encountered the "wrong file system selected by default" bug in partman, *sigh*
<pitti> Kamion: too late for Hoary now, I guess
<Kamion> pitti: meh what? details, man
<pitti> Kamion: I select a partition with an already existing file system
<pitti> Kamion: and my goal is to use it as it is
<infinity> thom : Want something clever to do that would pay me back?... Write a patch for apache2, so that I can do something like "apache2 -S" and get the current PidFile from it.
* infinity goes now.
<pitti> Kamion: so if I go to the file system choice, my XFS partition defaults to "reiserfs"
<Kamion> pitti: none of my bugs mention any issue like that; please file one with details and /var/log/partman, and I'll look at it post-hoary
<pitti> Kamion: yes, will do
<pitti> Kamion: doesn't happen all the time
<jsgotangco> bye bye
* Kamion -> moving between sources of bandwidth, will be back well within half an hour
<Lathiat> daniels: hrmm, when you upgrade from warty does it just transition yoru old X11 config file?
<daniels> yyyyyyyyyyyyyyyeeeeeeeeeeessssssssssss ...
<Lathiat> daniels: because the horizsync/vertrefresh were wrong to run my resolution (1680x1050), has to make it regenerat eit from scratch to make it work.
<Lathiat> ahh hrmm
<Lathiat> guess warty detected the wrong values
<daniels> (#6672 notwithstanding)
<daniels> sigh
<daniels> what did it calculate the horizsync and vertrefresh as?
* Lathiat reads 6672
<Lathiat> (was just trialling out warty->hoary upgrade)
<Lathiat> daniels: ah, that wasn't my problem
<Lathiat> i was using the nv driver before as well
<Lathiat> that said on warty my display never came up right, ended up with a screen all of one colour
<Lathiat> root@dhcppc0:/etc/X11 # cat xorg.conf|grep -Ei "(sync|refresh)"
<Lathiat>         HorizSync       30-90
<Lathiat>         VertRefresh     50-60
<Lathiat> root@dhcppc0:/etc/X11 # cat xorg.conf.200504061853|grep -Ei "(sync|refresh)"
<Lathiat>         HorizSync       28-33
<Lathiat>         VertRefresh     43-72
* daniels blinks.
<daniels> and in XF86Config-4?
<Lathiat> root@dhcppc0:/etc/X11 # cat XF86Config-4 |grep -Ei "(sync|refresh)"
<Lathiat>         HorizSync       28-84
<Lathiat>         VertRefresh     43-60
<daniels> i don't know how the shit it ended up with 33khz
<martinald> hi
<Lathiat> something i can do to figure it out?
<daniels> that's for 640x480@60
<daniels> yeah, but it's kind of sucky
<daniels> dpkg --force-depends --purge xserver-xorg
<daniels> apt-get install xserver-xfree86
<Lathiat> i just whacked in my pressed warty cd installed, had to edit the X config to start in 1280x1024 to make it work but put it back to how it was after it started then ran an upgrade off the 0406.1 daily
<daniels> DEBUG_XORG_PACKAGE=developer DEBUG_XORG_DEBCONF=developer sudo apt-get install xserver-xorg
<daniels> and send me the full log
<Lathiat> ok
<daniels> ah, it doesn't carry over custom changes from warty
<daniels> if warty picked up 640x480, that's what xorg will try
<Lathiat> i didnt make any changes
<Lathiat> i restored the changes after i started it
<Lathiat> just i ended with a fucked display to start with
<daniels> hmph
<Lathiat> thats probably not helping
<Lathiat> it was all one colour like brown for gdm, if i logged in it went brown and then went white a bit after and seemed to be working
<Lathiat> daniels: does that dump a log file or to stdout?
<daniels> Lathiat: stdout
<daniels> and stderr
<Lathiat> it wont ask me any questions right? so i can just &> xorg.log ?
<Lathiat> mm its ok i'll just read the logfile for hwo to answer the question :)
<daniels> it shouldn't ask you any questions, no
<Lathiat> apt did but :)
<Lathiat> http://bur.st/~lathiat/xorg.log
<daniels> can you please open up /var/cache/debconf/config.dat and look up xserver-xfree86/config/display/mode-list, and same for -xorg?
<Mithrandir> lamont: can you check what has happened to the ooo i386 build?  It seems to be lost somewhere.
<Lathiat> Name: xserver-xfree86/config/monitor/mode-list
<Lathiat> Template: xserver-xfree86/config/monitor/mode-list
<Lathiat> Value: 640x480 @ 60Hz
<Lathiat> Owners: xserver-xfree86
<Lathiat> ^^ that?
<daniels> er, yeah
<Lathiat> Name: xserver-xorg/config/monitor/mode-list
<Lathiat> Template: xserver-xorg/config/monitor/mode-list
<Lathiat> Value: 640x480 @ 60Hz
<Lathiat> Owners: xserver-xorg
<Lathiat> Flags: seen
<Lathiat> and that :)
<daniels> hoary is valiantly preserving warty's 640x480 detection
<Lathiat> that would seem to me rather broken in general
<daniels> the fact that warty picked up on 640x480, or the fact that hoary goes with that?
<daniels> if the former, well, yeah -- that'd be why it's fixed in xorg
<daniels> if the latter, not really -- all we can do is work on the principle of least surprise
<daniels> 'your life wasn't interesting enough previously, so I made you a totally new X configuration.  enjoy!'
<daniels> anyway, anything past here is probably #ubuntu material
<HiddenWolf> mvo, ping
<mvo> HiddenWolf: pong
<HiddenWolf> mvo; I got another spiffy child terminated with 117 status error on my update just now
<Lathiat> daniels: well i was thinking more that if we fix autoconfiguration, it won't be used
<Lathiat> daniels: but i guess your right.
<mvo> HiddenWolf: with update-manager? or synaptic?
<Lathiat> upgrade seems to have gone pretty much perfectly which is good
<HiddenWolf> mvo, update-manager
<mvo> HiddenWolf: thanks
<martinald> i've got a simple request for the wiki, could it show the page name in the title? it's a pain when you have multiple wiki windows open
<HiddenWolf> mvo, for the record, that is using the latest update-manager, updated yesterday-morning.
<Lathiat> daniels: that said, regenerating config files is also bad
<daniels> well, yeah
<daniels> i'm hoping that we won't need to change X implementations every other week
<Lathiat> heh
<daniels> all the options are shit.  this was just least shit.
* Lathiat nods
<mdke> is the website auth down again?
<mdke> i can login on launchpad but not on ubuntulinux.org
<Lathiat> are there plans to detect a video card change / when gdm refuses to start to offer to try to regenerate a new config file and start again or something? (for breezy or the future or whatever)
<daniels> Lathiat: yeah
<Lathiat> some kind of recovery mode on the installer could also be cool, to reinstall grub and stuff
<Lathiat> well im off to try a direct ubuntu install now and see how that goes
<thom> mdke: are you matthew east? (utterly unrelated query)
<Kamion> Lathiat: boot with 'rescue', dude
<Lathiat> Kamion: oh :) i'll try that
* Lathiat bbs
* Kamion waves the retroactive feature request satisfaction wand
<mdke> thom, yeah
<mdke> thom, how come?
<thom> mdke: bug #7105
<thom> are you using en_GB, by any chance?
<mdke> thom, yes
<thom> score, i win.
<mdke> lol
<mdke> thom, want me to test anything
<thom> can you grab en-GB.jar from http://people.ubuntu.com/~thom/ and replace the one currently installed with it, restart firefox, see if the problems fixed
<mdke> thom, sure. how do i install it?
<thom> mdke: dpkg -L mozilla-firefox-locale-en-gb|grep jar ; sudo cp en-GB.jar to the location from the previous command
<martinald> id guess just put it in /usr/lib/mozilla-firefox/chrome
<martinald> o
<thom> martinald: /usr/lib/mozilla-firefox/extensions/{6c3a4023-ca27-4847-a410-2fe8a2401654}/chrome/en-GB.jar FYI :-)
<mdke> thom, you win
<mdke> thom, close bug
<mdke> :)
<thom> not fixed yet, but thanks for confirming
<mdke> oh
<mdke> well it works anyhow
<thom> (well, fixed, but not in hoary)
<mdke> ok false alarm about the website anyway
<mdke> i suck
<mdke> thanks thom 
<thom> "Welcome to Ubuntu Linux 5.04: The Hoary Hehdeghog Release"
<thom> we're so doomed
<daniels> you're shitting me
<daniels> where does it say that?
<thom> on the firefox home page! (/usr/share/ubuntu-artwork/home/index.html)
<pitti> argh
<thom> Kamion: can i upload a quick fix for ubuntu-artwork, pelase
<thom> uh, please
<Kamion> haha, just that typo?
<thom> yeah
<Kamion> yes
<kent> Whats the problem with ubuntu-artwork? I looked at index.html, and it seems ok. (Well, it does imply that Im now running final version of Hoary, but.. its just a few days left, does any one care?)
<daniels> kent: 21:35 < thom> "Welcome to Ubuntu Linux 5.04: The Hoary Hehdeghog Release"
<fabbione> Kamion: i would have say no and blame gtk!
<carlos> thom: I just saw that I'm not able to open firefox's preferences window...
<daniels> kent: there is no such animal as a HEHdgehog
<thom> carlos: restart firefox
<kent> dand, ah..  I see now :) That would be embarrasing ;)
<carlos> thom: I did it already
<carlos> I get a window with this text in red: 'title="&prefWindowUnix.title;"
<daniels> thom: lazy loldgehog
<thom> carlos: quit firefox entirely, delete XUL.mfasl in your profile, try again
<thom> Kamion: it's bug #8717 for reference
<Kamion> thom: yay for last-minute updates
<carlos> thom: fixed
<carlos> thom: thanks
<Kamion> jdub: what's the state of artwork? mdz said sabdfl promised artwork by 11am
<d3vic3> can I use sudo in chroot ?  
<Mithrandir> yes, if you have an /etc/sudoers in the chroot
<jdub> Kamion: coming
<d3vic3> keeps giving me this -> sudo: unable to lookup ubuntu via gethostbyname()
<Kamion> thom: perhaps jdub can simply roll it into his upload
<d3vic3> and the commands don't execute :-( 
<carlos> d3vic3: add a entry for "ubuntu" to your /etc/hosts file
<Kamion> fabbione: the saying no is good, we'll make you into a release manager yet
<jdub> Kamion: what's this?
<Kamion> jdub: 12:34 < thom> "Welcome to Ubuntu Linux 5.04: The Hoary Hehdeghog Release"
<Treenaks> sounds klingon
<fabbione> Kamion: ehehhe
<jdub> Kamion: aha
<thom> oh well, i just NMUd quickly
<thom> no other changes
<Mithrandir> hm, the x41 is out
<daniels> ooo
<thom> jdub: #8717 is the report
<daniels> does it have non-intel graphics?
<jdub> thom: mmm, seen now
<jdub> thom: you uploaded?
<thom> jdub: yes
<daniels> cock, still intel
<thom> jdub: ubuntu-artwork_0.2.23-2.1_source.changes
<daniels> heh, on pcie
<Mithrandir> daniels: Intel Extreme 2; http://www-1.ibm.com/support/docview.wss?rs=0&uid=psg1MIGR-58221&loc=en_US
<jdub> thom: .1? silly mans ;)
<daniels> Mithrandir: iirc that's i915, especially if it's on pcie
<Mithrandir> daniels: i915GM chipset.
<daniels> yep
<Mithrandir> daniels: looks like you can get it with ATI Radeon $mumble too
<Mithrandir> or that might just be a brain fart on the spec page
<kent> Is im the only one having problem with files not updating on desktop? I have to press ctrl+r for it to show files when i have downloaded them with epiphany, etc. Only files i create with nautilus shows directly.
<jdub> thom: can you plop the dsc/diff.gz somewhere i can grab them easily?
<jdub> thom: uploads have to be accepted, etc.
<Kamion> it's in queue/accepted, not showing for approval ATM though, I'm figuring I'll wait until cron.daily
<daniels> Mithrandir: no, you can't; that's only x3x
<Lathiat> hmm the installer doesn't tell you anymore that XFS is unsafe to have for / (without a separate /boot) which is a regression from warty (at the partitioning time, the error does show up on the debug console) and it then later tries to install lilo instead which also fails with "Error 1" (i couldn't find out what that was)
<Treenaks> Lathiat: the installer should be installing grub anyway
<Kamion> no it shouldn't, not for XFS
<Lathiat> Treenaks: well it tries to, and grub installer went: installing /boot on XFS is unsafe
<Kamion> Lathiat: the installer falls back to lilo automatically, which works for me
<Lathiat> Kamion: right, i got an "Error 1" here
<thom> jdub: http://people.ubuntu.com/~thom/
<Lathiat> Kamion: any idea where i can look for what that is?
<Kamion> nobody has provided any details
<Lathiat> there was no more verbose information on either console
<Kamion> Lathiat: switch to console 2, chroot /target /sbin/lilo
<Lathiat> heh i'll have to do another install run, i'll let you know how that goes in half an hour :)
<Kamion> sheesh
<Kamion> ok :)
<Lathiat> just gonna let this ext3 install finish and make sure thats all working good
<Kamion> wait until lilo-installer fails before doing that procedure, though
<Lathiat> i take it no ones written an xfs stage_1_5
<Kamion> lilo's output should really be redirected to /var/log/messages
<Lathiat> or it doesn't work or something
<Kamion> Lathiat: it's not that; it's too long a problem to explain here
<Lathiat> Kamion: ok :)
<Lathiat> is it described anywhere?
<Kamion> basically xfs doesn't actually sync when you tell it to
<Lathiat> oh right
<Lathiat> woo :)
<Kamion> it's probably in one of the installer bug reports
<Lathiat> i'll have  alook around later out of curiosity
<daniels> Kamion: was that it, though?  iirc freezing and then thawing didn't have the desired effect
<jdub> thom: thanks
<Kamion> daniels: it works if you "wait a bit"
<daniels> heh
<daniels> so even freezing doesn't actually sync.  ugh.
<Kamion> daniels: apparently not, it didn't do the job when Kinnison and I sat for a day and tried everything we could think of, anyway
<daniels> istr it not working for me, either
<Kamion> but it's bloody hard to debug, because it works "after a while" so you have to reboot for every test
<daniels> heh
<Kamion> so since lilo works for me I ignored it
<Kamion> Lathiat: are you booting with vga=something, or anything like that?
<Lathiat> Kamion: nope
<Kamion> because I know that's broken with lilo
<Kamion> er, lilo-installer, it's not lilo's fault
<Lathiat> nah everythign is stock standard
<Lathiat> well this install seems to have run fine for me, woot.
<zul> hey
<dholbach> T-None: ping
<Kamion> Lathiat: the ext3 one?
<Lathiat> Kamion: yeh
<Lathiat> so just, the install in general
* Kamion leeches off pub bandwidth while he can
<smurfix> jdub: Do we get a nice shiny new calendar background to go with the release? ;-)
<Lathiat> however my usb drive isn't getting mounted
<Lathiat> but it shows up in hal-d-m
* Lathiat hmm
<Lathiat> lathiat@dhcppc0:~$ gnome-volume-manager
<Lathiat> manager.c/124: init_usb_restriction: no matching storage configuration in /etc/multiseat.conf, exiting
<jdub> smurfix: not immediately with the release, no
<Treenaks> jdub: no april calendar then?
<jdub> Treenaks: not yet, no
<smurfix> jdub: awwww
<Kamion> elmo: 'helena -m approval' isn't showing me anything
<pitti> elmo: helena doesn't show me any warty-security uploads either
<daniels> Lathiat: does it exit immediately, or continue on?
<Lathiat> exits immediately
<Lathiat> and doesn't start on login, assumedly because of that (just rebooted again to test)
<Lathiat> shows up in xsession-errors
<daniels> you don't have a /etc/multiseat.conf at all, do you?
<thom> urk, i can see that here too
<Lathiat> i have one
<thom> and i do have a multiseat.conf
<Lathiat> i should note i dont have this issue on my current install
<Lathiat> http://bur.st/~lathiat/multiseat.conf
<fabbione> ehhhh???
<fabbione> how on earth did you get a multiseat.conf?
<Lathiat> i just did a fresh install
<Lathiat> off 20050406.1 daily
<Lathiat> i'm going to guess this also happened with my warty upgrade as i didnt see the dirve on the desktop
<fabbione> daniels: i have it too
<fabbione> but the code CANNOT run if you don't have at least 4 video cards
* fabbione summons Kamion "the d-i allmighty" to shed some light
<Kamion> sec
<daniels> thom: do you have anything from nvidia?
<daniels> thom: i.e. lspci -n | grep 10de: | wc -l -gt 0
<fabbione> daniels: remember that it checks for MGA and ATI too
<thom> my X40 install from the 30th doesn't, my amd64 from monday does
<Kamion> it pays no attention to ATI
<Kamion>         if [ ${LSPCINV} = "4" ]  || [ ${LSPCIMGA} = "4" ] ; then
<Kamion> which, incidentally, is a fucked-up idea of shell quoting
<thom> daniels: no
<Kamion> "let's quote precisely the things I don't need to quote"
* fabbione looks towards Australia...
<Kamion> nevertheless, I don't see anything obviously broken
<daniels> here's my nave diff to .prebaseconfig:
<daniels> +db_get multiseat-udeb/force_multiseat
<daniels> +if [ "$RET" = "false" ] ; then
<daniels> +  exit 0
<daniels> +fi
<daniels> +
<daniels> just before configured_heads
<daniels> because it seems to write a multiseat.conf rather unconditionally
<fabbione> well it does
<daniels> (obviously I haven't tested this at all)
<daniels> ... which it shouldn't?
<Kamion> oh, prebaseconfig
<daniels> Kamion: yeah
<Kamion> fuck, yeah, that's broken
<Kamion> yes, I think daniels' suggestion is correct
<Kamion> please upload that
<Lathiat> so what do i do, delete that file?
<Kamion> Lathiat: yes
<fabbione> Lathiat: yes
<Lathiat> works now
<Kamion> why is anything honouring that file, though?
<Kamion> the multiseat package shouldn't be installed
<fabbione> Kamion: g-v-m
<Kamion> ah
<Lathiat> its not installed
<fabbione> to isolate specific usb port per user/head
<fabbione> Kamion: otherwise when you plugin your usb stick with your gpg secret keys, it might be kinda automounted on the wrong head with the wrong user :)
<fabbione> just a little *TINY* detail
<Kamion> sure
<fabbione> so if that file exists, the deafult is to be secure and restrictive.. nobody mounts anything
<daniels> fabbione, Kamion: 0.9.9 on chinstrap:~daniels, please review
<fabbione> daniels: i think Kamion knows much better than me...
<daniels> fabbione: more pairs of eyes can't hurt
<daniels> debdiff is there too
<Kamion> daniels: ok
<fabbione> daniels: the db_set in postinst is for safety reasons?
<Kamion> (er, i.e. looks good)
<fabbione> daniels: otherwise it looks ok
<daniels> fabbione: yeah, to be doubly sure
<fabbione> fine by me
<fabbione> but Kamion needs to bless the upload
<Kamion> yes, only once helena works though ;)
<Lathiat> hmm synaptics repositories dialog is a bit broken, tho seemingly not in a way that causes breakage
<Mitario> goodday everyone
<mvo> hey Mitario 
<mvo> Lathiat: broken in what way?
<Lathiat> just adding extra lines to /etc/apt/sources.list that are already there
<Lathiat> actually it hasn't its just moved it and scrambled the order, and doesn't update source lines when non-source lines are updated and shuffles the lines around
<daniels> multiseat uploaded
<mvo> Lathiat: it shouldn't shuffle lines around 
<Lathiat> its a bit hard to make sense of what its actually done
<Lathiat> http://bur.st/~lathiat/sources.list is what happened after i hit add to add universe and muiltiverse for main, updates and security
<Lathiat> i think the lines are just out of order and confusing me so you can ignore it
<mvo> Lathiat: it keeps a copy in /etc/apt/source.list.save, can you diff it too?
<Lathiat> everything is ok just scrambled, seems to be in issue with archive.ubuntu.com vs the installed au.archive.ubuntu.com and deb-src lines not being updated -- but: http://bur.st/~lathiat/sources.list.diff http://bur.st/~lathiat/sources.list.reordered
<Lathiat> probably nothign to worry about at this stage
<mvo> Lathiat: yes, looks disordered, but not too bad
<Lathiat> yep
<Lathiat> sorry to hassle you
<Lathiat> mvo: never could get that warty bug to happen in any recent build so must of bene an old glitch/bug thats fixed, which is good.
<Lathiat> while i've got a fresh install up is there anything anyone wanted testing for workingness?
<Kamion> ok, ubuntu-artwork and multiseat uploads approved
<daniels> phat
<Kamion> enrico: you need to clear uploads beforehand; what's that ubuntu-docs upload?
<Lathiat> then i'll go redo xfs and try see what upsetting lilo
<lamont> Mithrandir: don't be so impatient
<lamont> (it entered the archive 2 minutes before you asked...)
<daniels> Kamion: we should probably mail u-d/u-u telling people to nuke multiseat.conf
<Mithrandir> lamont: oh, ok.
<Mithrandir> lamont: powerpc was finished a bit before that.
<Kamion> daniels: go ahead
<lamont> yeah
<Kamion> lamont: if you mean ooo, he was right to ask, it was stuck in NEW
<lamont> Mithrandir: powerpc doesn't build all the &*)_&* locales
<Kamion> lamont: I lisa'd it
<mvo> Lathiat: thanks for checking/reporting :)
<lamont> Kamion: ah, ok
<enrico> Kamion: do I?
<enrico> ok
* Mithrandir builds ooo-amd64
<Kamion> enrico: you also need to read ubuntu-devel :P
<Mithrandir> hooray for 200MB source packages.
<Lathiat> right, since no one has any quirks to test, i'll go try track down this xfs problem.
<Kamion> or the topic of this channel
* Kamion -> back home
<enrico> Kamion: sorry man, I'm doing things from almost disconnection here
<fabbione> Mithrandir: shut up.. you have 100Mb there.. it took 50 minutes to download them from here, when you jumped on irc
<enrico> Kamion: that is same as 0.6, but with more translated OMF files
<Mithrandir> fabbione: yeah, it's a bit slow.  I only get 1MB/sec to a.u.c now.
<enrico> Kamion: translated OMF files allow documentation to be linked in its translated form form yelp's TOC
<Lathiat> gnome mixer should really use the alsa mixer by default, especially since many people have the OSS mixer not show up the master channel
<enrico> Kamion: anything else you need to know?
<dholbach> lamont: do you have an idea, why kernel-patch-2.4-ipvs, kernel-patch-2.4-rmap are on archive.u.c but have no buildlogs and those plus kernel-patch-lpp is not apt-get-source-able?
<dholbach> s/is/are
<smurfix> Mithrandir: Your definition of "only" doesn't match quite everybody's, thank you very much :-/   ;-)
<jdub> ok
<jdub> who has a wide screen?
* smurfix raises hand
<Lathiat> jdub: I
<lamont> Mithrandir: actually, ppc is about 8 hours without the ccache hit, but all 3 buildds appear to be seeded.  The i386 build is 6 hours without, and landed on a machine that hadn't built it before
<Lathiat> (16:10 -- 1680x1050)
<jdub> ok, suck down one of these: http://people.ubuntu.com/~jdub/random/ubuntu-artwork_0.2.24-1_all.deb
<d3vic3> doko, ping 
<jdub> please check the login screens for sanity :)
<Lathiat> ok
<Lathiat> yeh i noticed that sucked at least on the ubuntu circle of friends one
<daniels> jdub: yes, not the sort you're after
<jdub> yeah, previous gdm didn't have yummy ratio aware scaling
<Mithrandir> smurfix: you don't maintain packages which have a source package about 200MB big and which needs a download of half a gig each time somebody changes _anything_ in the package it wraps.
<enrico> mdz: are there problems with that last ubuntu-docs upload?
<Mithrandir> lamont: isn't that weighted, so you'll give it to the same machine each time, if it's available?
<lamont> Mithrandir: as soon as launchpad is around
<smurfix> Mithrandir: true ...
<Mithrandir> lamont: ook.
<Lathiat> jdub: looks fine
<Lathiat> doesn't appear stretched
<lamont> Mithrandir: yeah, I wish it were...
<Lathiat> i'll try the circle of friends it more obvious in that
<jdub> Lathiat: yeah
<Mithrandir> lamont: should be a trivial change to wanna-build?
<Lathiat> eww
<lamont> Mithrandir: I could lock it down to one host per architecture, but do you really want to wait the extra 4 hours because another eternal package is already building when you upload?
<Lathiat> i switched back to my second gdm after changing the theme it complained it can't find the circle of friends background image
* Lathiat tries again
<Lathiat> yep definately broken
<Lathiat> circle.png isnt in there
<Lathiat> jdub: 
<Mithrandir> lamont: it'd need to fall back if the buildd was busy, I think.
<lamont> ah, then it's not so trivial
<jdub> Lathiat: eh...!
<lamont> posixtestsuite:         77:19:35 (1 entry, sigma 00:00:00)
<lamont> You have _GOT_TO_BE_F^$(^%)&**%^N_KIDDING_!
<Lathiat> jdub: its /usr/share/gdm/themes/HumanCircle/circle.png that is missing
<Lathiat> or it was renamed and not updated but i cant see the file in there under another name
<jdub> yeah
<jdub> sorting now, thanks
<lamont> 12 packages > 2 hours on i386
<Lathiat> nps
<Lathiat> i seem to be being helpful tonight, woo :)
<Mithrandir> lamont: that is "77 hours", right?  That's just Wrong.
<Lathiat> i'll go try sort this xfs bug out now, back in 20
<daniels> lamont: is one of the tests sleeping for 76 hours?
* Mithrandir runs off
<Lathiat> actually before i go
<Lathiat> daniels: programs crash with an XBadAlloc when trying to use overlays (nv driver) -- i've seen that before but it went away
<enrico> mdz: around?
<Lathiat> anything i can do to debug/get info on that or is it just broken?
<daniels> Lathiat: there's a bug open on fd.o about it somewhere
<enrico> if both Kamion and mdz are not around, who do I ask approval for uploads?
<Lathiat> daniels: ok
* Lathiat gone
<daniels> Lathiat: https://bugs.freedesktop.org/show_bug.cgi?id=474
<superted> does anyone know how the beagle packages are coming along?
<lamont> daniels: that must be it..  That or the left orphans around that hung dpkg --purge after the build that took me 2 days to notice
<lamont> was back in march
<lamont> s/march/november/
<daniels> yow
<lamont> anything else for me to check on before I crawl back into bed for an hour or two?
<mvo> enrico: mdz is alseep, but Kamion is around AFAIK
<enrico> if both Kamion and mdz are not around, who do I ask approval for uploads?  There are two more translations that came in
<fabbione> enrico: Kamion will be back pretty soon
<enrico> ok
<enrico> I hope I can be online for that long
<lamont> enrico: worst case, you push them somewhere fetchable and email him
<enrico> lamont: right, good idea
<lamont> just make sure the .changes are signed, etc.
<HiddenWolf> I just installed ubuntu-calendar, but the backgrounds are not selectable in the 'change background dialog' menu
<theine> Hi, since I updated Hoary teo days ago the xserver crashes when I log out of a remote ssh session with X11 tunneling enabled. I thought I mention it here considering the upcoming official release
<daniels> theine: doesn't happen for me, and in any case, this is the development channel
<theine> daniels: alright
* lamont goes back to bed for an hour or so - moble-pingable
<seb128> hum
<dholbach> i'll take a nap - see you later
<seb128> daily i386 install doesn't boot here
<seb128> "Hard disk boot sector invalid"
<seb128> (I've tried 2 times, daily from yesterday works fine)
<seb128> is that a known issue ? or maybe an issue with my CD ?
<Lathiat> seb128: which daily
<Lathiat> 0405 or 0406?
<Kamion> enrico: dude
<Kamion> enrico: I said I was going back home, and would be back shortly
<seb128> 0406
<Kamion> enrico: mdz is asleep
<Kamion> I am reviewing your ubuntu-docs change now
<Lathiat> this channel needs to have some weird name so people stop mistaking it for #ubuntu
<CarlK_> Lathiat - ops and voice seem in order
<Lathiat> CarlK_: well like there are legit reasons for people to come here
<enrico> Kamion: wait, there's a new one :)
<enrico> Kamion: it's just that the two -xh OMF files were untranslated and now they are
<enrico> Kamion: http://lento.uncasino.it/enrico/store/ubuntu-docs-1.0.tar.gz has the new packages
<enrico> My problem here is that I could be kicked offline at any moment
<Kamion> enrico: ok, that's fine, I'm not going to go download a .tar.gz to find out what it is though
<Kamion> enrico: I've approved 0.7-1, so please just upload, I can ignore it if it's bad
<enrico> Kamion: uploaded
<CarlK_> Lathiat - more on this some other time ;)
<enrico> I bumped the version to 1.0 so that everyone in the team agrees this is the last one :)
<seb128> Kamion: have you read what I just said about the daily i386 ?
<seb128> Kamion: it ejects the CD, reboot to configure the package but doesn't boot
<Kamion> seb128: I'll try it here in a bit, doesn't sound like anything that's changed recently though
<seb128> I'll record a new CD
<Kamion> enrico: ubuntu-docs_1.0-1 installed
<Kamion> jdub: ubuntu-artwork_0.2.24-1 installed
<jdub> Kamion: ta
<GheRivero> res
<jdub> morning GheRivero 
<enrico> Kamion: thanks a lot!
<Lathiat> Kamion: ugh.
<Lathiat> Kamion: didn't happen this time and i didn't do anything different :(
<caleb__> jdub: you around?
<Kamion> Lathiat: welcome to race conditions; aren't they fun?
<Lathiat> Kamion: yep
<Lathiat> might try it in vmware a few times see if i can make it happen again
<Lathiat> should have thought to run lilo-intsaller when it first happened
<jdub> hey caleb__ 
<Kamion> Lathiat: you wouldn't want to run lilo-installer itself, just the command I mentioned
<Kamion> I'll make it log more sensible stuff in breezy
<Lathiat> cool
<caleb__> jdub: do you have an xplanet config that you can share that you used in l.g.o/GnomeWorldWide?  Minus the individual coords of course.
<jdub> caleb__: not up, no
<caleb__> and sry that it's so off topic here :S
<jdub> caleb__: will putit in to cvs at some stage
<jdub> hoping the kde guys put theirs up, which seems more interesting
<jdub> then i'll rejig our one so it still works with the wiki data
<caleb__> url to their display?
<Riddell> jdub: phsysos said he would make it available for download, will check to see if he has
<pitti> re
<Lathiat> hmm packages.gz us md5sum mismatching atm, thats annoying
* Mithrandir kicks samba in the nutts
<Mithrandir> s/tt/t/
<d3vic3> O.O
<seb128> Kamion: is that ok to update gnome-utils to 2.10.1, that's a GNOME 2.10.1 tarball with few fixes and translations updates
<lunitik> seb128: you wouldn't happen to know the bug number for your installer issue? (or is there even a bug report?)  
<Kamion> seb128: what fixes?
<Kamion> mdz said we were done with GNOME 2.10.1
<seb128>   * Fix bug #172351, "Cannot open dia files" [Dennis] 
<seb128>   * Fix bug #168990, "Unable to open nautilus using magnifier" [Vinay M R] 
<seb128> doh
<seb128> I though today was the limit
<Kamion> 00:21 < mdz> we've got all the 2.10.1 we're going to accept
<seb128> graah
<seb128> the dia file is "open file from the search file dialog"
<Kamion> I'm prepared to look over a debdiff
<seb128> ie atm when you double click on the search result it doesn't open the file right
<mvo> Kamion: have you seen my patch for #8496 (apt-cdrom honors Acquire::gpgv::Options)? should we wait for mdz for it?
<seb128> Kamion: k
<seb128> lunitik: what ?
<Kamion> mvo: I haven't looked over the patch, and would prefer somebody who knows apt to do so
<lunitik> seb128: the issue you were discussing in #ubuntu ... he seems adament he'd like to help... rather then take from your time... a bug report would help him try to help  :/
<mvo> Kamion: so we wait for mdz :) ?
<Kamion> lunitik: what issue is this?
<seb128> lunitik: #ubuntu is not the right chan for that
<seb128> Kamion: daily i386 doesn't booting here
<seb128> "Hard disk boot sector invalid"
<Kamion> oh, that; I'm testing now
<seb128> I've recorded again the issue and same issue
<Kamion> French?
<lunitik> seb128: I understand... just want to point him at some text about the issue so he can try to be useful as he wants to so bad...
<seb128> s/the issue/the iso/
<seb128> Kamion: correct
<seb128> lunitik: I would prefer to deal that here with Kamion rather than doing ping-pong by bugzilla
<Kamion> anything else I should know? what filesystem type?
<seb128> default choises for all
<seb128> French for the language
<Kamion> ok
<seb128> default keyboard
<seb128> DHCP
<seb128> all the hdd
<seb128> it copies the files, ejects the CD and doesn't reboot
<seb128> ie: fails to boot
<lunitik> seb128: understandable  :)
<mvo> Kamion: one last question: what about http://people.ubuntu.com/~mvo/review/update-manager/update-manager_0.37.1+svn20050405.debdiff.short? any chance for it? it fixes the problem that update-manager does not pick up the synaptic proxy when downloading changelogs?
<Kamion> seb128: any chance you could boot with rescue and have a poke around?
<seb128> Kamion: what should I look for ?
<Kamion> seb128: dunno, see if the filesystem works, see if 'grub-install (hd0)' fixes it, ...
<Kamion> mvo: does SYNAPTIC_CONF_FILE get substituted with something more sensible?
<seb128> Kamion: k
<mvo> seb128: the partion table maybe? I have seen that in the past
<mvo> (also my install today was fine)
<jbailey> doko!
<Kamion> mvo: it's a bit scary; have you tested it both with/without configured proxy?
<CarlK_> crap - 2nd phase of install, some "failed" message just scrolled by something like "setting up fonts, failed to install...." - where are these messages logged?
<Kamion> CarlK_: /var/log/base-config.log
<CarlK_> thanks
<mvo> Kamion: I did, should be fine. and yes, I'm not overly happy about it too. if we leave it as it is, the user needs to set http_proxy to get working changelogs in update-manager behind a proxy. not too bad, but not nice either.
<Kamion> CarlK_: that message is probably harmless though, fontconfig will sort it out when it actually gets installed
<Kamion> CarlK_: there are already bugs about that
<Kamion> mvo: oh, and does adding the shortcut on Settings affect translations?
<Kamion> seb128: oh, also maybe dd the boot sector and see what it looks like
<Kamion> (using 'od -tx1' or similar)
<mvo> Kamion: hrm, right (about the settings shortcut). I didn't noticed because that was fixed in gnome-cvs already for a couple of languages (including german)
<mvo> Kamion: I think you convinced me to bite the bullet and leave it as it is
<Kamion> mvo: which, _Settings or the whole thing?
<Kamion> I think I could be persuaded to accept the proxy change
<Kamion> it looks straightforward
<mvo> Kamion: ok, that would be cool. I'll do another round of tests and prepare a package then with only that patch and a debdiff. sounds ok?
<ska-fan> Can I rerun the menu.lst generation that takes into account the other os's on the hard drive? When I installed ubuntu there was a bug that didn't detect the fedora installs correctly and I want to test whether the fix for that bug works for me.
<Kamion> mvo: yep
<ska-fan> Otherwise switchers from fedora will be unhappy :)
<Kamion> ska-fan: unfortunately not
<Kamion> ska-fan: do you have a scratch partition you could use?
<ska-fan> to install ubuntu on? yes.
<Kamion> I'm afraid that's really the only option for testing that - it would be nice if os-prober and the bootloader installers were usable from a real system, but at the moment they aren't
<Kamion> I hacked up a sort of test harness when I was fixing that bug, but it's not really the same ...
<AndyFitz> I keep wondering why there arent new gaim packages made since 1.1.4 . is there a reason ? 
<thom> AndyFitz: upstream version freeze
<AndyFitz> thom,  oh yeah.   now it seems like a stupid question
<thom> AndyFitz: and all reports suggest the later versions have sucked fairly hard, too *shrug*
<ska-fan> Kamion: Oh, so that's you :)
<AndyFitz> http://packages.debian.org/unstable/net/gaim  hrm  ill try the version here
<ska-fan> What's the smallest iso image to try that out?
<Kamion> ska-fan: we only do full CDs I'm afraid
<AndyFitz> thom it seems to be working fine. . ill probably notice changes later
<Kamion> seb128: works for me
<lunitik> *cough*there should be net inst images*cough*
<lunitik> :P
<Kamion> *cough*yes, I'm too busy*cough*
<lunitik> Kamion: haha... fine be like that  :P
<seb128> Kamion: grub-install /dev/hda doesn't fix the issue, I'm rebooting with the rescue mode
<Kamion> seb128: also look for grub errors in /var/log/installer/
<seb128> k
<seb128> but the grub output for the rescue shell had no error
<CarlK_> base-config.log lines end in 0a0d ... that worth bugging?  
<Kamion> lunitik: also we won't ever actually publicise netinsts, since having two parallel sets of images would just lead to confusion; if they ever exist it'll just be on an if-you-know-about-it basis
<Kamion> CarlK_: no
<Kamion> CarlK_: (that's just how script(1) works)
<seb128> Kamion: http://pkg-gnome.alioth.debian.org/gnome-utils.debdiff if you want to have a look on the gnome-utils changes
<Kamion> seb128: also check that /boot/grub/device.map is right
<seb128> k
<CarlK_> ok.  "no" is plenty - don't need explanations today ;)
<Kamion> an 846k debdiff?!
<lunitik> Kamion: alright, well, if they ever do get created, let me know alright  :)  (ps, is cdimage.ubuntu.com hidden enough? its not on the main page  :P )
<CarlK_> lunitik - I figured it out ;)
<Kamion> lunitik: whatever, I don't have time now, sorry
<seb128> Kamion: GNOME l10n keep moving
<seb128> Kamion: I can make a diff on the code if you want
<seb128> device.map:
<seb128> (hd0) /dev/hda
<seb128> looks ok
<Kamion> seb128: ok, if you've tested that, go ahead and upload
<seb128> k, thanks
<seb128> the syslog content looks right
<seb128> Installing on '(hd0)'
<seb128> running chroot /target /sbin/grub-install --recheck --no-floppy ''(hd0)''
<seb128> grub-install ran successfully
<Kamion> meh, we always download language pack updates on install
<Kamion> fortunately I guess they aren't huge
<Kamion> pitti: I assume you won't be changing l-p-*-base post-release
<pitti> Kamion: right
<seb128> Kamion: what is the way to do uploads ?
<pitti> Kamion: unless there are so many updates that the update packages become too big, that is
<Kamion> seb128: as normal, they'll get held for approval
<seb128> hum
<seb128> Connection failed, aborting. Check your network (111, 'Connection refused')
<Kamion> erm
<Kamion> check your network? :-)
<seb128> works fine
<Lathiat> haha
<seb128> pinging the box works fine
* Lathiat bets that was python code
<Kamion> Lathiat: dput
<seb128> ---- Connecting to upload.ubuntu.com (82.211.81.140) port 21
<seb128> **** Socket error (Connection refused) - reconnecting
<seb128> with lftp
<Kamion> hmm, I think poppy fell over
<daniels> daniels@catsby:~/tmp% lftp upload.ubuntu.com
<daniels> lftp upload.ubuntu.com:~>
<seb128> daniels: ls ?
<daniels> yeah, just realised that; never mind me
<seb128> :)
<Lathiat> heh
<Kamion> oh, jackass ran out of disk space
<Kamion> that would also explain other errors
<zul> hehe
<Kamion> ok, technically I *could* fix this, but I really don't want to break stuff
<fabbione> amen
<lamont> Kamion: now I know that we _MUST_ be really close to release. :=(
<Mithrandir> uhm, this means you'll be "unhappy" with a ooo-amd64 upload ATM, right? :)
<Kamion> Mithrandir: well, it won't work ...
<Kamion> I'll SMS elmo with a plaintive cry for help as soon as my phone is sufficiently charged to manage that
<thom> Kamion: i'm just about to call him
<Kamion> ok, thanks
<seb128> Kamion: permission to fix #8175 (meeting/calendar entries breakage for evo), the patch is: http://bugzilla.ximian.com/showattachment.cgi?attach_id=14727
<Kamion> seb128: can I have the bug reference too?
<seb128> #8175
<seb128> http://bugzilla.ximian.com/show_bug.cgi?id=73844 upstream
<thom> Kamion: he says he'll randomly delete some stuff
<thom> ;-)
* thom utterly misrepresents phone call for comedic effect
<daniels> '/srv?  what do we need that for?'
<fabbione> Kamion: i need to go off-line for approx one hour (if not more) in 30 minutes from now. Is there anything you need me to do before that?
* thom is out till much later now
<Kamion> fabbione: shouldn't be
* Mithrandir finds his laptop, so he can sign and upload ooo-amd64 soonish
<fabbione> Kamion: ok. you can ping me via sms if it is something urgent but it will still take me a few minutes to come back online. I need turn off everything in the house and reconnect to the proper electric panel
<Kamion> fabbione: wtf are you doing? :)
<daniels> Kamion: he's had blackouts and stuff at his place
<fabbione> Kamion: this morning there was an electric outage in the central and i lost one phase
<fabbione> Kamion: so i rerouted all the stuff to keep the computers on and work
<fabbione> now i need to put it back
<fabbione> and rebalance the loads on the line
<fabbione> lines
<Mithrandir> fabbione: scary.
<fabbione> Mithrandir: yes.. half of my house was without power.. i almost fainthed 
<elmo> fixed jackass
<fabbione> specially because everything looked ok from the panel
<elmo> kamion: ^--
<lamont> elmo: used that magic rm -rf /, eh? :-)
<ogra> fabbione, they are still on it ?
<Kamion> elmo: thanks
<fabbione> ogra: no, they fixed after a couple of hours
<ogra> ah
<fabbione> ogra: but to shutdown everything here, it takes quite sometime
<ogra> heh, i can imagine, yeah
<fabbione> specially to pray that everything will come back as it should :)
<fabbione> 59 minutes of pray
<fabbione> 1 minute of real operations :)
<ogra> :)
<elmo> Kamion: did you get approval sorted?
<Kamion> elmo: yep, apart from 'helena -m approval' not working, but I just worked around with ls
<fabbione> i just need to wait for my wife to go out of the way while i will yell and scream in the datacenter
<Kamion> kelly -z works fine
<elmo> hmm, ok
<Mithrandir> Kamion: it makes so much sense when you go about talking about programs with nonsensical names... "how about if you try cindy -w"? :P
* lamont disappears for a little bit while he gets ready and goes to the neighbors for bandwidth
<elmo> DO NOT RUN CINDY
<elmo> cindy and ubuntu are not friends
<Mithrandir> what does cindy do?
<elmo> I know you were just joking, but that's a really bad example
<Kamion> # NB[3] : cindy ENTIRELY breaks for 'source-only'-upload based distros
<Kamion> # like Ubuntu.  Go Cindy.
<Kamion> 'k
<Mithrandir> elmo: sorry.
<Kamion> I assume it like clears out the override file or something
<elmo> Kamion: pretty much, yah
<mdz> morning
<daniels> mdz: 'morning
<fabbione> morning mdz
<mvo> morning mdz 
<Kamion> mdz: morning
<Mithrandir> mjg59: moo?
<ogra> hi mdz 
<smurfix> ... it always being morning *somewhere* in the world ;-)
<Kamion> seb128: you should be able to do that gnome-utils upload now
<Kamion> mvo: update-manager upload?
<Mithrandir> mjg59: lately, my kernel seems to report 1/10 of the charge level of my battery.  Fixes itself if I run acpi -V twice, then comes back after a while.
<Mithrandir> mjg59: x40, acts the same for all batteries, so it's not the battery acting funky.  AC/non-AC doesn't seem to matter.
<mvo> Kamion: will do it now (with only the reviewed change). ok?
<Mithrandir> mjg59: any ideas where to start debugging?
<Kamion> mvo: yep
<fabbione> Mithrandir: he will tell you.. from the kernel :)
<mdz> Kamion: how do we stand?
<seb128> Kamion: already uploaded, thanks :)
<pitti> Hi mdz 
<seb128> Kamion: and about the 1 line evo patch ?
<mdz> oh, we managed to fill jackass? wooo
<seb128> hi mdz
<elmo> to be fair my insane backup "strategy" did
<Kamion> seb128: evo> ok
<Mithrandir> hmm, does gnome have any sort of "location" concept?  So you can have different settings if you're at work than if you're at home than if you're on a wireless, travelling and so on?
<seb128> Kamion: thanks
<mvo> Kamion: thanks
<seb128> Mithrandir: no
<ogra> Mithrandir, defining your next project ? :-P
<Kamion> mdz: remaining to upload are mvo's update-manager fix (proxy/changelog breakage) and seb's evo vcal fix; artwork's in, rest looks ok
<Mithrandir> seb128: do you know if it plans to grow one?
<seb128> not afaik
<jbailey> Mithrandir: The closest thing is that the network thing had profiles you could choose.
<Mithrandir> seb128: because nobody has had interest or because it's nongnomeish?
<Mithrandir> jbailey: yeah, that would be an obvious input.
<jbailey> Mithrandir: But it didn't attach proxy settings to it, or anything interesting like that.
<mvo> Kamion: upload finished
<seb128> probably because that's not something really asked by the userbase and there is a ton of other stuff to do :)
<Mithrandir> ogra: I kinda want it for tpbd
<ogra> ah 
<jbailey> Mithrandir: As it is, running aps often don't notice that proxy settings have changed, so there's probably a metric assload of work to do to make that work.
<Mithrandir> so buttons can do different things depending on where you are.
<Mithrandir> jbailey: yeah, I imagine there would be a fair amount of work to get it working well.
* Mithrandir gets _really_ evil ideas.
<fabbione> Mithrandir: i think they first need to rewrite gnome from scratch :)
<fabbione> and try to get rid of a few (thousands) memory leaks
<elmo> argh, lost my .bash_history.  unix stuff really doesn't handle ENOSPC well
<mdz> gah, I said yes to that update-manager proxy thing 24 hours ago
<Mithrandir> this could integrate with, say, whereami and have the automounter use dbus so you'd automatically mount your home shares when you're home.
<Kamion> mdz: it's uploaded now anyway, just kellying
<Mithrandir> fabbione: heh
* Mithrandir wonders if he should continue or if he's going to be put into mental hospital at UDU
<mdz> Kamion: I'd hoped to have CDs built by now; it sounds like we are not much closer than we were when I left
<fabbione> Mithrandir: the latter :P
<Mithrandir> fabbione: you haven't heard my plans for mount yet. :D
<fabbione> ahaha
<ogra> elmo, from my POV dholbach s MOTUOTU, i reviewed the morgue list, everything listed there is fine with me, just dump it :)
<ogra> s/s/is
<mvo> mdz: there is also the fix for #8496 pending ... (I almost don't dare to mention it :/
<Kamion> I think #8496 loses
<mdz> mvo: I know
<mvo> mdz: I overlooked it yesterday, I'm very sorry 
<mdz> mvo: if I had known that update-manager would have taken 24 hours, I would rather you had spent that time preparing and testing #8496
<mdz> which is a major bug
<mdz> while the proxy thing is not
<elmo> maybe we should give up and just hax0r our gpgv to ignore time conflicts</half joking>
<Kamion> unfortunately I was not comfortable reviewing #8496, I'm afraid; I don't know apt internals at all
<mdz> Kamion: how about we stop signing the CDs instead
<Kamion> mdz: frankly I'm far more comfortable saying "sorry, you lose if your clock is set to 1990" than I am with changing that now; too much breakage with apt's signature support has happened in the past
<mdz> out of all the "one more thing" uploads which have been pressed since yesterday, none had as much impact as #8496, which prevents people from installing Ubuntu at all
<Kamion> and surely apt will just bitch endlessly about authentication warnings; I'm pretty sure not every last piece of code that calls apt turns that off
* Mithrandir gives jackass love.
<daniels> strange idea of 'love' you have
<mdz> and it fails in a completely random way, midway through the process, with an unhelpful error dialog
<Mithrandir> daniels: ramming a 250MB file onto her, you mean?
<mdz> seb128: what is this vcal fix and how long will it take?
<seb128> <seb128> Kamion: permission to fix #8175 (meeting/calendar entries breakage for evo), the patch is: http://bugzilla.ximian.com/showattachment.cgi?attach_id=14727
<seb128> <seb128> http://bugzilla.ximian.com/show_bug.cgi?id=73844 upstream
<seb128> I'll upload it within 5 min
<mdz> mvo: where is the patch for #8496?
<mvo> mdz: it's in my tree and in the bugreport
<Kamion> the patch is in #8496
* fabbione starts the shutdown procedure
<mdz> mvo: references to the return value of c_str() are invalid when the string object goes out of scope
<mdz> no?
<mdz> jdub: what happened to the firefox homepage update?
<mvo> mdz: yes. you think about the if(Opts!=0) {} scope? or am I overlooking someting?
<seb128> mdz, Kamion: evo uploaded
<pitti> mvo: can Args become invalid at the point when the " Opts = _config->Tree("Acquire::gpgv::Options");" scope ends?
<mvo> pitti: when opts goes out of scope, yes, but it does not get out of scope before the execvp
<mdz> mvo: I mean the temporary
<Kamion> what about the string().c_str()?
<pitti> mvo: hmm, execvp should copy its arguments, so this should be fine
<mdz> mvo: string(foo).c_str() would never be valid
<mdz> except for the duration of that statement
* Kamion squeezes new ubuntu-artwork down his pipe to see what the homepage looks like
<pitti> mvo: bah, mixing c++ strings with C strings is even scarier than using C strings alone...
<mvo> mdz: arggg, right. fixing that now
<Kamion> evolution, openoffice.org-amd64 installed
<pitti> mvo: maybe you should write a C++ wrapper around execve() 
<pitti> if you need this often
<Kamion> this isn't the time for new infrastructural code surely
<mvirkkil> Has the Firefox vulnerability in 1.0.2 been patched? Will Hoary ship with it unpatched?
<Kamion> mvirkkil: please see the changelog
<Kamion> +  * Apply patch from moz: 288688; Ubuntu: 8611
<Kamion> +    JS "lambda" replace exposes malloc heap space after end of JS string
<ogra> mvirkkil, vulnerability are always pathed, even after release....
<ogra> +s
<mvirkkil> ogra: Of course, but I was wondering if it might delay hoary. But I see it wont, so nevermind.
<ogra> mvirkkil, maybe we are a bit slow with the graphics design, but our security team has proven to be one of the fastest ;)
<fabbione> mdz, Kamion: i am going offline now... SMS for emergencies.. irclogs will go down with me.
<pitti> fabbione: I log everything, too
<pitti> fabbione: so if you want have scrollback, ask me
<fabbione> pitti: nah..
<fabbione> it's just FYI :)
<mdz> fabbione: is ubuntulog going offline too?
<fabbione> mdz: yes
<mdz> ah, you mentioned that
<fabbione> mdz: if you didn't read the scrollback i need to recable the power at home
<fabbione> it will take me ~1 hour
<fabbione> hopefully less
<Kamion> mdz: homepage update seems fine
<fabbione> ok.. later guys
<Kamion> unless there's more than the warty -> hoary bit
<mdz> Kamion: there was supposed to be a new homepage with the updated website CSS
(mdz/#ubuntu-devel) yay for last-minute cvs snapshots that ftbfs
(mvo/#ubuntu-devel) elmo: could you please have a look why lists.ubuntu.com does not accept http connections (when you have time for if, not urgent)
<elmo> mvo: lists.ubuntu.com isn't run by me, I don't even have a logon, sorry
<Kamion> elmo: no, it's really hard, those questions inherently rely on the base system being installed at the moment
<mvo> elmo: is that jdubs machine?
<elmo> mvo: he has a logon at least, yeah
<elmo> kamion: ah, ok
<mdz> only 18 hours per DVD image to get me up to date, whee
<lamont_r> lol
<mdz> that will certainly make it difficult to test DVD images before the release ~36 hours away
<Kamion> elmo: (as in, they chroot into /target and run stuff there which uses tools not in busybox)
<Kamion> plus the DVDs were last built on Tuesday ...
<fabbione> amen
<fabbione> this was really bad
<mdz> elmo: can you overnight me some ISOs?
<fabbione> how are we going?
<Kamion> install CDs are built, btw
<elmo> mdz: it'd be quicker
<elmo> well, if I were in london it would be
<mdz> oh, I thought you were
<elmo> I'm meant to be on my way - just haven't quite managed to leave yet
<lamont_r> mdz: you just need a loopfs machine in the DC to mount the dvd image on, get the ordered contents of the CD, and then seed your rsync image from your local mirror :0)
<doko> pitti: no, it only contains the code, not the language strings. I just finished a new merge, and build a new ooo-l10n-xh package. my idea is to put this one in it's own source package.
<pitti> mdz, doko: Now I tried for half an hour to get OO.o-l10n-xh running, on both i386 and ppc, no success
<pitti> doko: argh... good to know this eventually, I was already banging my head
<mdz> pitti: ok, then it should be quite safe then ;-)
<pitti> mdz: with the package in the archive, I only get C strings
<doko> banging his head should be safe ;-)
<ogra> heh
<pitti> mdz: what do you mean by safew?
* pitti pats his skull
<pitti> I'm in an environment where each and every string is unintelligible (good work, Adi :-) ), BUT OO.o :-/
<mdz> pitti: if it does not actually contain any translation data, it cannot possibly break oo.o
<ska> Kamion: Do the isos from march 30 include the fix for menu.lst generation?
<doko> heh, to try to navigate I always had another OOo running in non xhosa ...
<pitti> mdz: hehe
<mdz> Kamion: estimated 3 hours per CD image to get them here
* pitti boots back to normal system
<mdz> something is fucked between me and the DC
<Kamion> ska: yes, should have
<ska> Ok.
<mdz> less than 50kbyte/sec
<mdz> this is unfortunate timing
<Kamion> Ubuntu daily-live building
<Kamion> pitti: the CDs don't seem to have overflowed this time
<pitti> Kamion: the new langpacks should have saved about 11 mb on ppc (more on the other archs)
<pitti> Kamion: thanks for checking
<pitti> Kamion: so the limit is indeed 650*1000 bytes?
<pitti> Kamion: I vaguely remember having asked you about this already
<Kamion> should be
<Kamion> ah, no, 640*1024*1024
<Kamion> it can't be entirely accurate
<Kamion> (without better mkisofs integration) because you lose some space to ISO9660 indices and boot sectors and stuff
<lamont_r> pitti: DVD's are 4.7*1000^3
<lamont_r> damn marketing people, anyway
<Kamion> hmm, debian-cd is currently set to 4600*1024*1024
<lamont_r> that's 4.8G... 
<Kamion> daily-live finished
<Kamion> lamont_r: yeah, I was just following the comment from upstream ...
<mkedwards> Kamion: is livecd ready to resync?
<Kamion> mkedwards: yes
* lamont_r back in a minute or 5
<elmo> hmm, is 20050406.1 candidate-ish?
<elmo> not are-we-there-yet-ing, I just need to install _something_ on my laptop before I go
<mdz> elmo: -ish, yes
<mdz> though as far as I'm aware, no one has been able to test it yet
<mdz> my download is fucked
<elmo> ok, I'm mid-install on ppc
<astharot> elmo: who is the manager of ubuntu mail servers ?
<mdke> jdub is the boss of those
<astharot> shit.
<astharot> jdub ?
<elmo> astharot: lists.ubuntu.com?
<elmo> if so, then jdub
<mvo> astharot: probably sleeping
<astharot> elmo: yes, but not mailman..
<astharot> I mean the MTAs
<elmo> why?
<mdke> astharot, oh sorry
<astharot> because I have problems getting mails... probably you have problems sending mails to my mailserver :)
<astharot> no answer :P
<elmo> hmm, my laptop makes interesting 'ping-ing' noises when booting up, I dunno if that's the repair or hoary :/
<Kamion> elmo: try 'nvsetvol 0'
<mdz> astharot: postmaster@<domain> is usually the best contact for such issues
<elmo> kamion: oh, right, I zero'ed the prom settings as part of the testing with apple
<astharot> mdz: I know... but I thought that here could find someone :P
<mdz> astharot: we're quite busy preparing the release at the moment; since this isn't urgent, email is better
<mkedwards> rsync is not doing its magic on this livecd.  :(
<Kamion> there were a lot of changes in the install CD
<Kamion> new base language packs, new openoffice.org
<Kamion> so I imagine the live CD will be just as bad :-/
<mkedwards> I spoke just too soon ... starting to see bursts of race now.
<mdz> mvo: still here?
<mvo> mdz: yes
<mvo> mdz: just finished rsyncing the current install image and will do a test-install now
<mdz> mvo: please prepare a fix for that cron.daily bug; if we find a bug which requires building new images, we may as well include it then
<mdz> mvo: so have it ready, but don't upload unless these images are no good
<mvo> mdz: ok, doing that now
<mdz> mvo: thanks
<mdz> 24 minutes to get hoary-install-amd64; this is going to be a long day
<mdz> Kamion: would you post a call for testing to -devel and -users?
<elmo> successful install of 20050406.1 on a Powerbook, FWIW
<HiddenWolf> mdz, be lazy, do a /notice to #ubuntu. :)
<zul> then you only get irc users
<HiddenWolf> I'll rsync my image and do a test-install on amd64
* lamont_r is up to 80% of the first of 4 isos
<mdz> HiddenWolf: thanks
<Kamion> mdz: sure, are torrents working though?
<HiddenWolf> mdz; np, reserved a few extra partitions for this kind of thing. 
<tritium> I can run to the on-campus store and try the LiveCD on a G5
<HiddenWolf> I'd test more if my bandwith allowed. :S
<Ben2004uk> hey all
<mdz> Kamion: I'll check
<mkedwards> will torrent livecd in us as soon as rsync is done
<mdz> Kamion: they don't seem to be working yet, no
<mdz> thom: are you here, or do I need to call you?
<mvo> mdz: package prepared http://people.ubuntu.com/~mvo/apt_0.6.35ubuntu2.debdiff
<elmo> mdz: lemme check first
<mdz> mvo: thanks
<elmo> mdz: what isn't working?
<elmo> I can see daily-live/20050406.2 on there for example
<mdz> elmo: I opened it with gnome-btdownload, waited a minute, and had 0 bytes downloaded
<mdz> I was testing daily/current/
<mvo> same here
<HiddenWolf> why does 'uptime' tell me there are four users logged in?
<dholbach> elmo: in addition to the mail i sent you: hping3 sync from sid is in order, just supersede our changes
<dhonn> you probably have terminals opened hiddenwolf
<HiddenWolf> Ah. weird.
<dhonn> close them
<dhonn> killall gnome-terminal
<HiddenWolf> dhonn: one for x, one for gnome, others for terminals?
<dhonn> one user is u on x
<dhonn> that includes gnome
<Kamion> mdz: install-i386 looking good so far, I'm off for dinner while other images rsync
<Kamion> my phone is with me (and this time won't run out of battery); failing that I'll be back in two hours
<dhonn> if you open a gnome-terminal you will have logged on that terminal again, its weird but thats how it works
<Kamion> HiddenWolf: use 'w' to see the list
<mdz> gah
<mdz> the help topics for the release notes are not in English
<mdz> enriiiiiiicoooooooooooooooooo
<mdz> Kamion: install-amd64 successful
<mdz> but I think this help topics thing is a show-stopper
<mdz> has anyone else done an install from the current images?
<mvo> mdz: I am currently installing, the machine is not the fastest
<mdz> I would like to know if this yelp problem affects everyone
* jnc :)
<mvo> mdz: I will reboot into the live-cd now to check
<elmo> mdz: confirmed on powerpc
<jnc> btw i would like to point out a rather big trouble on amd64 hoary, before you cats release it;   namely, OpenOffice printing does not function properly
<dholbach> lamont: what has to be done to get dietlibc built on amd64 as well (apart from changing the architecture: field)?
<lamont_r> dholbach: PaS
<dholbach> lamont_r: who could do that? it builds fine and some packages depend on it
<lamont_r> me, elmo,
<lamont_r> generally me these days
<jnc> is the developer whom handles amd64 OpenOffice a frequent user of IRC/
<jnc> i meant that as a question, ?
<lamont_r> dholbach: it is amd64... 
<lamont_r> elmo:  what version of PaS does jackass have?
<dholbach> lamont_r: oh cool, will upload a changed version then
<elmo> lamont: dunno, but it's not as if I can update it ATM
<elmo> # $Id: Packages-arch-specific,v 1.552 2005/03/30 06:40:10 lamont Exp $
<lamont_r> 1.555 is current
<lamont_r> pls check and update
* elmo beats lamont with gluck's RAID array
<zyga> ;] 
<zyga> hyhy
<lamont_r> elmo: emailing
<lamont_r> sent
<mdz> seb128: are you here?
<seb128> mdz: yep
<mdz> seb128: can you look at the problem with ubuntu-docs/yelp?  the topics are showing non-english text in an english locale
<mdz> seb128: I assume this has to do with the OMF translations enrico put in
<mdz> but I can't reach him
<seb128> what locale are you using ?
<_mvo_> erm ... after test-install and saying: "take over the partition" I ended up with no partition marked "bootable" and my test-machine does indeed not boot (error: no active partion in HDD)
<seb128> oh
<seb128> maybe that's the issue I had this afternoon ?
<seb128> sounds like it
<_mvo_> seb128: sounds like it
<seb128> :(
<elmo> seb128: I'm on en_GB.UTF-8 and I see it on powerpc
<seb128> elmo: any idea of what language do you see ?
<jnc> seb128: if you have a moment, I make myself available to help test and troubleshoot OpenOffice print troubles for amd64 Hoary ubuntu
<seb128> jnc: not now, looking on some other issues atm, and I don't know anything about OOo anyway
<elmo> "Tala ng Labas na Hoary"
<jnc> seb128: okay :)
<jnc> i wonder who i should talk to
<elmo> 'Mga tala ukol sa labas ng Ubuntu 5.04 "Hoary Hedgehog"'
<seb128> hum
<sabdfl> elmo: swallow, dude
<elmo> 'Isang maiksing pagpapakilala sa sistemang" etc.
<tritium> elmo, is that Tagalog?
<seb128> sounds like "xh"
<mvo> and I get a strange resoltion on a different machine with the live-cd. it doesn't detect my lcd panel and puts it into 1278x1022 (according to the hardware) and 1024x768@0 accordning to the gnome-resolution panel
<seb128> arf
<seb128> s/arf/arg/
<mkedwards> tagalog
<seb128> $ grep C about-ubuntu-tl.omf
<seb128> <!DOCTYPE omf PUBLIC "-//OMF//DTD Scrollkeeper OMF Variant V1.0"
<seb128>     <identifier url="file:///usr/share/gnome/help/about-ubuntu/C/about-ubuntu.xml"/>
<seb128>     <language code="C"/>
<mvo> I got a german yelp help at least 
<seb128> 
<tritium> mkedwards, yeah, I ran it by my Filipino wife ;)
<seb128> the tl omf files have language code="C"
<seb128> mdz, elmo 
<seb128> mvo: tl overwritting C ...
<seb128> that's fine with french here too
<mvo> ah, ok
<seb128> try LANGUAGE=C yelp
<mdz> seb128: thanks for checking into it
<elmo> seb128: same thing?  or were you not talking to me? :)
<seb128> elmo: just saying what is broken, the "<seb128> try LANGUAGE=C yelp" is for "<mvo> I got a german yelp help at least "
<elmo> ah
<seb128> mdz: should I upload a fixed package now ? 
<mdz> seb128: yes, please
<dhonn> you know what would be cool is if you can choose an excutable and right click it, click add to Application Menu
<mdz> mvo: go ahead and upload the apt fix too, please
<froud> mvo: it should have lancode of tl
<mvo> mdz: rebooting into "real" system now and uploading
<froud> <identifier url="file:///usr/share/gnome/help/about-ubuntu/tl/about-ubuntu.xml"/>
<froud>     <language code="tl"/>
<sivang> pitti: have you fixed that bug? I just arrived home, I will look at it right now if you still havn't solved it.
<pitti> sivang: nevermind, everything is solved
<pitti> sivang: check your mail :-)
<mdz> lamont_r: please monitor the new kde-i18n
<sivang> pitti: ah cool, what was the problem? :-)
<mvo> froud: seb128 is going to roll out the fix
* sivang checking email
<lamont_r> ok'
<pitti> sivang: none, the patch was fine, just a bad interaction with gksudo
<seb128> mdz: have you read mvo's install issue ? I hade the same this afternoon with an daily from this morning
<froud> same problem with release-notes
<mdz> seb128: no, I haven't
<mdz> reading
<dhonn> I found a Create Launcher bug a few days back..  you cannot create a launcher with spaces in the file name.  You must manually edit the launcher and add your own spaces with "\ ", for example /home/dhonn/hello\ world
<mdz> mvo:which boot loader did you use?
<sivang> pitti: cool, thanks, again sorry I couldn't take care of it.
<lamont_r> Kamion: was just uploaded? as in not in archive yet?
<seb128> mdz: the previous daily used to work fine on the same computer here
<froud> ogra: did you register device databases OMF with scrollkeeper
<seb128> mdz: just today's one not booting
<ogra> froud, nope
<froud> ogra: does not open help on my system
<mdz> lamont_r: hmm, I think I needed to kick cron.daily since it was the only thing in the queue; it'll go through when seb128 and mvo's uploads do
<ogra> froud, huh ?
<mdz> seb128: manual partitioning?
<froud> ogra: must register the omf with scrollkeeper
<seb128> mdz: no, all the default choices
<froud> or yelp cant find the doc
<seb128> take over the disk
<seb128> froud: ?
<froud> seb128: yes
<ogra> froud, i tried it on four different machinec
<ogra> s
<seb128> froud: what is your issue ?
<froud> ogra: on my system help for the aps is not working
<mdz> seb128,mvo: I, too, have no active partition after my test install
<mdz> seb128,mvo: but it still boots
<froud> seb128: to do with the tl
<ogra> froud, it should work from the helpbutton...
<froud> ogra: nope
<seb128> mdz: so maybe that's not due to the active partition but today's daily didn't boot, I'm rsync the current and will give a try soon
<mdz> seb128: is this on i386?
<mdz> I have only tested amd64 so far
<ogra> froud, could you look if /usr/share/gnome/help/hwdb-client/C/hwdb-client.xml is there ?
<froud> seb128: both the about-ubuntu-tl.xml and release-notes-tl.xml are registered wrong
<dholbach> lamont, elmo: i didnt quite understand - should dietlibc upload (if i changed the architectures) be "ready to go"?
<seb128> mdz: i386 yep
<lamont_r> dholbach: the machine where that file lives (in cvs) is down, due to a raid failure.
<seb128> froud: I know
<lamont_r> I emailed elmo my copy of the file
<froud> seb128: you know the fix
<mkedwards> mvo: which livecd is that strange resolution from
<froud> identifier and lang elements need update
<seb128> froud: use the right locale instead of C ?
<seb128> froud: yeah, that's fine, thanks
<seb128> I'm updating the package
<dholbach> lamont_r: so we can't tell, if it would build, since the PaS in not recent?
<elmo> dholbach: it won't build, but it doesn't matter, upload it anyway, and when I fix p-a-s, it'll build
<dholbach> elmo, lamont_r: thanks a lot, will do
<froud> ogra: no it is not
<_mvo_> re
<_mvo_> mdz: uploaded
<froud> seb128: and the path
<ogra> froud, then there is something wrong with your package, odd...
<seb128> froud: s/C/<nn> 
<froud> just did update tonight
<froud> seb128: :-)
<sivang> night all
<ogra> froud, the path is hardcoded in the app, since there are no translations yet, thats only a little bit evil :) if the file is there, the help button should work in the app
<mdz> seb128,mvo: talked to Colin, I'm going to upload partman-auto to revert the change which caused this problem
<elmo> how did we not ship a modified dput?
<froud> ogra: my problem is on 0.5-0
<ogra> froud, use 0.6-0ubuntu2 ;)
<seb128> mdz: k, thanks
<mvo> mdz: ok, thanks
<seb128> " /usr/bin/update-manager:
<seb128> Child terminated with 129 status"
<jnc> seb128: my mistake, i thought you were a printing guru.  i see you're charged with fixing the numerous PalmOS user bugs.  good luck at that ;)
* seb128 kicks gksudo
<froud> ogra: thanks
<mvo> seb128: arg, not again!
<seb128> jnc: PalmOS ? me ?
<jnc> gnome-pilot, in bugzilla.ubuntu.com
<jnc> i did a query and it came up with quite a few
<seb128> mvo: that sucks :/
<seb128> jnc: I've almost everything with "gnome"
<jnc> ah
<mvo> seb128: can you reproduce it? I have seen very rarely and was never able to reproduce it
<seb128> but I don't have a PalmOS, so for these ones I just forward upstream
<seb128> mvo: no, just get it sometimes
* lamont_r lunches - back before kde-i18n gets far, I expect.
<mdz> lamont_r: we'll need new rootfs builds shortly
<mdz> I guess I can do them
<lamont_r> do you know when, and I can just schedule them?
<mdz> no, need to wait for builds to be done
<mdz> I'll trigger it when the time comes
* lamont_r expects to be gone about 20-25 min or so.
<sabdfl> elmo: is it possible to get a list of all the files read by an app?
<mdz> seb128: can you get the fixed ubuntu-docs in by :33?
<mdz> or :30 or whatever
<seb128> nop, the package is quite big and my upload slow :/
<seb128> will take a couple of min after that
<elmo> sabdfl: strace it and grep the strace log for open() calls is the usual way
<mvo> mdz: should I debug that live-cd X misdetection further i wrote about above?
<sabdfl> elmo: ok, thanks
<ogra> mdz, artwork ? i have a fixed package here...
<mvo> sabdfl: "strace -e trace=open $prog" is another possible way
<sabdfl> thanks mvo
<dholbach> hi sabdfl :-)
<mdz> ogra: artwork?
<sabdfl> hi daniel
<mvo> live-cd is fine on my other test-machine btw
<ogra> mdz, gdm theme screenshot changed....
<seb128> mdz: nm, that's a revision, it's uploaded
<mdz> seb128: thanks
<seb128> np
<mdz> elmo: I kelly'd it at 21:30:36; was I too late?
<elmo> mdz: shouldn't be, cron.daily is :33
<mdz> ok
<mdz> everything we need for the next build should be in, then
<mdz> for ubuntu anyway; kubuntu needs for kde-i18n to build
<dhonn> is it possible to create a livecd/installcd like how Linspire does it?
<Goshawk> i know that fedora core 4 is going to make a revolution of the boot system: starting gdm + xorg fast as possible and then start all the services: is ubuntu going to do the same?
<dhonn> thats the way MacOSX does it
<jnc> windows does the same thing
<ogra> Goshawk, it already does.... 
<thom> Goshawk: last we checked we were faster than fedora *shrug*
<dhonn> but windows is more transparent
<Goshawk> but ubuntu
<Goshawk> is ubuntu going to do that?
<dhonn> mac shows services booting using the top right systray
<ogra> Goshawk, it already does.... 
<jnc> it's hard to resist making a joke about doors being opaque
<dhonn> in the october release that would be nice
<jnc> Goshawk: why would paralell services be necessary for ubuntu?
<Goshawk> ogra, no: xorg is still S99 in my /etc/rcS.d
<dhonn> lol
<thom> Goshawk: http://blog.clearairturbulence.org/2004/12/11#sub-30-baby
<dhonn> i've run all the services in paralell on my fc3 box, it boots up really quick, under 30 seconds
<dhonn> average is about minute 30 
<jnc> i've used non-sysvinit systems that booted in 10 seconds
<ogra> Goshawk, /etc/rc2.d/S13gdm is rather what youre looking for i think ;)
<dhonn> and i turned off rhat graphical boot
<thom> dhonn/Goshawk: http://www.planetarytramp.net/bootchart/bootchart-20041210-1934.png is the last time we were playing and measuring; it may have gotten a bit slower but not much
<Goshawk> ogra, looks /etc/rcS.d scripts they are executed first
<dhonn> not to mention all default fc3 services running lol
<dhonn> link doesnt work
<dhonn> there we go
<dhonn> what program are you using thats awesome
<jnc> parallel isn't the savior
<jnc> when you think about things that are really troublesome, like DHCP taking a long bloody time when there's no authoritative server to be found
<Goshawk> jnc, or when there is not a cable connected
<jnc> that's included in what i said
<ogra> Goshawk, X ist started by gdm, you can see it in thoms chart...
<jnc> obviously if the cable is not hooked up, no authoritative dhcp servers will be found
<dhonn> I have no cable connected sometimes,  so I have it run "ifup eth0 &"
<thom> dhonn: bootchart
<Goshawk> ogra, yes it' right
<dhonn> k
<thom> we tried parallel, it was slower
<dhonn> its slower to boot, but you get the desktop up quickly
<dhonn> the desktop stays really unusable though lol
<thom> dhonn: yes, that's also pretty horrible
<dhonn> like windows
<thom> that's totally windows
<dhonn> and mac
<Goshawk> ogra, right it seems to be the fastest way to do the work
<jnc> hey guys, while you're talking about shaving off 1-2 seconds of boot time, want to help me resolve a showstopper bug?    OpenOffice does not print on amd64 hoary.
<jnc> confirmed by two other amd64 users i believe
<Goshawk> gdm is the first service after that the kernel recognized the system
<dhonn> services should be launched at paralell or even in background after the desktop is up and running
<Goshawk> thom, is your map done on a ubuntu system?
<Goshawk> dhonn, it's aready done 
<Goshawk> dhonn, http://www.planetarytramp.net/bootchart/bootchart-20041210-1934.png
<thom> Goshawk: yes
<thom> Goshawk: on an x40 laptop, so not even a super fast machine
<thom> there's a tonne more to do for breezy
<Goshawk> what if i've a ethernet card that is not connected? do the boot process wait until ifup return a bad value?
<doko> jbailey: you got mail
<jbailey> doko: So I do. ;)
<dhonn> guys you know Linux barely needs to be rebooted, and usually we reboot when we update the kernel.  What if instead of doing a full shut down, everything is just supended to disk.  Then when we boot up again we just reanimate.  The system would simply never reboot.
<Goshawk> dhonn, yu can't say that if you play on a desktop system, it's rebooted frequently
<mkedwards> writing 18:32 i386 livecd now.
<dhonn> how many times is it rebooted a month?
<crimsun> dhonn: look at kexec
<dhonn> oh yeah kexec
<Goshawk> dhonn, my computer: 7 times per day
<dhonn> there has been talk about that in some IBM docs
<dhonn> why?
<dhonn> that reminds me of win95
<Goshawk> dhonn: since i've something to do than stay ever on pc (or leave it up)
<Goshawk> s/ever/always
<thom> as long as we reboot *when* it's required (glibc security upgrades and kernels, basically) then i don't see it's at all a problem just to reboot
<thom> this fear of seeming like windows is fine, but it's taken too far
<Goshawk> dhonn, and i'm going to buy a laptop: do you think that it will be ever up?
<dhonn> laptops are hardly up
<dhonn> im on a laptop right now, its up and down many times a day
<dhonn> suspend makes sense on it
<mdz> elmo,lamont_r: can you check on ubuntu-docs?  it's looking like it might not make the cut
<dhonn> on my fc3 box i rebooted everytime they updated the kernel, thats pretty much it, i had to recompile nvidia everytime
<Goshawk> btw: here is something about fc4 boot process https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151952
<dhonn> people i have to go now, my gf is mad
<elmo> mdz: it's in queue/accepted
<elmo> shall I kelly it?
* thom -> home
<elmo> duh, nm it's binary
<mdz> elmo: dude, it appeared between when I wrote that and when you looked
<mdz> I have both ls outputs in my scrollback
<jnc> i've never heard that.   what is "shall I kelly ___? "
<jnc> 'kelly'  
<mdz> sysadminchronicity
<mdz> jnc: kelly is the name of a tool we use
<jnc> not some proper english slang
<jnc> okie
* elmo -> london
* lamont_r is back
* jnc -> chicago
* mkedwards -> 0406.2
* Goshawk -> bed
<lamont_r> mdz what's in the new fs??
<CarlK> Kamion, et all, if you are trying to follow links on bugzilla to my log files, my ISP is going nuts and the web server is basicaly off line - sorry for any frustruation this may have cuased
* CarlK wonders if anyone is awake and sober ;)
<mdz> lamont_r: ubuntu-docs and apt
<mdz> lamont_r: please trigger builds as soon as apt 0.6.35ubuntu2 and ubuntu-docs 1.0-2 are present
<lamont_r> roger
<mkedwards> livecd is now autodetecting 1920x1200 correctly.  w00t.
<mkedwards> framebuffer=false worked too.
<mkedwards> trying vga=ask next
<lamont_r> next cron.daily will get apt and u-d
<lamont_r> elmo: really gone, yes?
<mdz> lamont_r why next cron.daily?  should have gone in at :03
<mdz> lamont_r: it left accepted/ anyway
<mdz> they're now mirrored to little as well
<mdz> you should be able to start the builds now
<lamont_r> doh
<lamont_r> so it did
<lamont_r> ubuntu and kubuntu?
<mdz> not much point in kubuntu until kde-i18n is done
<lamont_r> well, they get a spare then.. :-(
<Kamion> back
<lamont_r> less typing and all that - lived builds running
<mkedwards> vga= doesn't help much, since debian-installer still goes to fb and scribbles on display.
<mdz> Kamion: install CD builds in progress
<lamont_r> mdz: was looking at logs, and it looked like u-d had missed the :00 cron.hourly at first blush.  my bad
<Kamion> mdz: yup, noticed
<mkedwards> mdz: shall I document debian-installer/framebuffer=false workaround on wiki (mentioning that it's not the default because of localization)?
<Kamion> debian-installer/framebuffer=false is a reasonable workaround for various problems on certain hardware, and certainly cannot be the default
<mdz> Volume id: Ubuntu 5.04 amd64
<mkedwards> Kamion: understood
<Kamion> mdz: I just committed that change, too
<mkedwards> Probably only important to people who know about Ctrl-Alt-Fn anyway.  :)
<mdz> Kamion: did I get all the bits?
<mdz> it looked good to me
<mdz> what's the reason for the differing label on powerpc, btw?
<Kamion> mdz: yeah, looked fine
<Kamion> mdz: dunno, it was like that when I got it; I figure maybe the full "powerpc" name overflows a length limit somewhere
<lamont_r> with Bin-1 gone, should fit though, yes?
<Kamion> true
<Kamion> but I don't see the need to diff even further from upstream debian-cd, it's hard enough as it is :)
<lamont_r> yeah, it would be a bit gratuitous
<Kamion> you must have figured out by now that I'm an obsessive about keeping diffs small :)
<lamont_r> Kamion: small and isolated.  that's how we like them.
<mako> alright.. so enough of this release talk.. lets talk about the serious issue
<mako> release parties
<azeem_> isn't there a wiki page for that?
<mako> i'm not cuaght up to today in mail
<mako> but i didn't see it searching for it
* lamont_r would be happy to attend a party in the denver area. :-)
<mako> http://www.ubuntulinux.org/wiki/ReleaseParty
<azeem_> mako: the GNOME release parties are coordinated via a wiki page, cf e.g. http://live.gnome.org/Gnome210Party
<mako> yeah, not much there
<mako> alright everyone. lets start putting parties on that list
<mako> pick a time late friday and pick a pub.. that's a party
<lamont_r> i386 loop done, amd64 compressing, ppc partimage-restor
<mako> lamont_r: c'mon, organize a party. :)
<mako> it takes like 5 minutes :)
<lamont_r> mako: yeah, yeha
<lamont_r> will contact a couple locals and we'll get something scheduled
<mako> cool
<mako> azeem_: munich party?
<lamont_r> but it'll be fort collins, not denver. :-P
<CarlK> is it toast time?
<azeem_> mako: murrayc is offline, he's the only Ubuntu user I know here
<lamont_r> azeem_: think of all the other users you'll meet at the party...
<lamont_r> mako: we need printable labels for the CD-R's we burn between now and then, you kknow...
<mako> azeem_: invite the debian people :)
<mako> that's what i'm doing
* lamont_r takes his laptop upstairs
<lamont_r> milli_: this isn't going to kill my IP is it?
<mako> then again, the debian-nyc list is largely a product of my desire not to drink alone
<Kamion> hmm, speaking of, I wonder if whisky would improve my waiting-for-stuff-to-happen time
* mako nods enthusiastically
<mako> tried that one last night
<T-Bone> Kamion: at the expense of your willingness-to-wait-for-stuff-to-happen ;)
<mako> shipit exports are at least twice as much fun when there is whiskey involved
<T-Bone> hehehe ;)
<Kamion> T-Bone: I have a relatively high patience quotient, fortunately
<T-Bone> mako: you send whiskey bottles in CD packs? :)
<T-Bone> Kamion: yeah, i noticed that 8)
<mdz> what a FINE IDEA
<ogra> yeah
<T-Bone> what, CD-whiskey? :)
<mako> and we thought our customs issues were a pain in the ass now
<T-Bone> lol
<mako> mdz: hoary party in LA?
<mako> it can involve whiskey
<azeem_> hmm
<azeem_> 00:54 < azeem> mag jemand zu einer Ubuntu Release Party am Freitag in Mnchen
<azeem_>                kommen?
<azeem_> 00:55 < Ganneff> BAH
<lamont_r> HUMBUG!
<mdz> mako: it'd be a bit of a delayed hoary party
<mako> mdz: i think that works
<Kamion> unfortunately I have little decent whiskey (or at least it's being kept for special occasions); I have a good stock of whisky though
<mdz> mako: but rest assured that whiskey will be involved regardless of the justification
<ogra> azeem_, which channel was that ? #hurd ?
<mako> mdz: or regardless of a party! :)
* mdz grumbles about source ISOs and jigdo
<azeem_> #hurd is an announcement-only chan these days
<azeem_> it was #debian.de on oftc
<T-Bone> mako: lol ;)
<mdz> mako: oh, there _will_ be a party
<mako> tonight is the pre-hoary party.. in fact, whiskey is the only one i've inviting
* whiprush adds his local party
<mdz> oh, is there a wiki page?
<mako> whiprush: you rock
<mdz> so there is
<mako> mdz: yes, that's what i'm trying to hype
<azeem_> 00:41 < mako> http://www.ubuntulinux.org/wiki/ReleaseParty
<mako> i'm trying to get a critical mass so i can send out an announcement to the lists/forums
#ubuntu-devel 2006-04-10
<AlinuxOS> hello boys :) why 6.04 to 6.06 ? :)
<AlinuxOS> I'm surprised really :)
<ogra> because it would be odd to release in june but call it 6.04
<Riddell> mdz: the kdeprint maintainer says he would be interested in a cups 1.2 bounty and it would help him allocate time to kdeprint. how do I proceed?
<doko> Riddell: pitti did want to look at an cups update, but he's quite busy
<Riddell> doko: it won't help
<Riddell> it's KDE at fault
<doko> Riddell: as with "system:" URL's ;-)
<mdz> Riddell: do you have a fairly good idea of the scope of the work?  small, medium, large?
<mdz> ogra: ah, I thought speedcrunch was an edubuntu app
<ogra> mdz, nope, its a kubuntu-desktop dep ...
<ogra> mdz, but dont worry, i'll sort it out with Riddell :)
<mdz> ogra: thakns
<Riddell> mdz: it's fixing the use of private apis to public ones
<Riddell> mdz: not a huge job, there shouldn't be too many
<mdz> Riddell: ask him to send me an email with a statement of work (a description of what needs to be done, that we can all agree on), a date he can commit to delivery, and a price
<mdz> I'll take it from there
<Riddell> mdz: ok, thanks
<Riddell> Kamion: kde espresso good for merging if you want, it's starting to become usable
<doko> mdz: how should we go on with the change of the default font? the discussion was somewhat short; just jdub did agree. didn't hear anything from Diziet (firefox default)
<mdz> doko: it makes me very nervous
<mdz> doko: do you have some ideas about how we can get sufficient testing and input from users of many different languages and content types?
<engla> Ubuntu dapper dropped out of X in a split second for me, leaving me witha black screen. Which logs should I preserve before starting gdm again? I've found .xsession-errors, but what more is good for a bug report?
<sladen> mdz: provide pizza and bribe all the overseas students from the local university to show up
<elmo> argh, christ.  is it a known bug that you can't paste non-ascii in gnome-terminal?
<sladen>  pasteage
<sivang> elmo: do you get hollow squares?
<elmo> sivang: it just won't let me paste
<Seveas> works fine for me
<sivang> elmo: ah
<sivang> 
<sladen> elmo: from PRIMARY or CLIPBOARD  (right-click, paste, or middle click?)
<sivang> I can paste but not see it right after having pasted it.
<elmo> sladen: shift-insert
<elmo> (which is middle-click, I think?)
<doko> mdz: if we only move the Nimbus font before the DejaVu font, then not much should happen (tm). The problem which I see is to get testers and developers interested in testing this. so maybe announce it again on devel-announce, and provide some test packages on p.d.o (have to convince seb128 and Riddell to help with this)
<elmo> right-click copy + right-click, paste, just does nothing too
<mdz> doko: which packages need to be touched?
<sladen> yes.  Shift-insert, middle click and right-click all work for me with speffal characters
<elmo> so I wonder what the heck is spethial about my setup, *sigh*
<elmo> sladen: thanks anyway
<doko> fontconfig, gnome-control-center(?), some KDE package (?), don't know for xubuntu.
<doko> mdz: there's one alternative, which might be less invasive: revert back Diziet 's fontconfig change, so that at least the replacement for the Times/Helvetica fonts is metrical correct. But then people will complain that their web pages look ugly ...
<mdz> doko: the fonts look very similar, though different metrics, so in theory it should look OK where glyphs are mixed, right?
<wasabi_> Is there any standard for encoding the type of a document into a plain text file as a comment so it can be sniffed?
<wasabi_> Some common #syntax or something.
<wasabi_> It's unimportant, I just want to know if there's something universally accepted currently.
<doko> mdz: glyph mixing is never ok, but the Nimbus font is somewhat complete in the glyph "groups", so substitutions should look ok (we won't have the alphabet in nimbus, except for the vowels in DejaVu)
<doko> mdz: last resort is to blacklist the Nimbus font for some languages in /etc/fonts/fonts.conf
<neuralis> wasabi_: what do you mean by type? text encoding, or actual type (perl script vs. TeX file vs. ...)?
<wasabi_> mime type.
<wasabi_> I'd just assume put #application/foo as the first line in the file.
<wasabi_> But I was wondering if there some syntax other programs are using I can steal.
<neuralis> not to my knowledge, no.
<wasabi_> Well, what's done for encoding?
<wasabi_> I've seen something done by VI before, trying to find an example.
<neuralis> vim has its own syntax for denoting encoding, if i remember correctly; unicode has the (optional) BOM, and general programs use the canonical solution of libmagic if they really need to figure out the type of a file.
<mdz> doko: let's give it a try and see what happens; it's simple to revert, right?
<mdz> doko: or does it migrate into user preferences?
<doko> mdz: fontconfig defaults not, I'll ask seb128/Riddell for gnome/KDE, so that we know at least that
<mdz> doko: ok, if it's entirely global config and easy to revert, let's try it
<robertj> the http://people.debian.org/~debacle/refcard/ webpage is a good example of exactly what is wrong with free software today :(
<doko> mdz: ok, will prepare it tomorrow and announce it
<ogra> elmo, did you try shift-ctrl-V
<engla> is it possible to attach files to bugs in launchpad?
<sladen> elmo: oh, remember that with copy and paste it is the application that you are copying /from/ that provides the string;  so it could it that which is broken rather than the recieving end
<engla> engla: yes it it, you are confused, engla 
<elmo> sladen: ah, maybe it's screen
<elmo> 'cos it's gnome-terminal in both cases
<mjg59> robertj: Mm?
<elmo> ogra: that's just paste from the menu isn't it?
<syntaxis> robertj: how so?
<ogra> yep
<ogra> elmo, but ususally works
<robertj> mjg59: it's an very plain page with an abstract that looks like the introduction of a conference paper. It follows with information about how to access the information using svn. Then it follows with the commands for checking it out of cvs. Then it lists a whole bunch of information users don't care about including the Translator & Print Title. 
<robertj> Then when you finally click the link you get a bunch of commands with too little explanation to actually be of use to anyone who would need the cheat sheet
<ogra> doko, do you read ubuntu-art ? "Has something changed with the fonts? Ubuntu looks very crisp and sharp, far more so than other LiveCD's somehow."
<mjg59> robertj: I think you've missed the point of that page
<ogra> thats about flight6
<mjg59> (Though your criticism of the card itself may be valid)
<doko> ogra: no, don't read it. maybe it's compared to breezy?
<robertj> mjg59: it it were me it would be Title - List of Languages - More information
<mjg59> robertj: It's not supposed to be a source for users
<ogra> doko, might be, but it indicates that we should probably keep the current setup as a fallback
<robertj> mjg59: it's on digg
<mjg59> robertj: Well it shouldn't be
<robertj> mjg59: I think it's a reality people have to prepare for these days
<sivang> robertj: which page is that?
<robertj> basically anything that does not have a whole-pager watermark reading "TEST RELEASE" is going to be presented as done
<robertj> sivang: http://people.debian.org/~debacle/refcard/
<mjg59> robertj: I write pages based on the audience I'm targetting, not the audience that may get pointed at my page by digg
<robertj> mjg59: I understand, but a cheat sheet is end-user documentation
<robertj> so it ought to have a similarly-targeted web page
<mjg59> robertj: It's a website that exists to provide information on the availability and translation infrastructure of the doc
<mjg59> Not a website that's supposed to provide it to a naive end-user
<robertj> mjg59: it's not marked as being in a developer section, isn't titled "Developer Information for X" etc
<mjg59> robertj: And?
<robertj> mjg59: so it's a good example of having an end-user product with no end-use web page.
<mjg59> robertj: And that's exactly what's wrong with free software these days?
* ogra makes a note to teach flint about cross posting tomorrow 
<Keybuk> heh
<Keybuk> he did manage to send that e-mail to everybody except the intended recipients
<ogra> heh, yes
<mjg59> robertj: Lack of clearly targetted webpages is hardly limited to free software. It's common pretty much anywhere where there's no direct profit motive
<robertj> mjg59: Yes, is it a good thing? Do developers really want to see the entire first page dominated by copyright discussion over the GPL?
<mjg59> robertj: You're restating your complaint
<robertj> Yes, and I'm asking, is this helpful to developers?
<mjg59> Yes
<robertj> So you like having the whole pre-amble right smack at the top?
<robertj> You don't need it up there, you don't have to accept it
<robertj> but that's quite enough about that
<mjg59> robertj: If I'm going to be distributing or translating something, I want to know what terms it's under
<robertj> mjg59: yes, that would be good, stick it at the bottom along with checkout directions
<mjg59> robertj: It's fairly clear that that page is aimed at distributors and translaters
<robertj> mjg59: and it shouldn't be, but we've already covered that ground
<mjg59> robertj: Given who the page is aimed at, the page is appropriate. Which leaves you with "This project has no end-user friendly website"
<mjg59> Which is again a reasonable objection, but it's certainly not an example of what's wrong with free software today
<mjg59> There are many worse things
<robertj> mjg59: that's right. And it doesn't really need a web site, it needs a web page, which would hopefully be linked off the dev page because it's also part of the development
<robertj> mjg59: I think it's emblematic, I surely don't think it's going to bring world peace
<robertj> I like the cheat sheet entry for building your own kernel image
<Kamion> mdz: why do you think #32529 belongs with partman? it looks like a parted bug to me
<mdz> Kamion: I thought partman decided what was permissible
<mdz> if not, apologies
<Kamion> looks to me that parted is not telling partman about the existence of hda3 because it's confused, partman then tries to tell parted to resize hda1, and all parted manages to do is write out a new partition table with its confused view of the world
<Kamion> anything that low-level about partition tables is usually parted
<Kamion> I'll reassign back and ask for the partman log, which may help
<Kamion> thanks, though, at least the reassign prompted me to look at the bug :-)
<Kamion> Riddell: noted, thanks
<mdz> I wish I could unsubscribe you/ubuntu-installer from some of these misplaced installer bugs
<Kamion> I can unsubscribe myself if need be (and sometimes do), but I can't figure out how to unsubscribe ubuntu-installer
<Kamion> it's probably right that you can't unsubscribe other people, but you should be able to unsubscribe a team you're in
<Kamion> https://launchpad.net/products/malone/+bug/30532
<Ubugtu> Malone bug 30532 in malone "Unable to unsubscribe a team from a bug" [Normal,Confirmed]  
<bddebian> heh
* infinity finds the most wonderful webpage EVER about EGA/VGA timings, and goes back to review his vga16fb patches.
<Kamion> Riddell: why does your branch remove necessary code from espresso/components/install.py?
<Kamion> Riddell: and as usual you didn't write a changelog entry; please do
<Kamion> for instance the apt-install change closes a bug and needs a changelog entry
<Kamion> I'll merge it after you've corrected that; thanks
<Kamion> (apologies if the above is snarky, insomnia is not good for tact)
<elmo> you said thanks, not kthxbye, so I think you're not quite up to snarky yet
<Kamion> true
<Seveas> getting close though ;)
<nictuku> Seveas, are you there?
<Seveas> nictuku, yes
<dAndy> Kamion: I am having another weird kickstart issue, when I specify a drivemap, it still pops up the drive map dialog, but when I tell it to erase all of hda, it still uses the drive map from the ks
<nictuku> can I pm you about members host cloak?
<dAndy> Kamion: is there something I am missing, about telling it to use hda or something?
<mjg59> Keybuk: Suspend/resume issues are almost certainly the kernel, not acpi-support
<Seveas> nictuku, please mail me (dennis@ubuntu.com) - it's 3:20 here and I should be sleeping 
<nictuku> Seveas, ah ok
<Kamion> dAndy: preseeding partman-auto/disk is the usual way to pick a disk
<nictuku> Seveas, thanks
<Kamion> dAndy: apart from that (and obviously you shouldn't have to do that by hand with kickstart) I can't immediately think what's wrong, but it's late here
<Keybuk> mjg59: aye, I take a "assign it to the first package I can think of that mjg59 knows about, so he can decide where to assign it further" approach :p
<dAndy> Kamion: it seems like if you specify a partition map, it should pick the default drive, should I file a bug? or is this normal behavior and preseeding is the way to go
<Kamion> clearpart preseeds partman-auto/disk ...
<Kamion> dAndy: go ahead and file a bug, I think I need (a) more details/context and (b) more sleep
<dAndy> ok, against d-i?
<Kamion> kickseed probably
<Kamion> include sample kickstart file minus passwords
<dAndy> will do
<Kamion> ta
<mjg59> Keybuk: What would be great would be a suspend/resume meta-target
<mjg59> That way I can see it and reassign it as appropriate
<mjg59> But sticking it on acpi-support (which is just a bunch of shell scripts) isn't ideal
<bddebian> Anyone know imake/xmkmf well?
<OgMaciel> jdub: ping
<sivang> night all, for real now. (boy am I past my bed time!)
<bddebian> Gnight sivang
<sivang> night bddebian , going to dream backup dreams :)
<bddebian> :-)
<jdub> OgMaciel: pong
<OgMaciel> jdub: can I pvt?
<jdub> OgMaciel: yeah
<bddebian> Damn did infinity die or what? 
<dAndy> Kamion: filed the bug, I think the issue may be that I am rebuilding mini.iso from the debian-installer source, the only thing I changed was added the nfs kernel module udeb, otherwise it uses the defaults
<infinity> bddebian: Did I?
<bddebian> infinity!!
<bddebian> infinity: Would mind helping me with this imake/xmkmf thing in ivtools?
<infinity> imake and I don't get along AT ALL...
<infinity> What's the problem?
<bddebian> The paths were wrong for X11/conf and libs
<bddebian> But now it pukes on build.  It appears that MakeCPU() isn't returning anything?
<wasabi__> So what's a nice good free place for a blog?
<infinity> bddebian: Erm, yeah.  I have no clue. :)
<wasabi__> What was that one set up for gnome devlopers at some point?
<Burgundavia> wasabi__: advogato or livejournal
<wasabi__> advo...
<bddebian> Damn :-(
<wasabi__> advogato. Yeah.
<bddebian> How can XCONFIGDIR be /usr/lib/X11/config, that's not even a valid dir??
<jdub> does kernel.org have a nice view of git trees? (specifically ben's ubuntu git tree?)
<ajmitch> how nice a view do you want?
<ajmitch> like http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=summary ?
<jdub> exactly like that
<jdub> thanks
<jdub> BenC: ping
<jdub> ber
* jdub forgets payload
<jdub> BenC: ping (what are the chances of getting that sata_promise update before the next package upload?)
<BenC> jdub: it will be in the next one
<jdub> BenC: ah, you're about - thanks! :)
<jdub> BenC: next as in, the one after?
<BenC> I just uploaded 20.30, so it will be in 20.31
<jdub> ok
<jdub> thanks
<TheMuso> c
<joelbryan> Hi, anyone awake?
<neuralis> joelbryan: what's up?
<joelbryan> anyone care to look at Bug #38115
<Ubugtu> Malone bug 38115 in ubuntu-meta ubuntu-desktop "A software for gaim that handles irc:// links in browser" [Normal,Unconfirmed]  http://launchpad.net/bugs/38115
<joelbryan> It's a small software I write to handle irc:// links in browser, and use Gaim.
<TheMuso> c
<TheMuso> gah!
<joelbryan> what?
<neuralis> joelbryan: please be patient. you only filed this bug today; the relevant developers have already received mail about it, and will get to it promptly.
<joelbryan> sorry man.
<LaserJock> joelbryan: you don't have to be sorry. I'd personally love to see something like what you have done in Dapper
<LaserJock> joelbryan: especially since xchat and xchat-gnome are not going to be installed by default
<joelbryan> thanks :-)
<neuralis> joelbryan: not a problem, and thanks for working on this! if you don't get feedback in 5-6 days, come poke us again.
<joelbryan> more things to come :-)
<joelbryan> does the home user backup already has a release software?
<Burgundavia> joelbryan: no, bug sivang
<bddebian> infinity: still here?
<infinity> bddebian: Ish.
<bddebian> infinity: Sorry to bug you and I don't know if you'll know but wouldn't you expect XCONFIGDIR to be /etc/X11/config rather than /usr/lib/X11/config (which doesn't even exist btw)?
<joelbryan> it's easy to convert it to be used in other protocol, like ssh://, jabber://, etc. if those are necessary.
<joelbryan> does the unified control center is part of the specification? sorry for asking alot.
<infinity> bddebian: Sometihng in /etc would certainly seem more reasonable.
<bddebian> Man, I thought you had ALL the answers :-)
<joelbryan> no, i'm still an amateur.
<bddebian> joelbryan: I meant infinity :-)
<infinity> bddebian: Sorry, I'm a bit preoccupied with fighting with LRM right now, and imake and I have always had a hate-hate relationship.
<infinity> bddebian: You might try poking Fabio about it when he wakes up
<bddebian> infinity: No worries, I'm just busting your chops.  Sorry.
<joelbryan> bddebian: oh
* joelbryan anti-blushing pills, do they work.
<bddebian> joelbryan: Bah, no worries :-)
<wasabi__> greatings, spaceman
<robotgeek> hi sabdfl 
<sabdfl> moin moin all
<sabdfl> got to dash off catch you later
<triceratops> On 27mar someone on ubuntu-users list mentioned a problem with resolvconf during an upgrade. It seems that he didn't fill a bugreport against resolvconf. So, is $devel aware of this irritating behaviour and is someone working on this?
<fabbione> morning
<Lathiat> http://launchpad.net/bugs/38009
<Ubugtu> Malone bug 38009 in resolvconf "Breezy -> Dapper transition needs proper /etc/resolvconf/run handling" [Normal,Needs info]  
<Lathiat> M#1
<wasabi__> Don't suppose anybody is aware of a good way to instruct synaptic to install some packages?
<wasabi__> with gksu in the middle. =/
<triceratops_> Lathiat: Interesting, looking for bugs at launchpad.net/distros/ubuntu/ asking for bugs in resolvconf this bug don't show up. (rom time to time this launchpad drives me nuts... ;-)
<triceratops_> Lathiat: So I shouldn't run into this problem due to the last report on this bug. But I did... *irritated*
<pitti> Hey everyone
<ajmitch> hi pitti 
<pitti> hi ajmitch 
<pitti> ajmitch: how's it going?
<ajmitch> good, how are you?
<mdke> infinity, any news on flashplayer-mozilla
<mdke> ?
<pitti> ajmitch: pretty well :)
<pitti> ajmitch: could you make any sense of that selinux kernel flaw?
<ajmitch> yeah, did you get my email?
<ajmitch> hey dholbach 
<dholbach> hey ajmitch
<pitti> ajmitch: no, I didn't !?
<ajmitch> pitti: hm, I sent it yesterday (I think)
* ajmitch has it in his sent messages folder
<pitti> ajmitch: nope, I checked my procmail log, nothing from you :(
<seth> jdong, ping?
<whiprush> jdub: ping
<mdke> whiprush, has someone poked you already about your blog?
<whiprush> yeah.
<mdke> cool
<whiprush> It's odd, it works fine in readers and whatnot, no idea what the problem is.
<mdke> whiprush, it doesn't work in blam reading from planet
<whiprush> yeah, it works for me when using my direct feed. :-/
<whiprush> If I can't resolve it soon I'll just move to wordpress or something.
<mdke> whiprush, perhaps it's planet's fault. lemme see
<whiprush> If you could rule it out one way or another, that would be great.
<mdke> yes, works fine in blam with your rdf feed
<mdke> although each post is just 2 lines long and then leaves me hanging
<mdke> whiprush, ^^
<whiprush> I wonder if typepad just broke (my hosted blog)
<whiprush> mdke: do you admin planet?
<mdke> whiprush, no, only jdub does, I think
<whiprush> ah.
* whiprush needs to be removed until he fixes his problem.
<dholbach> noooooooooo, don't remove whiprush!
<mdke> dholbach, on bug 38090, is the colour clashing with other non-orange icons filed somewhere else too? if not, I'll reopen the bug and change the description so its focused on that
<Ubugtu> Malone bug 38090 in ubuntu-artwork "Icons which are too orange and that look nothing like what they are supposed to portray" [Normal,Rejected]  http://launchpad.net/bugs/38090
<dholbach> I'm quite sure it is - but that's something which should be discussed on the mailing list, preferrably on ubuntu-art
<mdke> well, a bug is a bug, it's difficult to know when a bug is a mailing list bug or a bug tracker bug
<ajmitch> almost up to 40K bugs
<dholbach> the problem is that everybody has an opinion and it's more about a "discussion of changing a default" then a bug
* ajmitch chuckles at bug 38136
<Ubugtu> Malone bug 38136 in evolution "British English Spellings are Used" [Minor,Needs info]  http://launchpad.net/bugs/38136
<ajmitch> nothing wrong with using proper language in evolution :)
<mdke> dholbach, i think the fact that orange icons clash with non-orange ones in the same menu is not really a matter of opinion
<mdke> ajmitch, haha
<dholbach> let me re-read it
<dholbach> bug 34400 - places menu
<Ubugtu> Malone bug 34400 in ubuntu-artwork "Inconsistency: Icons in places menu" [Normal,Confirmed]  http://launchpad.net/bugs/34400
<mdke> dholbach, thanks. I dunno why this things don't show up when I search :/
<dholbach> if you want to have the bug there... go for it, I won't stop you
<dholbach> it's just that it has to be very precise and focussed
<dholbach> else it will just stay there :-/
<mdke> actually, I'm not sure that's the same bug. My problem is that the orange clashes with the silver in the (e.g.) mounted partitions icons
<dholbach> you have to mention that specifically
<mdke> i will get a screenshot
<mdke> sorry for the noise
<dholbach> sorry for not thinking enough when reading your bug report
<dholbach> but if it's not specific it reads just as "it's too orange for my taste" (when having had no coffee yet :-p)
<mdke> yes, it was my fault, not yours. (Although they are too orange :)
<sivang> morning!
<dholbach> pffft.... jdub in his orange clothes was too orange, but not the icons
<ajmitch> haha
<ajmitch> he just decided to wear the national costume, nothing wrong with that :)
<sivang> orange talking again?:)
<mdke> dude, my girlfriend, who i always use for usability assessment, actually physically shuddered when she saw the icons appear on the desktop
<mdke> let alone letting out a cry of horror
<mdke> if I hadn't switched to gnome icons, I would have been calling the psychotherapist
* dholbach wonders who calls the psychotherapist for which reasons... :-p
<sivang> mdke: ehehe, Seems you have gf with very strong usability opinions :)
<mdke> dholbach, :)
<jsgotangco> greetings
<ajmitch> hi jsgotangco 
<Burgundavia> hmm, lxer has posted an interesting piece about why there is going to be no Fedora Foudnation
<jsgotangco> xubuntu flight 6 a-ok here :)
<hunger> jsgotangco: Does pvmove work for you?
<hunger> jsgotangco: Coredumps on kubuntu for me.
<pitti> Kamion: can you please NEW the aspell-cs binary? Thanks in advance
<enyc> meep
<dholbach> heya seb128!
<seb128> hi dholbach :)
<jsgotangco> hey
<pitti> hey Mr. Sebarino
* pitti bows to the French Mafia
* sivang will bring a backup solution as a gesture of good will to the french mafia, soon or else...:\)
<pitti> sivang: how's HUB looking?
<seb128> bah, Keybuk closed all sort of non-fixed bugs because they were "Fix Commited"
* mvo should start doing this! a good way to keep the bug count down
<ajmitch> mvo: it really doesn't :)
<sivang> pitti: very good, checkout my last commit from last night at the launchpad page for the project.
<ajmitch> iirc open bugs doesn't count 'fix committed'
<mvo> ajmitch: ha! you spoiled my evil plan :P
<ajmitch> mvo: sorry 
<ajmitch> you'll have to do more evil plotting
* mvo goes back to his orbital laser plattform
<pitti> mvo: it is so precise that you can shoot bugs out of the LP database? wow :)
<ajmitch> pitti: he's probably targetting the data centre ;)
<pitti> well, ok, with a sufficiently big laser you can kill all bug reports (and bugs) at once :)
<pitti> then we'll just have one: bug #1: please build an Ubuntu OS
<Ubugtu> Malone bug 1 in Baltix "Microsoft has a majority market share" [Major,Confirmed]  http://launchpad.net/bugs/1
<pitti> yeah, well, that too
<pitti> (why is it for Baltix, anyway?)
<ajmitch> it probably picks the first bug task
<dholbach> mdz: are you still there?
<infinity> pitti: With a really, really large laser, we wouldn't need any more OSes either.
<pitti> heh :)
<infinity> If this isn't the last time I build LRM today, there will be blood.
<infinity> And tears.
<infinity> Oh, yay, I win.
<pitti> infinity: hm, 2.6.15-20 isn't even out of NEW? or do you still build against 19?
<infinity> Magic.
<pitti> you cheated and sneaked them from the buildds!
<infinity> Nah, that would make too much sense.  I've been counting on -20- not actually breaking LRM at all.
<infinity> Perhaps I should grab the headers from NEW and confirm that. :)
* pitti sighs at cupsys 1.2rc1 - this bloody thing doesn't work *at all*
<pitti> Riddell: ^ did it for you?
<pitti> Riddell: it neither detects my printer, nor does the web UI work (I just get text/plain pages)
* sivang arghs at the work computer that does not have a burner to allow HUBIng.
<pitti> sivang: yeah, the counterpart of loopback is missing for that :)
<pitti> a virtual CD burner that writes to an image
<Seveas> pitti, mkisofs?
<pitti> Seveas: ... behind a /dev/something, I meant :)
<sivang> pitti: indeed :)
<Seveas> ah, true...
<Seveas> well, write it then :D
<pitti> /dev/fakeburner
<Kamion> pitti: aspell-cs done
<pitti> thanks Kamion 
<Kamion> can a MOTU please fix silc-toolkit? its binary packages in NEW are empty apart from documentation
<sivang> interface injection at it's best :)
<ajmitch> Kamion: will look at it
<Kamion> thanks
<infinity> Kamion: Oh hey, you're awake.  I didn't want to NEW the kernel, because, frankly, I'm too lazy to check that many overrides (and unlike you, I wouldn't know if the source matches the archive so I can just slide it in)
<janimo> mvo, morning, just sent you a working fake-gconf for update manager
<dholbach> Kamion: hello Colin - not to drown you in work, but if you could NEW tangerine-icon-theme - that'd be brilliant :)
<infinity> I would also like an Ubuntu-branded pony.  Thank you.
<Kamion> infinity: I just did; it doesn't *quite* match the archive unfortunately (a few udebs need to go to universe)
<Kamion> I should sit down with Ben and sort that out at some point
<Kamion> +It was downloaded from my harddisk.
<Kamion> niiiice :P
<infinity> debian/copyright?
<infinity> In which package? :)
<dholbach> Kamion: i could probably add a bzr branch :)
<Kamion> dholbach: done, sorry for the delay
<Kamion> infinity: tangerine-icon-theme
<dholbach> merci beaucoup
* dholbach hugs Kamion
* dholbach -> out for a walk now... really
* infinity needs to take over upstream for something, so he can write flippant debian/copyright files, too...
<sivang> pitti: btw, I was sure we already had something like that?
<pitti> sivang: no, I doubt that :)
<mvo> janimo: thanks
<Kamion> lucas: oh dear god a new yada package?
<Kamion> ah, it's by dexter, no wonder
<infinity> Erk.
<infinity> What now?
<Kamion> cvssuck
<infinity> Well, it's appropriately named.
<Kamion> there's nothing actually wrong with it that I can pin on it, though :)
<infinity> "unmaintainable"
<infinity> This reminds me, I need to go on that repackaging crusade to get yada out of main. :/
<pitti> infinity: only three packages :)
<pitti> infinity: libapache2-mod-auth-{pam,plain}, libnss-db
<infinity> Damn.  I care about all three too, so I can't demote them.
<infinity> Shame.
<infinity> At least they're all painfully simple to package.
<pitti> yes, some simple cdbs and all will be good *duck*
<infinity> How do you feel about death?
<infinity> If I have to fork them and put my name on them, I'm not using cdbs. :)
<pitti> checkrdepends cdbs dapper|wc -l -> 295; happy crusading :-P
<infinity> Yes, but note that my name isn't in the maintainer field for any of them, and I'm not a bug contact in Malone for any of them either. :)
<infinity> (Though glibc is "almost cdbs, but not quite", and I'm a contact for that now... But... Well... It's not my fault)
<infinity> I'll note that, for some odd reason, I can actually follow glibc's packaging, but cdbs always leaves me flummoxed if I need to do anything "abnormal" with it.
<doko> seb128, Riddell: font preference ping ...
<seb128> doko: don't ask to ask just ask
<doko> seb128: mdz agreed to the fontconfig change (back to Nimbus as default). could you prepare a gnome-whatever upload which sets DejaVu as the default for the GUI? Maybe leave "Document Font" as the default?
<seb128> doko: the issue is that is that it'll not change the user setting
<seb128> doko: ie: whoever ever played with the font capplet will get the new default
<seb128> it'll only apply to new users and users who never changed the font
<seb128> if users already played with it and have "Sans" written to the user config they will keep it
<seb128> ie: lot of users will get Nimbus for their UI
<doko> seb128: right, so the thing we can do is to announce, what they have to change, right?
<seb128> that really sucks if you want my opinion
<seb128> but yeah, we can ask everybody upgrading to reconfigure their font
<doko> IMO it sucks more to print bad documents
<seb128> doesn't openoffice or other allow to set a printer font?
<doko> anyway, let's prepare that on rookery
<doko> for -writer, not for -calc, -impress and -draw
<seb128> I'm not happy with that, I don't prepare anything yet
<seb128> I want a word with mdz first
<doko> seb128: read the backlog
<seb128> we will be flooded by people complained if they got ugly UI font on upgrade
<seb128> what backlog?
<doko> irc
<doko> tonight
<seb128> my IRC doesn't run during the night
<janimo> Kamion, please remove xfce4-windowlist-plugin, xfce4-showdesktop-plugin and xfcalendar source packages from the archive. They have been obsoleted by xfce4-panel and orage respectively. Thank you
<Kamion> that's why http://people.ubuntu.com/~fabbione/irclogs/ exists ...
<seb128> doko: we should rather figure how Suse does get that working
<seb128> if they do it there is a way
<seb128> breaking user desktop on upgrade is not right
<doko> seb128: No, they don't get it working, they use the Nimbus font, maybe just better rendered
<seb128> you said yesterday they keep using "Sans" and get a non-Nimbus font used
* Yagisan would be happy if he *could* print, even if it is ugly
<seb128> urg
<seb128> Nimbus is really ugly to use for desktop
<jdub> nimbus has been accused of being so ugly as to provoke physical harm to the nerves between the eye and brain
<Treenaks> http://www.osnews.com/story.php?news_id=14217
<doko> seb128: just install it in a vm
<seb128> jdub: users don't deserve to be imposed that
<doko> jdub: tell me a free alternative ...
<seb128> doko: install what?
<doko> seb128: just install a distro with "BAD" looking fonts
<seb128> doko: by reading the log you didn't mention to mdz that users will have to reconfigure their fonts to not have the ugliest desktop ever
<seb128> doko: I've switched my Ubuntu to "Nimbus" to try a few min ago, what would be different with an another distro?
<seb128> and I don't care about another distro looking right, I want my Ubuntu desktop looking right
<seb128> and it doesn't using that Nimbus font
<doko> seb128: dude, maybe you could just join the discussion on the ML, instead of whining?
<Kamion> janimo: done
<shadeofgrey> excuse me...
<seb128> stuff users have configured should not be changed under their feet on upgrade
<janimo> \o/
<shadeofgrey> im in a very desperrate situation here and i cant find anyboidy taht knows jack about using the fsck command propery
<Kamion> shadeofgrey: what's the problem?
<ajmitch> Kamion: silc-toolkit should have some contents now in the binary packages
<seb128> doko: I don't know enough about fonts to join a discussion on the list, I just say that changing UI to Nimbus on upgrade ... no
<doko> seb128: right, and letting people coming from windows having a bad experience with documents
<shadeofgrey> kamion:  all i needto know is what to type to get fsck to check my /dev/hdb1 partition, automatically fix any errors, be verbose about it, and skip every otherr filesystem in my fstab file
<doko> seb128: without giving any alternative
<seb128> doko: whatever you do, you have to not break the upgrade path
<jdub> doko: so - why is it that the top level generic aliases have an impact on documents?
<doko> seb128: we already did break with making DejaVU/Bitstream the default
<jdub> doko: like, i've never used 'sans' to create a document on a microsoft platform
<seb128> I disagree imposing Nimbus to lot of people who did choice their font
<Kamion> shadeofgrey: 'fsck -v -y /dev/hdb1' should do that, although it depends somewhat on the filesystem in use on that partition
<Kamion> ajmitch: thanks, will look at NEW again in a bit
<shadeofgrey> hang on ill look
<shadeofgrey> i dont need the -a switch?
<doko> jdub: one thing is Diziet's change to fontconfig, so that Times and Helvetica don't alias to Nimbus, but the preferred Sans and Serif, i.e. DejaVu at the moment
<shadeofgrey> its ext3
<Kamion> shadeofgrey: -a (or -p; same thing, but -p is preferred) is what the system does at bootup
<Kamion> shadeofgrey: it repairs some things, but -y is a good bit more aggressive
<shadeofgrey> okay so give me the whole line one last time then
<shadeofgrey> bearing in mind that the part in question is ext3 formatted
<doko> jdub: the other thing is that DejaVu is selected by default font for new documents, but this font isn't available on other platforms (maybe I don't care).
<Kamion> if you mean "safely fix simple errors", then -p is fine; if you mean "automatically fix EVERYTHING", then -y is fine
<Kamion> shadeofgrey: 'fsck -v -p /dev/hdb1' or 'fsck -v -y /dev/hdb1', depending on the above
<Kamion> caveat on the above is that your filesystem has to be really pretty badly shagged before there's a risk of -y actually doing any damage, in my experience anyway
<joelbryan> hi, I have made an interface for Gaim to handle irc:// links, filed a Bug #38115
<Ubugtu> Malone bug 38115 in ubuntu-meta ubuntu-desktop "A software for gaim that handles irc:// links in browser" [Normal,Unconfirmed]  http://launchpad.net/bugs/38115
<jdub> doko: yeah, so i don't understand why the generic aliases should resolve to the windows equivalents first
<shadeofgrey> thanks kamion its working!
<shadeofgrey> ill leave now
<shadeofgrey> i know im not supposed to be here..  but just oyut of curiosity did any of the core developers get my email of thanks for everything?
<seb128> joelbryan: hi, that's not the right package for the bug, reassign it to "Ubuntu" rather ... that's a separate application?
<shadeofgrey> i never got a message back from sounder saying my message had been released
<Kamion> shadeofgrey: I certainly saw it on IRC, not sure about mail; thanks, and good luck
<mdke> can someone tell me if gsfonts-x11 is installed by default in dapper?
<Kamion> seb128: (I just reassigned it to plain "Ubuntu" and subscribed desktop-bugs)
<joelbryan> seb128: yes
<seb128> Kamion: thank you
<doko> jdub: new documents take these aliases and spread them around the world. people trying to print these docs looks ugly. IMO we should use defaults, which many printers have as a builtin.
<Kamion> shadeofgrey: we certainly appreciate thanks - sorry it has to be in such a situation
<seb128> joelbryan: join #ubuntu-desktop maybe if you want to discuss it, than chan is sort of busy atm :p
<joelbryan> ok, sorry :-)
<dholbach> mdke: i shouldn't think so
<shadeofgrey> kamion:  its okay...  by the way did that string you gave me with -y in it include the switch thaats supposed to make it show progress bars as it goes
<Kamion> shadeofgrey: oh, sorry, no, that would be '-C 0'
<shadeofgrey> kamion:  and its not like its really that big a deal... im just dying.  everybody has to do that someday anyway, and..  its not like im afraid of it
<shadeofgrey> can I ctrl-break the operation and start it over?
<Kamion> shadeofgrey: I wouldn't advise ctrl-c'ing fsck myself
<phaidros> how to update alsa kernel-modules to latest? (i have the latest alsa-driver & ubuntu kernel headers in /usr/src and installed make-kpkg)
<shadeofgrey> okay fine ill just leave it
<shadeofgrey> no biggie
<Kamion> I usually find it a good opportunity for a coffee :-)
<Kamion> (or moral equivalent)
* shadeofgrey laughs
<jdub> doko: people on other platforms who try to print documents authored on linux platforms?
<jdub> s/linux/free/
<shadeofgrey> i hoipe i live to see dapper release in june.  its goiung to look like a very professional badass of a distro when everytuhing is done
<shadeofgrey> my only regret is that i never did manage to buy my mac laptop and 30inch cinema display
<doko> jdub: print or view, as long as the fonts are not included in the document
<Kamion> hey, you're lucky you have ROOM for a 30" cinema display
* Kamion eyes his cramped study balefully
<Riddell> Kamion: changelog added for apt-install
<shadeofgrey> okay ill leave now
<jdub> doko: dude, ultimately i don't think this is either a) solvable or b) our problem to solve
<shadeofgrey> im impeding progress
<Kamion> Riddell: thanks
<Kamion> shadeofgrey: we do like to keep the channel clear for development, but everyone's welcome to stay and watch if they want
<Riddell> pitti: I'm not sure if rc 1 works, I only tried it with the KDE tools, I can try it with the web frontend if you want
<Riddell> doko: why change to Nimbus?
<shadeofgrey> nah its cool.  i got detention the other day for distracting and trying to feed a few of the coders behind the security gate
<pitti> Riddell: I set up my printer with the current dapper version, then upgraded to rc1, but I only get ghostscript errors and a non-working usb backend. pretty frustrating...
<mdke> dholbach, thanks
<pitti> Riddell: do you have an usb printer?
<doko> Riddell: please see my mail to -devel
<Riddell> pitti: yes, let me go next door and test it
<doko> jdub: it's a problem if people com from other platforms and their docs look scrambled
<jdub> doko: right, but surely our aliases for their font names would 'fix' that (apart from the fact that we don't ship metric-compatible fonts)
<jdub> doko: that doesn't answer the question about our generic aliases though, because documents from other platforms don't use our generic aliases :)
<Kinnison> dholbach: the gparted guys never want us to settle, do they?
<dholbach> not really
<Kinnison> ogra: do you still need someone to look?
<dholbach> i can do the "update" again
* Kinnison apologises for being late, slept really poorly last night
<doko> jdub: but we fall back to metric incompatible aliases
<dholbach> Kinnison: but anyway... I doubt that our problem will be fixed
<Kinnison> dholbach: indeed
<Kinnison> dholbach: it's most odd
<dholbach> Kinnison: i'll get cracking on it
<dholbach> the update, that is
* Kinnison nods
<TheMuso> Mithrandir: ping
<jdub> doko: that only matters for non-generic fallbacks
<doko> jdub: is the end user interested if the fallback is generic or not?
<dholbach> Kinnison: hihi... apparently we're not the only ones in thinking that... nobody downloaded a tarball yet :)
<jdub> doko: ie. a friend gives me a document in times new roman (PUKE!), which fontconfig will not find, but fall back to thorndale amt. that doesn't exist, so it will fall back to something else that is not metric-compatible. we can't do better anyway.
<doko> jdub: we could fallback to Nimbus, which still looks better than falling back to DejaVu
<Kinnison> dholbach: *g*
<jdub> doko: yeah - and that should go in the list for 'times new roman', *not* sans
<jdub> or serif or whatever
<infinity> Indeed, I'd be inclined to say that if you use a generic name, you are prepared to not have compatible metrics.
<jdub> solving this properly involves combinatorial brainfuckage
<infinity> (This has certainly been the case for web designers for years, where generic names are the norm)
<jdub> so we can skim the major use cases off the top
<infinity> Printed documents should specify exact fonts if they want them, and then we can attempt to match those.
<jdub> attempt to fix those ('cos we can't be metric compatible and Free at the same time)
<infinity> Claiming "serif should be the same everywhere" is BS.
<doko> right, but then web pages don't use an absolute layout as word processors do (and no, abiword is not better in this respect)
<jdub> infinity: different argument
<jdub> doko: sure - please add numbus to the fallbacks for the specific font names
<jdub> (ha ha numbus)
<Kamion> infinity: all l-r-m binaries in; if you want to do linux-meta, go for it ...
<infinity> Kamion: I already did.
<phaidros> bugzilla vertificate has expired half a year ago ;)
<infinity> Kamion: Thpt. :)
<phaidros> s/vertivicate/certificate
* infinity was tailing the buildd logs and hovering over dupload.
<Kamion> infinity: heh
* sivang hugs Kinnison and sympthizes after having trouble falling asleep last night as well.
<Riddell> pitti: well cups from svn doesn't seem to want to talk to hplip and there's no suitable driver under HP
<pitti> Riddell: it doesn't want to talk to my usb printer either
<phaidros> howto build newer alsa-driver to ubuntu kernel?
<phaidros> just make? does this break something?
<infinity> phaidros: Please take this to #ubuntu, this is not a support channel.
<janimo> infinity: how close are you to #3 in your TODO :)
<infinity> janimo: If I fall victim to insomnia tonight, "very close".
<janimo> good. It's like with install images, once set up they go daily right?
<infinity> Yup.
<phaidros> infinity, hm ok. but i thougt its more a devel question ;)
<pitti> Riddell: ok, the usb refusal is just a device permission error; chmod 666 /dev/usblp0 cures it for me, and now it detects/prints happily :)
<infinity> phaidros: "How do I compile something" has nothing to do with developing Ubuntu itself.
<phaidros> infinity, yeah, but its about upgrading alsa in the latest ubntu kernel :)
<TheMuso> phaidros: A new kernel has come out on the archives. Have you checked to see whether that has the fixes etc that you are looking for?
<phaidros> TheMuso, which archive? the latest dapper kernel is running here
<TheMuso> phaidros: 2.6.15-20?
<phaidros> 2.6.15-19-686
<phaidros> ah!
<infinity> To be far, it only JUST got published, like 40 minutes ago.
<phaidros> TheMuso, not on dapper repos yet :9
<TheMuso> phaidros: Yes it is. I am grabbing it as we speak.
* phaidros is apt-get updating again ..
<phaidros> so far no restricted modules for 2.6.15-20 so far :/
<jdub> it has been uploaded
<Kamion> phaidros: wait, ooh, about five minutes
<phaidros> :)
<phaidros> kewl
<Kamion> $patience{phaidros}++
* pitti loves programs which suddenly work when being straced
<sivang> pitti: dead lock problem maybe and the slowdown solves it?:)
<phaidros> Kamion, its in :)
<infinity> phaidros: We know.
<phaidros> btw.  which alsa version is in ?
<dholbach> Kinnison: after first forgetting two hunks, then doing it again and deleting the wrong directory, the result is the same
<dholbach> Kinnison: it's up at http://daniel.holba.ch/ubuntu/gparted
<dholbach> narf...
<Kinnison> dholbach: When I've finished this launchpad test set so that there isn't an un-regression-tested patch to the uploader in production, I'll take a look
* dholbach hugs Kinnison
<phaidros> ok, 20 is nice, but still the same version of alsa-drivers as before.
<slomo_> Kamion: when you move gstreamer0.10-pitfdll to multiverse you should move pitfdll to multiverse too... it's in fact only a new upstream version of pitfdll
<ajmitch> phaidros: a lot of fixes get pulled from cvs for alsa
<phaidros> is there a howto anywhwere for compiling modules to an ubuntu kernel (I'm familiar with kernel in general, but not with procedures like make-kpkg)
<ajmitch> phaidros: have you filed a bug about what isn't working with the current kernel?
<phaidros> ajmitch, inot yet. i just have issues recording from line-in .. which is most likely an alsa issue ..
<phaidros> for that I wanted to try for myself before filing a bug ..
<phaidros> and its somehow urgent .. that why I really wanna try out latest stable alsa, if that doesn't bring it alsa-cvs and if all is not working filing bug to ubuntu and maybe alsa too
<Kamion> slomo_: I didn't particularly "move" it, I made a judgement on the new package and didn't notice the existing one
<Kamion> slomo_: I reckon anything which says that it needs w32codecs to work properly belongs in multiverse, personally
<JanC> <Kinnison> dholbach: the gparted guys never want us to settle, do they?
<JanC> there is only one "gparted guy", imagine what would happen if there were more...   :P
<slomo_> Kamion: me too ;) but to be consistent could you move pitfdll too?
<dholbach> JanC: one of those guys could help us figure out how to apply our installer patch correctly to the new version? ;-pp
<Kamion> slomo_: done
<slomo_> Kamion: thanks :)
<Diziet> doko: fontconfig> Can you remember all the stuff that was discussed at the timek ?
<Diziet> IIRC it was quite inconclusive and my mail to various places says `I'm far from convinced that this is a wholly correct solution' ...
<doko> Diziet: yes, I do, but not beeing able to print docs correctly seems to be bad either
<doko> Diziet: can't you just disable "use webpage fonts" in the preferences?
<Diziet> https://lists.ubuntu.com/archives/ubuntu-devel/2005-September/011659.html seems relatively clear.
<Diziet> *blink* I'm not sure disabling `use webpage fonts' is the right answer.
<Diziet> Can't we make fontconfig give different answers for printing and display ?
<Diziet> https://lists.ubuntu.com/archives/ubuntu-devel/2005-September/011667.html
<doko> Diziet: even then, that would not help for #31596 mentioned in https://lists.ubuntu.com/archives/ubuntu-devel/2006-March/016949.html
<doko> no, fontconfig cannot differentiate between devices
<Diziet> Well, can't we fix that for Dapper ?
<Diziet> It's not a question of the device so much as whether the metrics have to be right.
<doko> what you are asking is to modify all applications which take the default from fontconfig, so that just firefox displays not so ugly characters?
<Diziet> I don't mind which applications we change.  We could change firefox to set a `don't care about metric' flag, rather than the other way around.
<Diziet> Is it only firefox which uses fontconfig for display ?
<Diziet> (I mean, in a situation where the metrics don't have to be right.)
<Diziet> (They don't have to be right - ie, the same as the requested font - for printing in Firefox either, AIUI.)
<doko> apparently evince does as well, and displays wrong results
<Diziet> evince needs the metrics to be right.
<mjg59> evince currently appears to display stuff like utter arse
<mvo> is it a known problem that the current live-cd appears to be hanging on splash-down? nothing happens after the cd was ejected
<pitti> mvo: yes, press enter
<Diziet> doko: Let me think about a way to fix this in fontconfig.  I'll write up a suggestion on a wiki page and post to -devel.
<Diziet> Is there a relevant Malone bug atm ?
<doko> #31596 is one
<Diziet> Noted, thanks.
* Kinnison lunches, back later
<pitti> BenC: here?
<infinity>  * Stopping Common Unix Printing System: cupsd                                               [ ok ] 
<infinity>  * Starting Common Unix Printing System: cupsd    ...done.
<infinity> Something seems... COnfused.
<pitti> yes, that's a common display bug from our lsb init script fork
<infinity> Really?  First time I've ever noticed it.  Whacky.
* infinity notes that cupsys's init scrpit doesn't do a log_end_msg on start...
<Kamion> Riddell: belatedly, merged and pushed
<pitti> infinity: odd, I see that bug with e. g. postgresql all the time
<infinity> And restart does a spurious log_end_msg.
<infinity> pitti: Do you do a log_end_msg without a begin_msg in postgres, by any chance?
<pitti> infinity: for start it's indeed missing
<infinity> pitti: That looks to be the bug in cupsys.
<infinity> pitti: For start, it's missing ,and for restart, there's an extra that shouldn't be there at all.
<pitti> yep, indeed
<pitti> it fell down a few lines :)
<infinity> :)
<pitti> will use better nails next time, sorry
<infinity> Shall I upload for it, or are you on it?
<pitti> infinity: don't bother, I'm currently changing the cupsys package heavily anyway
<infinity> Ahh, rock.  Cool.
<pitti> added to todo list, thanks
<Riddell> Kamion: thanks
<ajmitch> infinity: are you planning to do mass rebuilds for openssl & mysql?
<pitti> huh, openssl?
<pitti> ajmitch: ah, for universe?
<ajmitch> hm, that's what I was told
<ajmitch> yeah
<pitti> ajmitch: would be nice to drop openssl097 entirely, yes
<infinity> ajmitch: I plan to do mass rebuilds for MySQL tomorrow (right after I let it through binary NEW, which I won't do until i have a mess of uploads ready to fire off)
<infinity> ajmitch: openssl isn't as urgent (since you can have both versions installed together), but it sure would be nice to get 097 gone.
<ajmitch> ok, we might as well handle openssl ourselves then
<infinity> I can do some of them, as they irritate me.
<infinity> But your best bet it to do mass no-change uploads, then see what fails to build.  Then go back and clean up the mess. :)
<ajmitch> and the bug reports we've started getting asking for rebuilds irritate me :)
<infinity> (While I'd normally never advocate such a thing, test-building more than 100 packages doesn't sound all that fun to me)
<infinity> 99% of packages should transition smoothly anyway.
<sivang> infinity: who said fun is to be inloved ?:)
<ajmitch> I'm sure I could build a few hundred easily enough :)
<infinity> It's only rarely that the 0.9.7 -> 0.9.8 API changes bite.
<infinity> And they'll always bite as a build failure, not a runtime failure, so you're safe from breaking anything.
<ajmitch> looks to be 89 source packages
<infinity> Oh, well, that's not so bad, then.
<infinity> And if any of them do FTBFS, I'm sure Debian's already got patches for all of them.
<ajmitch> yeah, I should be able to test-build those overnight without trouble
<infinity> (Most of the API changes are simple renames of constants and such)
<TheMuso> c/
<pitti> Riddell: ok, I finally discovered what's breaking cupsys; let's see whether it'll help you, too :)
<Riddell> pitti: what's that?
<pitti> Riddell: first, upstream always changes to 'nogroup' (that's fixed in debian/ubuntu since ages), and second the latest rc1 drops the user id, but not the group id in cups-deviced
<pitti> Riddell: i. e. it tries to access /dev/usblp0 (root:lp) as user lp and group root
<pitti> which fails, of course
<Toadstool> hi here, someone to review the last debdiff attached to bug 36505?
<Ubugtu> Malone bug 36505 in lintian "Ubuntu Lintian shouldn't do the nmu checks" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/36505
<pitti> Riddell: try sudo chmod 700 /usr/lib/cups/backend-available/*
* ajmitch wonders why we still have python2.1 & 2.2 in universe
<Riddell> pitti: no different, it still doesn't list the make under HP and HPLIP makes the web interface timeout
<BenC> pitti: yeah
<pitti> BenC: I tested the new kernel with the AE; works pretty well :)
<BenC> pitti: nice, thanks mjg59 :)
<pitti> BenC: however, do you get these 'ethX: link not ready' messages in dmesg, too?
<pitti> they are the cause for the initial dhcp timeout
<pitti> BenC: the cause is that the access point defaults to 'invalid'
<pitti> BenC: if I do 'iwconfig eth0 ap any' it instantly works
<pitti> BenC: do you get this with your card, too?
<BenC> haven't seen that
<pitti> might be special for the Airport Express, both ogra and I have it
<pitti> BenC: any idea why it could default to 'invalid'? is that a driver or a firmware issue?
<BenC> I have an AE too
<pitti> BenC: or, rather, any chance to set it to 'any' by default?
<BenC> probably softmac issue
<pitti> BenC: I got the same 'link not ready' error in -19, but then, after some fiddling and waiting, it suddenly went to 'link ready'
<pitti> but it didn't work (or I ran out of patience) with 20
<pitti> I just found that access point trick pretty neat, it could point to the real cause of that bug
<Kamion> argh
<Kamion> (random 'export DH_OPTIONS')--, especially when you're calling debian/rules in nested packages
<slomo_> pitti: does your airport extreme work now? mine still doesn't :(
<pitti> slomo_: yes, it works for quite a while now
<pitti> slomo_: n-m 0.5.1 worked like charm, 0.6.x totally broke
<ogra> pitti, would it be very hard to split out kdeedu langpacks ? 
<slomo_> pitti: i still don't get a connection to anything :) no matter whether i use nm or do it by hand... or whether the network is encrypted or not :(
<ogra> (we need to install the whole kde packs for 6 apps, splitting them would gian a lot of space)
<ogra> (in edubuntu that is)
<pitti> slomo_: http://people.ubuntu.com/~pitti/scripts/airport-extreme
<pitti> slomo_: that's an /etc/network/if-pre-up.d/ script
<pitti> slomo_: you can also run it manually of course, with IFACE=eth0 (or whatever)
<slomo_> pitti: hm, i didn't try to set the rate to 11mbps... maybe that was the mistake :)
<pitti> slomo_: yes, it's still necessary for me; also the 'ap any'
<pitti> slomo_: iwconfig -> does it show 'access point: invalid'?
<pitti> (that's what the ap any fixes)
<pitti> ogra: not hard, but it would result in yet another 100 packages or so
<ogra> pitti, i wouldnt mind ... if i can get more than one language on the CD afterwards ...
<pitti> but it was already controversial enough to split off kde/gnome langpacks, hmm
<mdke> infinity, see my ping about flashplayer? Just wanted an indication of whether there is a chance of getting it back, because we're finalising the desktop guide at the moment
<ogra> pitti, lets talk later about it (edubuntu meeting currently) 
<ogra> it was just an idea that came up
<mdke> Diziet, did you see my email about firefox homepage translations? is it going to be possible? if so, I'd like to start gathering some translations immediately
<Diziet> Yes, I saw your mail.  I haven't looked at the recent events yet.
<Diziet> I don't see why it shouldn't be possible to do it in dapper the way we planned to in breezy.
<mdke> Diziet, cool. thanks. are there recent events?
<Diziet> But note that this doesn't depend on a change to the firefox package.
<Diziet> Well, any recent events.  Your mail had a bug URL in it which I didn't read.
<mdke> ah, right. no, should be fine
<Diziet> IIRC
<mdke> but the firefox changes are for the locale-induced homepage url
<Diziet> The changes are to the langpacks and err, as documented on that wiki page I wrote.
<slomo_> pitti: rate auto doesn't work at all?
<Diziet> No, the homepage url has to be supplied by the mozilla-firefox-locale-foo-bar package.
<pitti> slomo_: no idea, didn't try that yet
<Diziet> That is, specified there.
<mdke> Diziet, yeah. don't you take care of that package?
<Diziet> No, not normally.
<Diziet> Last time I looked at it the build system turned out to be crazy.
<mdke> Diziet, ok, who do I ping about that? afaik, the langpacks don't come into it
<Diziet> Sorry, yes, I misspoke.
* mdke nods
<pitti> slomo_: alright, it works
<Diziet> Well, leaving it to whoever normally does that didn't work.  Why don't we put it on my plate ?
<pitti> slomo_: so, after loading the module, I just need to do 'sudo iwconfig eth0 rate auto ap any' and then it works 
<Diziet> What happened to the list of locales on DapperFirefoxStartPageTranslation ?
<slomo_> pitti: cool :) even with 54mbps? ;)
<pitti> BenC: ^ any chance to fix that in the driver? or do we need to invent an userspace solution for that?
<pitti> slomo_: no idea, I just have an 11mbit AP here
<BenC> pitti: I'll look into a driver fix
<mdke> Diziet, we haven't done one. there aren't any translations yet: I will mail the various translator lists to get some
<pitti> great :)
<Diziet> mdke: It's OK for there to be entries in the list for nonexistent translations.
<mdke> Diziet, ok, so what's the list for?
<Diziet> We'll make them be a symlink to the English version.
<Diziet> (Or some other plausible version.)
<mdke> yep
<mdke> ok i'll start the translation-hunt. and get back to you about changing mozilla-firefox-locale-all
<Diziet> The list is needed to avoid (a) `file not found errors' (m-f-l-all thinks the translation exists but ubuntu-docs doesn't provide it) or (b) translations not used (vice versa).
<Diziet> mdke: m-f-l-all> Sure.  Just remember that we are _not_ changing this list.  Write it once.
<Diziet> So it should contain all locales for which a translation _might_ become available.
<mdke> Diziet, so what you are saying is that the list should have a full list of locales?
<Diziet> More or less, yes.
<mdke> heh, right
<Diziet> But it doesn't have to contain locales where we're sure we're not going to have a translation.
<infinity> Diziet: Erm, wait.  How is this translation business going to work?
<mdke> i'll copy it from rosetta, or something
<Diziet> infinity: https://wiki.ubuntu.com/DapperFirefoxStartPageTranslation
<Kamion> Locales do get added from time to time; our plan has to include the possibility of new locales turning up later
<Diziet> kamion: Sadly the hack that is DapperFirefoxStartPageTranslation doesn't cope with that.
<Diziet> It would be nice if the browser had some more comprehensive support but this is not the case.
<Kamion> Diziet: that's unfortunate - some of the locales in question end up being ones we care about down the line
<Kamion> or have ended up being, in the past
<Diziet> We can change the list from release to release, IYSWIM.
* mdke nods
<Kamion> ah, that's ok then
<Diziet> But we don't want to change it in an update or the like.
<infinity> mdke: I haven't had a chance to hunt down the right people to ask yet, sorry. :/
<Kamion> but it should match the list of locales we have in each release?
<Diziet> And it's best for stability during the dev cycle if we avoiding change it if we can.
<Diziet> kamion: No, it can be a superset.
<mdke> infinity, ok, shall we go with the downloader package then?
<Diziet> It has to be a subset of the locales for which m-f-l-all provides a locale-specific jar.
<infinity> Diziet: So, using the .jar file, I can have multiple firefox locales installed, but I'll see the homepage for whatever my current locale is, right?
<Diziet> That's the idea, yes.
<Diziet> Just like you get translated menus and what have you.
<infinity> Excellent.
<Diziet> But it's a grim hack, hence the need for a master list of locales.
<mdke> ok, I can go trigger the translators?
<Diziet> mdke: Yes.
<mdke> great, thanks again
<Diziet> DapperFirefoxStartPageTranslation may be a grim hack but it's definitely better than nothing.
<Diziet> So, yes, let me know when you want me to break^Wmess with^W^Wadjust m-f-l-all.
<mdke> Diziet, I will
<infinity> If you update ubuntu-docs right now to provide symlinks for every locale that m-f-l-all ships, the m-f-l-all can be updated right now.
<infinity> Then the symlinks can be replaced with real files as they become available.
<Diziet> What infinity said.
<mdke> clever. could do that
<infinity> (Can the .jar not be made intelligent, so it looks for locale.html, and falls back to index if it's not there?)
<mdke> we need this damn list though
<Diziet> infinity: Unfortunately not; it's just static.
<infinity> mdke: The list is in the m-f-l-all source package.
<mdke> infinity, i'll look, thanks
<Diziet> Cut and paste it from there onto the wiki page and then into the ubuntu-docs package.
<Kamion> wow, I think my huge espresso reorg works
<Diziet> Quadruple with extra sugar ?
<Kamion> given the size the source package is about to become, probably, yes
<Diziet> Which reminds me, I need coffee.
<mdke> before I start the translators, does anyone see any typos or anything in the current browser homepage?
<infinity> Diziet: So, does it need to be an exact match, then? (ie: for fr-fr, the filename needs to be fr-fr, but for ca, just ca?)
<infinity> Err, fr-FR even...
<infinity> mdke: Current list of XPIs shipped in the locale-all package:
<infinity> ar bg-BG ca cs-CZ da-DK de-DE el en-GB es-AR es-ES eu fi-FI fr-FR ga-IE gu-IN he-IL hu-HU it-IT ja-JP ko lt mk-MK mn nb-NO nl-NL pa-IN pl-PL pt-BR ro-RO ru-RU sk sl-SI sv-SE tr-TR zh-CN zh-TW
<mdke> infinity, thanks. so I do links for each of those? does the address matter? something like /usr/share/ubuntu-artwork/home/en_GB ?
<Diziet> infinity: The exact list of filenames which exist (as translations or links) needs to be known.
<Diziet> /usr/share/ubuntu-artwork/home/index-LOCALE.html  according to the spec.
<Diziet> where LOCALE is en_GB or ar or something.
<mdke> ok, that would be better, it has the same relationship to the css file that way
<mdke> Diziet, so if people send me translations for locales which aren't in infinity's list, that will be ok?
<infinity> mdke: Extra files shouldn't hurt, they just will never be displayed by firefox without firefox having a corresponding locale installed.
<infinity> (which won't happen unless we get a firefox locale for that language)
<mdke> ok, fingers crossed
<Diziet> mdke: So I wouldn't encourage people to do that work !
<mdke> oh
* mdke has sent the email
<mdke> so if someone sends a translation, and there is no firefox locale, can a locale be made? 
<Diziet> I don't know how expensive making a new locale is but at the very least it's a PITA to synchronise the changes to ubuntu-doc and m-f-l-all
<mdke> I think I will try and include all translations that I get
<mdke> then if they don't appear, people can file bugs about missing firefox locales
<mdke> make sense?
<Diziet> Have you read and understood DapperFirefoxStartPageTranslation ?
<infinity> Makes sense to me.  If translators are willing to do the homepage, maybe that will motivate them to contribute full firefox locale updates, too.
<Diziet> Adding the locale is not something we'd do in an update, just to be clear.
<mdke> Diziet, sure. I wrote most of it
<infinity> mdke: Anyhow, just make sure everything in that list has (at least) a symlink.
<seb128> mdke: want to /j #ubuntu-desktop later to discuss your s-j icon issue? :)
<infinity> mdke: Anything EXTA is fine, but anything missing would be disastrous to the current plan. :)
<infinity> s/EXTA/EXTRA/
<mdke> infinity, will do
<mdke> seb128, i'd rather do it via the bug, I'm a bit swamped
<infinity> Diziet: It's possible we could see adding locales in -updates as a useful community service.  "updating locales for stable releases" is one of the reasons behind rosetta and langpacks, I don't see how m-f-l-all should be any different.
<seb128> mdke: it should take 1 min on IRC, but as you prefer
<mdke> seb128, i haven't got my dapper system booted
<seb128> mdke: k, I'll comment on the bug so :)
<mdke> seb128, thanks
<mdke> Diziet, infinity, so if debian/links for ubuntu-docs looks like this: http://mdke.org/links is that right?
<infinity> Hrm, one thing this scheme doesn't address is how derivatives can do translations of their branded homepages.
<infinity> (since index.html is an alternative, but we certainly don't want to make all 30+ translation homepages alternatives, that just gets messy)
<mdke> infinity, yes, it's all rather disturbing. Perhaps the problem is caused by this file being shipped by ubuntu-docs?
<infinity> mdke: Shipping it elsewhere wouldn't improve things any.
<mdke> infinity, ok. Is the localisation effort going to disrupt the kubuntu/edubuntu alternatives for that file?
<infinity> mdke: No and yes.
<mdke> for example, if someone uses edubuntu, and firefox, and one of those locales, is he gonna get an edubuntu homepage?
<ogra> i was pointing that out in breezy already ...
<infinity> mdke: Their alternatives will work just fine... For that one file... So, if you're running kubuntu in English, or in an untranslated locale, it'll continue to work as you'd expect.  If you're running kubuntu in a translated locale, you'll get the (translated) Ubuntu homepage, instead of the Kubuntu homepage.
<mdke> that's uber bad
<mdke> can we resolve that?
<infinity> It is really bad?
<infinity> I mean, it's bad if kubunt and edubuntu start getting translations too.
<infinity> But until then, I'd rather see a translated Ubuntu start page than an english Kubuntu one.
<infinity> (Especially if I don't speak English)
<mdke> interesting point
<mdke> ogra, ?
<jsgotangco> i think it works fine
<infinity> If kubuntu and edubuntu start getting translations, we need to make every single one of those index-LOCALE.html files an alternative.  Whee.
* jsgotangco runs to the warm server cave
<mdke> can we do a spec for sorting this out better in dapper+1, then forge ahead on this for dapper?
<jsgotangco> that would be fab (the spec)
<infinity> mdke: I'd just go ahead and do it as planned for now.  Any progress is better than none.
<sivang> mdke: what the last dead line for the translated firefox start page?
<mdke> sivang, eh?
<jsgotangco> should be the same for translation deadlines i presume
<mdke> ah oh right
<mdke> 18th May
<mdke> try sooner if possible
<sivang> yes, I have a close relative of mine that is going to help me with translation works as I do a load of other stuff, as you know :)
<sivang> cool, I'll let him know
* sladen successfully gets his wannabe HFS+ filesystem to crash the Mac
<infinity> sladen: Impressive.
<Diziet> doko: ping
<doko> here
<Diziet> I'm trying to edit the bash source package.  It has your name on it.
<Diziet> It seems to be using a crazy patch system.
<Diziet> I mean, even crazier than most.
<infinity> dbs?
<Diziet> Where is the documentation ?  And why isn't there any in the package ?
<mvo> original dpatch?
<Diziet> No, it looks like a bastard thing a bit like dpatch.
<infinity> Oldskool dpatch, yeahp.
<Diziet> Lots of the files are called something dpatch something but there is no build-depends on dpatch.
<infinity> Diziet: dpatch used to be included in debian/*, before it got packaged and standardised.
<infinity> Diziet: This is one of the older implementations. :)
<mdke> infinity, so if that links file is ok, I'll commit it and ask dholbach to upload
<Diziet> I wouldn't mind (actually, I would only mind VERY MUCH) rather than being COMPLETELY NAUSEATED) if there were some DOCUMENTATION.
* sivang looses one more part of his soul for knowing yet another packagin with non standard patch syste.
<sivang> package, even
<Diziet> My current plan unless someone gives me a better idea is to clone-and-hack something else from debian/patches and make sure never to edit a built tree.
<infinity> Diziet: I'm campaigning for a "debian/rules help". :)
<Diziet> *vom* but it's necessary I suppose.
<infinity> Diziet: I think I'll sneak it into both the default dh_make template and cdbs, so it becomes a defacto standard overnight, then push for a policy ammendment. :)
<doko> Diziet: yes, it's old dpatch ;-)
<Diziet> Yes, well, where is the documentation telling me how to drive it ?
<infinity> Diziet: The documentation is deciphering the makefile, sadly.
<Diziet> Right.  Well, I'll try my original plan then which doesn't involve deciphering the makefile.  It just means I have to edit the bash source code by editing a diff in Emacs.
<infinity> Diziet: And adding your new patch to the "debian_patches" list in the makefile.
<Diziet> Yes, I was going to grep for the name of the patch I was going to clone-and-hack.
<doko> Diziet: as infinity said.
<doko> if you are going to make an upload, please add the two upstream patches
<Diziet> This is almost as bad as editing firefox source code.  Why does a package have to have a build system nearly as impenetrable as the actual code for a ~1Mloc web browser ?
<doko> s/two/two new/
<Diziet> I'm not adding any upstream patches to this nightmare.
<HiddenWolf> guys, question
<HiddenWolf> I just came across wpasupplicant in my dist-upgrade
<HiddenWolf> Setting up wpasupplicant (0.4.8-1build1) ...
<HiddenWolf>  Removing any system startup links for /etc/init.d/wpasupplicant ...
<HiddenWolf> what is going on here? 
<slomo_> HiddenWolf: the init script is no longer needed... you can do everything you want with the interface configurations
<HiddenWolf> slomo_: I'd rather do nothing, It's a desktop, but the message looks Odd
<HiddenWolf> "let's install it, but let's not start/use it"
<Kamion> it's not started by an init script any more, that's all, it's launched elsewhere
<Kamion> (by the ifupdown infrastructure)
<slomo_> Kamion: are the packages you accepted from NEW today again on NEW for the binary packages? or is there something broken with the publisher? at least i don't see the binaries anywhere
<Kamion> slomo_: yes, source and binary NEW are independent
<infinity> (since you can't know what new binaries you have until they're uploaded, which requires the source being accepted and built)
<sladen> feck0ring apple
<slomo_> oh ok, thanks... infinity, why can't you know them before building? they're all listed in control... because they could fail on some archs by design and won't be there?
<sladen> now with added l3gacy support
<elmo> slomo_: debian source packages don't accurately describe what they build
<Kamion> slomo_: furthermore, I am *not* NEWing binaries before I see what they actually contain (i.e. dpkg -I, dpkg -c)
<mdke> dholbach, can you do a -docs upload at some stage, I've just added some stuff for browser homepage translation
<Kamion> I'm not processing them on the basis of debian/control, that's not good enough, I'd have to test-build to check that they're halfway sane in many cases, and why bother
<Kamion> slomo_: for example the multiple packages that I've caught over the last few days that built binaries that were empty except for documentation
<slomo_> Kamion: ok, sounds sane :) and that short additional delay won't hurt anyone normally
<Kamion> only the chronically impatient, generally
<mdke> Diziet, infinity, once daniel has uploaded an ubuntu-docs package (6.04.3), you can go to work on the mozilla locale thing, I hope. I've added links for everything in that list, except "lt", which has a translation already, so I've shipped that too
<trappist> anybody know what system-conf.xml is in the serverguide dir? 
<trappist> not currently used?
<Diziet> mdke: Right, thanks.  Can you make sure I get an email about it ?  I don't watch the uploads very closely and IRC isn't very reliable :-).
<mdke> Diziet, good idea
<mdke> trappist, ECHAN
<trappist> eh?
<trappist> god bless you
<bddebian> trappist: He is saying wrong channel :-)
<trappist> doh!
<zakame> LOL
<zakame> er ELOL
<bddebian> ENOTFUNNY
<bddebian> :-)
<Diziet> doko: You'll see I've just uploaded a bash with an appropriate fix.  The patch has gone to debbugs too (which is down atm) FYI.
<Diziet> doko: Also, I was wanting to talk to you about KRGB and hpijs (Malone 23099).
<Ubugtu> Malone bug 23099 in hplip hpijs "ghostscript needs patch for KRGB printing" [Normal,Rejected]  http://launchpad.net/bugs/23099
<infinity> mvo: Did you see the update-notifier build failure on 4/6 arches?
<mvo> infinity: no
<infinity> mvo: Oddly enough, the 4 arches that don't know how to deal with i386 objects. :)
* Chipzz pokes mvo :)
<infinity> mvo: Looks like you shipped binary objects in your source...
<mvo> infinity: *ick*
* mvo wonders if that might be because of his new arch-build target
<ogra> infinity, fix the arches then
* mvo looks
<mvo> infinity: have you considered qemu on the buildds for cases like this ;) ?
* infinity slaps mvo and ogra.
<ogra> hehe
<doko> Diziet: want to test me that?
<Diziet> Do you have a relevant kind of HP ?
<infinity> Riddell: kdebase is FTBFS on all arches again.
<infinity> Riddell: http://librarian.launchpad.net/1928485/buildlog_ubuntu-dapper-i386.kdebase_4%3A3.5.2-0ubuntu4_FAILEDTOBUILD.txt.gz
<Diziet> kamion: ping
<doko> well, it's a newer one
<Diziet> kamion: 19403 ?  Do you know anything ?
<Diziet> `console-* prompts unnecessarily on upgrade'.
<Diziet> I see it's assigned to me now but reading between the lines you might know something about it ?
<Riddell> infinity: that'll be my fault, fixing..
<Diziet> doko: Right, but one that does KRGB.  Apparently it's not working.  To test it I think you'll have to either peer at the output or arrange for one of your ink cartridges to be empty.
<Diziet> And then print something with some black.
<doko> Diziet: I'll check with the new hplip, which I'm currently preparing
<Diziet> OK, good, thanks.
<Diziet> It's possible that the KRGB support is disabled somewhere in gs-{esp,gpl}.  I didn't think so - certainly the patch is applied - but I could be wrong.  So if your ijs reports that gs doesn't have it, do let me know.
<Kamion> Diziet: IIRC it was a debconf prompt from console-data on upgrade, probably from either hoary or mid-breezy to breezy
<infinity> Kamion: Erm, did d-i recently change to try to include nfs-modules.udeb on hppa, or did linux-source recently change to drop that udeb?
<infinity> Kamion: Or did soyuz explode and throw it away?  Pick one. :)
<Diziet> Urr.  Do we have any reason to think it's still around somehow in Dapper ?  Fixing Breezy upgrades seems a bit late now ...
<Kamion> Diziet: it started off at oem-config because oem-config depends indirectly on console-data
* infinity looks for the last one.
<Diziet> Right.
<Kamion> Diziet: console-data hasn't changed much, so the underlying cause is probably still around and might bite us - but it *could* easily be just a subtly buggered install, or a trashed debconf database, or something like that
<Kamion> infinity: d-i recently changed to try to include it; why, is it not there?
<infinity> Kamion: Appears to not be.  If that's your bug or BenC's, let me know, and I'll pass it on.
<Kamion> infinity: I'll have a look, thanks
<Diziet> kamion: Joy.  I think I'll ignore it and wait and see if anyone confirms it.  Thanks.  I'll also paste this conversation into the bug report for future reference :-).
<Kamion> Diziet: yeah, sounds reasonable, I had been ignoring it largely because I hadn't been seeing large floods of reports about it
<Kamion> could easily be that it only happens with certain keyboard configurations, too
<Kamion> perhaps sivang can elaborate
<Diziet> Right, thanks.
<bddebian> Bullocks on imake/xmkmf
* bddebian breaks down and cries
<sivang> Kamion: where can I help?
<Diziet> Your console-data bug report.  See the comment I've just added.  Malone 19403
<Ubugtu> Malone bug 19403 in console-data "console-* prompts unnecessarily on upgrade?" [Normal,Unconfirmed]  http://launchpad.net/bugs/19403
<bddebian> fabbione: ping?
<sivang> Kamion: should I attempt reinstall to see if this still happens? (I'm on dapper now)
<Kamion> sivang: 'debconf-show console-data' might help
<Kamion> sivang: I wouldn't trash your existing install just for this, though
<sivang> Kamion: Well, I have a couple of dapper / breezy vmwares here I can snapshot and go back
* sivang upgrades the VM before testing.
<sivang> Kamion: for my desktop here, this has lots of output
<sivang> Kamion, Diziet : anything particular I should be searching in the output of debconf-show console-data ?
<Diziet> If you know what question it asked then you can see whether it's listed.
<sivang> Diziet: k, I'll check
* Diziet looks at the console-data package.  Hmm, it's all using some complicated script.
<Diziet> Definitely save the output of the debconf-show before and after.
<Diziet> How many times has this happened to you ?  Just the once ?
<sladen> http://www.paul.sladen.org/ubuntu/mactel/pic_0008.jpg with the new Apple legacy compatible firmware crack
<sivang> Diziet: I can't recall, but at least 1 , the first time I installed after Colin made me curious about oem-config ...sorry
<Kamion> sladen: hang on, you mean syslinux actually works?
<siretart> does the dapper live cd has an option to say 'do not use swap partitions you might find on my hard drives'?
<sladen> Kamion: yes;  just no efi, so no way to actually 'install' a boot loader.  And the vga emulation is particularly lacking
<sladen> Kamion: bootloader comedy: http://www.paul.sladen.org/ubuntu/mactel/pic_0006.jpg
<Kamion> ah yes
* sivang arghs at gnome-terminal and his random decision to allow open a link or open a teminal when hovering the mouse over one.
<sivang> at least it offers me to "copy link address"
<sivang> Diziet: hmm, I installed oem-config on the physical machine, diff between the two outputs is clean now. Doesn's show any differences.
<sivang> (of before and after installation of oem-config)
<Kamion> sivang: oem-config is *totally irrelevant* except that originally when you installed it it upgraded console-data too
<Kamion> sivang: the console-data upgrade is what matters. Forget entirely about oem-config.
<ogra> sladen, oh, you dyed your hair !
<jsgotangco> eh?
<sivang> Kamion: okay, I'm sorry :-/
<jsgotangco> he removed it lol
<Kamion> sivang: so you need to install hoary and upgrade to breezy, or install breezy and upgrade to dapper, or similar
<sivang> Kamion: k.
<pitti> mdz: bad news about cups :(
<mdz> pitti: hmm?
<pitti> mdz: I spend hours and hours on making 1.2rc1 work, but it seems that upstream did a very good job of making this incredibly hard
<mdz> pitti: making it hard to make it wokr?
<mdz> work?
<pitti> mdz: yes; they removed RunAsUser, authentication does not work at all, web interface is broken and hangs, it doesn't work with hplip any more (for Riddell at leastt)
<pitti> mdz: I was able to at least repair the USB/parallel backend
<pitti> but in the current state it would require a serious amount of work
<sivang> oh god
<pitti> mdz: so I'm seriously considering rolling back to 1.1.23 ATM
<mdz> pitti: urgh, let's forget it then
<mdz> pitti: b1 is worse than 1.1.23?
<pitti> mdz: not really, our svn snapshot works pretty well
<pitti> apart from some bugs, which I need to fix, of course
<pitti> but 1.2 breaks with KDE (see yesterday's bounty discussion)
<mdz> pitti: then why roll back?
<pitti> mdz: well, first because it's an svn snapshot and upstream also fixed lots of bugs in it
<pitti> mdz: but mainly for that KDE thing
<pitti> mdz: if we can get KDE fixed, then I can port the bug fixes to our snapshot as well, of course
<sladen> ogra: that's mjg59
<pitti> mdz: if we can live with a svn snapshot in a stable release
<ogra> sladen, i know, was joking ... 
<pitti> mdz: sorry for discovering that so late, I didn't expect this to fail so horribly
<ogra> mdz, any objections against upgrading ltspfs/ltspfsd to the recent CVS ? sbalneav did a lot of fixes and told me it works flawless on ubuntu now
<mdz> pitti: we'll see what kdeprint upstream says
<mdz> ogra: none
<ogra> yay :)
<pitti> mdz: Riddell said that he would be keen to port it; yes, let's see
<Riddell> mdz: they guy said he'd like to do it but says he'll have to think about how he can make time and find hardware to do it on (for installing kubuntu)
<Riddell> mdz: I've told him a quick response would be appreciated
<phaidros> hi. what packages are needed to recompile the ubuntu kernel? (i have linux-headers so far, but get make errors, make menuconfig is fine)
<mjg59> phaidros: apt-get source linux-image-2.6.15-20-686 (or whatever)
<mjg59> Is the easiest way
<phaidros> make[2] : *** No rule to make target `init/main.o', needed by `init/built-in.o'.  Stop.
<phaidros> mjg59, true, but i need to try a kernel without oss support, because that might be solving a line-in problem here ..
<mjg59> phaidros: apt-get source linux-image-2.6.15-20-686
<mjg59> The headers don't contain the kernel source
<lamont> hrm.. /me wonders where evms gets it's configuration info...
<ogra> hmm, why has malone no dapper+1 milestone ... :/
<NAiL> How would I go about getting a kernel patch into ubuntu?
<NAiL> (simple fix, blacklist c2c3 on my thinkpad r40e)
<Diziet> Is it a bug that tar -x stops working properly if your umask includes 0200 or 0100, I wonder ?
<Diziet> Unless you say -p, in which case it doesn't care even if the dirs in it all have mode 0 ...
<mvo> mdz: update-notifier 0.41.11 was a really bad upload (a bug after moving from svn to bzr). 0.41.12 should be availalbe soon and is (hopefully) actually working :P
<mdz> NAiL: #ubuntu-kernel or kernel-team@lists
<mdz> NAiL: though surely it would be better to try to diagnose the problem and get it working than to blacklist it?
<elmo> oh for god's sakes
<elmo> I wish people NIH-syncing would at least be consistent
<ogra> NIH ? national health institute ? 
<tepsipakki> not invented here?
<tepsipakki> oh, "knights who say NIH!"
<KaiL_> huh? something in main depends on something in universe? How is that possible?
<KaiL_> even worse, it's update-manager depending on "unattended-upgrades", a tool for fully automatic installation of security updates
<ogra> its simply not promoted aet
<ogra> *yet
<KaiL_> not to mention, that this tool misses an obvious option to disable it
<KaiL_> as some people might not to want that
<mvo> KaiL_: easy, installing it dosn't mean that it will magically start :)
<mvo> maybe I should add this to the package description ...
<KaiL_> uhm, yes
<KaiL_> and maybe to readme, how to start it then ;)
<janimo> mvo, is gnome-app-install part of the 3rd party packages spec?
<mvo> KaiL_: yeah :) the easiest way is to just click on it in the gnome-software-properties window
<mvo> janimo: yes, why?
<janimo> some people said they'd want it for xubuntu
<mvo> *ick*
<mvo> it uses gconf :P
<ogra> lol
<mvo> and gtkhml2
<ogra> have fun ripping it apart :)
<mvo> and ...
<janimo> mvo, yes I saw that :)
<mvo> maybe more
<KaiL_> ah, cool!
<janimo> so besides is and gdebi are there other apps in the 3rd party spec?
<mvo> KaiL_: see /etc/cron.daily/apt for some more information how it can be enabled (it's a apt config option)
<dholbach> mdke: i'll do an update now
<mvo> janimo: yes, gdebi is lean, it only needs python-vte and python-apt (of course)
<mvo> no gconf IIRC ;)
<janimo> mvo, gdebi is already in xubuntu ;)
<mvo> oh, nice
* mvo hugs janimo
<janimo> just want to see what is lost if g-a-i is not there?As I see for skype & all gdebi suffices 
* janimo hugs mvo 
<dholbach> mdz: do you think we can seed gimp-print into ubuntu-desktop? it's built from the gutenprint source package (which is in main) and would give us printing capabilities for gimp (atm it's a recommends of gimp)
<ogra> wasnt that in main in breezy ? 
<dholbach> ogra: might be, but then gimpprint (source package) -> gutenprint (source package) and things changed
<ogra> yep
<mvo> janimo: currently it is mostly a nice way to install stuff, but when we get more 3rd party support it will (hopefully) become a plattform to install interessting stuff
<mdke> dholbach, yippe
<janimo> mvo, planned for dapper?
<ogra> i think i remember we moved it to universe when gutenprint enetered
<mvo> janimo: yes, updates can be shiped easily with new data files
<janimo> ok, sounds very useful
<dholbach> anyway... we keep getting bug reports about "gimp can't print" every now and then and having it in ubuntu-desktop might rememdy that
<mdke> dholbach, hold on the -docs upload for a moment, if you can
<dholbach> right
<dholbach> ogra: yet another new dia :)
<ogra> thanks
<mdke> dholbach, ok, go again, sorry about that
<NAiL> mdz: It'd be nice if there was a way to work around it. But the moment I load the processor module, the box hangs hard.
* mvo goes out for a bit
<NAiL> I'm not the one able to figure out how to actually pic it. 
<NAiL> s/pic/fix/
<dholbach> mdke: done
<highvoltage> it feels strange using a pre-release ubuntu with a gnome version number like 2.14.0
<highvoltage> it should be something like 2.13.96 or 2.15.89 :)
<ogra> but we'll release with 2.14.1 :)
<highvoltage> which will also feel strange :) usually it's .0 :)
<siretart> hm. am I supposed to do anything magic for making the rootfs autodetection work? when I leave out the root= kernel param, the boot procedure hangs at 'waiting for sysfs'...
<bddebian> fabbione: ping?
<Riddell> Kamion: components moved back into espresso's bzr?
<ogra> should we update lsb ro have 6.06 instead 6.04 ? 
<ogra> s/ro/to/
<bddebian> Hey Riddell, do you know imake/xmkmf?
<Riddell> bddebian: god no
<bddebian> Riddell: OK, sorry :-)
<Riddell> bddebian: what's the problem?
<bddebian> I believe that ivtools is exporting the wrong path for X11 config stuff so it breaks mxv build
<bddebian> But I can't get it to change XCONFDIR on build.
<Riddell> just as I suspected, I've no idea how to help
* bddebian jumps off a cliff
<bddebian> Riddell: NP, thanks anyway
<_mvo_> ogra: lsb_relase needs to be changed, yeah
<mdke> dholbach, thanks
<ogra> yep
<ogra> i just noticed its still at .04
<Riddell> lab-release is already changed for me
<Riddell> lsb-release rather
<ogra> or the one with underscore :)
<bddebian> Oh shit, because build extracts the tarball everytime so it's overwriting my changes :-(
<ogra> ogra@edubuntu:/mnt/devel/packages/xorg-7.0.0$ lsb_release -r
<ogra> Release:        6.04
<Riddell> jr@pechin3:~>lsb_release -r
<Riddell> Release:        6.06
<ogra> ogra@edubuntu:/mnt/devel/packages/xorg-7.0.0$ sudo apt-get install lsb-release
<ogra> Reading package lists... Done
<ogra> Building dependency tree... Done
<ogra> lsb-release is already the newest version.
<ogra> :(
<Riddell> try updating base-files
<ogra> how did you manage that ? 
<ogra> oh, yes :)
<Riddell> Kamion: where is /usr/lib/espresso/localechooser/localechooser ?
<carlos> seb128: hi, around?
<dholbach> carlos: he went for dinner
<carlos> dholbach: ok, thansk
<dholbach> de rien
<carlos> dholbach: perhaps you could answer my question
<dholbach> i'll try
<seb128> carlos: pong
<carlos> dholbach:  do you know about any change with latest GNOME that produces a 'beep' without any explanation?
<carlos> seb128: ^^^
<seb128> GNOME?
<seb128> since when?
<dholbach> beep? when? a real sound or a pcspkr beep?
<seb128> you might have the xchat-gnome sound plugin?
<seb128> so when somebody highligt you, you get a sound
<carlos> well, a standard GNOME installation. I have open Evolution, xchat-gnome and firefox
<seb128> or beep on completion?
<carlos> seb128: no, it's not that
<lucas> hibernate and sleep don't work with my laptop (but hibernate worked with breezy). Against which package should I file a bug ?
<carlos> seb128: I don't see any feedback about the 'beep'
<lucas> I filed one a month ago against linux-2.6.15, but received no answer, so it's probably not the good package :-)
<carlos> seb128: it started today
<seb128> carlos: is that a speaker beep or a sound played?
<carlos> speaker beep
<seb128> probably not GNOME
<seb128> we didn't do any real GNOME change for 1 week or so
<carlos> seb128: hmm I have gaim setup to use 'console bell'
<carlos> perhaps it's that...
<seb128> probably
<seb128> did you install gaim 2.0beta3? :)
<carlos> but I don't see any status change there
<Kinnison> ciau all
<carlos> nomeata, 1.5.1cvs
<carlos> grr
<carlos> nomeata: sorry
<seb128> k
<carlos> nomeata, 1.5.1cvs
<carlos> fuck
<dholbach> :-)
<seb128> so no reason it should have changed
<carlos> I cannot type 'no'
<seb128> don't use "," as separator
<seb128> I keep ":" for that reason :p
<dholbach> bye Kinnison
<dholbach> does it beep for irc notifications?
<carlos> seb128: ok, I think it's the join/leave notification from gaim
<seb128> did you change that yourself?
<seb128> because gaim package didn't change
<carlos> seb128: seems like the new kernel version I got today fixed the system bell and that's why I was not earing it until today
<seb128> k, that was my next supposition :)
<seb128> (that something fixed your bell)
<carlos> seb128: yes, I changed it so it doesn't locks the sound card and I'm able to use a broken VOIP client that needs the card completely free 
<seb128> k
<seb128> anyway diner time
<seb128> bbl!
<carlos> seb128: thanks for your input ;-)
<seb128> you're welcome ;)
<carlos> the beep was driving me crazy
<seb128> better now so :)
<seb128> see you:
<carlos> seb128: bon apetite
<_mvo_> dborg: fancy to do some notifcation-daemon hacking ;) ?
<dborg> _mvo_: I hope to have a look at it and maybe try that prelight idea, but it would probably be a bad idea to rely on that :)
<_mvo_> dborg: if you could do the pre-light, that would be great :) I banged my head against the wrong drawn bottom panel notitifactions today and it turns out that the whole calculartion of the arrow points is bogus
<_mvo_> this thing needs a serious rewrite :)
<dborg> _mvo_: I see :) I tried to find that bug before but the code scared me
<_mvo_> dborg: but pre-light should be easy :)
* bddebian smashes ivtools with a BIG hammer
<dborg> yeah I hope so
<kagou> BenC, i'v talked you this morning that you have (perhaps) closed Bug #31502
<Ubugtu> Malone bug 31502 in linux-source-2.6.15 "Incorrect MAC address on card (00:00:00 in device portion)" [Normal,Confirmed]  http://launchpad.net/bugs/31502
<kagou> in fact in syslog i'v messages that say that he can not load prism firmaware (isl3886)
<kagou> so wifi don't work at all. Do you have an idea ?!
<_kagou> BenC: http://pastebin.com/642641
* lamont idly notes that rebooting a dapper machine during sw-raid5 recovery "hangs" in starting evms.  then again, eta on finishing the recovery at the time of the reboot was just under 3 hours... so maybe it's just waiting for that..
<lamont> hrm... /me tests his theory
<BenC> kagou: is that with 2.6.15-20?
<BenC> The failure you show has to do with either missing firmware, or firmware upload error in general
<kagou> BenC, yes since last upgrade (since 1H)
<BenC> kagou: does the firmware exist?
<kagou> linux-image and restricted was upgraded
<kagou> yes
<kagou> BenC,  NO !!!
<kagou> ?!
<kagou> request for a isl3886 but only 3890 is provided (as in 2.6.15-19)
<kagou> i dont understand as it worked with 3890 before :/
<kagou> may be alink ?!
<BenC> kagou: can you find the firmware?
<BenC> it may be that you are now using prism54_softmac
<BenC> oops, no, it's islusb
<kagou> BenC, may be can i rename isl3890 in isl3886 ?!
<BenC> you can try, but I suspect that it really needs 3886
<mjg59> BenC: Did you add softmac firmware?
<BenC> mjg59: no, I didn't
<mjg59> If not, it's probably the case that the driver has changed from being prism54 to prism54_softmac for that card
<BenC> yeah, I'm looking at the prism54 firmware now
<mjg59> kagou: do rmmod prism54_softmac; modprobe prism54 and things should work
<mjg59> (as root)
<kagou> yes i'm testing renaming firmware
<BenC> kagou: http://daemonizer.de/prism54/prism54-fw/
<mjg59> kagou: Renaming the firmware will not work
<kagou> yes i see that
<kagou> i'm going to test your solution
<_kagou> mjg59: sudo rmmod prism54_softmac
<_kagou> Password:
<_kagou> ERROR: Module prism54_softmac does not exist in /proc/modules
<mjg59> kagou: Oh, it might be called something else
<kagou> _kagou, BenC kagou: http://daemonizer.de/prism54/prism54-fw/
<mjg59> islsm_pci or something?
<_kagou> mjg59: root@tchoupi:~# lsmod | grep isl
<_kagou> islsm_pci              24712  0
<_kagou> islsm_device           13000  1 islsm_pci
<_kagou> islsm                  40716  2 islsm_pci,islsm_device
<_kagou> ieee80211softmac       31104  1 islsm
<_kagou> ieee80211              37832  2 islsm,ieee80211softmac
<_kagou> crc_ccitt               2496  2 islsm,irda
<mjg59> kagou: Right. rmmod islsm_pci and the modprobe prism54
<_kagou> ok mjg59 it's do
<bddebian> I assume one would have to be a main uploader to help the X Swat team?
<kagou> mjg59, modprobe prism54 do nothing
<Amaranth> bddebian: you could do bug triage and/or give debdiffs
<bddebian> Amaranth: OK
<Amaranth> which would help when/if you apply to join the ubuntu-dev group :)
<bddebian> Amaranth: I don't think they would ever have me :-)
<kagou> mjg59, argll a freeze on notebook :p  trying again to modprobe prism54 ... see in syslog that prism54 : request_firmware ('isl3890')
<kagou> but eth2 : could not upload this firmwarez
<kagou> mjg59, i rebooted on 2.6.15-19 and all is  working
<kagou> can i block the loadind of module  islsm_pci  ?
<_kagou> BenC mjg59 my card is showed as (with lspci) : 0000:00:0a.0 Network controller: Intersil Corporation Intersil ISL3890 [Prism GT/Prism Duette]  (rev 01)
<_kagou> not isl3886
<kagou> BenC, you show me http://daemonizer.de/prism54/prism54-fw/ but i can't find wich i must take
<sns> Hi! I'd like to get in touch with someone from the Xen team.
<poningru> ##xen
<kagou> i'm tired. nothing work ... sniff :/ 
<sns> thanks
<mroth> mjg59: question re: bug 35174.  you want me to enable ACPI_SLEEP and then test *hibernate* with it enabled?
<Ubugtu> Malone bug 35174 in acpi-support "ThinkPad X60 cannot resume from sleep/hibernate" [Normal,Unconfirmed]  http://launchpad.net/bugs/35174
<kagou> see you later
<mjg59> mroth: Yes
<mroth> mjg59: okay, just checking since it sounded strange.  will do so now.
<kagou> mjg59, or BenC is it normal to have /lib/firmware/isl3886 ?! firmware are in /lib/firmware/'uname-r'/
<mjg59> kagou: I'm afraid I don't understand the question
<kagou> look here mjg59  :: _kagou BenC: http://pastebin.com/642641
<kagou> we have "main: error loading '/lib/firmware/isl3886'"
<kagou> firmware are not directly in /lib/firmware
<mjg59> kagou: Do you have the isl3886 firmware?
<kagou> no
<kagou> my card need a isl3890
<mjg59> Then whether that error is accurate or not is not your problem
<mjg59> kagou: As I've already told you, the islsm_pci driver needs different firmware to the prism54 driver
<kagou> mjg59, do i understand that now. my wifi card is no more supported ?!
<Kamion> Riddell: run 'debian/rules update' if building from bzr
<kagou> and i have to search for a isl3886
<mjg59> kagou: No, that's not correct
<kagou> i'v found 2 but none of them works ... so i'm very disapointed
<ogra> mdz, i cant reproduce your comment on bug 33748, -xrm has no influence at all on any of my machines here 
<Ubugtu> Malone bug 33748 in xscreensaver xscreensaver-data "[dapper]  images not grabbed from /usr/share/backgrounds" [Normal,Confirmed]  http://launchpad.net/bugs/33748
<kagou> mjg59, i think that i must open a bug on linux-source and we will try to close it 
* mvo goes to bed
<mdz> ogra: you get background images?
<mroth> mjg59: no such luck, same behavior, updated bug 35174 to reflect
<Ubugtu> Malone bug 35174 in acpi-support "ThinkPad X60 cannot resume from sleep/hibernate" [Normal,Unconfirmed]  http://launchpad.net/bugs/35174
<mjg59> mroth: Ok, thanks
<mjg59> mroth: But by the sounds of it, it now gets further than it did before?
<mjg59> (New kernel against old kernel)
<mroth> mjg59: hmm.. actually, slightly less far.  before it would show the status for the 'resuming from disk' status or whatever
<mjg59> mroth: Yeah, that actually means it's getting further
<mjg59> The brown lines appear when it's trying to change back to X
<mjg59> (It all gets a bit confusing)
<ogra> mdz, i get what i set in ~/.xscreensaver or in the system config in /etc/X11/XScerrnsaver
<ogra> *XScreensaver
<mdz> ogra: you see images from /usr/share/backgrounds or not?
<mdz> I certainly don't
<ogra> yes, i see them
<ogra> and -xrm doesnt override that 
<ogra> hmm
<Kamion> Riddell: I *could* add the whole lot to bzr, but I don't really want to if I can avoid it; pushing the bzr archive takes long enough as it is
<mdz> ogra: yes, -xrm doesn't seem to override  the config file
<ogra> mdz, and both files (~/.xscreensaver and /etc/X11/app-defaults/XScreenSaver) have the /usr/share/backgrounds imagedir ? 
<mdz> ogra: just updated the bug
<ogra> ah
<ogra> hmm
<ogra> i dont want to wipe user configs :(
<kagou> cya
<dieman> sdier@riesling:~$ cat /proc/mdstat
<dieman> Personalities : [raid5] 
<dieman> md0 : active raid5 sdb1[0]  sde1[3]  sdd1[2]  sdc1[1] 
<dieman>       430115904 blocks level 5, 64k chunk, algorithm 2 [4/4]  [UUUU] 
<dieman>       [======>..............]   resync = 34.6% (49652544/143371968) finish=2.7min speed=563516K/sec
<dieman> unused devices: <none>
<dieman> theres a cute bug in the server kernel
<dieman> (note the impossibl speed)
<dieman> impossible
<Kamion> elmo: have you had a chance to look at my mail about archive issues for some breezy-security uploads?
<elmo> Kamion: well I saw kinnison replied, so I was hoping it had been dealt with ;-)
<Kamion> that was just on the soyuz side, one issue out of four ;)
<elmo> doh
<ogra> wheee !!!! 
<ogra> looks like the "screensaver ignores user input" bug is fixed !!
<dieman> ogra: yay!
<ogra> and its a silly one line patch ...
<ogra> tsk 
<Kamion> Mithrandir: any progress on the timezone->country->recalculate-locale work you were doing for espresso?
<Kamion> or were going to do, at any rate
<Kamion> Kinnison: any progress on the location page UI work that IIRC you were going to look at?
<tsdgeos> jordi: ping
<tsdgeos> jordi: check mail when you can
<_TomB> what is the easiest way to remake the initrd.gz after I have modified the contents?
<TheMuso> _TomB: Is this on the install CD or the live CD?
<_TomB> LiveCD
<jordi> Burgwork: ping
#ubuntu-devel 2006-04-11
<_TomB> I have a directory tmp/ with the files and directories in
<Burgwork> jordi, pong
<TheMuso> _TomB: What did you need to update?
<_TomB> some casper scripts
<TheMuso> _TomB: I suggest grabbing the source casper package, adding the scripts to that, rebuilding, and installing the casper package.
<TheMuso> Then you need to update the initramfs of the kernel used on the live CD. It helps if you have the -386 kernel installed on your system.
<_TomB> what's the easiest way to rebuild into a .deb?
<TheMuso> _TomB: Grab the source, make the changes you want, and then in the main sorce directory, run dpkg-buildpackage -rfakeroot. Make sure you have casper's build dependancies as well as fakeroot installed.
<Red_Herring> hey, anyone concidered adding easyubuntu to dapper by default?
<Burgwork> Red_Herring, not for dapper. Something like easyubuntu would need to be discussed early
<Red_Herring> hrm, couldnt it be concidered "polishing"?
<Burgwork> Red_Herring, it is a significant new feature and is not polishing
<Red_Herring> well, easyubuntu is already finished, if i am not mistaken
<Red_Herring> i dont think it would be difficult to just add it to the start menu by default
<Burgwork> Red_Herring, finished != integrated
<Red_Herring> but ill take your word for it
<Red_Herring> Burgwork: all it needs ot be "integrated" is to have a applications menu entry
<Burgwork> Red_Herring, https://wiki.ubuntu.com/DesktopTeam/CommonInstallHook
<jordi> Burgwork: hmm, want to test the Debian fix for your nano bug?
<jordi> the Ubuntu package will need to be different, due to uvf
<Burgwork> jordi, my nano bug?
<jordi> the crontab editing thing
<jordi> I think you reported it
<Burgwork> jordi, was that a reportbug paste jobby?
<jordi> oh, probably
<Burgwork> ah
<Burgwork> the email for the reporter is there
<Red_Herring> has ANYONE taken any consideration on allowing the end user to install 3rd party apps that arent FOSS without all the terminal work?
<Burgwork> Red_Herring, yes, via searching for them in Add/Remove or Synaptic
<Red_Herring> Burgwork: uhh, they arent added by default, they are in the multiverse, and there still isnt java1.5 in the repos
<Red_Herring> maybe the latest update in the past 10 days or so has changed that, but not since i used it last
<Burgwork> Red_Herring, this is very much an understood problem and I understand it is annoying that the solution isn't here, but it is not going to happen for dapper
<Red_Herring> so what was the "6 weeks for polishing" for?
<Burgwork> fixing hte 9000 open bugs in Malone
<Red_Herring> w/e, i can help w/ the next release, but i still think its not that hard to have easyubuntu installed by default, and to just add it to the menu 
<Red_Herring> have it be dapper or the next release
<Burgwork> sorry, make that 9500 open bugs
<Red_Herring> Burgwork: hrm, so in the mean time, how hard is it for a guy to add it, im willing to do it myself, but i wanna know if anyone will take my idea seriously
<Burgwork> Red_Herring, here are the steps that are needed to make Easy ubuntu be available in ubuntu
<Burgwork> 1 - Package EasyUbuntu in .deb and get it into the repos
<Burgwork> 2 - Fill out a MainInclusionReport to get it into main
<Burgwork> 3 - ask the devs to add it the install cd
<Red_Herring> and i got what? 8 weeks to do this?
<Red_Herring> well, i know there is a freeze in the last few weeks or so
<Red_Herring> so more like a month
<Burgwork> sooner is better
<Red_Herring> but is this idea gonna be taken seriously?
<Burgwork> it would be great to get it packaged
<Red_Herring> are there any serious problems that i dont know about?
<Red_Herring> other than the ppc version doesnt have much features
<_TomB> Thank you TheMuso 
<Burgwork> Red_Herring, get it packaged and then we can have this dicussion again
<Red_Herring> ... any ideas where i can get a howto on that?
<Red_Herring> i have no experiance w/ packaging once so ever
<Burgwork> Red_Herring, ask in #ubuntu-motu
<Burgwork> they will get you going
* Red_Herring wonders if they will tell me to go to #ubuntu-devel
<Burgwork> nope
<Burgwork> Red_Herring, you might also want to coordinate with this person http://forum.ubuntu-fr.org/viewtopic.php?id=31515
<Red_Herring> thanks... i dont speak french
<Burgwork> Red_Herring, that is a surmoutable problem
<Red_Herring> google translator...
<Red_Herring> so someone already made a package...
<Red_Herring> that makes things exponentially easier
<LaserJock> Red_Herring: where? and it might be better to move to -motu
<Red_Herring> http://frazap.freehostia.com/easyubuntu_20060327.deb
<Red_Herring> ok, but this is just an idea, i really should not be made responsible for maintaing anything
<nekohayo> hey there, if I want to file a bug on the logout dialog, what is the package name?
<sladen> nekohayo: I'm not actually sure.  Try gnome-panel
<jdub> nekohayo: gnome-session
<nekohayo> just to make sure: I'm not the only one that the logout dialog pops up when waking up from standby am I ?
<sladen> nekohayo: even if you are, it's still a bug
<jdub> nekohayo: hrm, interesting - do you go into suspend from the logout dialogue?
<nekohayo> yes
<nekohayo> filed as https://launchpad.net/distros/ubuntu/+source/gnome-session/+bug/38301
<Ubugtu> Malone bug 38301 in gnome-session "logout dialog pops up when waking up from standby mode" [Normal,Unconfirmed]  
<jdub> nekohayo: nice one - make sure to metnion that :)
<nekohayo> just out of curiosity jdub, I remember hibernation working in breezy/hoary, and it doesn't anymore, is there a bug I can watch about this?
<jdub> not sure
<Chipzz> I have another nasty one
<nekohayo> and... why can't I translate espresso in rosetta >_<?
<Chipzz> hibernating *closes* your session
<Chipzz> which is not at all what I want
<nekohayo> I see parts of the graphical installer not being translated in French, I would like to be able to correct that :|
<mjg59> nekohayo: Should work with the latest kernel
<mjg59> Chipzz: Does it?
<sladen> Chipzz: do you mean that it fails to unhibernate and gives you a fresh boot?
<nekohayo> what do you mean mjg59 ? what should work? the standby bug? I'm fully up to date
<jdub> Chipzz: ?! ouch
<Amaranth> why can't laptops be smart and sleep until they run out of juice then hibernate?
<sladen> nekohayo: https://launchpad.net/distros/ubuntu/dapper/+source/debian-installer/+pots/debian-installer/fr/+translate
<mjg59> Amaranth: They will
<mjg59> nekohayo: Hibernate
<mjg59> nekohayo: As of today
<mjg59> Amaranth: At least, most modern machines will
<mjg59> Amaranth: They'll wake up when the battery becomes critical, at which point g-p-m will hibernate them
<nekohayo> sladen: thanks. I was searching for "espresso"
<Amaranth> mjg59: great, we can remove "Hibernate" from the "end of session" dialog then ;)
<jdub> Amaranth: no, sometimes you really want to know that you can hibernate and pull the plug out of the wall (or the battery out of the laptop)
<Amaranth> hmm...work on alacarte or go read my new book
<Amaranth> jdub: ah, good point
<sladen> nekohayo: actually it might be.  Did you use the LiveCD to install?  In which case, yes, it would be espresso-gtk I think
<nekohayo> yeah I'm talking about the livecd
<nekohayo> but when looking at the "software list" in rosetta, I ctrl-F "espres" and nothing matches
<Chipzz> not a fresh boot, but a fresh session
<Chipzz> it only happens when I use the gnome menu
<Chipzz> not when I use the power manager applet right click
<mjg59> Chipzz: Oh, right
<mjg59> The logout menu signals in the wrong way
<nekohayo> hey something is itching me: why isn't the "system" menu in the gnome menu bar applet never translated? I think I saw it translated in stable releases, but it always reverts to "system" when in a development ubuntu, is there a reason ?_?
<nekohayo> why is*
<Amaranth> nekohayo: well, it's an ubuntu-only modification
<Chipzz> mjg59: not unavoidable (just use the power manager), but quite annoying as the power manager is not easily keyboard accesible
<Amaranth> nekohayo: the translation for it probably keeps coming up fuzzy or something
<nekohayo> it's ubuntu-done? not upstream?
<Amaranth> "System" is, yes
<Amaranth> in upstream GNOME it's called "Desktop"
<mjg59> Chipzz: As I said, it's a bug in the logout dialog (rather than hibernate)
<Chipzz> yea, slight misphrasing on my part
<nekohayo> o_O I never knew upstream called it desktop... now that's surprising me
<spiv> Bug 36512 is filed against alsa-driver, but it looks like maybe it's a kernel issue -- certainly kernel updates affect it.  Should it be reassigned?
<Ubugtu> Malone bug 36512 in alsa-driver "Dell Inspiron 630m sound is broken" [Normal,Unconfirmed]  http://launchpad.net/bugs/36512
<crimsun> spiv: thanks, I'll triage it.
<crimsun> (and do the necessary git work to push)
<spiv> crimsun: Thanks!
<lamont> it appears that if sw raid decides to do recovery at boot (because I rebooted the machine during recovering the array), then evms just doesn't start.  Once the recovery finishes, rebooting the machine makes things happy again.  joy, joy
<infinity> Keybuk: Your dpkg upload is FTBFS.
<infinity> https://launchpad.net/distros/ubuntu/+source/dpkg/1.13.11ubuntu3
<Keybuk> sweet
<Keybuk> will just bounce that back to the Nexenta guys
<Keybuk> heh
<Keybuk> in fact
<Keybuk> let's just reject that
<Keybuk> next time I'll read a patch before applying it :)
<jdub> !!!
<jdub> ;-)
<Keybuk> *shrug* mdz did his "URGENT! MAJOR! DAPPER 6.06!" thing on it, so I assumed he'd read it <g>
<mbiebl> Keybuk, hi. I'm the Debian co-maintainer of NM and wanted to discuss the handling of devices defined in /e/n/i with you.
<mbiebl> Got a minute?
<Keybuk> sure
<Keybuk> let me just get some razor blades
<Keybuk> I love NM
<Keybuk> oh yes
<mbiebl> Your current policy seems to handle all devices not listed in /e/n/i, and all with dhcp+auto.
<pitti> Good morning
<Keybuk> that's right
<Keybuk> or, to put it another way
<pitti> Hey Keybuk 
<mbiebl> Which seems a bit strange to me, because devices with auto are ifup with -a (/e/i/networking)
<Keybuk> all devices that the user hasn't provided some kind of configuration for, that would conflict with whatever NM tried to do with it
<mbiebl> Wouldn't noauto+dhcp make more sense?
<Keybuk> no
<Keybuk> because noauto means "I don't want this device brought up"
<pitti> it would for ethernet cards in principle
<pitti> but the user has to configure that manually
<Keybuk> yes, auto+dhcp is brought up by udev, but not necessarily on the right wireless network
<Keybuk> it's NM's job to fix that later
<mbiebl> Hm, but so the device is handled by /etc/init.d/networking and NM?
<Keybuk> no, by udev and NM in Ubuntu
<Keybuk> bit inelegant, I agree
<Keybuk> but users never really notice
<mbiebl> Do you think, we should introduce a new keyword besides manual/static and dhcp?
<Keybuk> no
<Keybuk> because then we're getting as confusing as hell
<Keybuk> I think we should throw away ifupdown and admit that it just doesn't work these days
<Keybuk> there are much more interesting problems with it
<mbiebl> ;-)
<Keybuk> like the fact that it doesn't understand that dhclient can cause a network to go down when a lease is revoked, etc.
<pitti> Keybuk: yesterday night I wrote a patch for n-m to make it work without wpasupplicant (w. trashes my Airport Extreme, and in general it's not really requrired); any objections if I upload that?
<Keybuk> pitti: nope, none
<mbiebl> Ok, for now I will choose the same behaviour for the Debian packages: auto+dhcp and not defined.
<pitti> Keybuk: I'll explicitly seed it to ship in exchange
<Keybuk> I'm strongly leaning towards not seeding n-m, not even for live
<Keybuk> just leave it in supported
<pitti> Keybuk: uh, why not? I thought we wanted it in main?
<Keybuk> which, I guess means it's seeded, but you know what I mean
<pitti> Keybuk: hm, I'd vote for ship
<Keybuk> mbiebl: beware that there's an NM bug which means it crashes if you have anything else in /e/n/i at the moment :)
<Keybuk> pitti: maybe ship
<neuralis> Keybuk: it doesn't seem like replacing ifupdown with a smarter tool is too much work. if you want to spec it out, i'd be happy to write a replacement for edgy.
<Keybuk> the problem with it on Live is that you then can't configure a static IP
<pitti> Keybuk: yes, !desktop
<Keybuk> you go into the admin tools and configure your static IP
<mbiebl> Does that only affect the ubuntu backend?
<Keybuk> and NM fights you, and changes it back again
<Keybuk> mbiebl: it affects anything that says "no, don't control this interface"
<pitti> Keybuk: right, it doesn't dynamically react to /e/n/i changes
<mdz> Keybuk: I nudged on that bug because if our derivatives are sending us patches, we should be reading them and applying them where appropriate
<Keybuk> neuralis: my general thoughts are to go with something entirely different, where we have a set of ways of configuring any interface that comes up; and that each interface can elect to be configured or not in those ways
<Keybuk> (which makes no sense, it's hard to explain)
<pitti> ogra: good news then! I currently upload a new n-m; upgrade to that, remove wpasupplicant, then the AE runs smooth as silk (even without that hackish if-pre-up.d script)
<mbiebl> pitti, NM would have to monitor /e/n/i for that. Don't know if it wouldn't be easier to add a hook to the admin tool to call NM to update its config.
<Keybuk> mbiebl: that crashes NM too at the moment :(
<pitti> mbiebl: yes, inotify could come in handy there :)
* Keybuk thought of that <g>
<mbiebl> Keybuk, not good.
<Keybuk> NM is a piece of crap
<pitti> Keybuk: you say that at the time when it really really works for me the very first time :)
<Keybuk> pitti: now suspend your machine <g>
<Keybuk> *KA-BOOM*
<pitti> Keybuk: yes, I need to do iwconfig eth0 rate auto, but that's a bug in the bcm43xx driver
<neuralis> Keybuk: actually, that makes sense, and i've been thinking about something along the same lines. 
<pitti> Keybuk: after that, it just works
<pitti> Keybuk: i. e. I need my personal /etc/power/resume.d script, but that's about it
<neuralis> Keybuk: i'll prod you about writing a spec when the next conference rolls around.
<Keybuk> neuralis: the net effect would be that there's always a default way of configuring every interface -- which would probably amount to "try DHCP, fall back to 169.254" type thing
<Keybuk> pitti: NM gets very upset when you ifdown interfaces it's playing with
<Keybuk> and the acpi stuff ifdown and ifups interfaces
<pitti> have you guys ever heard a successful report about wpasupplicant on powerpc?
<Keybuk> also NM gets very upset if you UP interfaces it doesn't know about
<pitti> Keybuk: yes, the interface is shut down on suspend
<Keybuk> then it starts playing silly buggers
<pitti> I didn't try the latter
<infinity> pitti: \o/ on the "make wpasupplication optional" patch.
<pitti> infinity: :)
<infinity> supplicant, too.
<Keybuk> infinity: ITYM suppository
<mbiebl> Btw, is there a specific reason, why you wrote an own backend for ubuntu. I had a quick look at it and I think the differences are so minor, that there could be easily adapted/merged into the Debian backend.
<mbiebl> Do you want to keep your own backend or would you prefer you unify it again to save some work?
<Keybuk> just on general principal mostly
<Keybuk> I didn't expect Debian to follow
<Keybuk> so was easier to do it as a separate file
<mbiebl> It's mostly the handling of resolv.conf (where we have a slightly different approach in Debian) and the handling of device in /e/n/i
<mbiebl> And for the latter the Ubuntu behaviour seems sane to me. So I will adapt that.
<pitti> mbiebl: what do you think of making wpasupplicant optional? If you agree, I'll put the debdiff somewhere
<Keybuk> our resolv.conf handling is pretty hand-wavy
<mbiebl> Why not. If it does not have negative side effects I'm all for it.
<Keybuk> basically just "let dhclient do that"
<mbiebl> There are still users that don't need encryption and so would benefit of it.
<mbiebl> pitti, let me know, when you have the patch ready, or post it to the Debian BTS. I will then take a look at it.
<pitti> mbiebl: it's already uploaded to Ubuntu
<pitti> mbiebl: http://patches.ubuntu.com/patches/network-manager.optional-wpasupplicant.diff
<mbiebl> pitti, thanks.
<pitti> mbiebl: pretty straightforward
<mbiebl> Have to go to work now, guys. Nice talking to you. 
<mbiebl> cu
<kagou> hi
<pitti> hi  kagou 
<kagou> i want to help translating messages on the first boot screen when installing. Where can i do that ?!
<pitti> kagou: hm, gfxboot doesn't yet seem to be imported into Rosetta
<kagou> ok pitti
<mdz> Mithrandir: have you ever seen bootchart not be killed by stop-bootchart?
<kagou> pitti: gfxboot-theme-ubuntu is in rosetta, it's all translated (french) but the fr.po in source package is not synchronized. is it normal ?! it's not automatical ?
<pitti> kagou: oh, 'Translations' is greyed out on https://launchpad.net/distros/ubuntu/+source/gfxboot-theme-ubuntu, interesting
<pitti> kagou: entirely possible, Rosetta currently has a huge import backlog
<kagou> thanks pitti
<ogami1972> hey all you ubuntu developers!
<ogami1972> THANK YOU! it's great!
<pitti> ogami1972: thanks for the flowers :)
<ogami1972> :)
<pitti> ogami1972: so, what's your pet bug? :-P
<ogami1972> well, i am just a lowly user
<ogami1972> but
<ogami1972> no wait- no buts
<ogami1972> ubuntu is the best!
<pitti> rock!
<mdz> pitti: it might be a good idea to add wpasupplicant to desktop on i386 so that it can work out of the box
<Keybuk> mdz: it's in standard
<mdz> oh?
<pitti> mdz: I wanted to seed it to the same component as n-m itself
<pitti> oh, so it's in desktop already, I see
<mdz> ah, so it is
<pitti> hm, that's pretty bad
<Keybuk> mdz: it works well, and integrates nicely with ifupdown, etc.
<Keybuk> so deserves to be alongside things like wireless-tools
<pitti> right, I remember having to uninstall u-standard when I purged wpasupplicant
<mdz> but I thought pitti changed the dependency because having it installed broke things on powerpc
<ogami1972> am running 2 "dist-upgrade" boxes ( a compaq presario 900Mhz and a Inspirion 3700) and breezy on a dimension 2.4g- am setting up a dual-boot sytem to give away ( my third)
<pitti> right
<Keybuk> it works ok on powerpc for me
<mdz> but if it's in standard, that was a no-op at least for the live cd
<Keybuk> I thought it was just NM+WPA that broke
<ogami1972> anyway- thx again!
<mdz> and to some extent for the installed system too
<mdz> Keybuk: right, N-M
<pitti> yes, but there's currently no way to tell n-m not to use it
<Keybuk> I want to take NM out of live anyway
<mdz> oh?
<Keybuk> it's damned hard to shut down
<Keybuk> and means people can't use things like ppp, static IP, etc. on the live cd
<Keybuk> which seems rather a bug
<pitti> so, if I'm right, n-m needs to dynamically react to /e/n/i changes for that, that's about it?
<Keybuk> not just /e/n/i changes
<pitti> also manual ifconfig ones, hmm
<Keybuk> ppp brings up ppp0, NM goes "aha!  I'll manage that, THANK YOU VERY MUCH"
<pitti> can it sensibly drive modems?
<Keybuk> I don't think so
<Treenaks> would be a great wishlist bug ;)
<pitti> why not have it ignore ppp* then?
<Keybuk> pitti: because right now, it'd crash whenever you brought up a ppp* interface
<pitti> oh dear
<Keybuk> NM IS MY FAVOURITE EVER THING
* pitti hugs Keybuk 
<pitti> Keybuk: let's take nm and cupsys out for a public spanking :-P
<Keybuk> aww
<Keybuk> I'd prefer a public hanging
<Keybuk> make them both dance the hemp fandango
<infinity> mdz: Can I get a UVF exception for Subversion 1.3.1?  Looks like only bugfixes.  Changelog at: http://svn.collab.net/repos/svn/tags/1.3.1/CHANGES
<mdz> infinity: looks good
<infinity> mdz: Rock.  Thanks.
<ogra> pitti, nice
<Keybuk> siretart: ya know, it's probably easier if we just chat on IRC :)
<Keybuk> did you mean "waiting for root filesystem", not "waiting for sysfs"? :p
* Treenaks 's machine hangs when booting the flight6 CD
<Keybuk> Treenaks: anywhere in particular?
<Treenaks> Pressing Shift (and then 'abort'ing the graphical stuff) makes it work.
<Treenaks> Keybuk: there :)
<Keybuk> shift? graphical stuff?
<Treenaks> Keybuk: Yes, in  the bootloader
<Treenaks> Keybuk: Pressing shift disables gfxboot
<Keybuk> LiveCD?
<Treenaks> no, install
<Keybuk> I thought we used grub?
<Treenaks> Keybuk: Whatever is used, using 'shift' I can disable the graphical bootloader, and then it works.
<Keybuk> and you see "waiting for sysfs" or something?
<Treenaks> Keybuk: No, I see an Ubuntu logo, and the system hangs
<Treenaks> Keybuk: it doesn't even get to the point where it loads/boots the kernel
<infinity> Different bug.
<Keybuk> so you were just jumping in, while I was looking like I was in a bug-fixing mood, eh?
<Keybuk> DON'T YOU KNOW HOW EARLY IT IS?! ")($ :p
<infinity> Treenaks: Your bug has been reported against gfxboot-theme-ubuntu, and isn't what Keybuk was talking about. :)
<Treenaks> infinity: oh ok :)
<Treenaks> Keybuk: I saw 'booting bug' and jumped in :)
<Keybuk> infinity: do you know much about LVM?
<infinity> Yeah, cause we only ever have one of those at a time. :)
<ogra> Keybuk, thanks for pointing out *yawn*
<infinity> Keybuk: Do you know what SFA stands for?
<Keybuk> infinity: nope
<Kamion> Treenaks: yes, known bug, working on it
<infinity> Keybuk: fabbione may be your man for lvm stuff... At least, he's probably used it more than once.
<Keybuk> ogra: pointing out?
<Treenaks> Kamion: ok, thanks
<infinity> Keybuk: Oh.  In that case, I know "sweet fuck all" about lvm.  Now you know. :)
<Keybuk> ahh
<ogra> <Keybuk> DON'T YOU KNOW HOW EARLY IT IS?! ")($ :p
<Keybuk> I would have got that, had it been, oh, after breakfast
<Kamion> kagou: yes, gfxboot-theme-ubuntu is (obviously) not subject to language packs and requires me to sync translations from Rosetta by hand, which I do every so often
<kagou> Kamion: ok thanks for the precision
<Keybuk> fabbione: siretart is trying to mount a rootfilesystem with /dev/$VOLUMEGROUP/$LOGICAL
<Keybuk> which I've never heard of before
<Keybuk> and clearly, neither has the lvm initramfs script
<Kinnison> Kamion: No, no progress yet, sorry
<Kamion> Keybuk: that's common enough practice] 
<Kamion> minus the random punctuation that happens to be next to my Enter key
<Kamion> the practice dates from LVM1 really, before /dev/mapper/ was in use
<Kamion> (AFAIK)
<Keybuk> Kamion: oh, elmo let me in :)  so I guess at some point I'm ready to start lessons on ftp stuff
<Keybuk> Kamion: do you know what creates those device nodes?
<Kamion> nope
<Keybuk> bugger
<Kamion> sure, can give you a run-through once I've woken up a bit
<hunger> Keybuk: That works after the system is up.
<kagou> Kamion: may be you could answer me ... is there a project to translate init messages ?!
<hunger> Keybuk: But the kernel expects /dev/mapper/$VG-$LV.
<Keybuk> hunger: s/kernel/initramfs/
<Kamion> kagou: no, and no infrastructure for it yet either so doing the translations would be kinda pointless
<Keybuk> kernel doesn't expect anything
<Keybuk> hunger: do you know what creates the /dev/$VG/$LV then?
<hunger> Keybuk: Aehm, right.
<kagou> ok
<hunger> Keybuk: I'd expect the lvm start/stop script, but I never bothered to look.
<fabbione> Keybuk: bug number?
<Kamion> I thought I remembered the LVM tools transforming /dev/$VG/$LV into /dev/mapper/$VG-$LV at run-time, or something crazy like that
<fabbione> Kamion: yes that is correct
<Keybuk> fabbione: bug 38236
<Ubugtu> Malone bug 38236 in lvm-common "boot with root on lvm fails with root=/dev/vg/lv" [Normal,Unconfirmed]  http://launchpad.net/bugs/38236
<jdub> mjg59: http://www.flickr.com/photos/dirkolbertz/124109733/
<Keybuk> oh man
<Keybuk> so it's sickness
<hunger> Keybuk: I can confirm that. I stumbled over that before as well.
<Keybuk> so what you're saying is that /dev/$VG/$LV never exists
<Keybuk> and the evil lvm tools of doom just go "oh, you mean /dev/mapper/$VG-$LV" whenever you mention them?
<Kamion> Dapper development status meeting in #ubuntu-meeting in 7 minutes
* Kamion really hopes that spamassassin doesn't get the wrong idea here
<Kamion> recently I've started getting lots of spam forged from mdz@ubuntu.com
<fabbione> Keybuk: rejected..
<fabbione> Keybuk: it's not a bug..
<Keybuk> Kamion: heh, me too
<fabbione> oh
<fabbione> the meeting..
<Keybuk> bogofilter has since started filing ALL mails from mdz
<fabbione> hel i forgot to write the report!
<Kamion> do it quickly
<infinity> Keybuk: Ick.  There's nothing we can do to solve that, since /dev/randomstring/randomstring could just as easily refer to a real device, so I can't go blindly trying it as an LV...
<Keybuk> infinity: indeed
<Keybuk> I totally agree
<infinity> Keybuk: Or can I, perhaps, depending on when it's done?
* infinity ponders.
<infinity> Either way, icky.
<Keybuk> infinity: the lvm script could assuming anything /dev/*/* was worth a try
<Keybuk> but no
<hunger> Keybuk: Just remove /dev/$VG/$LV during runtime:-)
<Keybuk> that bug can go to the great big REJECTED bin in the sky
<Keybuk> Diziet: I always meant to ask; are you Diziet the drone, or Diziet Sma?
<Diziet> Sma.
<pef> hello, what does "PaS" means in a debian/changelog ?
<Keybuk> Packages-arch-Specific or something
<Kinnison> yep
<pef> perfect, thank you :)
<Keybuk> basically the list of "not for us" packages for a given arch
<carlos> Riddell: ok, then, there are three .pot files from kdebase that should be fixed. They are generated, but are using UTF-8 chars inside it and thus, the header should have 'charset=UTF-8', gettext does it automatically, I'm not sure why is not done for KDE...  The .pot files are: kfontinst.pot  knetattach.pot  konqueror.pot
<carlos> Riddell: also, the hacks.pot file from kdeartwork lacks the standard header that all .pot and .po files have and we are rejecting it
<carlos> could you fix it, please?
<Riddell> carlos: I'll look into them
<carlos> Riddell: thanks. I can file bugs about those problems if you prefer it..
<j^> Keybuk rigth now NM with orinoco_pci does not work with encrypted networks, and without a patch(bug 36708) for hostap_pci it does not works with unencypted networks with hostap_pci. indending to change that?
<Ubugtu> Malone bug 36708 in network-manager "[PATCH]  wpa_supplicant needs to know about hostap driver" [Critical,Unconfirmed]  http://launchpad.net/bugs/36708
<Keybuk> j^: change which part?
<j^> Keybuk i dont care, i suggested to go the hostap_pci route since that also brings WPA support
<Keybuk> btw, did the author of that patch deliberately try to make their coding style almost exactly different to the surrounding style
<j^> Keybuk if its about strcmp ("hostap", kernel_driver)<=0 vs !strcmp (kernel_driver, "ndiswrapper")
<Keybuk> well, first off is the whole orinoco vs. hostap argument, which is still very much open
<j^> thats doing something else
<j^> hostap is patching hostap_pci and hostap_cs etc
<j^> *matching
<Keybuk> right, but that will mean that you'll get the hostap driver if kernel_driver is "rtl8129" for example
<Keybuk> because hostap < rtl8129
<j^> Keybuk besides the argument about the default, hostap, if choosen manulay should work
<j^> in that case it should be !strcmp (kernel_driver, "hostap_pci") || !strcmp (kernel_driver, "hostap_cs") || !strcmp (kernel_driver, "hostap_plx")
<Keybuk> aye
<Keybuk> anyway, it is on my list'o'bugs
<Keybuk> and there's a patch
<Keybuk> but there are bigger NM bugs first
<siretart> Keybuk: ok, now I'm sort of available. that machine with the lvm 'trouble' is my machine at home. when I'm home (in about 7h), I can look up the exact error message from the initrd
<Keybuk> your bug got rejected anyway -- only the /dev/mapper/$VG-$LV is supposed to work
<seb128> mdz: could you get me a backtrace for bug #34396 now? They will roll new gst tarballs next will, we can probably get the crasher fixed if we forward the issue (it might be already fixed)
<Ubugtu> Malone bug 34396 in totem "Totem scroll not working properly" [Normal,Needs info]  http://launchpad.net/bugs/34396
<mdz> seb128: I'm not sleepy anymore ;-)
<seb128> hehe
<mdz> #0  0xb4b40e28 in mpeg2_init_fbuf () from /usr/lib/libmpeg2.so.0
<mdz> #1  0xb55424ed in ?? () from /usr/lib/gstreamer-0.10/libgstmpeg2dec.so
<mdz> very easy to reproduce here, I just hold the scroll thumb and go back and forth a few times
* holy_cow ponders upgrading his main workbox to dapper
<mdz> installing -dbg
<Lathiat> 
<seb128> mdz: that's known, no need
<mdz> heh, doesn't help anyway
<mdz> #0  0xb4af4e28 in mpeg2_init_fbuf () from /usr/lib/libmpeg2.so.0
<mdz> #1  0xb54f64ed in __PRETTY_FUNCTION__.17258 ()
<mdz>    from /usr/lib/gstreamer-0.10/libgstmpeg2dec.so
<Kinnison> mdz: since I appear to be a member of ubuntu-archive should I be prepared to do syncs, or is that just in case I'm needed for other stuff?
<seb128> mdz: http://bugzilla.gnome.org/show_bug.cgi?id=335288
<Ubugtu> Gnome bug 335288 in gst-plugins-ugly "Totem Crashes on Certain .mpg Files" [Normal,Assigned]  
<StevenK> Hah, __PRETTY_FUNCTION__. How nice of them.
<mdz> Kinnison: I created the team based on group membership on drescher
<Kinnison> mdz: fair enough
<mdz> Kinnison: if you have the privileges and know the tools, I'm happy for you to help
<siretart> Keybuk: well, I tried to boot without any root= line as well, and it showed the same symptoms. is THIS supposed to work?
<Kinnison> mdz: okay
<Keybuk> siretart: without any whatsoever?  not even the default one?
<Keybuk> that'd probably sit twiddling it's thumbs, yeah :p
<Kamion> mdz: presumably Keybuk needs to be added to ubuntu-archive now too
<Keybuk> filed under "well, don't do THAT then"
<mdz> Kamion: ah, that must have changed very recently. will do
<siretart> Keybuk: I wasn't sure because of your last mail to u-d-a, it seemed to me that rootfs autodetection should enable booting without any root= kernel param at all, which doesn't work for me
<Keybuk> siretart: there is no rootfs autodetection
<Keybuk> that would be somewhat magic :)
<Keybuk> if you feel like a project, it'd be damned cool
<Keybuk> perhaps with a little menu for when it finds multiple choices
<siretart> ok. then I got something wrong, and it was right to reject that bug.
<Keybuk> the waiting thing is initramfs-tools btw
<Keybuk> not udev
<Keybuk> it loops at the point of no return, just before it's about to m ount t
<Keybuk> of course, the fact you get there means you have a bug
<mjg59> jdub: Yeah, that's about as far as he's going to get
<jdub> mjg59: so is bootcamp pushing a BIOS out to all mactels?
<Kamion> jdub: unfortunately it doesn't help us much
<Kamion> jdub: once you're in the legacy mode, you can't talk to EFI and therefore you can't install a bootloader
<Kamion> although it would make the live CD work
<jdub> suck!
<jdub> thus their installer-installer for XP...
<mjg59> jdub: It could probably be made to work with extreme pain
<mjg59> jdub: But realistically, we want it to work without having to jump through these hoops
<jdub> yeah
<dholbach> mdz, Kamion: what do you think about bug 34430 - would it be ok, if I seeded gimp-print to ubuntu-desktop?
<Ubugtu> Malone bug 34430 in ubuntu-meta ubuntu-desktop "add gimp-print to ubuntu-desktop" [Wishlist,Confirmed]  http://launchpad.net/bugs/34430
<mdz> dholbach: seems logical; I thought it was already there
<dholbach> mdz: it was merely a recommends of gimp (as it "worked without it") - ogra mused it might have been a dependency (or something) in breezy
<dholbach> i'm happy to do it (and not get bug reports for it any more) :-)
<ogra> ogra@edubuntu:~$ apt-cache showsrc gimp-print|grep main
<ogra> Directory: pool/main/g/gimp-print
<ogra> ^^^ breezy :)
<dholbach> mdz: seeded it
<Keybuk> mdz: ubuntu-archive team needs an emblem! :D
<mdz> Keybuk: you are official ubuntu-archive emblem delegate
<dholbach> that's a title for a business card
<Keybuk> mdz /usr/share/icons/Human/16x16/filesystems/gnome-fs-ftp.png
<ogra> yeah
<pitti> dholbach: isn't gimp-print obsoleted by gutenprint nowadays?
<Treenaks> pitti: gimpprint the library is, but gimp-print is the 'Print' menu entry/dialog box for the GIMP image editor
<pitti> ah, I see
<ogra> pitti, thats how i understood it as well back then, but seems not to be the ccase
<pitti> Riddell: did you get my /msg from this morning?
<ogra> we had no binary called gimp-print in breezy ... thats new
<Riddell> pitti: replied
<Kamion> Kinnison: any idea how it would be best to request updates of uid_mappings in /srv/launchpad.net/codelines/current/scripts/ftpmaster-tools/sync-source.py?
<Kamion> Kinnison: that dictionary needs to be updated reasonably often when new people request syncs of stuff
<Kamion> Kinnison: can I just monkey in an update and send somebody a patch?
<Kinnison> Kamion: for now, monkey in changes and send patches to me
<Kamion> ok, thanks
<Kamion> eventually that script should be taught to just use launchpad ids
<Keybuk> hmm
<Keybuk> pitti: why can'
<Keybuk> can't I see your sync requests?
<Keybuk> oh
<Keybuk> mdz: did you really mean for the team to be subscribed to syncs and not assigned them?
<Kamion> yes, I noticed that, assigned bugs don't necessarily show up in +subscribedbugs
<Kamion> which is an insanely annoying malone quirk
<pitti> Keybuk: I just followed the instructions which asked to sub the team
<Keybuk> yeah
<Keybuk> the instructions do say that
<pitti> https://launchpad.net/people/ubuntu-archive/+subscribedbugs
<pitti> works quite well
<Keybuk> pitti: except the one sladen filed and put in +assignedbugs isn't in that list
<dholbach> hm, it seems that bug 10822 has re-surfaced
<Ubugtu> Malone bug 10822 in localechooser "en_US users see en_GB strings all over?" [Normal,Fix released]  http://launchpad.net/bugs/10822
<dholbach> bug 38250 and bug 38136 indicate that
<Ubugtu> Malone bug 38250 in epiphany-browser "incorrect default keyword search page" [Normal,Unconfirmed]  http://launchpad.net/bugs/38250
<Ubugtu> Malone bug 38136 in evolution "British English Spellings are Used" [Minor,Rejected]  http://launchpad.net/bugs/38136
<pitti> Keybuk: just to be sure, I'll modify my script to assign *and* subscribe the archive team
<Keybuk> pitti: doesn't assigning infer subscription?
<pitti> Keybuk: I hoped so, but as Kamion says this might not always be the case
<Kamion> Keybuk: ("imply". grr. pet peeve)
<Kamion> dholbach: please only reopen 10822 if you're sure that it's due to the installer and not something else messing with $LANGUAGE
<dholbach> ok, will put some more investigation into it
<Keybuk> Kamion: I clearly have the opposite to dholbach's bug
<Keybuk> my brain is getting words from en_US
<sladen> Keybuk: should I subscribe ubu
<sladen> Keybuk: should I subscribe 'ubuntu-archive' on that bug, or change the instructions on the wiki?
<Kamion> subscribe ubuntu-archive for now, I think
<Kamion> I don't think it'll always make sense to assign ubuntu-archive
<Kamion> thanks :)
<Kamion> (er, echan)
<Keybuk> Kamion: don't mention it
<dholbach> Keybuk: hum... why didn't the ubuntu-meta upload get my seed changes?
<Keybuk> dholbach: did you forget to push them?
<dholbach> no... i think not
* dholbach looks
<Keybuk> I see no dhugbach in bzr log
<Keybuk> oh, wait
<Keybuk> 10:40:20 today
<ogra> btw, will we get a working bzrk anytime again ? 
<dholbach> 0 revision(s) pushed.
<dholbach> seems I pushed it
<janimo> mvo, hello. I have just noticed that update-manager depends on gconf. I somehow missed it before
<Keybuk> probably means that the http copies didn't update yet
<janimo> directly I mean not via python-gnome
<Keybuk> they were updated sometime before you pushed
<Keybuk> and will be updated sometime soon
<dholbach> alright
<dholbach> well... it's not terribly urgent... i just wondered
<ogra> it takes ~20 min until they get pulled in
<Keybuk> dholbach: looks like they're up now, so you could update and upload
<dholbach> as I said... it's not that urgent
<ogra> meh, if you want to use sorting by distro on the new +packages page, you'll always get breezy first ... :/ we should have release numbers instead of names there
<mvo> janimo: hm, ok
<Keybuk> Kinnison: so, this is probably a really silly question
<Keybuk> but is there any way to unpublish a source package?
<mvo> janimo: I have a upgrade failure for you (breezy->dapper with xfce installed in breezy)
<jdub> dholbach: https://launchpad.net/distros/ubuntu/+source/evolution/+bug/37858
<Ubugtu> Malone bug 37858 in evolution "Missing emails in data file" [Normal,Rejected]  
<mvo> janimo: do you prefer mail or bugreport?
<jdub> dholbach: that doesn't appear to be a support requiest
<jdub> request
<jdub> that appears to be an actual bug
<janimo> mvo, whichever is easier for you
<dholbach> jdub: he seems to have deleted some files... "help me recover" is a support request, no?
<jdub> dholbach: no, the emails are there, but not displayed
<dholbach> i understood the "I deleted ..." as "I deleted some files and now things are broken, please help me"
<Kinnison> Keybuk: define unpublish
<Keybuk> Kinnison: "oops, I didn't read that patch and it all FTBFS so I'd like to make like that upload never happened"
<ogra> just upload a fixed version ? 
<Kinnison> Keybuk: If it's not a case of "this results in all builds failing horribly for everything" then as ogra says, upload a fixed version and take the embarassment
<Keybuk> ogra: the fixed version was the one in the archive before I uploaded that one :)
<ogra> so revert the change in the next upload
<jdub> dholbach: he's goign to repoen it and point to other people's reproductions of it 8)
<ogra> :)
* Kinnison can "unpublish" but it won't remove the announce, and it might confuse things a lot, and it'll take about an hour of database surgery to unpick it all
<Keybuk> I uploaded an ubuntu4 which is identical to ubuntu2 except for the changelog
<Keybuk> bah
<Keybuk> you mean there's no "LOOK OVER THERE!" surgery tool? :p
<Kinnison> No because of the mirrors etc
<Kinnison> launchpad is an honest and hardworking lad
<Keybuk> BOR-ING
* Kinnison shrugs.
<ogra> and you get into trouble if i grab your source before it built
<Kinnison> better to be boring and consistent
<Kinnison> than risk breaking mirrors etc
<ogra> and upload my change 
<Keybuk> I like getting in trouble
* ogra grabs the source
<ogra> :)
<Kinnison> Keybuk: y'think that if there was a "look over there, an obvious distraction!" tool, I'd have let my upload of g-p-m with the shoddy changelog remain in the archive?
* Kinnison hands keybuk a "one free test build with every package" ticket and suggests he uses it :-)
<Keybuk> Kinnison: bah
<dholbach> jdub: did the guy point you to the bug?
<Keybuk> Kinnison: testing builds involves installing build-deps
<Keybuk> which nearly always find some way of conflicting with something I have installed
<Keybuk> or, these days
* Kinnison hands keybuk pbuilder
<Keybuk> pulling in postfix and resolvconf
<Keybuk> I've never got pbuilder to work
<Kinnison> eh?
<ogra> huh ?
<Kinnison> s'easy
<Kamion> or just debootstrap a chroot
<Keybuk> Kamion: still hassle :p
<Keybuk> infinity tells me soon enough if it doesn't build <g
<ogra> you didnt read dholbachs PbuilderHowto ?
<janimo> ogra, that howto is very confusing
<ogra> err ? 
<Keybuk> ogra: confused the hell out of me
* janimo thinks about rewriting it
<Keybuk> and still suffers the same pbuilder problem I hit every time
<ogra> dholbach, ^^^^
<Keybuk> you need a source package
<janimo> mentions all kinds of cr*p you don;t actually need
<Keybuk> which means you need the build-deps
<janimo> like messing with /etc and apt config stuff
<janimo> none of that is actual
<Keybuk> or, at least, some of them
<Kinnison> why do you need the build-deps for making a source package?
<Kamion> Keybuk: you don't need the build-deps to create a source package
<Keybuk> Kinnison: evil ones that edit control
<Kamion> at worst, you need one or two of them
<Keybuk> or, e.g. postfix, which fails in clean if libdb4.3-dev isn't installed
<Kinnison> Keybuk: change them so that they don't
<dholbach> ogra: what?
<Kamion> like cdbs
<Keybuk> aye
<Keybuk> once I've got the energy up to doing that though, it's easier just to build it on the machine
<ogra> dholbach, they say your PbuilderHowto is confusing
<Keybuk> rather than muck around with pbuilder
<dholbach> ogra: it's not mine... i made some tiny additions to an existing page
<janimo> ogra, that howto does not seem to be touched since hoary?
<ogra> janimo, Keybuk 
<ogra> Installing Pbuilder on dapper
<ogra> The latest pbuilder package in dapper (0.145ubuntu2) should work out of the box. You only need to install it. Then run:
<ogra> pbuilder create 
<ogra> and then
<ogra> pbuilder buld my-pacakge_1.0.dsc
<janimo> I'll rewrite it. It looks there actually confuses others too not just me
<ogra> whats confusing there ? 
<Keybuk> ogra: needs the dsc
<janimo> ogra, is that in the howto?
<ogra> yes
<Keybuk> why can't it build the package in the current working directory
<ogra> at the top
<janimo> ok, did not check in the lats 2 weeks
<Keybuk> when I'm testing builds, I've nearly always got edits I want to test
<Keybuk> I don't want to have to clean it, make a source, etc. just to test it
<Kamion> you can always copy the cwd into the chroot and 'pbuilder login'
<Keybuk> Kamion: but then why? :)
<Kamion> you might then not have to ask how to unpublish a source package. :)
<mvo> janimo: let me know if the latest uploads works as expected please 
<Keybuk> Kamion: I'd still not bother testing builds of drive-by patching
<ogra> oh, you are right its very coinfusing ... "buld" should be "build" 
<janimo> mvo, ok, thanks. I assume update-notifier
* ogra fixes
<Keybuk> patch, changelog, upload, NEXT! :p
<TheMuso> 
<mvo> janimo: and pbuilder :)
<janimo> mvo, you mean the patch from MOTU?
<mvo> janimo: yes, the stuff I uploaded
<mvo> (for pbuilder)
<Keybuk> oh, if you copy the cwd into the chroot, you then find that emacs in the chroot doesn't have my .emacsrc :)
<dholbach> oh stop complaining :-p
<Keybuk> the only use I've ever found for a chroot is checking you've got the build-deps right on a new package
<jdub> dholbach: yeah, SLUG dude. :)
<ogra> bah, aussie conspiracy
<dholbach> jdub: i see... i replied :)
<ogra> againnst our hugmaster
<dholbach> :-p
<jdub> heh, he hadn't even replied/reopened yet 8)
<jdub> that'll freak him out a bit
<janimo> mvo, thanks I'll take a look at the breezy->dapper issue.I know I corrected a similar one last week fro the same two packages.
<mvo> janimo: cool, thank
<janimo> mvo, hmm I don't see recent uploads by you on the changes list
* mvo goes to take a nap
<pitti> mvo: enjoy!
<mvo> pitti: thanks :)
<TMM> hi all!
<TMM> I was just having a little discussion with someone, and he advised me to go here and ask your collective opinions on autopackage
<ogra> just dont ask
<TMM> I am not trying to start a flamewar or anything :)
<ogra> there are several threads on the ubuntu-devel ML ... look at the archives
<TMM> ok
<ogra> http://www.kitenet.net/~joey/blog/entry/autopackage_designed_by_monkeys.html might be informative too
<TMM> ogra: not entirely accurate though, the functions of the shell scripts don't change during stable releases
<sebest> on a related note, why is it needed to have root privileges to install packages? many package should be installable by normal user
<sebest> things  like firefox, gaim, gimp etc etc
<ogra> TMM, i didnt write it
<ogra> sebest, how would you do that without write access to the system directorys ? 
<sebest> ogra, i would install them in the home directory
<ogra> sebest, cool, so with 200 users you install 200 times firefox in their homes ? 
<sebest> with 200 users, it's different usecase, you are in an enterprise use case
<zakame> ogra: not to mention in various states (some installed, some half-installed, some broken...)
<sebest> btw, it's already doable, just not easy
<Treenaks> zakame: and different versions!
<ogra> yay
* zakame hugs Treenaks
<ogra> thats only 1.8G in the firefox case with 200 users :)
<sebest> ogra, you know a lot of workstation with 200 users on it? :)
<kent> if the programs dependencies or right - they could easely be installed in system folders (no need for autop.),  if not - they will need lots of dependency-files and creating a mess.
<ogra> sebest, nope, but i know several edubuntu installations with 400 for example 
<sebest> and btw , if they can already do it
<sebest> ogra, yes, but nothing forbid them to install 400 firefox in their home :)
<mjg59> sebest: Quotas generally do
<ogra> sebest, sanity does (i hope)
<zakame> not to mention maintaining a $HOME/var/lib/dpkg/* ...
<Treenaks> noexec does, too :P
<sebest> ok ok ok , was just a bad suggestion ;)
<TheMuso> can anybody tell me why if I blacklist a usb controller module, ehci_hcd in this case, in /etc/modprobe.d/blacklist, that it still gets loaded on subsequent reboots?
<ogra> it comes up once a month ... we're used to it :)
<sebest> ogra: you mean autopackage, or being able to install software as normal user?
<ogra> as often as autopackage i think...
<ogra> both 
<zakame> TheMuso: experienced the same, except I was trying to blacklist nvidia
<ogra> related or unrelated
<ogra> not as often as klick though
<sebest> i don't care about autopackage, but i thought it "may" make sense that a normal user can install a simple package without being root
<TheMuso> zakame: Glad I am not the only one. For a sec I thought that the controller driver was loaded by something other than udev for a sec there.
<sebest> so klick is also a bad thing?
<ogra> its an autopackage frontend ...
<Keybuk> usually it means something else (other than modprobe) is causing the device to get loaded
<Keybuk> s/device/module/ sorry
<sebest> ogra, i thoug that click was more an apt server side
<TheMuso> Keybuk: Yeah thats true.
<ogra> with autopackage bits included
<jdub> sebest: it's just a different way to blat blobs of goop on the disk
<Keybuk> zakame: nvidia is usually loaded explicitly by the xserver and its shell scripts, iirc
<jdub> sebest: different to autopackage, but the 'interesting' bit is the url handler to download klik blobs
<TheMuso> Keybuk: But after logging into a console after a fresh boot, the controller driver is loaded, yet no other modules seem to depend on something.
<zakame> Keybuk: hmm, even if I use `nv'?
<TheMuso> I am probably missing something here however.
<Keybuk> zakame: something must be loading it
<zakame> indeed :/
<Keybuk> TheMuso: best thing would be to work out where it's being loaded
<TheMuso> Right.
<Keybuk> most likely in the initramfs actually
<Keybuk> after you added it to the blacklist, did you update-initramfs -u ?
<TheMuso> No. I will try that. Thats a good point.
<Keybuk> that'd be my bet
<TheMuso> You're probably right.
<sebest> jdub, i understand that requiring root priv, helps to keep the installation clean, i just thought, it mays be interesting to be able to install simple app without root access
<jdub> it woudl be interesting
<jdub> at some stage
<jdub> perhaps
<jdub> but you'd be tossing out package management to a large degree
<ogra> we could just go the lindwos path and only have root :)
<jdub> so we'd be putting ourselves in the same position that apple wants to get out of
<sebest> jdub: yes i guess it wasn't a goal of apt, so it would require major changes
<zakame> hmm something like firefox extensions (sorry I'm still sharpening)
<sebest> jdub: could you explain this point?
<Keybuk> zakame: the blacklist files only get used by modprobe when expanding hardware aliases
<sebest> jdub: about apple
<Keybuk> e.g. modprobe pci:v000010DEd*sv*sd*bc03sc00i00*  (with the *s expanded)
<zakame> hmmm....
<jdub> they've painted themselves into a non-package-managed corner
<jdub> and now they're wondering what to do
<Keybuk> if anything calls modprobe nvidia (or insmod nvidia) explicitly, then that bypasses the blacklist
<TheMuso> Keybuk: Indeed it was the initramfs. Thanks. I would have tried that eventually. :)
<sebest> jdub: what are their issues?
<sebest> updating?
<sebest> dependencies?
<Keybuk> I've tried fairly hard to find all the modprobe calls and add "-b" (check blacklist) to them, but there are other that escape me
<jdub> sebest: complete lack of package management for the system and for applications
<Keybuk> TheMuso: nah, you'd've installed a new kernel eventually and wondered why it magically fixed itself <g>
<jdub> updates to the system are cpio blobs spewed onto the filesystem
<jdub> etc
<sebest> jdub, i can understanf it's an issue for the base system, but for apps like itunes, gaim, and so on?
<jdub> totally unmanaged
<Keybuk> /opt/itunes /opt/gaim :)
<TheMuso> I just wish I didn't have to blacklist a controller module just so I could use stupid USB devices that try and fake themselves as being 2.0 devices which causes them to not register as storage devices.
<Keybuk> TheMuso: heh
<sebest> jdub, yes i see, they need to find a good balance between ease of use and managability
<TheMuso> If one inserts them when Windows is running, Windows says they could perform faster etc etc.
<pitti> hmm, no daily ppc live CD today?
<pitti> ... or in the last two days
<Keybuk> jdub: tbh, dpkg isn't *much* more clever than unpacking cpio blobs over the file system
<Keybuk> except it does clean up stuff that was in the last blob but not in the new one
<Keybuk> sorta, partially, sometimes
<jdub> Keybuk: at least there's sane management going on behind the scenes
<Keybuk> yeah
<Keybuk> there's some attempt to make sure you don't have eight programs all wanting different versions of the same .so
<ogra> Keybuk, hey, thats proven to work by M$ :P
<Keybuk> I do quite like the idea of app-in-a-dir though
<Keybuk> nautilus could be trained to recognise them, and then run $appdir/script with PATH and LD_LIBRARY_PATH set to look inside and stuff
<jdub> Keybuk: baby jesus is frowning
<sebest> Keybuk: i think that's what apple do more or less
<Keybuk> jdub: it's not bad
<Keybuk> such things would be limited to user home dirs and /opt
<Keybuk> easy to clean up (just delete the dir)
<sebest> Keybuk, looks like "staw"
<Keybuk> not heard of that
<Keybuk> the way Apps worked in Risc OS is vaguely in my mind here
<sebest> stow
<Keybuk> (apps were directories whose name began with !
<Keybuk> e.g. you'd have !Gaim
<sebest> Keybuk, that's a gnu project
<Keybuk> inside that w
<sebest> Keybuk, http://www.gnu.org/software/stow/
<Keybuk> as the special file !Boot that set up the icons and file manager behaviour
<sebest> GNU Stow is a program for managing the installation of software packages, keeping them separate (/usr/local/stow/emacs vs. /usr/local/stow/perl, for example) while making them appear to be installed in the same place (/usr/local).
<Keybuk> and !Run that was run when the icon was double-clicked
<Keybuk> you'd usually have !Sprites (icons) etc. as well
<Keybuk> and everything else for the app was in the directory)
<torkel> whats wrong with ./configure --prefix=$HOME/itunes && make && make install ? :-)
<Keybuk> sebest: isn't that just the symlink-masher ?
<Keybuk> torkel: mv itunes ../stuff
<sebest> Keybuk, yes somehow 
<Keybuk> sebest: so not the same, really
<sebest> Keybuk, i think that your idea is what apple does
<sebest> you think that you drag and drop a file (the application) but in fact it's a folder, with all the needed ressource for the application
<Keybuk> yeah
<sebest> and the equivalent of nautilus managed it so when you double click on the folder it executes a script to start the apps
<infinity> Does this system have any concept of dependencies, or is everything self-contained and statically compiled?
<sebest> infinity, it's not statically compiled as far as i know
<Keybuk> self-contained or static in general on Risc OS
<Keybuk> it wasn't really great on dynamic linking
<sebest> but there is not really a problem of dependencies because there is only one MacOsX
<Keybuk> Kinnison's partner will no doubt leap in and bite my balls off and tell the world that Risc OS had the BEST DAMNED linker on the planet, but nobody ever used it, or something
<sebest> you just have to say "requive macosx versionb x.y)
<infinity> sebest: Unless you need to depend on another third party package, or something.
<sebest> infinity, yes true
<infinity> sebest: Then, I guess, you get permission to ship their with yours, or pray that users are smart enough to jump through hoops...
<Keybuk> infinity: those are what you stick in your app-dir
<Keybuk> this is not that different to how they try and ship ooo.o now
<sebest> Keybuk,  you can put them anywhere
<Keybuk> "mommy! why does openoffice's source package contain a copy of libc?"
<Keybuk> sebest: I do hope you were channelling Sarah Michelle-Gellar then
<Treenaks> Keybuk: doko's your MUM?
<infinity> OpenOffice's distribution rollup is scary.
* Treenaks wonders if there's emacs source in there somewhere, too
<sebest> Keybuk, what do you mean?
<Keybuk> sebest: Cruel Intentions ... "you can put it anywhere" ... etc.
<sebest> ah
<sebest> ok :)
<zakame> Treenaks: lol
<Kinnison> Keybuk: he says there's no such thing as Risc OS, but that RISC OS's linker was shite
<sebest> Keybuk, i didn't see it in english ;)
<Keybuk> Kinnison: I'm not going to bow down to the authorised spelling of a company that couldn't spell "disk"
<jdub> Keybuk: j00 are teh flamebait!
<Kinnison> Keybuk: well, I can see where the confusion comes from for you. I mean, a RiscPC runs RISC OS, as does a RiscStation. But RISC/os ran on MIPS based systems
<MidMark> Hi people <Kamping_Kaiser> sent me here because I was having an hard disk failure with lost of boot with ubuntu 5.10 fully updated
<MidMark> yesterday all filesystem of my ubuntu 5.10 structure goes in failure, fortunatelly I have backupped all my data with flight 6 live cd, the hard disk isn't broken (deep test result are ok), but how is it possible that failure? Bug? Is there a chance to view some logs and find the bug ot the problem?
<jdub> what's the libmysqlclient15off stuff?
<MidMark> probably if there are some bugs in ext3 (the filesystem) need to be investigated and fixed... helps is very appreciated
<Treenaks> MidMark: bugs in ext3? like what?
<MidMark> it seems strange that my filesystem was broken without an hard disk failure, so I've thought an ext3 butg
<MidMark> the problem was: I have started my notebook: a forced filesystem check was started, then stops and asked a manual fsck
<MidMark> after done the fsck a lot of problems were recognized and a lot of dirs goes in lost+found, dirs like: /var /etc and others
<MidMark> of course ubuntu 5.10 won't boot anymore
<MidMark> so I'm asking if there are some logs I can view to investigate the problem, if it wasn't a bug I'll go out immediately
<mjg59> MidMark: /var/log/messages may provide an indication of filesystem corruption
<mjg59> But if there is any, it may well be caused by hardware failure of some sort (not necessarily in the disk)
<MidMark> mjg59: thanx now I'm seeing it, but which different failure can cause filesystem corruption?
<Kamion> MidMark: the disk suddenly deciding that it didn't like the concept of actually retaining data any more, would be a favourite one
<Kamion> hard disks are far from perfect
<mjg59> MidMark: Bad CPU, bad memory, bad power supply...
<Kamion> if the data it happens not to want to retain is in the middle of your filesystem's directory indexes, well ...
<Kamion> and the controller might *now* have realised that it can't use those blocks any more
<Kamion> (so a test would be fine)
<MidMark> kamion: the hard disk seems ok, I have done a deep analysis with Hitachi software specific
<Kamion> but as mjg59 says, a failure in any part of your system between you and the disk could cause problems
<MidMark> mjg59: the notebook seems all ok, and was ok right now. Now is running flight 6 live cd... you are thinking a temporary failure?
<Kamion> ext3 bugs are possible, but in general ext3 is used because it's exceptionally reliable
<mjg59> MidMark: An individual sector can go bad. The next time you try to write it'll remap it, but that means the original data is lost
<mjg59> However, a test will then report fine
<zul> mvo: ping
<mvo> zul: pong
<zul> mvo: what change did you make to grub that caused the bug reports?
<bddebian> fabbione: ping?
<mvo> zul: I restored save-defaults and updatedefaultentry
<mvo> zul: if it causes too much trouble we should revert it (both changes taken from debian)
<zul> mvo: i think it might be causing problems by the looks of the bug reports..
<mvo> zul: what bug ids in particular? 
<zul> uh...gimme a sec..
<mvo> thanks
<MidMark> mjg59: this is messages log file http://paste.ubuntu-nl.org/11593
<MidMark> the problem is failure was yesterday not 4th of april
<zul> mvo: 38182 for one
<mjg59> MidMark: That suggests that the failure wasn't logged
<MidMark> mjg59: damn, so there is no way to understand the problem?
<mvo> zul: I'm investigation this one currently. the patches *should* be harmless and do nothing to a default configuraton. but I may well have overlooked something :/
<zul> mvo: ok...good to know..
<Kamion> mvo: I think we should consider syncing to current Debian grub
<Kamion> well, merging with
<Kamion> there are a number of fixes that are essentially stabilisation of 0.97
<mvo> Kamion: yes, it seems to me like we already took a lot of them
<mvo> Kamion: so it's probably better to go all the way
<mjg59> MidMark: I'm afraid so
<MidMark> mjg59: thanx anyway for your time
<jono> hey
<Seveas> Treenaks, #ubuntu-nl misses you 
<HiddenWolf> Yeah, we do. :)
<Kamion> heh, pitti is about to run into the batch of espresso bugs I'm fixing right now, I'm betting
<mdke> is gnome-xchat configured to have an entry in the server list for Ubuntu which automatically joins #ubuntu? sorry to ask, haven't got a dapper system on me
<mdke> xchat-gnome*
<ogra> has anybody an idea what patchsystem is used in ppp ? (i see a ton of patches in debian/patches and need to disable one) there is no dependency on any patch system in the control file ...
<ogra> and rules doesnt have anything patch related either ....
<ogra> (at least grep retuns nothing)
<ogra> *returns
<dholbach> might be those are simply applied patches
<ogra> but how ? 
<ogra> there is no patch command anywhere
<ogra> oh, you mean manually applied to the orig.tar.gz ?
<dholbach> to the diff.gz?
<ogra> hmm ...
* ogra looks 
<dholbach> if there's no patch system, i usually apply the patch and put it to debian/applied-patches, so people can extract it easier
<seb128> mdke: around?
<ogra> btw, dont look at this debian/patches dir in ppp, you'll surely go blind, its a mess
<rcaskey_> has there been any talk of applying the apparmor patch in dapper+1?
<jdub> there are way more enjoyable things you can do to go blind
<ogra> yeah
<ogra> indeed :)
<ogra> but mdz did the dancing dervish on malone and assigned alotta bugs to me
<ogra> so i somehow need to fix them and try to not go blind
<mdke> seb128, briefly
<seb128> mdke: patch is by Don Scorgie right?
<seb128> mdke: since that's you who sent it, to get the changelog credit correctly :p
<mdke> seb128, yes, except the strings, which are by the documentation team
<mdke> fine, credit is definitely his :)
<seb128> "patch by Don Scorgie, description by Matthew East"
<seb128> is that fine with you? :)
<seb128> I'm using your patch description for the changelog :p
<jsgotangco> lol
<mdke> seb128, "patch by Don Scorgie" is fine :)
<pitti_live>  /msg nickserv link pitti pitti_live
<pitti_live> oops, sorry
<Kamion> 14:58 < Kamion> heh, pitti is about to run into the batch of espresso bugs I'm fixing right now, I'm betting
<pitti_live> Kamion: believe it or not, this time I installed on /dev/hda2 instead of /dev/hdc2, and it didn't crash :)
<Kamion> pitti_live: bet it crashed later
<Kamion> network configuration had a bit of a whoopsie
<Kamion> as did localechooser
<pitti_live> Kamion: I'm 50% into 'installing system' now, that's way more than I'm used to :)
<Kamion> chmod +x /usr/lib/espresso/localechooser/* quickly and it'll get further than it otherwise would
<Kamion> but will probably still crash at network config, sorry, can't fix that on the fly
<pitti_live> sure, no problem
<pitti_live> I actually intended to play a bit with hda2 vs. hdc2 to (a) check that 'doesn't install grub' bug and (b) that libparted related crash
<seb128> mdke: does that patch includes your 04_text_color.patch change too?
<ogra> dholbach, ha ! there is a debian/sys-build.mk ....
* ogra shudders about that package 
<pitti_live> Wow, "Installing language packs..." -- shiny
<dholbach> ogra: ouch... i converted one of the gnome packages that has that kind of stuff in Debian to CDBS :-p
<Kamion> ogra: oh, that's DBS
<ogra> i doubt i can do that with ppp
<ogra> Kamion, oh, why doesnt it just use dbs then ...
<ogra> looks really messy
<Kamion> because it probably dates from before dbs was packaged
<ogra> ah
<Kamion> like dpatch, it used to just be copied into whatever packages used it
<pitti_live> Kamion: at which point is grub supposed to be installed?
<Kamion> pitti_live: near the end, just after network config
<pitti_live> Kamion: I have a dialog "Installing language packs" -- "90%" -- "Configuring hardware"
<pitti_live> :)
<pitti_live> ah, it complains about not being able to install grub
<Kamion> yeah, I just noticed that it's not dealing with the title change correctly
<Treenaks> Finalizing settings.... [wait]  Applying settings....
<pitti_live> Kamion: ok, I won't file a bug then
<Kamion> huh, it got past network config?
<mdke> seb128, no, I don't think so
<Treenaks> (sorry, that was what a Windows installer told TMM once ;))
<pitti_live> Kamion: I didn't see any status message about network
<Kamion> pitti_live: go ahead and file a bug anyway if you would, I haven't nailed it down yet so I might forget
<pitti_live> Kamion: I had langpack configuartion, then hardware, now boot loader
<pitti_live> Kamion: sure
<Kamion> pitti_live: maybe you have a sufficiently old CD not to have network config, then
<Kamion> which is fine
<mdke> seb128, if unsure, ask on the bug: I've subscribed Don
<pitti_live> Kamion: hm, today's live
<TMM> windows server 2003 to be exact
<Kamion> pitti_live: might not have picked up yesterday's espresso uploads ...
<TMM> and it didn't end there :)
<pitti_live> indeed
<TMM> the settings where finalized, applied, written and finished
<Kamion> oh, live CD builds appear to be disabled
<Kamion> infinity: <poke>
<pitti_live> Kamion: yes, ppc is missing entirely
<Kamion> sorry, I mean live filesystem
<Kamion> pitti_live: separate problem
<pitti_live> Kamion: strange, the espresso log says that it couldn't resolve the host name when it wanted to install grub
<Kamion> pitti_live: yep, it's trying to upgrade
<Kamion> pitti_live: fixed in newer versions of espresso
<pitti_live> cool
<infinity> Kamion: Yes'm?
<Kamion> infinity: please re-enable live filesystem builds
<infinity> Kamion: Oh, right, cronjobs.  Whee.
<infinity> Kamion: On it.
<bddebian> Heya infinity.  fabbione is a hard person to get a hold of :-)
<seb128> mdke: I've figured, the toc2html.xsl "text-decoration: none; color:" change was dupped
<seb128> mdke: it builds now :)
<infinity> Kamion: Done.
<Kamion> pitti_live: the powerpc thing is due to temporary directories somehow ending up as group warthogs; fixing
<mdke> seb128, lovely, thanks for doing that
<seb128> mdke: np, thank you for coordinating that :)
<Kamion> pitti_live: missing powerpc fixed for the next round of builds
<pitti_live> cool
<bddebian> Since I am not getting an answer in #u-motu or #u-bugs, what person/team should I move a main bug to?  It's assigned to MOTU's currently but it's a main package?
<Kamion> bddebian: "nobody"
<Kamion> main bugs shouldn't be assigned to a team unless that team's actually working on it
<bddebian> Kamion: OK, thx
<bddebian> Though the supplied patch does work :-)
<pitti_live> bddebian: which bug in particular?
<bddebian> Malone bug 4587
<Ubugtu> Malone bug 4587 in bittornado "[PATCH]  bittornado absolute icon path and specs problems" [Normal,Rejected]  http://launchpad.net/bugs/4587
<pitti_live> oh, rejected
<pitti_live> have to reboot to get espresso to a clean state again, brb
<bddebian> Rejected?
<bddebian> Oh rejected for Dapper but open in Ubuntu
<Treenaks> ah, so Seveas' bot is buggy ;)
<Seveas> hmm
<Seveas> meh
<Seveas> will fix
<jcole> are there any open source launchpad equivs out there?
<jcole> better yet, is launchpad open source?
<fabbione> bddebian: pong?
<pitti_live> bah, yay xchat-gnome
<BenC> is there any reason that devices like /dev/usb/hiddev0 are not actually there?
<BenC> usbhid is loaded, but hiddev# devices are not in the device tree
<sladen> jcole: LP isn't Free Software yet.  it will be one day.  When it has so much market share that nothing else can compete...  Sourceforge/etc are the closest elsewhere.
<jcole> sladen: ok, i understand, thanks
<jcole> sladen: simple question (not), at my company, we use http://linuxcoe.sourceforge.net/ to net-install various distros... right now, we're trying to figure out a way so people can contribute their own packages...
<jcole> sladen: we were thinking about something along the lines of a user only contributing a source package, and then have an auto-build system that creates binary packages for the various distros... any suggestions?
<joelbryan> Hi, anyone please check out Bug #38426
<Ubugtu> Malone bug 38426 in ubuntu-meta ubuntu-desktop "A software to get live chat support in #ubuntu." [Normal,Unconfirmed]  http://launchpad.net/bugs/38426
<sebest> it seems bootcamp boots ubuntu too
<sebest> http://theweeklyrant.com/article/8/news-apple-bootcamp-boots-linux
<jcole> sladen: i've mentioned it here before, this is an example -> http://www.instalinux.com/cgi-bin/coe_bootimage.cgi
<sladen> jcole: in theory you can create deriviatives very easily under launchpad.  You could ask on #launchpad what the current status of that is
<sladen> jcole: who are "people", are they people internally to your company?  You can do a fair amount just by rebuilding the current install CDs and tweaking the pre-seed lists (which I think is what linuxcoe might be doing anyway)
<jcole> sladen: so, launchpad is the closest tool for the type of thing we are looking for?
<bddebian> fabbione: Ahh, sorry.  How is your imake/xmkmf foo? :-)
<fabbione> bddebian: so what is the next question?
<jcole> sladen: yes, what also makes it complicated is the combinations of distros and architectures
<fabbione> bddebian: just ask please :)
<jcole> sladen: ya, i'm the one making the ubuntu netinstall cds
<bddebian> fabbione: I think ivtools is exporting the wrong XCONFDIR path which is breaking the mxv build but I'm not getting it to take my changes on building ivtools
<Kamion> sebest: as previously mentioned, yeah, the installer boots under it, but you won't be able to install a bootloader and thereby complete the install
<jcole> sladen: i've created one for x86, amd64, ia64, and hppa
<Kamion> sebest: so it's fine for live CDs if you don't want to install them
<fabbione> bddebian: ok.. put the source somewhere with a proper explanation of what needs to be changed.. i will look at it when i have time
<jcole> sladen: also used bits from ports
<sladen> sebest: my hunch is that it's checking for an NTFS partition and knows specifically how to boot that from the hard-disk
<sebest> i saw that mjg59 worked on getting ubuntu working on mac hardware, how is the bootloader handled?
<sebest> it uses something like elilo?
<Kamion> sebest: elilo, yes
<Kamion> sebest: once you've booted using bootcamp, you can't talk to EFI to install elilo
<sebest> Kamion, does elilo support dualboot with macosx?
<Kamion> sebest: I don't know; don't see why not though
<Kamion> sebest: (I think the above claim about installing elilo may be a bit of a simplification, but it's certainly true in the short term at least)
<bddebian> fabbione: Actually I think my only problem is that buildpackage re-extracts the tarball everytime and overwrites my changes.  Does that mean I have to add a patching system and a patch?
<sebest> Kamion, in the long term it may be interesting to support bootcamp for the virtualisation features: running both os side by side
<Kamion> sebest: if you're willing to install the bootloader yourself, then there's no problem really supporting bootcamp
<Kamion> although apparently their VGA implementation isn't all that great
<fabbione> bddebian: eh.. what do you think?
<bddebian> fabbione: I don't think, that's my problem :)
<bddebian> OK, sorry
<fabbione> :)
<sebest> Kamion, that's still a beta, things may change until they releas it in 6 months or more
<bddebian> Fuck, I hate deviating that far from the Debian package :-(
<infinity> bddebian: Why on earth would you need to add a patch system?
<Kamion> sebest: sure, but to some extent we have to deal with what we've got now - and it *would* be better to get away from the legacy stuff if we can
<infinity> bddebian: Show me your current patch against the package.
<bddebian> infinity: Because it doesn't have one?
<ogra> bddebian, for some i'd love to just redo them ....
* ogra is just totally shocked by the ppp package
<infinity> bddebian: You don't need a patch system to patch a package.  What do you think difd.gz is all about?
<bddebian> ogra: You should see maelstrom :_)
<infinity> diff, too.
<bddebian> infinity: Oh, I don't know about diff.gz Hmm
<bddebian> Oh well yes I do
<ogra> bddebian, thanks, i already have to wear my xray proof glasses to no go blind here ;)
<bddebian> infinity: But dpkg-buildpackage overwites my source changes anytime I run it
<Kamion> bddebian: then either you're doing it wrong, or the package is overwriting stuff, not dpkg-buildpackage
<bddebian> Kamion: The package is yes
<Kamion> if you're editing in build-tree/, then it's probably got a patch system and you just haven't found it yet :)
<bddebian> fabbione: One quick question.  SHouldn't XCONFDIR be /etc/X11/config rather than /usr/lib/X11/config (which doesn't exist)
<fabbione> bddebian: i think so ..
<bddebian> Bah, you folks are useless.. ;-P
<bddebian> Just kidding
<jsgotangco> lol
* bddebian will become even more hated
<bddebian> Heya LaserJock
<LaserJock> hi bddebian 
<LaserJock> I can't imagine you being hated at all :-)
<bddebian> LaserJock: Hang out in #d-d for a little bit ;-P
<mvo> lol
<LaserJock> oh, I don't think so d-d (IRC and ML) scare me
<LaserJock> I'm glad d-d wasn't my first look at Debian. I would have stayed with Gentoo ;-)
<jsgotangco> its a nice cave indeed
<bddebian> Damnit, I'm going to have to strip ivtools again :(
<infinity> Kamion: Care to do some NBS removals?... The out-of-date output is getting rather messy (kernels, LRM, libsexy, d-i-utils..)
<bandini> mmh pdftops from poppler-utils seems to produce broken .ps files. Anyone else seeing this? (haven't found anything on bugzilla.fd.org & launchpad)
<Kamion> infinity: I would but archive-cruft-check is broken at the moment
<infinity> Kamion: Oh.  Then never mind. :)  I can read around the cruft.
<Kamion> infinity: I'll try to do some slightly more manually checked ones once I've finished caning my network connection with a d-i daily upload
<infinity> Kamion: One simple removal you could do is the 'xmkmf' source package from universe (and corresponding binary).. It's been eaten by imake in main.
<infinity> Kamion: Was causing some sketchy FTBFSs that I had to track down, due to the whacky conflicts and provides going on between imake and xmkmf.
* bddebian hides at the mention of imake/xmkmf
<bddebian> fabbione, or anyone else brave enough to looK:  Here is what I am trying to do to ivtools:  http://www2.bddebian.com:8000/packages/ubuntu/ivtools/ivtools-1.1.3.diff
<infinity> bddebian: And which part isn't sticking?  The last bit?
<bddebian> infinity: The src/scripts/ivmkmf stuff afaict
<azeem> maybe that file gets generated during build?
<infinity> Most likely.  Looking anyway.
* infinity freshens a chroot and grabs build-deps.
<Kamion> infinity: ok, that's not an NBS so wouldn't have been caught by the cruft-checker anyway; will do after this publisher run
<infinity> I wonder if it's bad that I'm still working at 2am.
<infinity> Kamion: Yeah, I know it's not NBS, it was an afterthought. :)
* jsgotangco yawns
<bddebian> infinity: No, it's great :-)
<Toadstool> heya here, sorry to bother you with a very low priority task, but anyone to check and maybe upload the latest debdiff I added to bug 36505?
<Ubugtu> Malone bug 36505 in lintian "Ubuntu Lintian shouldn't do the nmu checks" [Wishlist,In progress]  http://launchpad.net/bugs/36505
<Toadstool> it's an ubuntu lintian "customization"
<infinity> bddebian: I'm not sure what you were doing wrong, but when I apply your patch to a freshly-unpacked package, build a source package, then do a binary build from that, it works great.  Want me to sign and upload based on what I have here? :)
<bddebian> infinity: What does /usr/lib/ivtools/config/config.mk look like?
<infinity> bddebian: Wrong, in several special ways.
<infinity> XCONFIGDIR = /usr/lib/X11/config
<infinity> ABSTOP = /home/adconrad/foo/ivtools-1.1.3
<bddebian> Yep :-)
<infinity> But that's has nothing to do with the include directories in that other file you messed with, afaict.
<bddebian> XCONFIGDIR should get set to /etc/X11/config
<bddebian> Even if I run xmkmf and imake I still get that crap
<infinity> Just means your imake template isn't getting used.
<infinity> bddebian: Okay, I think I spot the issue here, but I also need to get some sleep and not look at this when I'm in a haze of confusion.
<infinity> bddebian: Can you poke me tomorrow, and I'll fix it up?
<bddebian> infinity: Of course, thanks man
<mdz> Keybuk: yes, I don't much care for the idea of bugs assigned to teams
<mdz> Keybuk: subscription leaves assignment open for an "I'll handle this request" workflow
<mdz> Keybuk: of course, some people ignore the instructions and assign to the team anyway
<Kamion> infinity: xmkmf removed
<bddebian> removed?
<bddebian> infinity: BTW, let me know if there is any way I can help the X Swat team with bugs even though I'm not a main uploader
<danimo> Keybuk: around?
<Kamion> bddebian: superseded by imake
<bddebian> Kamion: Really?  I thought you still needed to run xmkmf prior to imake? I.E. xmkmf -> Imakefile -> imake -> Makefile ?
<Kamion> bddebian: xmkmf is in the imake package now
<Kamion> so there is no longer a need for the xmkmf package
<Kamion> see infinity's request above
<bddebian> Ah, OK, sorry
<ogra> oh, youre on a removal quest ? 
<Kamion> ogra: not especially, but do you have something urgent?
<ogra> the ltsp-client-builder and power-manager sources could go as well ...
<ogra> not urgent 
<Kamion> ogra: can you give a reason for each, please? "superseded by <some other package>" is a good reason, for example
<Kamion> I need it for the record
<ogra> ok, ltsp-client-builder is included in ltsp since dapper 
<Kamion> ogra: the ltsp-client-builder source went away ages ago
<ogra> hmm, LP still shows them both for me ...
<Kamion> like pre-soyuz
<Kamion> ltsp-client-builder |    0.1.0-5 |        breezy | source
<Kamion> ltsp-client-builder |    0.1.0-5 | breezy/main/debian-installer | all
<Kamion> ltsp-client-builder |       0.84 | dapper/main/debian-installer | all
<Kamion> https://launchpad.net/distros/ubuntu/+source/ltsp-client-builder says "removed"
<ogra> ok
<Kamion> and if you're looking at https://launchpad.net/people/ogra/+packages then it says "Ubuntu Breezy"
<bddebian> Hmm, what to "fix" now then
<Kamion> ogra: ok, what was power-manager replaced by?
<ogra> power-manager was the helper for gnome-powermanager before we had it integrated properly
<ogra> its superseded by gdm or the libpam stuff mjg59 added, as you like 
<Kamion> libpam-foreground?
<ogra> yeah
<ogra> couldnt remember the right name 
<pitti> ugh, that espresso bug did a fairly good job of ruining my boot loader :/
<Kamion> ok, in future please try to make it your responsibility to provide these details, I don't want to have to do lots of research every time
<Riddell> Kamion: kde espresso is good to merge if you want
<dholbach> Kamion: are you removing stuff from the archive atm?
<ogra> first g-p-m used gdm instead of the power-manager backend, laetr libpam-foreground
<ogra> *later
<Kamion> dholbach: apparently so
<dholbach> Kamion: could you please remove evolution-caldav? it was merged into evolution-data-server.
<Kamion> ogra: power-manager done
<ogra> thanks :)
<ogra> Kinnison, would it be possible to have the release numbers instead of the release names in https://launchpad.net/people/ogra/+packages ? 
<Kamion> dholbach: done
<dholbach> Kamion: merci
<Kinnison> ogra: ask kiko
<ogra> sorting by distro release gets a bit unsorted since its alphabetical
<Kamion> dholbach: would a replaces or provides or something somewhere on evolution-caldav be a good idea
<Kamion> ?
<ogra> Kinnison, thanks... i'll wait until he drops the -zzz then :)
<Amaranth> ick, en_GB got into my /etc/environment again
<dholbach> Kamion: hmmm - might be
<bddebian> The source packages for python2.3-* are pretty much gone from the archive correct?
<bddebian> Like python2.3-numeric, etc
<dholbach> mdke: the newest ubuntu-docs seem to have problems with scrollkeeper update processing
<bddebian> Oh, maybe they are from the python2.3 package
<mdke> dholbach, I see it. making a note to fix it sometime
<dholbach> ok cool
<bddebian> Hmm, have I gone over my quota of dumb questions for the day?
<azeem> you now have
<bddebian> Bah, crawl back to Debian azeem ;-P
<bddebian> j/k
<azeem> oh, I thought you were serious :P
<bddebian> Kamion: Is python2.3-numeric, et al completely gone from the archive?
<Kamion> bddebian: if you want me to look things up for you, you need to be more specific than "et al", but yes, python2.3-numeric is no longer in dapper
<bddebian> Kamion: Sorry, I'm lookint at Malone bug 37625
<Ubugtu> Malone bug 37625 in matplotlib python2.3-matplotlib "python2.3-matplotlib has unavailable dependencies" [Major,Confirmed]  http://launchpad.net/bugs/37625
<zyga> hello
<bddebian> Hello zyga
<doko> bddebian: either port it to 2.4, or you have to duplicate all the sources, i.e. copy the python-numarray source to python2.3-numarray and just build the 2.3 module
<bddebian> doko: That was kind of what I was getting at I guess.  Is our "policy" that 2.3 just isn't "supported" any longer?
<doko> bddebian: correct
<bddebian> Great, then I'll just remove the 2.3 deps, thanks
<dborg> et merc available (ts2 only) but tell me early :>
<joelbryan> How will I edit System > Help > stuff?
<pitti> YAY SYNCS!!!
<jsgotangco> good night too
<pef> can someone with main upload privileges have a look at this pbuilder bug ? a debdiff is provided :) #38456
<pef> (thanks)
<mdke> joelbryan, you can't edit it, it's provided by the ubuntu-docs package
<mdke> joelbryan, the links themselves are in gnome-panel
<ogra> you could join the doctem to edit it :)
<ogra> *docteam
<mdke> ogra, our strings are freezing today :D
<ogra> oh ? why that ? 
<mdke> we want to allow more time for translation
<ogra> but you are freezing before the UI
<ogra> that can get complicated
<mdke> yes. if anything changes, it will be updated, and announced to the translators
<Kamion> pef: uploaded, thanks; I've left the bug for you to close
<ogra> i.e. edubuntu hanst even remotely its final artwork
<bddebian> Ack, why did I pick an ace bug ugh
<ogra> all screenshots would be shallow 
<pef> Kamion: thank you :)
<mdke> ogra, screenshots aren't strings. They aren't frozen. But anyway, we hardly use screenshots.
<ogra> ah
<mdke> and edubuntu docs aren't frozen either
<Kamion> Riddell: merged and pushed, thanks; sorry for the delay, I got distracted by archive stuff
<ogra> mdke, i know ... i'll be the one who freezes them :)
<ogra> since i write a bunch of them :)
<mdke> ogra, quite :)
<ogra> (in fact highvoltage writes the base and i just flesh it out a bit and fix ubuntu specifics in ltsp docs)
<sivang> Kamion: ping, around?
<sivang> Kamion: how good is the support for NTFS resize in d-i currently ? 
* sivang wonders where are everybody
<Burgwork> sivang, ntfs is pretty good, provided the ntfs drive is not heavily fragmented
<sivang> Burgwork: cool, have you tried it yourself ? (finally got a GOOD t43p and I need to resize :) )
<Burgwork> sivang, not recently, but I did use it for the first install
<sivang> Burgwork: Have you had free space on the drive with it?
<sivang> (stupid preloaders consumed all the disk)
<Burgwork> say again?
<sivang> Burgwork: prior to resizing, have you had any free space unpartitioned from the NTFS partitoin?
<Burgwork> nope
<sivang> Burgwork: cool then ;) let's see if it works well with dapper flight 6 
* sivang goes to install ubuntu and hopes to be back soon.
* sivang detaches
<mroth> win 4
<mroth> whoops :-)
<jdong> what does preload do in Dapper right now, if I were to install it?
<jdong> I know in SUSE 10 it's used as an adaptive readahead and prefetcher for firefox, OOo, and system bootup (others, too)
<Treenaks> jdub: An image for your 'Ubuntu PowerPC CDs' quote: http://www.worth1000.com/emailthis.asp?entry=274562 
<dieman> hmm
<dieman> it'd be fun to get my hands on a sun niagra t2000 box and host some of the ubuntu release bittorrents to see how it works out
<dieman> if i could get sun to ship me one and get ubuntu on it ;)
<KaiL_> ALSA lib pcm_dmix.c:819:(snd_pcm_dmix_open) unable to open slave
<KaiL_> what does that mean?
<sladen> KaiL_: related to software mixing
<sladen> please file against alsa-utils
<KaiL_> might also be some config remaining fom breezy times..?
<KaiL_> eh, hoary
<dholbach> good night guys
<KaiL_> sladen, dmix got automatically enabled on that update?
<KaiL_> ah, gone..
#ubuntu-devel 2006-04-12
<BenM> hey guys, have a quick package building question. I want to patch the makefile.am for some stuff
<BenM> what's the best way to get the .in regenerated
<bddebian> automake?
<BenM> but run it from where?
<bddebian> Depends but typically from the dir that Makefile.am is in
<BenM> somewhere in the fules file?
<bddebian> Oh, you mean at build time?
<BenM> lemme put it like this: i want to build the package after i patche the makefile.am
<BenM> what is my best plan
<lifeless> autoreconf in the build target
<bddebian> Aye
<BenM> ok, am a bit lost in the rules files, this is gnome-panel
<BenM> it seems to be getting those targets via a maze of includes
<BenM> would somebody mind n00bing me through it
<jcole> this may be a dumb question
<jcole> i installed apache2 and tried to share my downloaded ubuntu dvd... i'm getting "Value too large for defined data type" in my error.log... how do i make apache2 share large files?
<HrdwrBoB> you can't
<HrdwrBoB> is the simple answer
<jcole> HrdwrBoB: another web server perhaps?
<HrdwrBoB> jcole: no
<HrdwrBoB> files that big won't work with the clients either
<HrdwrBoB> don't use http for transferring files that big, use ftp
<jcole> ah
<jcole> doh!
<KaiL> hmm, does ekiga have Problems with their STUN-Server, am I just to stupid to set it up, or is there just a bug?
<lifeless> KaiL: try some details
<jcole> HrdwrBoB: thanks alot
<KaiL> on my desktop, which is directly connected to the NET, everything works. But not on the Laptop behind - it doesn't get audio data
<lifeless> KaiL: it depends on your NAT configurations
<bddebian> BenM: If you're still around after I get the kids in the bath, I can try to help you, though I'm not the most experienced
<lifeless> what nat device, the nat of the other endpoint
<lifeless> port constraints
<KaiL> ekiga says, it's a "port restricted NAT" (ipmasq on the first system)
<lifeless> ipmasq? not iptables ?
<KaiL> ipmasq afaik uses iptables
<lifeless> port restricted NAT is a pretty useless feedback btw, not your fault, ekigas.
<lifeless> KaiL: ipmasq - ip masquerade - != iptables
<lifeless> unless you are using some whacky compatability layer.
<KaiL> ah, ok
<jdub> lifeless: apt-cache show ipmasq
* jdub loved ipmasq when he used it 8)
<KaiL> afaik it's a script to configure iptables to do NAT
<jdub> clever little package
<lifeless> jdub: meep
<lifeless> ok.
<KaiL> so this setup is not enough, even as ekiga says?
<lifeless> heres a good reference for you
<lifeless> http://en.wikipedia.org/wiki/STUN
<lifeless> ekiga is telling you at most 1/3 the story
<KaiL> uh
<lifeless> its probable you need a sip proxy, and I don't know if they supply one
<HiddenWolf> they do
<lifeless> specifically, I don't know what class nat ipmasq configures iptables to be
<lifeless> HiddenWolf: oh? cool. whats its dns name ?
<HiddenWolf> I don't know, I just know that ekiga has a stun-check and uses an ekiga.net stun if need be.
<KaiL> HiddenWolf, yes, but that only helps the login
<HiddenWolf> Know nothing about how it works besides  that, sorry.
<KaiL> not to receice audio data :/
<lifeless> HiddenWolf: STUN != sip proxy.
<HiddenWolf> Hm, right
<HiddenWolf> sorry guys
<lifeless> HiddenWolf: the stun server is at stun.ekiga.net, but all stun does is allow you to find out the external ip and port you should use to talk to the other party.
<lifeless> np
<HiddenWolf> If you are using SIP, yes. You can use SIPROXD from http://siproxd.sourceforge.net as outbound proxy.
<HiddenWolf> Ekiga faq
<lifeless> HiddenWolf: not what I meant. I meant *does ekiga provide the sip proxy*
<lifeless> HiddenWolf: not 'can people install their own'.
<HiddenWolf> It answers the "does ekiga provide it" question with a solid no. :)
<lifeless> HiddenWolf: well, I guess :0
<HiddenWolf> btw, I can't get ekiga to start
<HiddenWolf> lots of /dev/device fun
<HiddenWolf> I have an audio card and an usb-headset and a tv-tuner and webcam. :)
<lifeless> kill all alsa using programs
<lifeless> kill rb
<lifeless> its pretty horrendous
<HiddenWolf> that is kinda sick
<lifeless> yup
<HiddenWolf> why the hell don't they play along?
<lifeless> couldashouldawoulda
<lifeless> jdub: my windtendo is aging. I'm thinking I want this in my new one: http://www.newegg.com/Product/Product.asp?Item=N82E16814121002
<jdub> lifeless: sick fuck ;)
<lifeless> (its > 2 years old, time for an upgrade)
<jdub> lifeless: you're office is loud enough as it is already!
<HiddenWolf> I'm just a noob, I don't know if it's possible even, but I guess I'd want ekiga to be on 24/7 and mute/pauze/lower RB volume when I get called. :)
<lifeless> HiddenWolf: I would like the same
<jdub> HiddenWolf: yeah, totally
<lifeless> shtoom plays nicer
<lifeless> but its ui is, as jdub would say, bong
<HiddenWolf> heh
<HiddenWolf> Well, my problem is I have both a tv-card and a webcam, and effectively 2 audio cards. :)
<HiddenWolf> Which get initialised in a random order when I boot.
<BenM> jdub, hey, i think my pgo feed isn't updating
<HiddenWolf> so things looking for /dev/video get random results. :)
<HrdwrBoB> HiddenWolf: which is bad, but not as bad as random ethernet order
<BenM> also, am still waiting for you to put up the hacker head
<HiddenWolf> HrdwrBoB: nothing serious, seems to be intended udev behavior, I just have to edit the tvtime config file a few times a week, when it tries to show my webcam ;)
<jdub> BenM: will look
<HiddenWolf> I guess I should file a bug some day.
<jdub> BenM: oh. you're blogspot.
<HrdwrBoB> HiddenWolf: if it's on boot, it should boot up with the same order
<HrdwrBoB> but if you un/replug it, all bets are off
<HiddenWolf> HrdwrBoB: on boot, different order.
<bddebian> Anyone up on the dhIconCache thing?  Do we really just need to add dh_iconcache to debian/rules?  I assume in install: ?
<lifeless> jdub: upgrading my firewall....from warty
<jdub> lifeless: ha ha
<mdz> Kamion: what happened to /dists/dapper/main/installer-i386/current/images/cdrom/initrd.list ?
<bddebian> Should libtyvis1 still be libtyvis1c2?
<lifeless> ok, it begins. if I disappear, I've fucked the firewall. News at 11.
<bluefoxicy> is there some channel on irc where I should discuss random things like Ubuntu's upcoming netauth support (someone did spec out NIS/LDAP/ActiveDirectory/KRB authentication, it's apparently slated for Dapper+1) and roaming /home directories?
<bluefoxicy> even Red Hat doesn't have roaming /home... it shouldn't be hard with ldap + sshfs/NFS + bind mount + PAM module; but you'll have to write a PAM module :)
<bluefoxicy> well, you could just mount the roaming /home tree on /home in its entirity; but it's more fun to mount it as /mnt/home mode rwx------ (700) and bind mount only users logged in... it'd be an information leak if only 'who' and 'w' didn't exist already 8)
<LaserJock> #ubuntu-offtopic ? ;-)
<HrdwrBoB> it's not offtopic
<bluefoxicy> well it depends on how on topic you want to be  8)
<bluefoxicy> I know on ubuntu-devel@ about every message posted is claimed to be offtopic by someone
<LaserJock> yeah, well that is why I don't dare email ubuntu-devel :-)
<bluefoxicy> they've actually been getting criticisms there
<bluefoxicy> "and yes, your message was offtopic: everything is offtopic here, since this is supposed to be a zero-traffic list.  oh and all your messages are belong to us"
<bluefoxicy> there we go :P
<LaserJock> I can understand. When I'm working hard on dev work it is really distracting to have lots of "noise"
<bluefoxicy> it's fairly entertaining though
<LaserJock> not when I'm trying to get work done
<bddebian> Should the mime stuff be handled in .desktop or the xml files now?
<Burgundavia> joelbryan: nice work on LiveChatSupport
<Burgundavia> joelbryan: there if a good class in the new gtk to do wizard/druid style stuff
<infinity> Oh, isn't this smashing.  On dist-upgrade, discover has hung in D state.
<Burgundavia> joelbryan: umm, you rock even harder
<pitti> Good morning
<fabbione> hey pitti
<pitti> hi fabbione, how's it going?
<fabbione> pitti: as usual
<fabbione> you=?
<fabbione> infinity, Mithrandir: i am taking  a lock on xorg
<pitti> fabbione: in the mood for squashing bugs :)
<fabbione> pitti: isn't that what we are supposed to be doing 23 hours/day?
<fabbione> 1 hour for feeding and personal igiene should be enough for everybody :P
<pitti> fabbione: right, sleeping and real life are for wimps :)
<joelbryan> Burgundavia: thanks man! finally I can smile! :-)
<Burgundavia> joelbryan: one note about the registration thing on freenode. I would reorder that section slightly, I would have them create their nick and on the last page, with the connect button, also have a register button, which would launch a seperate dialog
<mdke_> joelbryan, is this intended to go into dapper?
<joelbryan> Burgundavia: so a checkbox that says "Register me" would be available in account login screen?
<joelbryan> mdke_: hopefully man :-) I'll work hard for this if this would go into Dapper.
<mdke_> joelbryan, the feature freeze passed quite a long time ago: make sure you ask someone important ASAP about it
<Burgundavia> joelbryan: oh, nevermind, it already does that
<Burgundavia> joelbryan: however, are you aware of the gtk stock dialog to do wizardy stuff?
<Burgundavia> I would also cut down the number of channels that are automatically added to the contact list
<joelbryan> Burgundavia: yes
<Burgundavia> maybe only add the localized #ubuntu and then point them at the channel wiki page
<joelbryan> Burgundavia: how about depending on their locale?, will it be autojoined?
<mdke_> although, I remember someone saying (perhaps jokingly) that part of the reason for removing xchat-gnome from the default install was so that people would stop complaining about the reception they get in #ubuntu
<Burgundavia> joelbryan: their locale is a good choice
<Burgundavia> you need to have a some sanity checks to make certain they don't autojoin a channel that doesn't exist
<infinity> fabbione: Lock whetever you want, I'm barely even paying attention to anything other than buildds right now.
<infinity> fabbione: (Including IRC, obviously)
<fabbione> infinity: yeah it was just to avoid multiple people uploading the same (you did yesterday and Mith other times) ;)
<joelbryan> Burgundavia: will it take long to register a local channel in freenode?
<joelbryan> Burgundavia: is there something needed to be wizarded?
<mpt> sladen, ping
<sladen> mpt: yo
<mpt> sladen, what do the Launchpad-specific parts of your user style sheet look like? :-)
<mpt> and who else do you know who uses them?
<sladen> mpt: http://www.paul.sladen.org/ubuntu/launchpad/  But nobody else users them and I mostly make do just by having the font smaller so there is less wrapped/overflowed content
<mpt> thanks
<Burgundavia> joelbryan: that is not a problem I think this wizard should solve. It should only connect them to existing channels
<mvo> can a native speaker please have a look at http://paste.ubuntu-nl.org/11665 (failed searches in gnome-app-install help text). does that sound ok? 
<mdke_> looking
<mdke_> mvo, doing a few amendments, is it ok to use the word "you"?
<mvo> I suppose so, not sure
<mdke_> mvo, http://paste.ubuntu-nl.org/11666
<mdke_> actually, maybe "The search has no results" is better
<mvo> thanks, fixes
<mdke_> mvo, also perhaps s/has restrictions/is restricted
<mvo> mdke_: thanks, done as well
<mdke_> which package are the translations for the logout dialogue in? gnome-panel?
<seb128> no, gnome-session
<seb128> why? is there an issue?
<mdke_> seb128, no. a translator just asked where they will appear in Rosetta
<seb128> k, so gnome-session :)
<mdke_> thanks
<seb128> I looked the pot before uploading, it had them
<seb128> so it should be fine
<mdke_> cool, i don't know how frequently rosetta updates, but it will be there eventually
<mdke_> seb128, another quick question. Gnome is an exception to upstream version freeze, isn't it? does the same apply to gstreamer?
<pitti> seb128, carlos: so, what's the decision for bug 35403?
<Ubugtu> Malone bug 35403 in gucharmap "Help .pot file is not being generated" [Normal,Confirmed]  http://launchpad.net/bugs/35403
<seb128> mdke_: why that question?
<carlos> pitti: whatever you think is better for you
<mdke_> seb128, a different question by the same translator.
<seb128> pitti: bug #35418 too
<Ubugtu> Malone bug 35418 in gedit "Help .pot file is not being generated" [Normal,Confirmed]  http://launchpad.net/bugs/35418
<carlos> pitti: I'm deleting the .po files without a .pot file, when you upload it with a .pot file it will be imported
<carlos> seb128, pitti: there are others that I didn't reported as you have a list of missing .pot files...
<seb128> mdke_: tell him we consider new versions but they don't have the exact same cycle as GNOME for tarball rolling
<mdke_> seb128, thank you.
<seb128> mdke_: we will ship new tarball from this week and next week if that's the question
<mdke_> seb128, wow, from gstreamer cvs?
<mdke_> rocking
<seb128> no, new tarballs, not cvs version
<seb128> they have planned new gst -base -good I think
<mdke_> right
<seb128> and probably -bad next week for slomo :p
<pitti> carlos: so, when pot files for these are generated, can we ignore them for the langpack export tarballs?
<seb128> carlos: rosetta question, do you have a "give me a tarball with all the .po for my project" feature for upstream now? if not is it planned?
<carlos> pitti: yes, I have a flag per potemplate that decides whether it will appear as part of the language pack
<infinity> pitti: BTW, your recent changes to pkgstriptranslations to fix the exit code on error now makes espresso FTBFS.  So, is that your fault (for not having some slever override for such situations), my fault (for enabling fail-on-inconsistent-CurrentlyBuilding on the buildds) or Colin's fault (for building packages inside other packages)?
<pitti> seb128: hm, that works for ages, doesn't it?
<seb128> pitti: where is the function?
<infinity> s/slever/clever/
<pitti> seb128: https://launchpad.net/products/pmount/+series/main/+pots/pmount/+export
<carlos> seb128: we have that per potemplate, it should be trivial to add it for all potemplates available for a project, please file a bug
<seb128> pitti: oh, thanks you
<carlos> seb128: oh, you wanted only for a concrete template?
<seb128> carlos: by potemplate is good enough
<pitti> infinity: hm, due to empty po files?
<pitti> seb128: or due to enabling set -e in dpkg-deb?
<infinity> pitti: No, due to building source packages inside source packages. :)
<carlos> ok
<seb128> carlos: yeah, gaim upstream discussion about if rosetta would be easy to use for them
<infinity> pitti: Thus causing CurrentlyBuilding to appear inconsistent.
<carlos> seb128: do they want to use it directly from upstream?
<pitti> infinity: so you don't mean yesterday's change?
<seb128> carlos: discussing it
<infinity> pitti: Well, yesterday's change fixed the part where we weren't exiting non-zero on error. :)
<seb128> carlos: I would appreciate some comments from jordim though, is he working this week? He didn't reply yesterday
<pitti> carlos: alright, when seb128 is fine with me changing cdbs, I'll generate pot for help/
<carlos> seb128: sounds good, please, tell them to ask jordi to solve any question they could have
<carlos> jordi: ^^^
<seb128> pitti: I'm fine with you changing it whenever you want
<seb128> jordi: https://launchpad.net/distros/ubuntu/+source/gaim/+bug/38330
<Ubugtu> Malone bug 38330 in gaim "Rosetta Translations" [Normal,Rejected]  
<infinity> pitti: http://librarian.launchpad.net/1966090/buildlog_ubuntu-dapper-i386.espresso_0.99.41_FAILEDTOBUILD.txt.gz
<pitti> infinity: ok, I understand now; I thought you refered to 'yesterday' with 'recent' :)
<carlos> seb128: he's online now, but busy with other things. Mail will work better
<seb128> I'll subscribe it to the bug
<seb128> s/it/him
<pitti> infinity, Kamion: would be fine for me to special-case espresso as a band-aid
<carlos> seb128: cool, thanks
<infinity> pitti: That was yesterday. :)
<infinity> pitti: (The "set -e" fix)
<infinity> Of course, that was my bug to begin with (oops)
<pitti> ah, clear now
<infinity> Kamion: Around?
<pitti> hmm, I try to find a more general solution than just [ "$package" = espresso ] 
<infinity> Oh, eww, it's going to get ugly in other ways too.
<pitti> infinity: we could also disable the consistency checking in the first place
<pitti> infinity: it was mainly meant to check that everything works smoothly when we started using pkgstriptranslations
<infinity> If any of those subpackages contain translations, we'd end up with extras in the espresso_translations tarball.
<pitti> infinity: why, are the sub-tarballs added to espresso's translation tarball?
<hunger> ubuntu-artwork fails to install at the moment.
<infinity> pitti: Erm, wait, no, good point, they'd be made with the sub-package's name, and then just never uploaded.
<infinity> So that's fine.
<pitti> yes, that's what I thought
<pitti> infinity: that would be bad if espresso modified the strings of the embedded packages, but that's another story
* infinity really isn't keen on espresso shipping "static" copies of all this stuff..
<infinity> But I guess I can see why.
<infinity> pitti: Well, I can disable the CurrentlyBuilding check, but then we have nothing failing builds in the cases where it really does explode (like, if I break sbuild somehow)
<infinity> pitti: I suppose that's a chance we can take... Or we can get Colin to work around it somehow.
<pitti> infinity: a hideous hack is to hardcode the exception, a slightly better one to introduce a blacklist for it
<infinity> pitti: If he doesn't actually need debs, but just the result of the package builds, he could just skip on creating debs, and fish stuff out of package-1.2.3/debian/package/
<infinity> pitti: Or, yes, we could have an "allow_cb_inconsistent" list, and add espresso to it.  That's easy enough.
<pitti> infinity: both would be fine for me; let's wait for Kamion and ask him, then I'll do the change
<seb128> pitti: when is planned the next language-pack update?
<pitti> seb128: I can roll one whenever we want to
<pitti> I wanted to wait just a little to get more KDE imported by Rosetta
<pitti> but it won't be the last one anyway
<seb128> like this afternoon? :)
<pitti> well, why not :)
<seb128> it would help translators to figure where they are
<seb128> to have like a weekly update from now
<pitti> seb128: I have to wait 5 hours still, Rosetta exports tarballs in the afternoon now
<pitti> not overly comfortable for me, but that needs to be enough
<seb128> oh, there is a daily fixed export?
* infinity wonders why update-notifier appears to no longer be notifying him of updates...
<pitti> yep, I cron'ed everything
<seb128> what is not comfortable? doing an update today?
<infinity> mvo: Your applet hates me.
<seb128> monday is good too, don't stress youtself :)
<seb128> infinity: is it running?
<infinity> seb128: Yes. :
<infinity> P
<seb128> oh oh
<pitti> seb128: no, I mean exports in the late afternoon
<seb128> /usr/lib/update-notifier/apt-check
<seb128> Traceback (most recent call last):
<seb128>   File "/usr/lib/update-notifier/apt-check", line 57, in ?
<seb128>     saveDistUpgrade(depcache)
<seb128>   File "/usr/lib/update-notifier/apt-check", line 20, in saveDistUpgrade
<seb128>     clean(depcache)
<seb128>   File "/usr/lib/update-notifier/apt-check", line 13, in clean
<seb128>     for pkg in depcache:
<seb128> TypeError: iteration over non-sequence
<seb128> mvo: what did you do !!! :)
<seb128> pitti: ah, k
<pitti> seb128: works here
<seb128> ii  update-notifier          0.41.12                  Daemon which notifies about package updates
<pitti> same here
* mvo looks
<pitti> seb128: heh, the final hoary tarball was produced *exactly* 1 year ago :)
<seb128> happy anniversary :p
<doko> Kamion, mdz: any word on the printing related UVF exceptions, so pitti and I can go on with the upgrades?
<Kamion> mdz: moved to udeb.list in the parent directory, in line with Debian; I think the file format might have changed a bit to
<jalalabadddddddd> Steve & Denise Mertz
<jalalabadddddddd> 
<jalalabadddddddd> 1926 Old Dixie Dr
<jalalabadddddddd> Richmond, TX 77469-6811
<jalalabadddddddd> (832) 595-8254
<Kamion> doko: I haven't even read that mail yet, give me a chance
<Kamion> infinity: I only need the result of the package builds, not debs/udebs; but I do need to call binary-arch/indep
<jalalabadddddddd> zhivago
<jalalabadddddddd> zhivago docs
<jalalabadddddddd> Steve & Denise Mertz
<jalalabadddddddd> 
<jalalabadddddddd> 1926 Old Dixie Dr
<jalalabadddddddd> Richmond, TX 77469-6811
<jalalabadddddddd> (832) 595-8254
<infinity> Kamion: Right, then whitelist it is.
<Kamion> fabbione: ping, op needed
* mode/#ubuntu-devel [+o fabbione]  by ChanServ
* mode/#ubuntu-devel [+b *!*@toronto-HSE-ppp3972384.sympatico.ca]  by fabbione
* jalalabadddddddd was kicked off #ubuntu-devel by fabbione (fabbione)
<Kamion> ta
<fabbione> np
<infinity> pitti: Looks like we need a "skip consistency check" whitelist, then.
<Kamion> infinity: is there a way for espresso to set something while building those packages that says "don't run pkgstriptranslations"?
<infinity> Kamion: No, but we could certainly fix that easily.
<infinity> Kamion: I'm all about magic environment variables.
<infinity> pitti: How would you feel about that?
<pitti> sounds good
<infinity> Right, and given the impending rename, we'll do this once.
<fabbione> does vmware run on platforms != x86 based?
<pitti> infinity: rename == pkgmangler, or whatever?
<infinity> Kamion: How's "NO_PKG_MANGLE" being set and non-empty sound to you?
<jdub> infinity: what was the libmysqlclient15off stuff?
<Kamion> infinity: I sort of agree with you on espresso shipping static copies, but all the alternatives seemed worse
<Kamion> and at least there's a neat 'debian/rules update' target
<infinity> Kamion: Just rememnet to unset it again after running all the sub-builds.
<Kamion> NO_PKG_MANGLE is fine
* infinity will fix it now, document it later.
<Kamion> infinity: yeah, that's no problem, it's in a subshell anyway
<Kamion> all that stuff is hived off to d-i/Makefile
<infinity> jdub: We've had versioned symbols for ages.  Upstream (off = official) finally accepted our patch for symbol versioning, but decided on a different version tag.  Boom.
<infinity> pitti: I'll upload for this change right now, if you don't mind.
<pitti> infinity: sure, go ahead :)
<pef> how can I refresh desktop menu entries with files present in /usr/share/applications ?
<jdub> infinity: ahr. bong. so that'll die with the next soname change?
<infinity> jdub: Right.
<ogra> lifeless, ping
<infinity> jdub: I'd have yelled at them about it, but I was so happy that we finally talked them into symbol versioning at all, I preferred to just leave it alone and fix it.
<infinity> jdub: I would have been more miffed if either of us (Debian or Ubuntu) had actually released with the old lib, but we hadn't yet.
* seb128 kicks rosetta
<lifeless> ogra: ?
<seb128> https://launchpad.net/products/gnome-session/+translations defaulting to "hoary"
<ogra> lifeless, you were one of the guys seeing g-s-s pop in regardless of input after suspend
<ogra> lifeless, i'm waiting for feedback to (hopefully) close that bug
<ogra> bug 33523
<Ubugtu> Malone bug 33523 in gnome-screensaver "g-screensaver starts after idle period, regardless of user input" [Major,Needs info]  http://launchpad.net/bugs/33523
<pitti> Kinnison: in about 2/3 of cases I get a 'Suspend failed' bubble from g-p-m immediately after resume; known bug?
<pitti> Kinnison: (i. e. the bubble is the bug, suspend/resume works for ages on the iBook)
<pitti> s/works/has worked/
<Kamion> infinity: let me know when I should upload
<infinity> Kamion: Whenever?  I can give them back when they fail.
<infinity> Kamion: pkgstriptranslations_27_source.changes just uploaded now, though.
<infinity>    * If NO_PKG_MANGLE is set and non-empty, don't run pkgstriptranslations
<infinity>      for the current dpkg-deb invocation, but print a warning so we know.
<Kamion> infinity: ok, espresso 0.99.42 uploading now
<infinity> Kamion: Thanks, dude.  Thou dost truely rule.
<infinity> And stuff.
<lifeless> ogra: do you think you have fixed it ?
<lifeless> ogra: I'll reboot tomorrow, see how it goes.
<ogra> lifeless, yes, some people already reported success, but i want to hear it from you and Mithrandir
<ogra> (to be sure)
<ogra> Mithrandir is on vac anyway, so no hurry
<lifeless> ogra: okies
<ogra> :)
<ogra> congrats to the new job btw :)
<Kamion> pitti: hmm, damn, I promoted git-core before spotting that it had a number of other dependencies listed by anastacia; do you think you could have a quick look over them? they're just perl modules
<pitti> Kamion: sure
<lifeless> ogra: thanks 
<lifeless> its actually a little premature 
<lifeless> when dapper goes out I'll be switching
* infinity watches as Kamion continues his "more Perl in main" campaign subtly.
<ogra> ah
<lifeless> until then I'm helping deliver bzr for dapper
<ogra> so are you the guy to poke for a working bzrk ? 
<ogra> poke poke
<pitti> Kamion: hm, I just see asciidoc
<pitti> Kamion: ah, for git-email, nevermind
<mvo> infinity: I'm uploading a update-notifier that should fix the problem you mentioned earlier
<infinity> mvo: And that's why I love you.
* mvo hugs infinity
<Kamion> oh, and I missed asciidoc too. go me.
<pitti> Kamion: libemail-valid-perl has an RC bug with a patch
<jordi> seb128: I can have a look at that gaim reply this evening
<seb128> jordi: I've Cced you on the bug, I think I replied correctly but that's in case upstream have some specific question next, thank you :)
<jordi> ok
<jordi> let's talk about it when I'm back home in the evening
<pitti> Kamion: libnet-domain-tld-perl has an RC bug as well :/
<pitti> Kamion: maybe you can temporarily demote just git-email until this is sorted out?
<infinity> pitti: That's technically the same RC bug, twice. :)
<Kamion> pitti: all right, git-email is back in universe
<pitti> fabbione: do you want git-email in main? it has a series of perl module dependencies, some of them have RC bugs
<infinity> pitti: I can fix those up right now.  It's essentially one bug in two places, easily fixes.
<infinity> s/fixes/fixed/
<pitti> would be nice, I didn't look at the details
<infinity> pitti: libnet-domain-tld-perl has exactly one rdep (libemail-valid-perl), so fixing the latter to work with the former (and adding a conflict in the other direction to force smooth upgrades) is easy.
<infinity> pitti: Doing.
<infinity> Err, wait.
<infinity> We don't have that RC bug yet anyway, cause we never synced the new version.
<infinity> Go us.
<Lathiat> haha
<infinity> pitti: The RC bug doesn't apply to Ubuntu.  Do you want me to sync the bug in (and then fix it), or just leave it as-is? :)
<fabbione> pitti: well yes.. it's used quite a lot for kernel devel
<infinity> pitti: If I leave it, we can probably safely assume Debian will have it sorted when we start autosyncing for dapper+1.
<pitti> infinity: sounds good for me
<pitti> infinity: (leaving as it is)
<infinity> Right, then.
<infinity> Kamion: git-email and dependencies good to go, then. :)
<pitti> yep, security history and bugs are fine; didn't check the packages so far, but I'm not afraid of surprises
<infinity> It's hard to be surprised by perl modules.
<infinity> They're all packaged pretty much the same.
<pitti> carlos, seb128: new cdbs is up
<seb128> with help stuff?
<pitti> yes
<seb128> cool
<pitti> this will probably break my buildd import, but should be easy enough to fix
<seb128> why?
<fabbione> infinity: are you still looking at mesa stuff?
<pitti> seb128: dload-strippedtar will be confused if it finds two pot files with the same name
<fabbione> infinity: if so #34856 =
<fabbione> ?
<seb128> ah, k
<infinity> fabbione: deop yourself, scary man. :)
<pitti> seb128: I'll just blacklist help/, no big deal
* mode/#ubuntu-devel [-o fabbione]  by fabbione
<fabbione> whops..
<fabbione> sorry
<fabbione> i didn't meant to be scary :P
<carlos> pitti: are they using the same filename for the help?
<seb128> pitti: ok, cool. Still doing language pack update this afternoon so? :)
<pitti> carlos: usually
<carlos> ok
<pitti> seb128: sure
<carlos> pitti: for dapper, breezy and hoary?
<infinity> fabbione: Yeah, I'll steal that bug.
<pitti> carlos: let's do dapper for now
<fabbione> infinity: k thx
<pitti> carlos: no time to do all three of them today
<carlos> ok
* infinity ponders quitting for the weekend..
<sandra> Hello. Was libdevmapper upgraded recently ? sudenly iy is incompatible with my kernel and I can't use the dev-mapper (to mount my encrypted home).
<seb128> lamont: around?
<sladen> sandra: what error message do you get?
<fabbione> sandra: what kernel are you running? what version of libdevmapper? and what version of Ubuntu?
<fabbione> seb128: does gdm still implements the FallBackServer option? the one that is started if the default server doesn't work?
<seb128> lamont: what was your usecase for the "strict" focus mode? What does metacity does by default annoying you? Cf http://bugzilla.gnome.org/show_bug.cgi?id=326159 upstream, they are discussing putting app launched from a command line to background automatically by example
<Ubugtu> Gnome bug 326159 in general "Experimental strict-focus-approximation feature" [Normal,New]  
<sandra> This is ubuntu 5.10, Linux 2.6.12-10-686, libdevmapper1.01 1.01.03-1ubuntu2
<fabbione> sandra: unlikely.. it's a stable release..
<fabbione> sandra: only security fixes go there and libdevmapper didn't get any
<sandra> The error is:
<seb128> fabbione: there is no such option afaik
<sandra> BTW, this was a kubuntu installation where I installed ubuntu-desktop. It was working till then.
<sandra> Can anybody tell me the output of ls /etc/rc.*/*crypt* ?
<sandra> The error is (among others): Incompatible libdevmapper 1.01.03 (2005-06-13)(compat) and kernel driver.
<fabbione> seb128: #FailsafeXServer=
<fabbione>  <-
<fabbione> sandra: please use pastebin and show all errors.
<seb128> fabbione: ah, right
<fabbione> seb128: problem is #27020
<seb128> bug #27020
<Ubugtu> Malone bug 27020 in xorg xserver-xorg "Please make X fallback to vesa if the card driver doesn't work." [Wishlist,Confirmed]  http://launchpad.net/bugs/27020
<sandra> fabbione: I can copy and paste the errors, I can type them, but itl take long.
<fabbione> seb128: i want to approach it in 2 ways... one using gdm fallback (after i test it) and as more hardcore, as boot option
<fabbione> sandra: copy/paste them to pastebin?
<fabbione> seb128: do you have any gdm uploads pending?
<seb128> fabbione: new tarball for GNOME 2.14.1 due monday
<seb128> nothing planned today
<fabbione> seb128: ok thanks
<seb128> the failsafe code is still here
<seb128> I just looked
<seb128> so it should work
<fabbione> seb128: ok thanks...
<seb128> deal_with_x_crashes (GdmDisplay *d) to daemon/gdm.c if you need to have a look to the code
<sandra> The error: http://paste.lisp.org/display/18726
<fabbione> seb128: yes... we want to disable at least the error that comes up when we go to failsafe, or make it less scary
<fabbione> sandra: it seems like the dm-mod is not loaded
<fabbione> can you please do modprobe dm-mod
<fabbione> and rerun that script?
<sandra> fabbione: that was it! I didn't know the name of the module, thanks!
<sandra> fabbione: now, any idas why it is not being loaded by default ? how shoudl it be loaded.
<fabbione> sandra: it should be loaded by default.. there might be an error message before that you haven't seen perhaps
<sandra> fabbione: maybe, let me see.
<Keybuk> fabbione: dm-mod is loaded by the lvm initramfs script; assuming BOOT=local and ROOT=/dev/mapper/*
<fabbione> Keybuk: yes, that's why i find suprising it's not loaded for sandra
<sandra> I removed lvm from init, but I re-added it and it didn't help. Somehow I think rcconf and friends screwed up my init, any ideas of how to restore it ?
<sebest> keybuk : hello, do you have an idea for bug 38392 ?
<Ubugtu> Malone bug 38392 in network-manager "Regression: network-manager doesn't find the wifi iface if the software switch is off when NetworkManager starts" [Major,Unconfirmed]  http://launchpad.net/bugs/38392
<Keybuk> sebest: nope; I'll copy it upstream when I go through them later
<sebest> Keybuk, interface detection is done throught hal, i guess?
<Keybuk> I believe so
<sebest> because i can see that detection in hal works
<Keybuk> NM in general isn't very good at keeping up with changes to interfaces
<Keybuk> which is ironic, given that's arguably its one job!
<sebest> when the softswitch is off, i can see the interface
<sebest> and when i switch it on, something appear under it : "Networking interface"
<Keybuk> sebest: I would recommend making sure all this information is in the bu
<sebest> i'm using the hal gui to see this
<Keybuk> bug
<Keybuk> include lshal output and stuff
<Keybuk> that way when upstream look at it, they'll have the information
<sebest> ok i update it
<Keybuk> it's not something I'm going to put any time/effort into trying to debug/fix myself
<sebest> ok, so let's hope they'll find the bug...
<Keybuk> I hope they find all the bugs :)
<sebest> Keybuk, is there a lot of ubuntu specific patch? or could i try the official 0.6.2 to check that the issue is in it too?
<Keybuk> there's almost no Ubuntu specific patch now
<Keybuk> that which there was for 0.5 was all folded into upstream's 0.6
<Keybuk> most of the patches we apply are from the NM mailing list itself nowadays
<sebest> Keybuk, i updated the bug with lshal output
<sebest> i'll try to trace the regression, testing older release
<sebest> Keybuk, maybe it's this libnl ...
<Keybuk> doubt it
<Keybuk> that's not that interesting
<sebest> i thought it was related to netlink , we use netlink in avahi to detect iface status
<sebest> so i thought the iface status was missdetect or something...
<Keybuk> yeah, but I doubt it's a bug in libnl
<Keybuk> from what I've seen of libnl, it's just a very badly written wrapper around the kernel netlink API
<Keybuk> NM is still interpreting the changes
<mdke_> 1.Is there a list anywhere of the amount of hard disk space the various minimal/standard/desktop installations take up? and is the python stuff included in all of those?
<Keybuk> http://people.ubuntu.com/~cjwatson/germinate-output/dapper/
<mdke_> Keybuk, that's great thanks
<sebest> Keybuk, i've noticed something, for some unknown reason, lshal doesn't display "info.linux.driver" for my ipw2100 
<Keybuk> at any time?
<sebest> yes at any time
<Keybuk> kooky
<sebest> i'm reading the code, trying to find if it does something special when ->driver == NULL
<Keybuk> probably does nothing :)
<Keybuk> I think NM cares about ->driver
<sebest> i'll add some debug info to see what going on
<sebest> i think something bad happen in nm_device_new
<KaiL> ubuntu-artwork package broken?
<dholbach> KaiL: known issue
<KaiL> k
<sebest> Keybuk, i think i found part of the bug
<Keybuk> sebest: oh, aye?
<sebest> there is a real bug in nm, but it has always been there, but my problem is a side effect
<sebest> it seems that before, my module was autoloaded on boot
<sebest> so when networkmanager start it found the iface (with the software switch off)
<sebest> but now, the module is no more loaded at boot time
<sebest> so networkmanager doesn't find it when it starts
<Keybuk> ok, so let's debug the first problem first
<Keybuk> and get that module loading
<Keybuk> you're running an up to date dapper install, yes?
<sebest> yes
<Keybuk> ok, and you're not doing anything silly like compiling your own kernel?
<sebest> i think i notice the problem because something changed in the autoloading of modules
<sebest> no
<Keybuk> right
<sebest> i'm using a vanilla ubuntu dapper
<Keybuk> could you run the following two commands, and paste the output somewhere (not directly here, use a nopaste)
<Keybuk> lspci
<Keybuk> lspci -n
<lifeless> Keybuk: is network manager worth installing yet ?
<Keybuk> lifeless: if it works for you, try it;  but it's not good enough for default installation at this point
<sebest> Keybuk, what do you want to see from lspci, because as you guess, i have some network issue ;)
<sebest> in my bug repport i pasted the output of lspci -v 
<lifeless> Keybuk: you know me and network .. :0 I'll pass
<Keybuk> ok, what was the bug# ?
<sebest> bug 38392
<Ubugtu> Malone bug 38392 in network-manager "Regression: network-manager doesn't find the wifi iface if the software switch is off when NetworkManager starts" [Major,Unconfirmed]  http://launchpad.net/bugs/38392
<Keybuk> ok
<Keybuk> it's the IPW2100 that's not detected, right?
<Keybuk> sebest: cat /sys/bus/pci/devices/0000:02:06.0/modalias
<Keybuk> (it's a complicated string, so type it carefully here)
<lamont> seb128: what metacity was doing that prompted "strict" focus mode was changing focus from the window that had it.  Thereby occasionally causing me to type in a window that I didn't want to at this time.
<lamont> seb128: the use model is "I've manually focused my windows with the pointer for 15 years, and I don't want to change from that model"
<sebest> Keybuk, v00008086d00001043sv00008086sd00002527bc02sc80i00
<Keybuk> sebest: you forgot the "pci:" on the front :p
<sebest> yes :)
<sebest> pci:v00008086d00001043sv00008086sd00002527bc02sc80i00
<Keybuk> ok
<Keybuk> now run
<Keybuk> modinfo ipw2100 | grep pci:v00008086d00001043sv00008086sd00002527
<lifeless> lamont: you use follow-mouse too ?
<lifeless> lamont: and are crying at metacities regression ?
<Keybuk> it's not the full string, you don't want the "bc02sc80i00" bit
<sebest> yes ok?
<Keybuk> did you get anything back?
<sebest> yes
<sebest> with some stars
<Keybuk> should have been alias: pci:blahblahbc*sc*i*
<sebest> bc*sc*i*
<Keybuk> right
<Keybuk> ok
<Keybuk> now run this
<lamont> lifeless: I use "strict".  what regression?
<Keybuk> modprobe -v -n --first-time pci:v00008086d00001043sv00008086sd00002527bc02sc80i00
<Keybuk> (note that that's the full string)
<Keybuk> and paste the output here
<lifeless> lamont: I use 'select windows when the mouse moves over them'
<lifeless> lamont: and its not doing it
<sebest> modprobe -v -n --first-time pci:v00008086d00001043sv00008086sd00002527bc02sc80i00
<lamont> lifeless: gconf-editor, change it from whatever to "strict" - see if that gives you more love...
<sebest_> Keybuk, FATAL: Module ipw2100 already in kernel.
<Keybuk> sebest_: did you load that 
<Keybuk> ?
* sebest_ using irc copy/pasting
<Riddell> Kamion: I'm getting this error on espresso's language selection page, any ideas how to fix? http://kubuntu.pastebin.com/645919
<sebest_> Keybuk, ah you want me to reboot and test from a fresh boot?
<Keybuk> sebest_: if you've already loaded that module, you'll need to reboot
<lifeless> lamont: what key to change ?
<Keybuk> yes
<Keybuk> can't debug why things don't work if it's not fresh :)
<sebest_> ok
<lamont> lifeless: checking
<lamont> apps, metacity, general, focus_mode
<sebest> Keybuk, i can't use "lsmod | grep ipw2100" to check if the module is loaded or not?
<lifeless> lamont: mines on sloppy
<lifeless> and the help does not mention strict
<Keybuk> sebest: you can, yes; but that isn't the answer to the question
<Keybuk> that modprobe command will yield more information than just "is loaded or not"
<lifeless> lamont: no love :p 
<lamont> lifeless: strict is only mentioned in the source - and it wouldn't surprise me if you have to restart metacity to have it see the change..
<lifeless> meep
<sebest> ok, it tolded me witch module it loaded
<lifeless> ok, I'll fiddle tomrrow, I've a few things to tweak on
<lamont> lifeless: seb128 added it under some duress :-)
<lamont> to warty
<lifeless> lamont: how does strict and sloppy differ ?
<sebest> Keybuk, it just output on line
<Keybuk> sebest: what was that line?
<lifeless> and strict and mouse for that matter
<lamont> sloppy allows metacity to use it's mind in hijacking focus for new windows.  strict says "no"
<lifeless> ah, THANK YOU GOD^WLamont
<sebest> module path with 2.6.15-20-686/path to ipw2100.ko
<Keybuk> ok
<sebest> you need the exact line?
<Keybuk> nah
<Keybuk> just the fact it said that module is enough
<lamont> if (whole complex logic) && !strict { take focus to newly created window }
<lifeless> lamont: now if I can figure out why its fully borked right now
<Keybuk> so this tells us that you have a module for that device, and that the system should be loading that module
<lifeless> only alt-tab and clicking are changing focus
<Keybuk> ok
<Keybuk> sebest: was it just the one line?
<Keybuk> or was there also a line for ieee8011.ko ?
<lamont> lifeless: oh... I found a website or two that b0rked it into that mode.
<sebest> Keybuk, only one line
<lifeless> websites ?!
<lamont> java R^()$(^%)&^ app
<Keybuk> sebest: lsmod | grep ieee80211 -- loaded or not?
<lamont> at least, that was all I could attribute it to...  restarting helped. :-)
<lifeless> you are kdding me right
<sebest> yes
<Keybuk> sebest: anything after the numbers?
<pitti> yay, tailor finally worked
<sebest> and _crypt to
<lamont> lifeless: I, uh, didn't trouble shoot it very hard. 
<sebest> ieee80211 37032 0
<Keybuk> odd
<Keybuk> wonder what loaded that
<Keybuk> ok
<Keybuk> onwards
<sebest> and _crypt  6528 1 ieee80211
<Keybuk> grep "^U.*0000:02:06.0" /var/log/udev
<Keybuk> do you get exactly two lines, one beginning UEVENT and one beginning UDEV ?
<sebest> i get 5
<Keybuk> 5 lines?  ok, you'll have to type those
<sebest> ok, so the first one is:
<sebest> UEVENT [ts]  add@/class/firmware/0000:02:06.0
<sebest> then the same with UDEV
<sebest> then the 2 same line with s/add/remove/
<sebest> then the last one
<lifeless> lamont: :)
<sebest> UDEV [ts]  add@/devices/pci0000:00:1e.0/0000:06:06.0
<sebest> oups sorry UDEV [ts]  add@/devices/pci0000:00:1e.0/0000:02:06.0
<sebest> UDEV [ts]  add@/devices/pci0000:00/0000:00:1e.0/0000:02:06.0
<Keybuk> is there a UEVENT for that UDEV ?
<sebest> no
<Keybuk> not to worry
<Keybuk> right, open /var/log/udev with less or something
<Keybuk> and find that UDEV line (look for 0000:02:06.0)
<Keybuk> does it have MODALIAS= then the module string?
* sebest brb
<sebest> Keybuk, yes there is a moalias
<Keybuk> and it's the same?
<sebest> yes
<Keybuk> okies
<Keybuk> back to the prompt
<Keybuk> now run grep "^UDEV.*ipw" /var/log/udev
<Keybuk> and type the results here (including the timestamps, I'm afraid)
<zul> heylo
* sebest needs a serial cable
<sebest> [something.958964]  add@/module/ipw2100
<sebest> [samething.959695]  add@/bus/pci/drivers/ipw2100
<sebest> Keybuk, here it is
<seb128> lifeless: I think there is some bug fixed upstream with mouse focus, dholbach knows about it
<Keybuk> sebest: grep "^UDEV.*eth" /var/log/udev
<sebest> UDEV [ts]  add@/class/net/eth0
<sebest> and then eth1
<Keybuk> sebest: grep ^MODULES= /etc/default/acpi-support
<sebest> the vars are empty
<Keybuk> ok
<lifeless> seb128: thanks. if rebooting doesn't clear it up, I'll check malone etc
<Keybuk> grep -r ipw2100 /etc
<Keybuk> (as root, to avoid the Permission Denied errors)
<Keybuk> there should be no mention of it, is there?
<dholbach> seb128: i'm not sure, which bug that was, but i'll have a look on it too again
<sebest> nothing
<Keybuk> ok
<Keybuk> well, I've no idea then
<Keybuk> you've got something on your system calling "rmmod ipw2100"
<sebest> may i suggest something?
<Keybuk> it's detected fine, the module is loaded, and for a brief period you have eth1
<Keybuk> sure
<sebest> it may be the fsam7400 module
<Keybuk> what's that?
<seb128> dholbach: ta
<sebest> it the module that control the soft switch
<Keybuk> oh right
<Keybuk> is that one you load manually?
<sebest> no
<Keybuk> what loads that then?
<sebest> but it seems his behaviour changed
<sebest> befor when it was loaded, it loaded also ipw2100
<Keybuk> parm:           autoload:load/unloads ipw2100 driver when toggling radio (default) (i)
<Keybuk> yes
<Keybuk> that would certainly break the world
<Keybuk> what a stupid module
<sebest> but it has always worked before
<sebest> and the version number didn't changed
<sebest> so it seems there is a bad interaction somewhere..
<Keybuk> you must be loading that manually
<Keybuk> did you put it in /etc/modules ?
<sebest> you mean fsam7400 ?
<Keybuk> yes
<sebest> i have a file in /etc/modprobe.d/
<Keybuk> what does that file look like?
<sebest> that's me who did it, just to change the gid=
<sebest> to allow my own user to change the status of the switch
<sebest> options fsam7400 gid=106
<Keybuk> you must also have done something to load that module
<Keybuk> it won't be automatically loaded
<sebest> yes i added it to /etc/modules
<Keybuk> riiiight
<sebest> that's not good?
<Keybuk> stick autoload=0 to the end of that options line
<azeem> 14:08 < sebest> i'm using a vanilla ubuntu dapper
<sebest> oki, i reboot?
<Keybuk> azeem: yes, well, who EVER believes a user when they claim that? :)
<Keybuk> sebest: yup, reboot
<Keybuk> "I didn't touch it, honest, it just LEAPT off the mantlepiece"
<Keybuk> "I tripped, and fell, and landed o"..ANYWAY!
<Keybuk> BenC: ping
<sebest> if i don't add this to modules, how am i supposed to have wifi working?
<Keybuk> sebest: should be ok, as long as you've got that autoload=0 option
<sebest> yes it seems better
<sebest> ok it works now
<sebest> Keybuk, thanx for the help! 
<Keybuk> no worries
<sebest> but don't you think that this modprobe.d file should be added 
<sebest> other people with the same module will have the same problem no?
<Kamion> Riddell: yeah, I ran into the same thing the other day; you need to upgrade localechooser-data to a version including Thai support
<sebest> because "autoload=1" is the default of the module
<Keybuk> bug 38597
<Ubugtu> Malone bug 38597 in linux-source-2.6.15 "fsam7400 is fucking stupid" [Normal,Unconfirmed]  http://launchpad.net/bugs/38597
<doko> Riddell: ping
<Keybuk> sebest: yup, I agree; better to fix the kernel :)
<sebest> Keybuk, i'm not sure that fsam7400 load and unload, i think it load it, and something else unload it
<sebest> i think this, because i'm using the module for 2 years now (the exact same version) and i have this issue until recently
<sebest|lunch> Keybuk, thanx again for your patience! and help!
<mjg59> Keybuk: Oh my christ, that's insane
<Riddell> doko: hi
<Keybuk> sebest|lunch: ipw2100 is loaded automatically because you have one in your system
<Keybuk> in general, modules should never be unloaded
<Keybuk> about the only exception to that is dealing with suspend/resume where sometimes you have to reset the hardware
<Riddell> Kamion: that sorted it, thanks
<lifeless> Keybuk: like with da ipw2200's ;)
<Kamion> good good
<lifeless> Keybuk: while you're here, whats the magic these days to bring up a stanza FOO when the interface BAR is brought up by udev events ?
<Keybuk> lifeless: you'll have to be a bit more specific
<Keybuk> what's FOO, what's BAR?
<lifeless> well
<lifeless> BAR is eth1
<lifeless> FOO is 'home'
<Keybuk> you want to mount /home when eth1 is brought up?
<lifeless> no
<lifeless> I want the hotplugging infrastructure to do the equivalent of 'ifup eth1=home' rather than 'ifup eth1'
<Keybuk> oh, sorry
<lifeless> np, was not as clear as possible
<Keybuk> I think it's pretty much as documented
<Keybuk> one of the reasons I got rid of that stupid "mapping hotplug" crap was that it broke this
<Keybuk> mapping eth0
<Keybuk>    script /some/test/or/other
<Keybuk>    map HOME eth0-home
<Keybuk>    map WORK eth0-work
<Keybuk> iface eth0-home inet ...
<Keybuk> iface eth0-wokr inet ...
<Keybuk> auto eth0
<lifeless> Keybuk: you're saying that that is current - if I put a mapping stanza back in it should work ?
<Keybuk> udev will "ifup eth0" (with a check it's got an auto line), ifup will bring up either eth0-home or eth0-work depending on what /some/test/or/other returns
<Keybuk> lifeless: yup
<lifeless> danke
<BenC> Keybuk: pong
<lifeless> mapping eth1
<lifeless>   script /bin/echo
<lifeless>   map eth1 home
<lifeless> :)
* BenC laughs at bug #38597
<Ubugtu> Malone bug 38597 in linux-source-2.6.15 "fsam7400 is fucking stupid" [Normal,Unconfirmed]  http://launchpad.net/bugs/38597
<HiddenWolf> Well, that's certainly a positive attitude. :)
<Keybuk> BenC: please apply that patch <g>
<Keybuk> lifeless: heh, that's a somewhat trivial example, but yes
<BenC> Keybuk: will do, and thanks for the bug report ;)
<Keybuk> lifeless: making sure you have "auto eth1"
<Keybuk> (not auto eth1-home)
<hunger> Is somebody working on a fix for ubuntu-artwork already?
<Keybuk> or "auto home", which would be the matching equivalent
<Keybuk> uh, to clarify
<Keybuk> you want "auto eth1" "iface home inet ..."  but not "auto home"
<lifeless> Keybuk: yes I have auth eth1
<lifeless> the interface stanza for home is literally 'home' not 'eth1-home'
<Keybuk> yup
<Keybuk> that sounds right then
<lifeless> the reason I dont have auto home or auto eth1-home is that thats not what udev finds :).
<Keybuk> yup, you don't want them either
<lifeless> I used to have a mapping stanza way back, but it got borked, so I worked around. I'm glad its restored.
<bddebian> Hello folks
<folks> hello bddebian
<bddebian> Uhm, heh
<lifeless> yeouch
<sladen> hunger: please join  ubuntu-artwork@lists.ubuntu.com  there doesn't seem to be any way to get responses through the bugtracker or on IRC from any of the art people
<lifeless> I need a hand with a dapper upgrade that just deep-sixed
<lifeless> PANIC: Circular dependancy.   Exiting.
<Keybuk> cute
<sladen> lifeless: funky.
<lifeless> this is an amd64 3000+ desktop
<Keybuk> I like it when initramfs does that
<Keybuk> and I blame jbailey
<sladen> lifeless: did it say anything about the packages that might be circularising?
<Keybuk> sladen: of course not, that'd be useful
* bddebian heard that Kamion was supposed to lart him for an empty upload :'-(
<Keybuk> lifeless: easiest debug ... boot with break=top (and no quiet/splash) on the kernel command line
<lifeless> Keybuk: thank you
<Keybuk> then grep ^PREREQ scripts/*/*
<sladen> Keybuk: /win 28
<Keybuk> sladen: /lose 40
<lifeless> http://pastebin.com/646013
<lifeless> sladen: ^^
<Keybuk> lifeless: ok, so it's in local-top
<Keybuk> that narrows it down a bit
<Keybuk> lifeless: can you boot a different kernel/initramfs pair?
<lifeless> Keybuk: no, I had to remove them to let initramfs work at all
<lifeless> Keybuk: I had upgraded in series from hoary - breezy, then breezy - dapper
<Keybuk> sorry, clarify me a moment; what state is the machine in right now?
<lifeless> is booting with break=top still useful ?
<Kamion> bddebian: huh?
<Keybuk> is it in "not booting and panic'ing" state, with no alternate kernel to fall back on?
<lifeless> failing to boot with that error in recovery mode, hard lock with coloured line fragments in normal boot. One kernel available. 
<Keybuk> ok
<Keybuk> boot with break=top then
<bddebian> Kamion: ajmitch said you were going to lart me for an empty upload of silc-toolkit, which I don't know how it happened?
<lifeless> I have a separate partition with a 64-bit kernel
<lifeless> and separate ubuntu install
<lifeless> and a windows install as well.
<lifeless> thats all the state I can think of thats relevant
<Keybuk> yup
<Keybuk> break=top with the failing kernel
<Keybuk> it'll give you a shell in the initramfs
<lifeless> oh, and the incomplete install of dapper packages.
<lifeless> ok, its up
<Keybuk> ok, ls scripts/local-top
<Kamion> bddebian: was just wrongly-named .install files so the binaries ended up mostly empty; it's fixed now, I'd already mostly forgotten about it :)
<Keybuk> what's in there?
<lifeless> evms md lvm
<sladen> lifeless: oh.  that's the kernel, not apt or anything
<Keybuk> ok
<Keybuk> incomplete dapper install, eh? :p
<lifeless> Keybuk: ubuntu-base, ubuntu-standard are both fully installed
<bddebian> Kamion: Was it in my "fix"?
<Keybuk> lifeless: oh, really?
<Keybuk> lifeless: grep ^PREREQ scripts/local-top/*
<lifeless> Keybuk: well, I can't check *now*, but aptitude seemed to think so.
<lifeless> heh
<lifeless> md wants udev
<Keybuk> right
<Keybuk> md should want udev
<Keybuk> ls init-premount init-bottom
<lifeless> maybe initramfs should set a minimum udev version ?
<lifeless> neither exist
<Keybuk> initramfs doesn't depend on udev at all; ubuntu-minimal does
<Keybuk> sorry
<Keybuk> ls scripts/init-premount scripts/init-bottom
<lifeless> nothing and thermal respectively
<Keybuk> right
<Keybuk> I bet I know what's happened here
<mdke_> dholbach, new docs package for you. the error you pointed out has been fixed
<Keybuk> do you reckon you could scream "INFINITY!" loud enough so he can here you? :p
<Keybuk> hear even
<lifeless> theermal is 0 length
<dholbach> mdke_: super
* lifeless screams
<jdub> Keybuk: i can recalibrate the OLP
<bddebian> infinity: awake yet? :-)
<Keybuk> lifeless: sed -i s/udev// scripts/local-top/md
<lifeless> done
<Keybuk> is your hard-disk ide or scsi?
<lifeless> ide
<Keybuk> root= ?
<lifeless> /dev/hda6 IIRC.
<Keybuk> mknod b 3 6 /dev/hda6
<Keybuk> uh
<Keybuk> mknod /dev/hda6 b 3 6
<lifeless> better :)
<Keybuk> then hit ^D and see how far you get
<lifeless> up to init
<lifeless> /dev/loop is readonly
<lifeless> looks recoverable from here
<Keybuk> yeah this boot will be verrrrry messy
<Keybuk> hopefully you'll get a shell though
<lifeless> thank you *very* much
<Keybuk> now
<Keybuk> once you have a shell, check /usr/share/initramfs-tools/scripts/local-top
<Keybuk> and see if that has udev in it
<Keybuk> if so, update-initramfs -u
<Keybuk> and prepare a can of whoop-ass for infinity when he surfaces
<Keybuk> if not, let's debug more why this is so
<lifeless> no
<lifeless> it does not
<Keybuk> right
<Keybuk> interesting
<Keybuk> dpkg-query -W ubuntu-minimal initramfs-tools udev
<lifeless> 0.106
<lifeless> 0.40ubuntu28
<lifeless> 0.060-1ubuntu15
<lifeless> in that order
<Keybuk> apt-cache policy udev
<lifeless> want the lot, or a subset ?
<Keybuk> just Installed/Candidate
<lifeless> installed 0.060-1ubuntu5 candidate 079-0ubuntu24
<Keybuk> right
<Keybuk> is /dev massively populated at this point, or rather empty?
<lifeless> ubuntu-minimal needs a versioned depends ?
<lifeless> populated
<dholbach> mdke_: doesn't build
<lifeless> 1436 entries
<Keybuk> ok, is root fs read/write?
<lifeless> rw
<lifeless> I'm good to repair from here I think
<dholbach> mdke_: ubuntu/browser-startpage/index-fi_FI.html not found
<Keybuk> ok, apt-get install udev
<Keybuk> lifeless: we generally trust that people do upgrade everything by default
<lifeless> I can see whats fucked - there is no dependency requirement for the version that is needed to make initramfs work
<Keybuk> mdadm needs a minimal version though, you'reright
<lifeless> should I file a bug for you ?
<Keybuk> no need, upload already on its way into the archive
<lifeless> sweet. 
<lifeless> thanks
<mdke_> dholbach, sorry, fixed
<jdub> lifeless, Keybuk: not good for your launchpad karma! ;-)
<Keybuk> jdub: we all pale in comparison to seb128 anyway
<jdub> lifeless, Keybuk: you can't jsut communicate like human beings when karma is at stake
<lifeless> jdub: good for keybuks, hes uploading
<lifeless> jdub: meh, check my karma, see if I am worried
<jdub> you will be crushed by MECHA SEB128
<seb128> lol
<bddebian> heh
<lifeless> lts see if this boots more happily
<jdub> and his sidekick MECHA DANIEL.HOLBA.CH
<_mvo_> haha
<dholbach> hahaha :)
<lifeless> right, its half way there.
* dholbach hugs jdub
<jdub> they were built in a volcano, you know
<lifeless> now recovery mode boots fine
<lifeless> but the 'normal' boot crashes with a 'corrupted' video display
<lifeless> I'm about to try without splash
<lifeless> confirmed, 'splash' breaks my boot
<lifeless> is it possible that a missing package causes that ? 
<dholbach> mdke_: uploading
<janimo> seb128, I'd like gdm to depend on the xubuntu package proving the theme as an alternate to current ubuntu and edubuntu artwork deps
<janimo> should I file a bug, or upload myself?
<janimo> or what about depending on a virtual package and have the various artwork packages provide that?
<seb128> janimo: like https://launchpad.net/distros/ubuntu/+source/gdm/+bug/38551 ?
<Ubugtu> Malone bug 38551 in gdm "gdm should depends on xubuntu-artwork too" [Normal,Confirmed]  
<janimo> :) prbably
<carlos> who is in charge of dappers' bzr?
* janimo sighs in relief aftwer thinkng maybe he files a bug and completely forgot
<_mvo_> janimo: did you had a chance to look at the upgrade issue I send you?
<janimo> _mv_ yes looked at it
<janimo> but am not sure what it could be
<janimo> the theme package which overwrites the other
<janimo> actually depends on a version of the other which should not conflict
<mdke_> dholbach, thanks
<janimo> it depends on xfwm >4.3 
<janimo> and should only conflict with an oledr version of xwfm4 (4.2)
<janimo> seb128, it;s anothetr package name thatn it says there
<janimo> updatung the bug info
<seb128> janimo: ok, thank you
<sebest|lunch> mjg59, i have a question about wifi softswitch and ubuntu, most softswitch needs something like "echo 1 > /proc/driver/wireless/radio" , how is it handled from a gui point of view in ubuntu?
<janimo> carlos it's jbailey who did the last uploads
<sebest> Keybuk, i noticed something weird, since the autoload=0 my wifi interface is eth2 (it used to be eth1)
<Keybuk> paste /etc/iftab and ifconfig -a somewhere
<janimo> _mvo_ sent an answer now.
<janimo> is this a during a normal dist-upgrde
<janimo> I have to install a breezy chroot and try it myself
<sebest_> Keybuk, http://pastebin.com/646106
<_mvo_> janimo: thanks
<mjg59> sebest: It isn't
<sebest> mjg59,  i will never be? 
<mjg59> sebest: If somebody writes good code to implement it, it will be
<mjg59> It's the sort of thing that ought to be done through hal
<janimo> mjg59, do you think X can be made (without patching) to inherit 'at_console' from a tty if launched via startx?
<mjg59> janimo: No
<Keybuk> sebest: I don't know why it's eth1 ... but if you want it to be -- add "eth1 mac 00:0C:F1:0F:89:34" to your /etc/iftab file
<sebest> mjg59, but i can't be really generic?!
<janimo> mjg59, hmm so only the gdm case is supported  I guess
<mjg59> janimo: Any display manager
<mjg59> sebest: I don't understand the question
<sebest> Keybuk, i don't really mind, it's just strange that the name changed for no apparent reason
<sebest> mjg59, each softswitch implementation use a different way to switch on/off
<mjg59> sebest: So it should be done through hal
<Keybuk> sebest: yeah, it's strange; attach /var/log/udev somewhere
<Keybuk> paste/copy it
<sebest> mjg59, you mean the "module" should export something using hal? 
<mjg59> sebest: No, I mean hal needs to be taught about these modules
<sebest_> Keybuk, i kept the interesting thing only: http://pastebin.com/646123
<Keybuk> sebest: weird
<Keybuk> oh
<Keybuk> no, I see what happened
<Keybuk> your wireless card initialised faster, and got eth0
<Keybuk> your network card got eth1
<Keybuk> then they got swapped, and your wireless popped up to eth2
<Keybuk> if you explicitly name it eth1, it'll work right
<Keybuk> that'll force it to wait an extra second
<sebest> using /etc/iftab
<Keybuk> yup
<sebest> the question is why, does the network card got eth1
<janimo> _mvo_ has unattended-upgrades anything to do with a virtual package?
<Keybuk> cause it took longer to initialise than your wireless card
<Keybuk> tg3 is it?
<janimo> I see the cdimage reports have u-m as uninstallble
<sebest> no
<sebest> b44
<Keybuk> ok
<Keybuk> doesn't matter anyway
<janimo> I ahve done xubuntu install today and something about that being a virtual package was in the log
<_mvo_> janimo: no
<janimo> http://cdimage.ubuntu.com/xubuntu/daily/current/report.html
<sebest> Keybuk, that's the first time i notice this
<_mvo_> janimo: it's possible that hasn't yet been promoted to main
<janimo> aha
<_mvo_> janimo: its a new depedency of update-manager
<janimo> probably, ok so probably that's the cause of uninstallability.thanks
<sebest> Keybuk, but as you seen my iftab says that eth0 is reserved for the wired card, so it shouldn't have happened, no?
<Keybuk> sebest: the reservation happens in userspace
<Keybuk> not in kernel land
<Keybuk> kernel gave it the name eth0, userspace responded to that by renaming it to something else
<Keybuk> in this case eth2 because the wired had eth1 (kernel named)
<Keybuk> and userspace responded to that by renaming wired to eth0
<Keybuk> you just managed to get the timing exactly right so they went eth0/eth2
<sebest> ok, that makes senses
<Keybuk> was probably happening before
<Keybuk> but fsam7400 unloaded the ipw2100 driver, and when it was loaded again, there was no eth1, so that number was free
<sebest> i don't think so, because i was connectiong wifi by hand
<sebest> so i would have notice it if i had to type something else than eth1 in the cli
<sebest> Keybuk, i've rebooted 3 times, and it is always eth2, i think that fsam7400 does something stupid with autoload=0 (like loading it and removing it imediately)
<Keybuk> sebest: did you make the modification to /etc/iftab
<sebest> no, because i wanted to check the timing issue
<sebest> i just wanted to check if it was "no luck" or if it was constantly eth2
<Keybuk> it's always constant
<Keybuk> even though it's luck
<Keybuk> hardware is often predictable
<sebest> yes, but before this autoload=0, it was always eth1
<Keybuk> this card takes Xms, this card takes Yms, etc.
<Keybuk> yes
<Keybuk> and I explained why
<Keybuk> during boot, it was eth2
<Keybuk> then it was unloaded by fsam7400
<Keybuk> when you loaded it later, it was eth1
<Keybuk> because that was free at the time
<Keybuk> it's only eth2 because of a fun little race
<sebest> ok, i'll bind it to eth1 with iftab
<sebest> fsam7400, shouldn't load/unload anything, stupid module
<pitti> Riddell, seb128, carlos: new test langpacks in http://people.ubuntu.com/~pitti/langpacks/ 
<carlos> pitti: cool, thanks
<Riddell> pitti: looks good to me
<pitti> seb128: they work fine for me
<pitti> Riddell: cool, thanks
<Riddell> pitti: did we decide what to do with koffice-l10n?  do I just need to poke someone to move it into main?
<pitti> Riddell: oh, right, yes; if carlos needs it in main, we'll move it there
<pitti> Riddell: it's just a bit weird since we only need the source in main, not the binaries
<Riddell> yeah
<carlos> pitti: Riddell: The kubuntu-translations spec says that we were going to move the .po files inside the binary packages and remove those empty packages...
<pitti> carlos: any problem from your side?
<pitti> carlos: (the new debs)
<lemsx1> Bug #38609
<pitti> carlos: *what*?
<Ubugtu> Malone bug 38609 in gnome-system-tools "disks-admin doesn't cope with encrypted disks in fstab" [Normal,Unconfirmed]  http://launchpad.net/bugs/38609
<pitti> carlos: po files in debs?
<lemsx1> simple bug to fix
<carlos> pitti: sorry, inside the same source where the binaries come from
<Riddell> lemsx1: attach a patch then and make sure the gnome packagers are aware
<pitti> carlos: ah, that makes sense; however, AIUI KDE upstream just doesn't work that way?
<carlos> pitti: https://wiki.ubuntu.com/KubuntuTranslations
<carlos> no they don't work that way
<carlos> "k3b has a separate k3b-i18n package that only contains .po files. This can be merged into k3b to prevent an empty k3b-i18n binary package."
<carlos> that's what we talk at UBZ, I didn't remember it until this week, when JaneW pointed me back to that spec...
<pitti> carlos: yes, for {koffice,k3b}-i18n that would be really helpful
<carlos> pitti: it doesn't affect Rosetta at all
<carlos> Riddell:  so it's up to you
<pitti> I thought you mean kde-i18n-*
<carlos> nomed, no, sorry :-P
<carlos> fuck
<pitti> Kinnison: AYT?
<carlos> the nick completion....
<Kinnison> pitti: aye
<pitti> Kinnison: I'm about to upload 500 shiny new language packs, and I would like to avoid using the normal way for that
<pitti> Kinnison: last time, cprov manually uploaded them with bypassing the *-changes announcement email
<pitti> Kinnison: can I bother you with that today?
<Riddell> I'm somewhat against putting them together in the same package because it deviates from debian and means I have to spend some time doing that
<Kinnison> pitti: umm, sure, I think we can do that
<pitti> Riddell, carlos: alternatively, why not drop these two -i18n packages altogether and just use Rosetta?
<Riddell> pitti: how do you mean just use rosetta?
<Kinnison> pitti: Did you prepare a dir on chinstrap with them all in or something?
<carlos> Riddell: that's ok for me, I was just pointing at what we wrote in the spec, as I said, it doesn't affect Rosetta at all
<pitti> Kinnison: will have it ready in some minutes (on rookery, though)
<carlos> pitti: who will upload those translations?
<pitti> carlos: just upload a big tarball once?
<carlos> pitti: I guess we could do something like what we planned for firefox and debian installer
<pitti> carlos, Riddell: nevermind if that was a crackful idea
<Kinnison> pitti: so long as it somewhere I can get to from drescher I imagine it'll all be fine
<carlos> Riddell: that would allow you to do an upload from inside our datacenter to a given URL without asking you for extra permissions or SSL certificates
<Riddell> seems easiest to me to just promote the source packages to main
<carlos> but I don't think I will have it ready for next week... in the mean time, we will need those empty packages...
<carlos> Riddell: another option is to do it manually from the website
<carlos> until that feature is in place, That's only needed once per new upstream version, and I guess you are not going to import new things from upstream, right?
<Riddell> carlos: now koffice is coming out on sunday, I may ask for an upstream version freeze exception for it
<carlos> we could then do the upload on Monday and remove the i18n packages from Ubuntu's archive
<carlos> if you provide me with a tarball with all .po files, I can do it for you
<carlos> (in fact, I'm not sure if you have enough rights to do it)
<Riddell> ok
<Riddell> carlos: otherwise, how is KDE translations importing going?
<carlos> Riddell: kdebase and kdemultimedia are done
<carlos> I detected a bug in my code that prevents the automatic import of .po files that use '_' char as part of its name
<seb128> pitti: re
<carlos> but It has an easy fix I will implement next week
<seb128> pitti: /usr/share/i18n/locales dropped from the language pack ... is that on purpose?
<carlos> Riddell: I was late to activate them to be used with the new language packs...
<carlos> but next ones will use Rosetta
<pitti> seb128: yes, that dir was superfluous
<seb128> /usr/share/locale-langpack/fr/LC_MESSAGES/debconf.mo has been dropped 
<seb128> and /usr/share/locale-langpack/fr/LC_MESSAGES/xine-lib.mo from the gnome one
<pitti> hm, strange
<seb128> /usr/share/locale-langpack/fr/LC_MESSAGES/xfce-utils.mo and /usr/share/locale-langpack/fr/LC_MESSAGES/xfdesktop.mo too
<seb128> (running my diff hack before installing)
<seb128> I'm running your previous batch, not the official ones I think (if that makes a difference)
<Kinnison> pitti: msg me when you're ready
<desrt> dholbach; ping
<pitti> seb128: right, these domains are nowhere in the langpacks
<carlos> pitti: I'm having problems with the update
<desrt> dholbach; just so i don't leave you hanging... i won't be able to reply to bug mail for about the rest of april.  finals.
<carlos> pitti: https://chinstrap.ubuntu.com/~dsilvers/paste/fileft4y7t.html
<desrt> dholbach; cheers.
<pitti> carlos: you have to install the base langpacks at the same time, I think
<pitti> carlos: oh, no
<pitti> language-pack-gnome-es_6.04+20060324_all.deb
<carlos> pitti: I think we imported those .pot files recently inside Rosetta, but perhaps the .po files were missing at the time the mirror started...
<pitti> carlos: ^ old
<carlos> pitti: the base packages is already installed
<pitti> carlos: you need to install the recent language-pack-gnome-es
<pitti> you can't install a newer base with an older update
<carlos> oh, right, I didn't get it... :-P
<pitti> seb128: ah, I see; look at http://people.ubuntu.com/~pitti/langpacks/dload-strippedtar.txt
<carlos> pitti: works, thanks
<pitti> seb128: ===== Processing /home/lamont/public_html/translations/20060315/debconf_1.4.72ubuntu1_i386_translations.tar.gz =====
<pitti> wasabi: debconf_1.4.72ubuntu1: 1 domains, but 2 pot files
<pitti> elmo: debconf_1.4.72ubuntu1: debconf.pot occurs twice
<pitti> wasabi, elmo: sorry, auto nick completion; ^ this was W: and E:
* pitti kicks xchat
<seb128> "===== Processing /home/lamont/public_html/translations/20060322/xine-lib_1.1.1+ubuntu2-6_i386_translations.tar.gz ====="
<carlos> this fucked xchat-gnome doesn't have a way to disble the nick autocompletion....
<carlos> :-(
<seb128> and that one?
<seb128> carlos: "xchat.conf:completion_suffix = :"
<seb128> carlos: edit that with your favorite editor
<carlos> seb128: oh, so you mean that ...
<pitti> seb128: hm, it should be libxine1.mo
<carlos> that's not user friendly at all... :-P
<seb128> carlos: no, feel free to open a bug
<pitti> seb128: somehow libxine1.mo ended up in the gnome tarball
<seb128> hum?
<seb128> my diff mentions "< /usr/share/locale-langpack/fr/LC_MESSAGES/xine-lib.mo" on the gnome package
<pitti> seb128: so, xine-lib.mo was an orphan
<seb128> $ dpkg -L language-pack-gnome-fr-base | grep xine
<seb128> /usr/share/locale-langpack/fr/LC_MESSAGES/libxine1.mo
<seb128> /usr/share/locale-langpack/fr/LC_MESSAGES/xine-lib.mo
<seb128> k
<pitti> seb128: ah, xine-lib b-deps on libgnomevfs-dev, so langpack-o-matic classified it as gnome
<pitti> seb128: xfce-utils wasn't imported at all
<pitti> seb128: ah, package was removed from dapper, it's obsolete
<pitti> seb128: ok, so AFAICS I only need to fix the debconf package import in my scripts
<pitti> seb128: and move libxine1 to the main langpacks
<pitti> right?
<seb128> k
<seb128> yeah, looks good
<pitti> thanks for testing!
<seb128> np :)
<seb128> pitti: if you move the xine stuff you need a Replaces, but you probably knows about that (just making sure you don't forget)
* carlos ->out
<carlos> see you
<pitti> seb128: why, it's the first time libxine1.mo appeared, right?
<pitti> seb128: and I moved them into the main packs already
<seb128> $ dpkg -c /var/cache/apt/archives/language-pack-gnome-fr-base_1%3a6.04+20060316_all.deb | grep xine
<seb128> -rw-r--r-- root/root      3081 2006-03-16 23:11:32 ./usr/share/locale-langpack/fr/LC_MESSAGES/libxine1.mo
<seb128> Filename: pool/main/l/language-pack-gnome-fr-base/language-pack-gnome-fr-base_6.04+20060316_all.deb
<seb128> pitti: that one is the dapper one
<pitti> seb128: whoopsie, they have been in -gnome all the time?
<seb128> seems so
<pitti> then I indeed need a replace, right
<pitti> seb128: bah, then gnome and main would replace each other; that might break
<pitti> hm, moving from gnome to main isn't really supported so far
<seb128> I'm fine with keeping it to gnome :p
<pitti> shit, I *really* really need to leave now
<pitti> I'm afraid I can't fix that in a minute
<seb128> yeah, np, that's not new
<seb128> either upload the current stuff if you want
<seb128> or do the update monday, that's fine too
<seb128> there is no hurry to move the file, and updates can wait too
<mdke_> Riddell, can you ping me when the kubuntu-docs upload is done?
<Riddell> mdke_: why?
<pitti> seb128: alright, I /msged Kinnison to upload them
<seb128> pitti: cool, ta
<mdke_> Riddell, i want to ask jordi to approve some pot files and announce translation
* bddebian wonders if pot files are like pot brownies :-)
* jordi kicks bddebian.
<bddebian> Doh
<jordi> BDDEBIAN!!1
<Riddell> mdke_: does it need the package to be uploaded?
<mdke_> Riddell, yes
<jordi> yah
* bddebian does the summon infinity dance
<Riddell> mdke_: why's that?  surely you just upload the .pots and people can start translating in rosetta
<Riddell> although it's obviously good practice to keep rosetta and packages in sync
<mdke_> Riddell, it goes through soyuz
<dholbach> desrt: ok, gotcha... good luck with the exams!
<mdke_> rosetta gets it magically
<Riddell> mdke_: so you're expecting me to include the .pots in the kubuntu-docs source package?
<mdke_> Riddell, that's correct.
<Riddell> mdke_: ok, groovy, I just read your post to ubuntu-docs wrongly then
<Riddell> mdke_: they're in SVN?
<mdke_> Riddell, yes, just upload them in the directories they are in in SVN
<Riddell> mdke_: thanks, I'll try and get that done today then
<mdke_> Riddell, magnifico, grazie
<jordi> Riddell, mdke_: just ping when it is
* Kinnison apologises for the langpack spam on -changes
<Kinnison> it's just those which were NEW
<lemsx1> Riddell: sounds good. i'll look into the source and make a patch for it
<bluefoxicy> anyone know the status on bug #29586
<Ubugtu> Malone bug 29586 in linux-source-2.6.15 "Solid hangs in VIA glx code" [Normal,Confirmed]  http://launchpad.net/bugs/29586
<infinity> mdz: Nvidia released a new binary driver upstream with support for the shiny new 7xxx series cards, and improved power management support.  UVF exception, s'il vous plait?
<mdz> infinity: naturellement
<infinity> Merci.
<bddebian> infinity!!  Sure, show up when I have to go to a fscking meeting :-)
<jsgotangco> infinity: wow 4am?
<infinity> 4:30, even.
<jsgotangco> oh yeah
<infinity> Alcohol == extra special insomnia.  Though, I'm finally crashing.
<jsgotangco> me too
<bddebian> Gah
<infinity> bddebian: Hey, it's a weekend, dude.  If you don't catch me in the next couple of days, there's always Monday, where I kinda have to be here. :)
<bddebian> It's not the weekend it's only 2:30pm of a Friday afternoon ;-P
<bddebian> s/of/on/
<infinity> Or, 4:30am on Saturday. :P
<bddebian> :-)
<bddebian> Ack, off to meeting :-(
<Riddell> mdke_: Accepted kubuntu-docs 6.06-2 (source)
<floam> is there a .gtkrc or environmental variable added by your guys' "make gtk filechooser default to Documents" patch?
<floam> (so that it can be turned off or default somewher else)
<floam> s/wher/where/
<Chipzz> floam: please read gtk+ changelog.Debian.gz
<Chipzz> floam: zless /usr/share/doc/libgtk2.0-0/changelog.Debian.gz
<mdke> Riddell, great, thanks
<sabdfl> night all
<pygi> mdz: around?
<mdz> yes
<pygi> should I forward that mail to colin, or what? =P
<mdz> I'm going to need a little more context
<pygi> you sent a mail to me with subject "[Bug 35740]  Re: Hang during RAID creation" and you mention colin in it :P
<Ubugtu> Malone bug 35740 in debian-installer "Hang during RAID creation" [Normal,Unconfirmed]  http://launchpad.net/bugs/35740
<mdz> Colin is subscribed to the bug
<mdz> he has already received a copy of that comment
<mdz> you  do not need to take any action
<pygi> mdz: will do
#ubuntu-devel 2006-04-13
<neuralis> mdz: you received that automatically because you're a member of the ubuntu-server team; matt didn't address the mail to you.
<neuralis> er. s/mdz/pygi/
<pygi> neuralis: yup, right :-/
<pygi> neuralis: I just saw u-s is assigned
<KaiL> idea for X-Problems: if gdm fails, maybe add a question to change to vesa driver and re-try with that?
<mdz> KaiL: bug #27020
<Ubugtu> Malone bug 27020 in xorg xserver-xorg "Please make X fallback to vesa if the card driver doesn't work." [Wishlist,Fix released]  http://launchpad.net/bugs/27020
<KaiL> ah, cool
<KaiL> ubuntu seams to become _to_ easy, if I see the recent idiot in #ubuntu-de *g*
<Treenaks> KaiL: Yeah, I note that too in #ubuntu-nl
<Treenaks> KaiL: People _expect_ things to be hard, and think to hard about their problem
<Treenaks> KaiL: while the solution is right in their face
<Treenaks> ('How do I burn a CD?' is a common one there)
<KaiL> Treenaks, this one is great - he doesn't even know, what a GUI or a console is
<ajmitch> KaiL: calling people like that 'idiots' isn't much help though :)
<Treenaks> ajmitch: What would you call them? Thinkers? :)
<KaiL> ajmitch, I needed 15min to find out, if he has a running X or not ;)
<Treenaks> ajmitch: 'They're called thinkers because they think too hard' :)
<ajmitch> Treenaks: ignorance is different from idiocy - one is fixable :)
<neuralis> Treenaks: i'd call them the ideal ubuntu beginners.
<Treenaks> neuralis: sure, they all reply with 'Oh is it THAT simple' when you tell them how to burn CDs ;)
<pygi> Treenaks: hehe :)
<KaiL> Treenaks, did you ever need to use nero on windows?
<KaiL> after that you know, why this question comes that often ;)
<dholbach> good night
<KaiL> 2 other problems I saw today:
<KaiL> 1. do we have drivers for intels A/B/G WLAN chip?
<KaiL> 2. I saw the detection for the 'synaptics' touchpad driver failing very often
<mdz> KaiL: 1. modinfo ipw2200
<KaiL> mdz, nop
<Treenaks> mdz: ip2200 doesn't cover all chips, there's the 39xx family now
<KaiL> I mean the new one
<Treenaks> mdz: ask mjg59
<mdz> KaiL: 2. I don't think we attempt to detect synaptics
<mdz> KaiL: ipw2200 supports the 2915 which is A/B/G
<KaiL> sometimes we detect synaptics ;)
<KaiL> ipw 3945 ABG
<Treenaks> KaiL: afaik people are working on that driver
<KaiL> would be very important for dapper, imho, as it's used on all (?) Core Duo laptops
<mdz> KaiL: we configure X for synaptics on all laptops
<KaiL> mdz, fails on FSC Amilo M1437, afaik
<mdz> KaiL: I doubt that it fails to be configured
<mdz> if [ -n "$LAPTOP" ] ; then
<mdz> that's the test
<KaiL> strange
<mdz> unless laptop-detect is wrong on your laptop
<KaiL> ok, the WLAN driver is to be found at ipw3945.sf.net
<KaiL> "only" needs to be integrated into dapper...
<zul> heylo
<opi> Hi guys
<opi> have you noticed that dapper/universe package list is broken?
<crimsun> more context?
<zul> broken as in how?
<KaiL> maybe mirror sync problems?
<KaiL> or just file not fully loaded?
<opi> oh, I'm stupid
<opi> I forgot that I'm currently using .pl mirror
* opi bangs head against desk 
<opi> yeah, it's sync problem. Sorry for the mess. :-)
<KaiL> for dapper I recommend to use the master, as it's more "up-to-date"
<opi> that's what I just did
<opi> it's fresh installation, it was picked by installer to use .pl mirror :)
<KaiL> mdz, oh, and finnally some very strange and big bug: and deadlocks on intel 915GM known?
<KaiL> FSC Amilo M1450 hangs on loading X
<jmg> guys is there a daily netinst image?
<jadaz87> hello everyone i had wanted to come out with my own ubuntu distrobution like they have ubuntu, kubuntu, xubuntu i was wondering where can i start?
<hyperactivecrond> jadaz87: and why would you want to do this? (not cynical, just curious) and what would you put in it?
<jadaz87> i want to create a ubuntu release that is geared only towards laptop users
<hyperactivecrond> jadaz87: um. how?
<LaserJock> hmm, how would that be different from the current Ubuntu?
<jadaz87> adding more packages that are for mobile users as default without going to the repositories
<LaserJock> why not put then in the repositories?
<jadaz87> and taking away things that are not needed for mobile users
<jadaz87> because you have to be connected to the internet to get it
<LaserJock> so you want to customize the install cd, correct?
<jadaz87> i am on a HP ze5000 desktop replacement series laptop and i had to go on lan in order to get the stuff i needed to get on wireless
<jadaz87> yes a customized install cd i presume
<hyperactivecrond> so customize the ce jadaz87 
<hyperactivecrond> cd*
<jadaz87> that is the part i do not know how to do
<LaserJock> jadaz87: you might want to check out https://wiki.ubuntu.com/InstallCDCustomizationHowTo
<jadaz87> oh ok thanks also i know i will have to get copyright permission before i can use the ubuntu name how do i go about that?
<jadaz87> and does canonical aid in any way?
<hyperactivecrond> jadaz87: don't reinvent the wheel. you won't be able (i think do NOT quote me) to get listed on the official, supported by ubuntu community, caonical aided, on-the-main-page-of-the-website because it's too vague imo
<hyperactivecrond> s/aided/sponcered
<hyperactivecrond> sponsered
<jadaz87> oh ok
<jadaz87> then who sponsers these other projects like xubuntu, ubuntulite?
<LaserJock> umm, nobody exactly
<LaserJock> I think xubuntu has some hosting from the ubuntu China LoCo team perhaps
<jadaz87> i am suprised kubuntu is on the official site then all that is, is ubuntu with kde
<jadaz87> the copyright is still going to be any issue though
<LaserJock> why?
<jdub> jadaz87: trademark more than copyright. see the webpage for more details about trademark licensing.
<jdub> jadaz87: kubuntu is a sister project.
<hyperactivecrond> jadaz87: can i /query you?
<jadaz87> LaserJock i cannot use the ubuntu trademark with out permission
<jadaz87> what does /query do?
<hyperactivecrond> same as /msg but keeps window open
<jadaz87> oh sure
<LaserJock> jadaz87: why would you use the ubuntu trademark?
<jadaz87> LaserJock the same reason why xubuntu gets to use it
<LaserJock> it does?
<LaserJock> sorry, I'm very ignorant when it comes to these issues
<bddebian> Is /usr/bin/X11 supposed to be symlinked to ../bin?
<jdong> bddebian: yes...
<Lathiat> bddebian: yes, as everythig nin /usr/bin/X11 was moved to /usr/bin, symlink is there for backwards compat
<bddebian> Lathiat: That was my guess, I was just curious because of Malone bug 4599
<Ubugtu> Malone bug 4599 in wdm "wdm expects "X" at wrong location: /usr/bin/X11/X" [Normal,Needs info]  http://launchpad.net/bugs/4599
<Burgundavia> infinity: is there a known issue with the madwifi module barfing in fligh 6?
<bddebian> infinity: Get your drunk ass off the floor and tell me how to fix ivtools.. :-)
* bddebian hides
<Burgundavia> bddebian: bad boy :)
<bddebian> :-)
<joelbryan> hello, If all people in the planet that use Ubuntu will auto-join #ubuntu, do you think that would going to be a total chaos.
<bddebian> probably couldn't be much worse that #debian :-)
<joelbryan> so if not, then US will join #ubuntu-US
<andrewski> at this point, you wouldn't even notice a difference in #ubuntu.  it's already too fast for comprehension.
<joelbryan> to solve that problem, the users will not auto-join #ubuntu, but will join #ubuntu-USA if they live in USA.
<bluefoxicy> I have a dumb question
<bluefoxicy> https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/Xen
<bluefoxicy> Why is SimosXenetelis dependent on this?
<LaserJock> bluefoxicy: because the dependents are calculated from a Full Text Search of Xen
<bluefoxicy> LaserJock:  ah.
<bluefoxicy> okay help
<bluefoxicy> I don't know the best way to do roaming profiles-- NFS, samba, or sshfs
<andrewski> is it appropriate to piggyback on someone else's laptop testing report in the wiki, e.g. to give results of something they didn't test or to clarify/mention more details?  or should i perform a brand new test?
<jmg> hey all
<jmg> ubuntu-artwork is horked?
<andrewski> horked?
<jmg> broken
<jmg> http://paste.ubuntu-nl.org/11733 anyone?
<jmg> it's in the postinst
<andrewski> my ubuntu-artwork is 13 now.
<jmg> hmm... nz mirror out of date.
<jmg> gack
<andrewski> maybe try the us one (that's what i'm on)
<jmg> yeah im updating now
<jmg> thx
<andrewski> cool
<mwright1> hi
<andrewski> i'm actually having trouble with gnome-app-install, it's looking for python-dbus, which isn't available, so it can't be updated.  is that bugworthy?
<andrewski> jmg: maybe you'll see that one crop up as soon as you update. ;)
<jmg> andrewski: le sigh :)
<andrewski> it's not a big deal for me; i don't use g-a-i.  but i think i'll throw it at launchpad, for posterity.
<jmg> i got a new one
<jmg> Setting up kubuntu-docs (6.06-2) ...
<jmg>  /usr/share/doc-base/kubuntu-adept: cannot open control file for reading: No such file or directory
<andrewski> hmm... what if you try installing adept first?  does that help?
<jmg> it's installed
<andrewski> erm... dunno. ^_^
<mwright1> can someone give an opinion as to why I need to test this bug with 5.10 when I have filed it for Dapper drake
<mwright1> https://launchpad.net/distros/ubuntu/+source/gnome-vfs2/+bug/36647
<Ubugtu> Malone bug 36647 in Baltix "setgid not respected when copying into a directory" [Normal,Unconfirmed]  
<andrewski> mwright1: looks like they're wondering if this is a bug that used to work.  also, they're wondering if you could supply some steps to reproduce it, so that sebastian and others could reproduce it.
<andrewski> so if you've never tried on 5.10, i guess you could just say "dunno". :)
<jmg> where is the config.gz for the ubuntu kernel?
<jmg> why would you turn such a useful option off?
<jmg> anyone got a link to the .config used for linux-image?
<hile> jmg, /boot/config-* ...
<hile> you really just don't need the /proc version since it's always packaged to the image
<mwright1> andrewski: it's easy to reproduce
<mwright1> I can do that,  but I do not have a ubuntu 5.1 box
<mwright1> or install / live cds
<andrewski> mwright1: good.  then it'd be easy to document on the bug. :)  i don't think it's essential that you test it on breezy; it was just something that would be helpful to know.
<andrewski> the important thing is helping someone else reproduce it.  maybe with some test dirs/files that you could create?
<nadjyla> hello
<LaserJock> hi nadjyla 
<mwright1> andrewski: https://launchpad.net/distros/ubuntu/+source/gnome-vfs2/+bug/36647/+index is now upto date, there is step by step instructions to reproduce it and breezy + updates has been tested and it has the bug also
<Ubugtu> Malone bug 36647 in gnome-vfs "setgid not respected when copying into a directory" [Unknown,Unknown]  
<mwright1> I think the problem is cause gnome is doing a move by default
<mwright1> even though the user requests a copy and that is the process which shoudl be taking place
<lifeless> ogra: not fixed for me
<whiprush> jdub: around?
<mwright1> this is a usability question with gnome filemanager... nautilus
<mwright1> who makes those calls.
<bmon> mwright1: I don't think the main devels are around
<bmon> I'm not a devel at all
<bmon> but whats the issue?
<mwright1> well i mistakenly put a bug in that setgid for group permissions wasn't being respected for copy action in nautilus
<mwright1> however it is being respected for copy action
<mwright1> the problem is with the move action ... being the default action
<mwright1> regular users want to move a file to a destination directory and don't want to change permissions themselves to make it available to their colleagues who are members of the same group
<mwright1> mv is the same as cp -a permissions wise in unix
<mwright1> I feel this is not the right way to do things in the end user world
<tepsipakki> mactel-boot from daily-dvd with bootcamp doesn't work :) usplash image is not visible, so there is something wrong with vesa?
<mjg59> The firmware's vesa doesn't seem to quite match the kernel's idea of vesa
<mjg59> This new firmware makes life quite difficult
<tepsipakki> I bet
<jpatrick> can someone look at malone 38705 ?
<Ubugtu> Malone bug 38705 in kmplayer "UVF kmplayer 0.9.2-pre3 -> 0.9.2-rc1" [Normal,Unconfirmed]  http://launchpad.net/bugs/38705
<mjg59> tepsipakki: But right now, you won't be able to install on a Mac (even using the new firmware)
<tepsipakki> I'm not even trying, but a friend of mine who told that it wont work :)
<tepsipakki> so no worries
<siretart> did someone recently filed a bug in malone via email? are they any bad caveats I need to consider?
<pef> can someone with main upload privileges have a look at #37422 ? just added desktop file, debdiff is provided, thanks !
<mdke> can anyone tell me what package I need to file a bug on if I want to complain about the names that other mounted partitions are given on the desktop?
<ivoks> mdke: pmount, but let me check that...
<ivoks> no, it's not pmount
<mdke> ivoks, could it be gnome-volume-manager or something?
<ivoks> no, it's not gvm
<ivoks> it's hal or dbus :)
<ivoks> more likely hal
<mdke> ivoks, ok, I'll file there, it can get reassigned if wrong
<ivoks> yes, it's hal
<mdke> thanks!
<ivoks> what bug # is that?
<ivoks> it's acctually not a bug, it's a feature
<ivoks> names are given according to label name
<mdke> i didn't file it yet
<mdke> but my breezy partition appears as "/" which is kinda silly, given that I already have a "/"
<ivoks> hm
<mdke> i'd prefer it to appear as /media/whatever
<ivoks> what's it's label name?
<mdke> I don't know.
<ivoks> mdke: you can do that, but that's not a bug
<mdke> imo it's a bug for it to appear under a name which suggests its my root directory, when it isn't
<ivoks> mdke: dirty way is to change /usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi
<mdke> i think i'll file it and take the risk of rejection :)
<ivoks> mdke: but there is a nicer way, but i'm not sure wich is it... :(
<mdke> gtg, thanks for your help
<ivoks> :) ok
<zul> heylo
<infinity> mdz: Around?  Any objections to a UVF exception for re2c (from 0.9.10 to 0.9.12) to satisfy PHP's insistence that anything (<< 0.9.11) is broken?
<sladen> tepsipakki: on the ATI mactels (the iMac) the video BIOS is buggy
<sladen> tepsipakki: ^^legacy VGA BIOS
<andrewski> is a regression in the support on dapper for a printer/scanner bugworthy?
<Yagisan> andrewski: I'd assume so, dapper is supposed to be better
<andrewski> Yagisan: one would think. :)  yeah, i'll go ahead and file it and if any devs want to yell at me, i'll let 'em. ;)
<andrewski> but first, i guess i should try it on flight 6.
<nictuku> Seveas, hi. are you there, and not busy?
<Seveas> yes and no
<Seveas> if this is about the cloak: it's on it's way
<mdke> yves, ^
<yves> ah ok, thank you again
* LaserJock goes into stealth mode, gotta love the cloak
<LaserJock> actually, I haven't really figured out exactly why it is useful, other than people can tell ubuntu members from the hostmask
<bluefoxicy> LaserJock:  it's useful so we can bug you when X breaks :P
* bluefoxicy remembers when X broke in breezy devel for like a month....
<LaserJock> and if you bugged me, it would be pretty pointless ;-)
<Treenaks> LaserJock: this is why I don't have a cloak. I hate them.
<Treenaks> LaserJock: I can be found _anyway_, just google my nick
<LaserJock> Treenaks: heh, I just found when I was starting out that it was easier to tell if a person had some Ubuntu experience because of the cloak
<Treenaks> LaserJock: hm.. that's a point, but you could also look on launchpad for that
<LaserJock> perhaps, although LP has some weirdnesses that way.
<LaserJock> I mean, that Shuttleworth guy has got 180000+ karma, but what has he done for Ubuntu ;-p
<Treenaks> lp needs a qdb module ;)
<lifeless> ogra: around ?
#ubuntu-devel 2006-04-14
<mdz> infinity: depends on what the changes are
<floam> anyone packaged a new restricted-modules .deb with the new NVIDIA module? I doubt it's going to be in dapper, but I'm guessing someone wanted to try it
<jdong> floam: mjg59 stated at the forums that Dapper does intend to have this new NVidia module
<jdong> (I don't know how accurate that is)
<jdong> currently, I've failed to manually install the module from NVidia installers on two Dapper boxes
<jdong> so I'm waiting and saving my time :)
<crimsun> well if matthew says so, I'd say it's pretty darned certain it will be.
<floam> jdong: wow, that surprises me
<floam> being so late in the game and all
<jdong> floam, it surprised me as well
<floam> although that would probably be a good thing for dapper in the long run, since it's supposed to be supported for a long time and the new version adds support for some newer hardware
<jdong> floam: http://ubuntuforums.org/showpost.php?p=899834&postcount=7
<floam> and I thought nothing useful was ever stated on the fourms.
<jdong> floam: umm, what would make you think that?
<floam> jdong: just my last few years experience with the internet. webforums for Linux distributions tend to be places where cluebies spread false information and diseases
<floam> they are usually devoid of anyone important
<jdong> I see....
<jdong> there are developers who regularly are on the forums
<jdong> while it's true that any online community you're going to get some level of false information....
<floam> the signal-to-noise ratio is usally much worse for web forums than for the proper mailing lists
<jdong> I wouldn't say so... our forums just have monstrous proportions of traffic compared to the lists
<jdong> but we do acknowledge that problem... it's getting better though
<floam> I'm not speaking specifically about the ubuntu forums
<desrt> is it possible to remove a remote bug watch on launchpad?
* desrt accidentally registered 2 (one of them pointing to a non-existant bug on the abiword tracker)
<bluefoxicy> crimsun:  Lovely, upon gdm starting the kernel hard-freezes and magicsysrq won't shut the machine off :p
<bluefoxicy> irqpoll nah.
<nictuku> nwu project calling for initial version testing: https://lists.ubuntu.com/archives/ubuntu-server/2006-April/000129.html 
<Le_Vert> Hi
<Le_Vert> How could I submit a new packages for Ubuntu ?
<Le_Vert> I have some packages that'll be sent to debian and I would send them to ubuntu too
<crimsun> Le_Vert: see #ubuntu-motu; https://wiki.ubuntu.com/MOTU/Packages/New
<LaserJock> Le_Vert: check out wiki.ubuntu.com/REVU and #ubuntu-motu
<Le_Vert> thanks :)
<Seveas> Le_Vert, there's no real need to send them to Ubuntu separately, Ubuntu will get them through debian
<Le_Vert> ok :)
* desrt rage
<desrt> someone did something really really awful to my tab key.
<aimaz> did they make tab complete have spelling mistakes?
<desrt> they made it totally fail to work properly
<desrt> erasing /etc/bash_complete seems to fix the problem
<desrt> bash_completion even
<infinity> mdz: http://cerberus.0c3.net/~adconrad/re2c.changelog
<wasabi__> Writing a utility with pygtk... need to run part of it as root. Seperated it into a seperate program, want to run it with gksu. Some reason gksu won't exit properly when run with popen.
<wasabi__> Or is there a better way... making an Ubuntu utility. ;)
<jmg> is there a way to make make-kpkg not rebuild the tree before building the .debs?
* #ubuntu-devel  [freenode-info]  channel flooding and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
<zakame> hello fabbione :)
<fabbione> hi zakame 
<neuralis> fabbione: what do you think about a lynx/links udeb for the server install cd?
<fabbione> neuralis: for what use case?
<neuralis> fabbione: there's a guy providing one (not very convincing) use case on the ML, but it does actually seem at least as useful as the openssh-client udeb
<neuralis> i haven't made up my mind about whether i'd support it yet. what do you think?
<fabbione> i am thinking...
<fabbione> it's like Sunday 9 am :)
<neuralis> 2:43AM here :)
<fabbione> yeah i know
<fabbione> well there is wget already
<fabbione> i can see the point of the login script
<fabbione> the testing part is junk
<neuralis> agreed. though it might be convenient to take a look at some instructions online that one didn't print, etc
<fabbione> the only counter side for him not being able to login to his ISP is that apt-get source.lists lines for security are not enabled by default
<fabbione> no no, let's keep the use case simple
<fabbione> if he is installing a server he has at lease one client
<fabbione> that he can use to browse
<fabbione> otherwise it really makes no sense to install a server
<neuralis> that's not (always) true. think server rooms.
<neuralis> then again, if he's installing a server in a server room, he shouldn't be browsing online for instructions, usually :)
<fabbione> exactly
<neuralis> okay, i think i'm convinced we don't need it.
<fabbione> i think so too
<fabbione> it's too much of a corner case
<neuralis> agreed; i'm writing a reply to the guy.
<fabbione> and once he reboots, he can login and enable security updates
<neuralis> another quick thing -- i wrote in the server chapter that we have ocfs2-tools in dapper. is that no longer the case?
<neuralis> or do we just have the breezy version?
<fabbione> yes we do have ocfs2-tools and ocfs2console in main
<fabbione> we have new versions in dapper
<neuralis> ah. i thought i saw you say something else in one of the dev meetings, but i probably misremembered. thanks.
<fabbione> we were waiting for a new major uptream version
<fabbione> that didt really happen
<fabbione> so we will stay with what we already have in Dapper
<fabbione> nothing too fancy
<fabbione> we do have 1.1.5 or so
<fabbione> there 1.2 out
<fabbione> but also tons of bug fixes for 1.2 in svn
<fabbione> and i was waiting for 1.2.1 that's not happening yet
<neuralis> sounds like it's best sticking with 1.1.5.\
<fabbione> yeah
<fabbione> it's ok for what we need
<neuralis> fabbione: so i just reread the guy's away message, and i don't think he was actually asking about an udeb, but about shipping the package on the cd
<neuralis> because if we don't, he can't reboot and log in, because logging in requires a browser which he can't install.
<fabbione> hmmm right
<fabbione> yes that can be done
<neuralis> should be pretty trivial. can you poke colin to include it, or do you want me to mail him?
<fabbione> i can do it directly...
<fabbione> just send me a reminder
<neuralis> sure.
<fabbione> i own the server seeds
<neuralis> ah, even better
<fabbione> that hounestly.. i should really clean up a lot soon
<neuralis> i'll send you a reminder sometime tomorrow, then.
<fabbione> sure..
<jmg> hmm..
<jmg> bizarro
<fabbione> neuralis: still around?
<neuralis> fabbione: what's up?
<sivang> elmo: thank you :)
<sivang> morning all
<MagnusR> Hi! If I find a translation error in synaptic, how do I do to correct it?
<Lathiat> At a guess, it would be available by rosetta on http://launchpad.net ?
<MagnusR> I have looked around there a bit. but i did not quit understand how o do.
<Kinnison> Morning
<ajmitch> morning Kinnison 
<Kinnison> hihi
<sivang> hey Kinnison 
<sivang> howdy bddebian 
<bddebian> Heya sivang
<engla> I'm not a dev, I just reported some bugs in ubuntu. Is it the right thing to do to go back and close those bugs if I think they are fixed/resolved/invalid?
<sivang> engla: you can try and ask other people who have reported the same and are subscribed to the bug if it works for them.
<sivang> engla: if so, then I reckon it would be okay.
<mdke> engla, yeah, close em if you don't see them anymore and you were the original reporter
<sivang> that as well :)
<_ion> Astronomers have discovered that Uranus has a blue ring.
<darklinux> hi
<darklinux> i want to build a new kernel 2.6.17 of the dpkg base of dapper kernel 2.6.15 i have change the control and changelog file to 2.6.17 and the dir name when in want to build the package they remove the debian folder not more
<_ion> ARGH, my eyes
<darklinux> can help anybody
<infinity> darklinux: apt-get install kernel-package && man make-kpkg
<infinity> darklinux: And please ask these questions in #ubuntu, not #ubuntu-devel, this is not a support channel.
<bddebian> infinity!!
* infinity hides.
<bddebian> Is it Monday for you yet? :-)
<_ion> su160317 Ignoring ALL from darklinux
<infinity> Nope!
<infinity> 23:03 on Sunday night.
<bddebian> Damn :-)
<jsgotangco> heh
<jsgotangco> not yet work time
* bddebian crawls back into his corner to pounce on infinity later
<jsgotangco> im gonna go play oblivion
<bddebian> Heh, I can't play Morrowind today, we have "company" :-(
<sivang> bddebian: comapny?
<bddebian> sivang: US word for guests :-)
<sivang> bddebian: :) But why does it stop you from playing?
<infinity> bddebian: So, instead, you sit on IRC and ignore them? :)
<infinity> congeniality++
<bddebian> sivang: They don't, the wife does :-)
<bddebian> infinity: Well at least I'm in the same room and not screaming "DIE, DIE, DIE" :-)
<sivang> bddebian: ehehe
<sivang> infinity: go the thinkpad , I chicken out and got the one with FireGL V3200 ;-)
<sivang> *got
<sivang> infinity: minus one flight 6 bug that didn't configure gdm to start, the ati FOSS driver seems to be working well so far.
<jdub> mdz: given the slip, what do you think about getting the shut-up-grub patch in?
<bddebian> shut-up-grub.. Heh
<infinity> jdub: How shut up is it?
<infinity> jdub: Do you even remove "hit Esc for a menu"?
<jdub> infinity: no, just the post-menu spew from memory
<jdub> infinity: and i think it only hid that if you had 'quiet' on the boot line
<infinity> The stageX, stageY stuff?
<jdub> infinity: the patch is in launchpad somewhere
<jdub> yeah
<fabbione> jdub: it's not wise to shut things up too much
<fabbione> specially in very sensible parts of the boot like grub where debugging is already quite difficult
<infinity> Shutting them up is fine if they can be "un-shut".
<fabbione> at least we get to know "it hangs between stage1 and stage2" or stuff like that
<infinity> (ie: Hold down key X during boot, so you get proper debug spew)
<infinity> Or whatever.
<fabbione> infinity: right.. but the 512bytes loader doesn't really have that much cleverness
<infinity> That's a single branch.  I'm sure there are a few bytes to spare.
<infinity> And it already knows how to listen for keys, IIRC.
<fabbione> it's slightly more than that but yes...
<fabbione> it understands concept of harddisks and how to read ext2 :)
<jdub> the 'quiet' on the command line could be a nice way of doing it
<jdub> if grub should be allowed to interpret those for itself
<fabbione> erk
<fabbione> that smells so much as a cmdline args clash
<jdub> yeah
<jdub> fabbione: have you tried building one of our 2.6.15 kernels with xen love, or know anyone on the server team doing it?
<fabbione> jdub: nobody afaik
<fabbione> and it's kind of late to do it
<infinity> Haven't even tried.
<jdub> fabbione: oh yeah, i mean independently of dapper
<fabbione> jdub: no idea.. i don't use xen and i am not going to, till it's upstream
<fabbione> since a bunch of kernel devel don't like at all how it's written
<infinity> It can probably be done with enough wrangling and provided as a community supported thing, but I doubt any of us have enough hours in the day to try right now.
<fabbione> from a first review they found serious design flaws
<jdub> it's funny how much gar i hear about xen internals :)
<fabbione> jdub: well yes..
<fabbione> for x86 they have 3 times as much asm required that it's arch/x86 to suppor the entire architecture..
<jdub> heh
<fabbione> + they use a 2 level interpreter that slows stuff down a lot..
<fabbione> when i was told they could just use a more generic 1 level intererpreter..
<fabbione> twice as fast.. more portable
<bddebian> WTF does this mean?:
<bddebian> Rejected:
<bddebian> Not permitted to upload to a release in CURRENT state
<siretart> bddebian: you tried to upload to breezy, which doesn't work since some time
<bddebian> Ack, breezy? WTF.  I didn't even see that
<bddebian> Thanks siretart
<siretart> bddebian: but you're right somewhre, the error message could be more verbose
<infinity> Verbosity isn't the issue, it's that no one except launchpad hackers knows what CURRENT means, since the rest of us would think of it as RELEASED, perhaps.
<bddebian> Well I should check user submitted changelogs more closely too :-(
<infinity> You should check the entire patch closely, really.  If you're not doing so, the black helicopters will visit.
<bddebian> Well I did check the patch and test it, I just always seem to overlook the distro thing.  I've done a couple unstable ones too :-(
<siretart> jdong: hey, john
<jdong> what's up, siretart 
<wasabi> So anybody want to play with gapti?  http://akita.larvalstage.net/~wasabi/bzr/gapti--main    It pretty much works!
<siretart> whats gapti?
<wasabi> http://wiki.ubuntu.com/ThirdPartyApt
<jdong> interesting...
<aimaz> wasabi, ISV = independent software vendor?
<wasabi> aimaz: yeah.
<aimaz> so with gapti a user will click a link and it'll modify their sources.list?
<aimaz> wasabi, would added repositories be removed when they're not required because the dependent software is removed?
<wasabi> aimaz: no. If that should be added... which I think it should, it would be seperate from this.
<aimaz> ok
<wasabi> Like, an automatic sources.list cleanup would be nice.
<aimaz> how does apt decide which repository to install a package from?
<wasabi> The one with the latest version or highest pin
<aimaz> maybe if there was a way to restrict a repository to only what you want
<aimaz> that would remove some of the security implications mentioned on the wiki page and prevent unstable version of other software provided on a 3rd party repo being installed
<aimaz> again i suppose that would fall outside gapti
<wasabi> It wouldn't help anything.
<wasabi> At all.
<wasabi> Because any software you install has to be installed as root.
<wasabi> At that point, any security concerns are useless.
<wasabi> Who cares if it can only install packageX, if packageX can do whatever it wants?
<aimaz> ok
<aimaz> but it would help if say i wanted package x from a 3rd party repo but not other packages they might provide
<wasabi> Well, that's basic pinning.
<aimaz> ok
<wasabi> gapti should probably pin all but the asked packages down.
<wasabi> Just to prevent them from being installed on accedent.
<wasabi> But it's not a security mechanism.
<aimaz> yeah i understand that
<wasabi> I think I'm going to change the way the public key is distributed though... cleartext sign the .apt file, including the public key.
<wasabi> that way the key added to apt-key must be the same as the one the .apt file is signed with
<elmo> mdke: I reset and resent jjesse's password a couple of weeks ago (or less) - has he really lost his gpg key again already?
<mdke> elmo, last time he lost he password, but didn't realise he'd also lost the gpg key, so couldn't open your mail. I'm really sorry, as is he
<elmo> mdke: k
<mdke> elmo, thanks a lot
<Zauberer> hallo zusammen
<Zauberer> ich habe in der 6.06 2 kleine fehler gefunden, wo mu ich die posten?
<j^> Zauberer https://launchpad.net/distros/ubuntu/+bugs/
<bluefoxicy> does anyone have a qemu video.x for ppc?
<bluefoxicy> qemu swears I have no video bios if I run qemu-system-ppc
<bluefoxicy> I have openhackware installed
<bluefoxicy> oops
<bluefoxicy> wrong channel
<elmo> are we shipping bcm43xx firmware yet or is it still in legal limbo?
<mjg59> elmo: The latter
<mjg59> If anyone has any contacts in Broadcom...
<elmo> or if someone wants to just BUY Broadcom... :-P
<mdke> does anyone else find that they default editor is suddenly vim? rather than good old nano...
<mdke> s/they/their
<elmo> mjg59: how do I know which of these myriad firmware .exe's or .sys's I want?
<bddebian> mdke: Yes that happened to me a couple of times now
<mdke> bddebian, very disconcerting :)
<bddebian> aye
<_ion> mdke: To me it sounds like a feature rather than a bug. ;-)
<mdke> heh, it's definitely a bug. I pity the new user who is following instructions in some guide and has to figure out how to use the command line at the same time as VIM
<mjg59> elmo: You want a .sys file, and you want to run fwcutter on it
<elmo> mjg59: yeah, I just picked the latest one, I'm still getting invalid AP tho, oh well
<elmo> (after setting rate to 11M and ap to any, I mean)
<mjg59> elmo: What's in dmesg?
<mjg59> And which kernel are you running?
<Yagisan> G'day all, who do I need to badger about CJK support not working "out-of-the-box" on dapper, even with language-packs installed
<sivang> bah, switched to fglrx now I have an annoying thin line that follows the mouse curose hovering the desktop
<sivang> mjg59: is that known or expected? I have FireGL V3200 128MB 
<mjg59> sivang: I don't touch fglrx
<sivang> mjg59: bummer, it seemed to be working fine on x300 that I returned..
<bddebian> Gad I hate looking at configure files :-(
<sivang> funny, IBM also put a Broadcom wried ethernet (Gigabit) on this particular setup.
<sivang> (but thank god the WiFi is intel)
<sivang> mjg59: is there nothing we can do to try and have some of at least the failing code? under some strict code-sharing agreemnet? don't they want linux to be supported on their cards? :)
<mdke_> Yagisan, I'd say the bug tracker
<mjg59> sivang: Since this would involve me never being able to touch free code again, I'm not keen...
<Yagisan> mdke_: it's already full of "unconfirmed" entries about the same thing (I've been browsing it since I posted here)
<mdke_> Yagisan, ok, so if you have the same bug, you can post and confirm the bug
<sivang> mjg59: they can't impose restrictions like that! Can they ?
<mjg59> sivang: I'd have to prove that I never used any of their intellectual property in other code
<mjg59> That's a difficult thing to prove
<mdke_> mjg59, they'd have to prove you did, I would have thought
<sivang> yes, you're usually unguilty until proven otherwise :)
<mjg59> mdke_: Civil case, so balance of probabilities applies
<mdke> mjg59, yes. But the burden would be on them
<mjg59> And they'd have rather more money to throw at it
<sivang> mjg59: in any event, the FOSS driver only gives us 2D acceleration right?
<mjg59> sivang: No, it supports 3D on pretty much everything
<sivang> mjg59: ah, so there is no apparent reason to use fglrx over the foss one?
* sivang wonders if Xgl could work ontop of the FOSS driver
<mjg59> sivang: It'll be faster, but.
<mdke_> fonts in dapper suddenly look rather rubbish since upgrading today :-(
#ubuntu-devel 2006-04-15
<ds> someone want to thwack some ubuntu maintainers for not sending patches upstream for me?
<Burgundavia> ds: which packages?
<ds> Burgundavia: liboil0.3, mainly
<ds> I just looked at the changelog, and saw a bunch of stuff that nobody ever told me about
<ds> which is totally uncool
<Christopher> helo i want to report something
<Christopher> delire from #ubuntu sent me
<LaserJock> Christopher: a bug?
<Christopher> yes
<Burgundavia> wiki.ubuntu.com/ReportingBugs
<Christopher> thanks
<LaserJock> Christopher: you should file a bug report at https://launchpad.net/distros/ubuntu then
<Christopher> im doing it now
<Christopher> bye
<LaserJock> Christopher: great, thanks for helping out
<Christopher> no problem
<LaserJock> ds: does the link to the patches at http://packages.qa.debian.org/libo/liboil.html help?
<LaserJock> ds: or are you looking for specific bug reports filed?
<jmg> hey guys
<jmg> my locales are horked. crimsun is giving me rubbish about how not to use dpkg-reconfigure locales. if this isnt used anymore, shouldnt the debconf script be changed?
<jmg> if dpkg-reconfigure locales is no longer supported, what is the supported way to regenerate locales?
<crimsun> rubbish? lovely.
<jmg> note i'm using ubuntu-minimal 
<jmg> hi crimsun
<jmg> i think the ubuntu-minimal depends is horked somehow. something must be missing
<LaserJock> jmg: you are talking about that perl error, right?
<jmg> LaserJock: yes
<LaserJock> jmg: I got similar error in a chroot, but not in a real install
<LaserJock> jmg: do you have a langpack installed?
<jmg> LaserJock: probably not. i'm on ubuntu-minimal
<LaserJock> jmg: the locales are in the langpacks I believe
<crimsun> I don't have any language-pack-\* installed, and I don't get the locale warnings from Perl.
<LaserJock> crimsun: no langpacks? hmm, I thought all the locales where moved there
<LaserJock> jmg: for my chroot I just exported LC_ALL=C
<jmg> LaserJock: cheap ;)
<LaserJock> well, it was because of my chroot, not Dapper
<jmg> LaserJock: im on a debootstrap install here
<LaserJock> jmg: ok, so it is probably the same thing
<jmg> hunger: you about?
<unstable> The security cert from bugzilla.ubuntu.com expired on 10/04/05 09:20
<unstable> Anyone want to update the certificate?
<unstable> And in the future...where is the right place to give this information?
<Lathiat> a good question
<Lathiat> i guess no one sbothered sine BZ isnt in use now
<Burgundavia> unstable: bugzilla is obsolete
<dieman> bah, its too bad the support engineer position is so far away from ehre ;)
<dieman> here
<Burgundavia> dieman: montreal is a lovely place to live
<dieman> yah
<dieman> but im not a citizen, which probally wouldn't be an issue
<Burgundavia> dieman: are you a US citizen?
<dieman> and my wife would be against moving
<dieman> yah
<Burgundavia> dieman: you can get a work visa under NAFTA
<Burgundavia> where do you live currently?
<dieman> ahh cool
<dieman> minneapolis
<dieman> the climate doesn't scare me
<Burgundavia> you also get to enjoy evil Canuckistani socialized medicare
<dieman> that would be the second sticking point :)
<bddebian> Heh, you beat me to canuckistan :-)
<dieman> wife has a cronic illness and gets resonable healthcare here.
<dieman> im lucky enough to work for a state-sponsored university
<Burgundavia> bddebian: only Canucks are permitted to call it Canuckistani
<Burgundavia> yes
<dieman> which has resisted the urge to tell us to to all die instead of having healthcare
<Burgundavia> Quebec also probably has the worse healthcare in all of Canada, tbh
<dieman> heh
<dieman> why is that, anyhow?
<Burgundavia> long lines, not great funding
<dieman> never been to quebec really, just ontario and manitoba
<Burgundavia> lots of politics with healthcare in Quebec
<dieman> and manitoba was for the fishing
<infinity> Is it wrong to admit that I sometimes miss living in Alberta?
<infinity> Probably.
<dieman> i know theres a private system of some sort in canada too though
<dieman> but it all seems really wacked out
<Burgundavia> dieman: yes, it is called teh US
<dieman> hah
<bddebian> Ah infinity, you are becoming a master of eluding me :-)
<Burgundavia> what is wacked is having the poorest 1/3 of your population not insured in anyway
<dieman> yeah
<dieman> we are strange
<dieman> minnesota is much better than most
<LaserJock> hmm, I lived not all that far from Canada in Montana but never made it across the border
<Burgundavia> health crap is a probably the biggest reason I have never considered a job int he us
<dieman> oh
<dieman> if you have a job your usually fine
<dieman> and if you can afford it when you lose your job
<HrdwrBoB> Burgundavia: not really
<dieman> COBRA benefits can help
<Burgundavia> the other wacked thing is that the US spends the most per capita on health of all the G8 countries
<dieman> but are $$$
<HrdwrBoB> Burgundavia: the problem is requiring insurance in the first place
<Burgundavia> HrdwrBoB: yes, I agree
<bddebian> COBRA is outrageous to pay
<infinity> bddebian: It's an art.
<dieman> yeah
<dieman> COBRA is $$$
<bddebian> infinity: So I'm told :-)
* bddebian gets no love
<Burgundavia> bddebian: I see lots of .desktop love
* LaserJock give bddebian a hug from the whole MOTUScience team
<bddebian> LaserJock: :-)
<bddebian> Burgundavia: Well I guess it's all my dumb ass can handle :-(
<Burgundavia> bddebian: ah, don't be so self deprecating
<LaserJock> I'm the US dholbach. We have global coverage now ;-)
<dieman> Burgundavia: its 6.7% of citizens in minnesota
<dieman> Burgundavia: in 2004 were uninsured
<bddebian> MN? Egads, that's like the Arctic.. ;-P
<dieman> it got worse from 2001 to 2004 since the right wingers cut healthcare to the poor
<dieman> bddebian: so is canada :)
<bddebian> Good point
<dieman> it was warm this week
<dieman> its 11C outside right now
<dieman> or 52F
<LaserJock> heh, healthcare for the poor. They get better health care than I do. Stupid university :(
<dieman> yeah
<dieman> i love how that works too
<dieman> the inbetween section
<dieman> i was in that area for student loans
<dieman> where i get shit for financial aid, but shit from my parents because they can't afford it
<dieman> (at the time)
<LaserJock> exactly
<dieman> but they've been kicking around everyone being insured here in MN
<dieman> and coming up with ways to help with compliance
<LaserJock> I'd probably go the other way and give less insured but lower costs of healthcare
<dieman> but i *do* know that canada will not let my wife become a citizen
<dieman> due to her healthcare costs
<HrdwrBoB> ouch
<dieman> after reading the rules on it once a few years back
<LaserJock> that would make a difference?
<dieman> its something about you have to be expected not to be more expensive as another canadian's healthcare for your first 5 years
<dieman> so they have you take a physical, etc.
<dieman> and if the doctor says your not healthy then it doesn't work out i guess.
<dieman> im guessing theres variances and stuff
<dieman> but i basically decided against trying to figure out what the procedure would be at that point
<LaserJock> has the date for the next dev conference been set?
<dieman> ive been wondering that too
<dieman> i want to show up and help out with specbuilding
<Burgundavia> LaserJock, dieman, no, due to the change in dates for dapper release
<LaserJock> Burgundavia: is the city set? I've heard somewhere in Germany
<Burgundavia> so have I
<dieman> ooo
<dieman> that would be cool
<dieman> i can fly there from here easily via amsterdam
<dieman> sadly on expenso-klm
<dieman> but work pays
<pitti> Good morning
<pitti> hey fabbione 
<fabbione> morning pitti
<na7e> howdy pardners
<dholbach> good morning
<Treenaks> hi
<spacey> moin
<na7e> morning people
<na7e> it's 1 am here
<Mithrandir> ogra_ibook: re bug 33523, I'm not sure if it has gone away yet.  Though, it appears that gss now has forgotten that I asked it to always ask for a password.
<Ubugtu> Malone bug 33523 in gnome-screensaver "g-screensaver starts after idle period, regardless of user input" [Major,Needs info]  http://launchpad.net/bugs/33523
<Mithrandir> TheMuso: pong
<TheMuso> Did you see my bug report re casper?
<TheMuso> I was going to talk to you directly, but when you didn't respond within 48 hours or so, I thought a bug report would be better as I have been busy this apst weekend. :)
<Mithrandir> TheMuso: given that I came back from a three-day vacation without network access last night and just now sat down and looking at scrollback, no, not yet.
<TheMuso> Ok.
<TheMuso> No problem.
<jmg> anyone know Malcolm Yates?
<jmg> canonical guy?
<lifeless> yes
<jmg> is he on irc?
<lifeless> mdy on freenode
<jmg> lifeless: thanks
<Mithrandir> pitti: cupsd is eating 100% cpu here when upgrading.  Is this known?
<Mithrandir> it seems to be busy doing:
<Mithrandir> write(6, ptrace: umoven: Input/output error
<Mithrandir> 0xfffffffff8621de9, 133959602) = -1 EFAULT (Bad address)
<Mithrandir> gdb gives me:
<Mithrandir> #0  0x00002aaaab2bc0d2 in __write_nocancel () from /lib/libpthread.so.0
<Mithrandir> #1  0x00002aaaab193d7f in cupsFileGetChar () from /usr/lib/libcups.so.2
<Mithrandir> #2  0x00002aaaab19422c in cupsFileFlush () from /usr/lib/libcups.so.2
<Mithrandir> as the useful bits of the backtrace.
<pitti> Mithrandir: no, not known to me so far, but I didn't yet wade through all of its bug reports
<Mithrandir> pitti: I've seen it sometimes before too, but I'm not sure what the steps to reproduce are.
<infinity> Grr, why are people randomly reassigning my bugs to other people/teams?
<pitti> doko: ping (about cups)
<doko> pitti: pong
<pitti> doko: you said that you rather want me to ship cups' ppd files in /u/s/cups/model and add /usr/share/ppd/cups-included -> /u/s/c/model, right?
<pitti> doko: I didn't understand the reason for that; to avoid symlink loops, we need to fix all packages anyway
<pitti> doko: or do you want to ignore /u/s/ppd completely for dapper?
<pitti> doko: (symlink loops: /u/s/cups/model/<otherpackage's symlink> -> /u/s/ppd/otherpackage)
<doko> no, ship it in /usr/share/ppd/cups-included and add /u/s/c/model/cups-included -> /usr/share/ppd/cups-included
<sivang> morning all
<pitti> doko: what should this /u/s/c/model/cups-included symlink be good for?
<pitti> hi sivang
* sivang hugs pitti 
<doko> pitti: IIUC the spec, ppd files should by looking at /usr/share/ppd, not /u/s/c/model
<doko> not awake ... ppd files should found by looking at /usr/share/ppd, not /u/s/c/model
<pitti> doko: right
<pitti> doko: and since cups doesn't look into /u/s/c/model *at all* any more, why should we put stuff there?
<pitti> doko: (*at all* is true for my current test version I sent to you)
<infinity> doko: Oh, BTW, two things.  The buildds *CAN* resolve localhost just fine (though I double-checked, and freshened the chroots a bit), and if you have a python2.4 upload that stops the testsuite from looking for the internet, please upload it.
<infinity> doko: Some may not have been able to resolve their own IP (ie: sejong.buildd would have had no idea how to get to "sejong" or "sejong.buildd", though it could do localhost fine), but that should be resolved too.
* infinity runs off to get a very late lunch.
<doko> infinity: ok
<infinity> doko: Oh, and if you mistakenly rely on /etc/hostname anywhere, instead of `hostname` (though I doubt you or upstream would make that mistake), don't.  Sine the chroots are shared between buildds, it's obviously impossible for /etc/hostname to be correct.
<infinity> s/Sine/Since/
<doko> pitti: but this was my mail about on Sat, it's a nightmare to find out all packages which currently look at /u/s/c/model. without having symlinks there, they would not the the ppd's provided by cups
<doko> s/the the/see the/
<pitti> doko: aah, I understand - you mean that should fix other printer spoolers than cups, not other packags which provide PPDs for spoolers?
<pitti> hey carlos 
<carlos> morning
* sivang hugs carlos 
<doko> pitti: right, AFAIK in the long term they want to point /usr/share/cups/model -> /usr/share/ppds (and this symlink should be managed by cups), so packages providing ppds don't have to care about making them available for a spooling system
<pitti> doko: alright, that makes sense then
<pitti> thanks
<pitti> doko: otherwise, the current version works for you? (it does fine for me)
<pitti> doko: btw, /usr/share/cups/model can't be a symlink as long as other packages ship files in that directory
<lifeless> ogra_ibook: ping
<pitti> doko: so I'll wait with adding that symlink until all the PPD providing packages are fixed, right?
<doko> at least for my OfficeJet, yes
<mdke> pitti, is it difficult to add a locale to mozilla-firefox-locales-all?
<pitti> mdke: as long as there is a working XPI, it's relatively easy
<mdke> pitti, a working XPI is a translation, right?
<pitti> mdke: not necessarily, XPIs can contain any kind of extension
<pitti> mdz: other way round: a working translation must come in an XPI
<mdke> right
<mdke> so you need a translation before you can add it
<mdke> thanks
<pitti> mdke: obviously :)
<mdke> pitti, well I was wondering whether you can add the locale which defaults to English where the translation exists. np
<pitti> mdke: I didn't understand that
<pitti> mdke: you mean the translation is already installed, but ffox doesn't use it because you don't have the corresponding locale?
<mdke> no, no
<mdke> pitti, i was just curious about how it works. I wondered if you can add a locale to firefox without having a translation, or a full translation
<lifeless> mdz: around ?
<pitti> mdke: hm, I'm not sure, but it should work
<pitti> mdke: if you base a new translation on the en-US.xpi one, then you only need to change the bits you want
<mdke> pitti, cool, thanks
<dholbach> heya mvo!
<mvo> dholbach!
<mvo> dholbach: rock-star
<doko_> hi plaudertasche
<dholbach> :)
<doko_> ;)
* mvo thinks he is a washing-woman
<Mithrandir> fabbione: https://launchpad.net/distros/ubuntu/+source/xkeyboard-config/+bug/23691 might be yours/xorg's.
<Ubugtu> Malone bug 23691 in xkeyboard-config "Latin Keyboard Layout wrongly recognized as 'Laos'" [Major,Needs info]  
<Mithrandir> you probably need to change la => latam on upgrades from old versions.
<fabbione> Mithrandir: WEEEEHHHHHHHH
<fabbione> Mithrandir: go ahead and fix it :)
<Mithrandir> fabbione: enjoy. :-P
<Mithrandir> fabbione: iz not xkb bug.
<fabbione> well you change a layout...
<fabbione> you get to fix it on upgrades :P
<Mithrandir> I can't touch X's configuration files.
<fabbione> neitgher can i :)
<dholbach> mdke: I'm just about to do a gnome-user-docs update - I wondered, why is their source tarball 2,3 MB (resulting package 1,7MB) and the ubuntu-docs tarball 15,7 MB (and the resulting package 637K)? :-)
<lifeless> dholbach: languages ?
<dholbach> lifeless: i built the package locally - so there are no stripped translations
<Mithrandir> mdke: I haven't done anything on the kubuntu-docs update as I have been on vacation and am still busy trawling my mail.
<mdke> Mithrandir, no problem. 
<mdke> dholbach, must be superior compression in ubuntu-docs :p
<mdke> it's all the images
<hendry> is there a way of telling the date of a daily CD from the gfxboot phase?
<hendry> good day Kamion 
<jordi> fabbione: ping ping
<fabbione> jordi: pong
<fabbione> jordi: POOONG
<pitti> infinity: are the amd64 live image generation cron jobs active? I just got an rsync speedup of 709.10 (760 kB received), that seems unrealistic...
<pitti> similar for ppc
<infinity> pitti: Maybe nothing in desktop/live changed? :)
* infinity goes to look and make sure.
<infinity> Or, maybe it's not installable, and hasn't been for days.
<infinity> WOO.
* infinity looks into that.
<infinity> Wow, sweet.  gnome-app-install, update-notifier, and update-manager are all uninstallable.
<infinity> It's an mvo surprise!
<pitti> :/
<seb128> pitti: so you are back in bug fixing instead of CD playing :p
<ajmitch> lucky mvo
<seb128> s/in/to
<mvo> infinity: *cough*
<pitti> seb128: instead of espresso bug filing :)
<infinity> mvo: Looks like unattended-upgrades needs a promotion.
<infinity> mvo: Have you provided pitti the appropriate inclusion reports and such?
<mvo> infinity: it's software we have written, last time a (formal) report wasn't required then
<infinity> mvo: An informal one, then? :)
<pitti> mvo: ^ works for me
<mvo> pitti: let me know your needs, I'll write it up
<Mithrandir> seb128: it seems it's impossible to assign printscreen as a hotkey.  The applet the complains that it'll be impossible to use the key and asks me to use something with shift, control or alt.
<pitti> mvo: would be nice to note down the daemons and security boundaries (only invoked as root, network ports, and so on); but I don't really need a report for our own software
<seb128> Mithrandir: yeah, that's known and reported downstream and upstream
<Mithrandir> seb128: 'k. :-)
<mvo> pitti: so the ball is in kamions court now :) ? 
<pitti> Kamion: ^ fine for me to promote unattended-upgrades (pathologic case anyway)
<pitti> doko: ok to upload cupsys? or are there any blockers?
<radone> Greetings, I have just installed ubuntu and packages gcc, g++
<radone> but after compilation simple program it reports: mikrodes.c:1:19: error: stdio.h: No such file or directory
<Kamion> pitti: ok, will do once the publisher finishes
<Mithrandir> radone: install build-essential
<radone> thanks
<Kamion> (actually, infinity'll do it as practice)
<doko> pitti: please go ahead, I don't see any
<pitti> doko: uploaded
<pitti> doko: so your package upload rave can start, too :)
<doko> pitti: yes, waiting for some UVF exception approvals
<mvo> doko: all openoffice.org-l10n-* and openoffice.org-help-* stuff was renamed (from openoffice.org2- to openoffice.org-), correct?
<doko> mvo: yes, and we have some *2 transition packages
<mvo> ok
<mvo> but the future is with *2?
<mvo> errr
<mvo> without *2?
<mvo> ^--- doko
<doko> no future for *2
<infinity> Does anyone know why we have libglitz1-dev in the supported seeds, despite nothing {build-,}depending on it?
<infinity> If I don't get a useful answer in about 30 seconds, I'm dropping it. :)
<pitti> do it! :)
<infinity> Trunk pooped.
* mvo sings in his best punk voice "no future, no future, no future for you"
<infinity> popped, too.
<Unfrgiven> Kamion: ping
<infinity> Oh, wait.
* infinity sighs.
<infinity> OpenOffice build-deps on glitz, but doesn't end up linking to it.
<infinity> Special.
<pitti> infinity: then it still shouldn't be seeded...
<infinity> doko: Why does OOo buil-dep on glitz?
<infinity> pitti: Well, that's also true.
<doko> infinity: includes some header files, in ooimpress
<Kamion> Unfrgiven: yes? (reduces round-trip times if you include some content with your pings)
<infinity> doko: And then doesn't link to it?
<infinity> doko: That's sketchy...
<Unfrgiven> Kamion: sorry about that. I was told that I should ping you about ubuntu membership. i was approved as a member in a CC meeting but havent been added to the ubuntu members list in launchpad.
<hunger> Is it normal for kern.log and syslog to go way over 200MiB?
<Unfrgiven> Kamion: if you are busy, we can do this some other time.
<Kamion> Unfrgiven: what date was the meeting in question, so I can dig up IRC logs?
<Unfrgiven> Kamion: im trying to dig up the logs myself, it was well over 6 months back. ill just have a look now
<ajmitch> Kamion: may 24th, 2005
<ajmitch> (for the CC meeting in question)
<Unfrgiven> ajmitch: wow, impressive that you remember. aw shucks ;P
<ajmitch> Unfrgiven: grep is a wonderful thing
<Unfrgiven> ajmitch: if you already have the logs, yeah
<ajmitch> I have a bad habit of keeping them around
<hunger> I have cups' access_log eat up all my space in /var in secounds. What might be causing that?
<hunger> It is not even a text file...
<Unfrgiven> Kamion: 12:35 in case you want the time too.
* Kamion looks irritatedly at all the people who randomly say "++" in meetings thus making it impossible for him to grep for that
<Lathiat> why would you grep for ++?
<Kamion> voting for membership approvals
<Lathiat> ah you mean people say it outside of that sort of thing?
<Kamion> that's not the problem, it's when a vote is in progress but people who aren't actually entitled to vote on the matter use the same phrasing as those who are
<infinity> The "me too" instinct is a strong one.
<infinity> If you changed the voting procedure to involve saying "I'm a complete tool!" to show approval, you'd still get just as many people chiming in, but it would at least be more entertaining.
<Kamion> Unfrgiven: right, approved you for ubuntumembers now, also simira and uniq who had also slipped through the cracks from the same meeting
<Kamion> that meeting was before we were tracking membership properly in Launchpad, and you only applied to join the team nearly five months after the meeting so we didn't make the connection
<Unfrgiven> Kamion: ok thanks very much.
<jordi> fabbione: ooh
<jordi> fabbione: I had to leave :)
<jordi> fabbione: ping #2
<Unfrgiven> Kamion: one last question, how do i activate my @ubuntu.com e-mail? i just tested it and the mail bounced. what is my ubuntu.com address?
<jordi> fabbione: are you aware of the ubuntu kernel having some patch to improve the performance of the IDE subsystem on ICH7/Intel 945 motherboards?
<jordi> fabbione: with any Debian kernel, scping a large file, for example, sees a progressive drop of the transfer rate from 10Mb/s to some kbs after some seconds
<jordi> installing is also a lot slower than usual
<jordi> scping to /dev/null is fast
<jordi> ie, the transfer rate keeps at 10
<mjg59> jordi: Only thing that springs to mind is having the PCI IDs for the hardware
<jordi> mjg59: I can get them from a Ubuntu install. Sarge doesn't have a clue of most of them
<jordi> mjg59: give me a sec
<jordi> ubuntu works ok, I forgot to say that
<jordi> and ugh, gentoo
<mjg59> jordi: Sorry, that's what I meant - Ubuntu may know the PCI IDs for the hardware, and so bind sensible drivers to them
<mjg59> You may be running ide-generic
<fabbione> jordi: BenC is the kernel maintainer
<fabbione> jordi: it's probably due to load module order
<fabbione> jordi: check if you have ide-generic loaded in debian
<jordi> mjg59: ok
<jordi> so, we did hack a bit to get ide-generic loaded before piix-sata
<jordi> er, -ata
<fabbione> after
<jordi> because, if piix-ata was loaded first, the CDROMs would not work.
<jordi> (with 2.6.8 from sarge)
<jordi> but, iirc, a etch d-i beta did have the same problem with undetected cds
<fabbione> jordi: ok.. the problem doens't exist in Ubuntu.. so we are ok.. anything else.. though luck :P
<Mithrandir> seb128: the keyboard indictor doesn't seem to pick up changes in the keyboard settings done with setxkbmap + xkbcomp.  Is this known?
<jordi> I guess that's friendly enough...
<seb128> Mithrandir: I think there might be a bug about that
<Kamion> Unfrgiven: I understand that it gets done semi-automatically after you're added to the ubuntumembers team; you do not activate it yourself
<Kamion> Unfrgiven: it may take a day or so, though. if it still doesn't work after that, ask on #launchpad
<Unfrgiven> Kamion: will do, thanks very much for your help.
<Kamion> Unfrgiven: the address is constructed from your launchpad name, so it'll be ankur.kotwal@ubuntu.com
<Unfrgiven> Kamion: just what i was after.
<Kamion> doko: thanks for that foomatic-db change, I appreciate the extra CD space
<Lure> Kamion: ping
<Kamion> Lure: hi
<Lure> I wanted to follow instructions from bug 31974, but most of boot line is wrapped :-(
<Ubugtu> Malone bug 31974 in gfxboot-theme-ubuntu "Kubuntu Dapper Flight 4 - Boot menu boots into a kernel panic" [Normal,Confirmed]  http://launchpad.net/bugs/31974
<Kamion> Lure: how much can you see?
<Kamion> oh, Kubuntu
<Kamion> try Ubuntu
<Lure> I just get "Install on << (press ESC)"
<Lure> I did try ubuntu
<Kamion> so "Install on " is at the start of the line?
<Lure> yes
<Kamion> that's not wrapping, that sounds like the cause of the bug
<Kamion> please add that information to the bug
<Lure> you mean, empty boot line?
<Lure> will do
<Kamion> *wrong*, not empty
<Kamion> for comparison, today's live CD:
<Kamion> "live boot=casper initrd=/install/initrd.gz ramdisk_size=1048576 root=/dev/ram rw qui..."
<Kamion> the human-readable label - "Install on" - shouldn't be in there at all
<Lure> interesting...
<Kamion> oh, really "Install on", not "Install to"?
<Kamion> because there's no "Install on" in the set of labels on the install CD
<Kamion> but there is "Install to first hard disk"
<Kamion> er, "Install to the hard disk"
<Lure> now you got me - I did not write it down, as I expected something else...
<Lure> I will reboot and write it down this time (char by char) ;-)
<Kamion> thanks
<Lure> brb
<doko> Kamion: don't be happy too early ... we'll have to include some PPD files for Postscript printers.
<Kamion> will those grow the package back to the original 12MB?
<doko> I'm afraid, maybe yes. foomatic-db only includes the -xml files, linuxprinting.org-ppds (currently in universe) the ppd files for the laser printers. I'll still have to look, what was included in breezy
<heno> Kamion, Mithrandir: Just to let you know I've just merged in a seed change following the instructions in SeedManagement. Hope I didn't break anything :)
<heno> (it might be worth having a look though)
<Lure> Kamion: my mistake - it does not seem that wrong now - see bug 31974
<Ubugtu> Malone bug 31974 in gfxboot-theme-ubuntu "Kubuntu Dapper Flight 4 - Boot menu boots into a kernel panic" [Normal,Confirmed]  http://launchpad.net/bugs/31974
<Lure> it is just cut to the level that I do not know if it really helps....
<doko> Riddell: qt ping
<Riddell> doko: hi
<Kamion> Lure: interesting, ok, so it's massively truncated inside gfxboot-theme-ubuntu
<Kamion> Lure: thanks, yes, I think that does help; the truncation alone indicates a bug
<Kamion> consistently cut to 10 characters
<Lure> Kamion: ok, then it is not just debug print cut-off (wrapping)
<Kamion> heno: I don't see anything from you in the seeds
<Kamion> heno: did you remember to push the change?
<Lure> Kamion: if you need anything else just ping me or request in bug...
<Kamion> Lure: will do, thanks
<heno> Kamion: the first push was rejected due to a conflict. I merged and I'm pushing again now
<doko> Riddell: is there some environment variable for QT, where to look for qt plugins?
<Riddell> doko: you can set QTDIR, but that might break things
<doko> nothing else?
<doko> QTDIR is /usr/lib?
<Riddell> you can set /etc/qt3/qtrc too
<Riddell> this is for amd64 32bit libs?
<Riddell> QTDIR is /usr generally
<pitti> hi Riddell 
<pitti> Riddell: any news from that kdeprint guy?
<Riddell> pitti: no :(, I told him yesterday we'd need a reply in the next couple of days
<pitti> ok, thanks
<doko> Riddell: yes, for amd64
<doko> Riddell: and probably /etc/qt3/qt_plugins_3.3rc is needed as well
<Riddell> doko: where are the 32bit qt plugins and where is that directory set?
<doko> Riddell: ia32-libs-kde installs into /usr/lib32/qt3/plugins
<doko> Riddell: #36859 tells, that /usr/lib/qt3/plugins/inputmethods/libqscim.so is accessed
<Riddell> bug 36859
<Ubugtu> Malone bug 36859 in kernel-package "wrong arch ppc on powerbook with kernel 2.6.16 and kernel-package 9.001ubuntu5 - 9.001ubuntu15 " [Normal,Unconfirmed]  http://launchpad.net/bugs/36859
<Riddell> not the right one?
<doko>  bug 36589
<Ubugtu> Malone bug 36589 in openoffice.org openoffice.org-kde "KDE Openoffice.org cannot load scim library" [Major,Confirmed]  http://launchpad.net/bugs/36589
<Riddell> doko: maybe we need to compile qt3 again for ia32libs with -sysconfdir  "/etc/qt3ia32"
<doko> Riddell: currently trying some other dirty tricks which I played for pango
<Mithrandir> Riddell: http://err.no/patches/kubuntu-docs_5.10-0.6.2_fix_about_kubuntu_path.diff ; Are you ok with me uploading this?
<Riddell> Mithrandir: /usr/share/doc/kde/HTML/en/kubuntu/about-kubuntu/index.html seems to be the correct directory
<Mithrandir> Riddell: not according to that bug report, since that is what it currently is.
<Riddell> Mithrandir: oh, didn't see it was breezy
<Riddell> Mithrandir: yeah, that's fine then
<Mithrandir> Riddell: excellent, thanks.
* mdke hugs Mithrandir 
* _ion hugs self
<Amaranth> fabbione: bug 26341 has a patch available that supposedly fixes it
<Ubugtu> Malone bug 26341 in xserver-xorg-driver-i810 "[i855]  dual-head configs are ill" [Normal,Unconfirmed]  http://launchpad.net/bugs/26341
<HiddenWolf> "ill"
<pirast> where's keybuk?
<desrt> on the surface of the sphere
<HiddenWolf> desrt: between heaven and hell. ;)
<Riddell> Kamion: on_list_changed in gtkui.py seems to end with a for..else block, is that some form of python I've not seen before or as I suspect a mistake in indentation?
<bddebian> infinity: You awake?
<Kamion> Riddell: some form of python you've not seen before :)
<Kamion> Riddell: http://docs.python.org/ref/for.html
<Chipzz> Riddell: for else is something specific
<Chipzz> +python
<Kamion> Riddell: immensely useful syntax which cuts down on random break statements
<Kamion> well, not break statements, random 'found' variables or whatever
<Chipzz> Kamion: it can only be usefull when using break ;)
<Riddell> interesting
<Kamion> so instead of "for foo in bar: if foo == 'bar': found = True; break" // "if not found: ...", you do "for foo in bar: if foo == 'bar': break" // "else: ..."
<Riddell> Kamion: kde espresso should be good to merge currently
<Kamion> Chipzz: yeah, was a thinko
<Kamion> Riddell: thanks, am just finishing off the choose-mirror/apt-setup work I just pushed
<Kamion> (so you'll need to do debian/rules update)
<Riddell> Kamion: in gtk what's the difference between set_sensitive and set_active?
<Riddell> or where would I find that out?
<Mithrandir> active is what gets pushed when you press enter, sensitive means you can push it.  I think.
<Kamion> Riddell: sensitive is the greyed-out state, active is checked/unchecked
<Kamion> http://www.pygtk.org/pygtk2reference/class-gtkwidget.html#method-gtkwidget--set-sensitive
<Kamion> http://www.pygtk.org/pygtk2reference/class-gtktogglebutton.html#method-gtktogglebutton--set-active
<Riddell> aah, thanks
<Riddell> how come when I google for stuff like that it always come up with python docs and not C docs?
<Kamion> "what gets pushed when you press enter" per Mithrandir is has_default
<Kamion> or widget.grab_default() I guess
<Mithrandir> Riddell: docs.gnome.org (or what it's called) seems to have terrible google-fu for some reason.
<Kamion> Riddell: the Python docs and the C docs are pretty much equivalent (and equivalently-readable) in most cases; the Python API is pretty good like that
<Kamion> these days I use the pygtk docs almost regardless of whether I'm using C or python :)
<Kamion> (not that I do much C GTK programming)
<Kamion> Riddell: anyway, http://www.pygtk.org/pygtk2reference/index.html is my bookmarked starting point for pygtk docs
<Riddell> thanks
<ogra> Kamion, if i do: "command| while read x; do; echo x; done" in an udeb postinst, i always get "illegal number" as soon as i try to use debconf commands like db_progress STEP or db_progress INFO ... is there anywher a doc about redirecting in udeb scripts ? 
<Mithrandir> ogra: don't do that.  debconf takes your stdio.
<Kamion> ogra: no, but see archive-copier.postinst for an example workaround
<ogra> ok
<Kamion> down near the end
<ogra> whats that illegal number error about ? 
<ogra> (it usually gets strings not numbers)
<Kamion> it's because you're using db_* inside the while loop (I assume)
<ogra> yep
<Kamion> debconf uses stdin/stdout for its own communication
<Kamion> so the db_progress command tries to read from stdin, which it expects to be debconf, but which is actually command|
<Kamion> it expects the first thing on each line to be something which it can use as the argument to 'return'
<ogra> yeah
<Kamion> and so return gives "illegal number"
<ogra> ah, k
<ogra> hmm, i see, i have to fiddle with file descriptors 
* pitti sighs at Kino - that's a good candiate for dropping into universe...
<Kamion> while there's no documentation on doing this with udebs in particular, it's not a udeb thing, it's a debconf thing; so debconf-devel(7) may help
<ogra> (actually i stole from this archive.copier script, but omitted the redirection)
<ogra> ok
<Kamion> and I even put a comment there. :-)
<Kamion> # Using fd 9 is a bit ugly; debconf gets in the way of random other fds.
<Kamion> (because cdebconf actually uses more than just 0/1/2)
<ogra> heh, yes, i wrote the script at 4am saturday night ... i probably was a bit tired :)
<Mithrandir> we should rather fix debconf to not use stdio.
<Mithrandir> I have that code lying about here somewhere and should fix it up for inclusion in Debian
<Mithrandir> (so it'll trickle down to us in a bit)
<Kamion> piping from a command (as opposed to reading from a file) using fd9 is, er, tricky; can't immediately think of how to do that
<ogra> achieveable for dapper ? (then i'll wait, else i'll work on the workaround)
<Kamion> unfortunately mkfifo isn't available in busybox or you could use a fifo
<Kamion> although mknod is, I guess you could use that
<Chipzz> Kamion: http://chipzz.studentenweb.org/pybookmarks.html ;)
<Kamion> otherwise, if command completes quickly, just redirect its output to a temporary file and use similar code to archive-copier.postinst
<Kamion> Chipzz: neat
<ogra> its not completing quickly :/
<ogra> (its ltsp-client-builder progress reporting)
<Kamion> in that case, 'mknod /some/temporary/path p; command >/some/temporary/path & while read x </some/temporary/path; do ...; done; wait'
<Kamion> or something along those lines
<Kamion> oh, and rm -f /some/temporary/path afterwards
<ogra> thanks :)
<ogra> will try that ...
<Kamion> ogra: I don't think Mithrandir's cdebconf-unixsocket work will go into dapper now
<ogra> yep, thats what i thought
<Mithrandir> yeah, it's dapper+1 material
<Kamion> Riddell: your branch reverts a change of mine in d-i/Makefile; I'll ignore that diff, but you probably want to sort it out in your branch
<Kamion> -                       (export NO_PKG_MANGLE=1; \
<Kamion> -                        cd "$(SOURCEDIR)/$$package" && \
<Kamion> +                       (cd "$(SOURCEDIR)/$$package" && \
<wasabi> If anybody wants to mess with gapti... it pretty much works now:  http://wiki.ubuntu.com/GAptI
<Kamion> Riddell: would you mind renaming gparted_to_mountpoints in kde-ui at some point? it's confusing :)
<Riddell> strange, I'm sure I never touched d-i/Makefile
<Riddell> Kamion: rename to qtparted you mean?
<Kamion> Riddell: yeah
<Riddell> I thought it less confusing to keep method names the same where possible
<Kamion> it confused Daniel and me a while back when we were grepping for gparted
<Riddell> ah :)
<Kamion> I wouldn't mind renaming both to a common name if you'd prefer that
* Kamion merges
<Riddell> sure, I can do that
<Kamion> you missed a bit in the frontend-independence fix for usersetup.py, BTW ... fixing that up now
<fabbione> Amaranth: supposely or does it fix?
<Kamion> Riddell: pushed, thanks for that lot
<Kamion> Riddell: have you had a look at the i18n infrastructure at all? it's a bit idiosyncratic
<Kamion> since we're pulling it all out of debconf
<Riddell> Kamion: no I havn't yet, that's todo after I've got the mountpoints page working properly
<Riddell> there's still the strange qstring unicode problem I was having to be fixed
<Kamion> mm
<Kamion> feel free to put your todo items on UbuntuExpress/ToDo if you like, BTW
<Kamion> I left a slot for them :)
<Riddell> they were at KubuntuEspresso but that's quite out of date now
<Riddell> I'll move them over to your page when I update that
<Kamion> cool
<Kamion> I'm hoping you can use the same text as the GTK frontend, but if there are any KDE-specific strings that we should be pre-emptively adding to the templates file, let me know ... better to get them translated ASAP
<Kamion> the template names kind of assume the widget identifiers currently used by the GTK frontend; I hope it'll be possible to keep those in sync
<zul> heylo
<Fade> !conv 250 gbp cad
<Fade> missend
<Surak> Kamion: there?
<Kamion> Surak: hi
<Surak> Kamion: I'm using friday's dapper live. Espresso has a very small keyboard listbox. I can't see the full layout names for my language. Can it be wider?
<Surak> Kamion: is occupies only a small portion of the window. The rest of it is empty. It could be widened. What do you think?
<Kamion> Surak: known issue, on the to-do list
<Kamion> inconveniently hard to solve though
<Kamion> well, to solve properly anyway
<Kamion> anyway, report a bug if you like
<Surak> ok
<ogra> hmm, using a fifo only works if i dont do any processing of the line ... splitting it with sed or similar things make it stop at random lines ...
<ogra> looks like a race condition or something :/
<ogra> ohoel, its not stuck, it reads in chunks ... but takes ages ...
<ogra> grr
<ogra> s/ohoel/oh/
<dholbach> ogra: new gnome-screensaver for you :)
<ogra> oooohhh !!!
<ogra> yippie 
<dholbach> yeah :)
<dholbach> ogra is happy again. :-)
<ogra> dholbach, thanks a lot, you might save my day :)
<ogra> as far as i can be in my current RL situation, yes :)
<mdz> lifeless: am now
<infinity> mdz: BTW, that re2c changelog for the UVF exception I was after is here: http://cerberus.0c3.net/~adconrad/re2c.changelog
* bddebian pounces on infinit
<bddebian> Err infinity even
<infinity> bddebian: Pounce in about 7 or 8 hours, please.  It's many hours past my bedtime. :)
<bddebian> Gah
<infinity> bddebian: I have your diff up on my screen still, I may just fix it when I have some free time and mail you my findings.
<bddebian> Fair enough
<heno> does anyone know if Espresso can be run purely from the command line?
<heno> we got this email from a blind sysadmin who would like to install on multiple machines
<heno> https://lists.ubuntu.com/archives/ubuntu-accessibility/2006-April/000245.html
<heno> a good solution for him might be to boot live CDs and then ssh into them and run espresso
<heno> possibly scripted
<Mithrandir> heno: it can't.
<mdz> infinity: short and sweet
<Mithrandir> heno: there has been a bit of effort to get d-i running with a braille frontend.  Unsure what the state is there, though.
<mdz> infinity: what's the symbol table reimplementation about?
<heno> Mithrandir: braille would be nice, but having something run in pure CLI in a booted session would be great, because then you could just SSH in and run it from a system already set up with full access
<Mithrandir> heno: there's an ssh-server udeb, usually used by s390 installs.
<heno> Mithrandir: so that let's you ssh into a running d-i session?
<Mithrandir> heno: yes.
<Mithrandir> (basically)
<Mithrandir> heno: I'm not sure exactly how the details there work, though.
<heno> ok, I can ask the guy to look into that
<heno> Are there any major technical obstacles to making a CLI front-end for espresso though?
<heno> yiu would think that was much easier than the gui one
<infinity> mdz: Just looks like general code cleanup to me: http://cerberus.0c3.net/~adconrad/re2c.symboltable.diff
<Mithrandir> heno: it'd be called "d-i". :-)
<heno> :)
<Mithrandir> heno: espresso is "just" a fairly complicated set of custom widgets to drive a selected set of d-i.
<Seveas> Mithrandir, well, not really, espresso doesn't mimic d-i too much
<heno> So d-i just needs to learn to run from a live CD session like espresso does
<Seveas> you could call it espresso-decaf
<bddebian> heh
<heno> installing to a chosen HD
<Seveas> and I still think the kde frontend should be kappucino
<sivang> re all
<mdz> infinity: that diff isn't very comprehensible without context, but if re2c is in main it's as a build-dep, and if the dependents continue to build, I'm OK with it
<infinity> mdz: Yeah, like I said, it just looks like minor code cleanups to me (and the obvious one or two bugs fixed, which some upstream claim they want, hence the versioned autoconf checks)
<infinity> mdz: I don't pretend to fully understand re2c, however (nor bison, flex, or any other such twisted tools)
<infinity> mdz: I'll make sure to sping it's rdeps before I sync it, however.
<infinity> s/sping/spin/
<mdz> infinity: sping sounds like a good name for an sbuild-based rebuild test tool
<bddebian> Damn, flight5 is taking forever on this POS Celeron machine :-(
<sabdfl> Kamion: during package installation, is it possible for a postinst script to look into the queue of other packages to be installed?
<KaiL_> hmm, MacOS has a toiol to migrate data from Windows - might be an idea for ubuntu too... automatically import emails, comy media files and add them to rhythmbox, copy documents and so on ;)
<KaiL_> -i
<elmo> sabdfl: not in any sane way, no
<sabdfl> elmo: so there's no way to see a list of unconfigured packages?
<elmo> you can see the state of packages, yes, including which ones are unconfigured
<elmo> but that's not equivalent to knowing which other packages are due to be installed
<elmo> (i.e. there's no "I'm due to be upgraded" or whatever state)
<elmo> ('cos 'state' is at the dpkg level, not apt or higher)
<Burgwork> KaiL_, there are specs on the wiki for that
<KaiL_> ah, nice
<Burgwork> however spec != code
<KaiL_> as always - the world is full of great ideas, but they need to get implemented
<LaserJock> KaiL_: https://wiki.ubuntu.com/SwitchingFromWindows is at least a help
<sivang> elmo: oh, I recalled you pinged me the other day? 
<KaiL_> LaserJock, reading that remembered me of that tool ;)
<Burgwork> KaiL_, there is some linux code from openmoveover
<Burgwork> just need to write a windows tools
<elmo> sivang: it was just about the account, if it's working, it doesn't matter
<KaiL_> Burgwork, might be something for dapper+1
<Burgwork> KaiL_, I think it is more a case of the community doing it
<Burgwork> speaking of community work, sivang ...
* sivang screams and runs away
<KaiL_> Burgwork, why not a tool in ubuntu for that? as MacOS has...
<sivang> Burgwork: I'm cranking on it as we speak :-) 
<Burgwork> KaiL_, there are two parts. We already have the Ubuntu side, in openmoveover
<sabdfl> elmo: reason i;m asking is that we spend quite a lot of time updating the font cache during a d-i install
<sabdfl> we do it like 15 times
<Burgwork> we need a windows program to take the data and burn it onto a cd
<sabdfl> and it would be a big timesaver to defer that until the last font package was being configured
<sabdfl> sort of "peek into the queue, yes there are otherunconfigured font packages, ok so i won't do the font cache"
<elmo> sabdfl: oh, you don't need to peek into the queue, it should just be deferred - we already do that, for e.g. menu updates, and scrollkeeper (I think).  it just needs someone to either code the deferrment stuff, or implement generic hooks in dpkg for it
<KaiL_> sabdfl, tried to install on a slow CPU? ;)
<elmo> haha, slow CPU, haha
<sivang> ?
<KaiL_> then this problem starts to become a real one
<sabdfl> elmo: :-p
* sivang waits silently for bzr to push and thing he needs to take the latest snapshot and re-init the bzr branc for performance.
<sabdfl> elmo: this was on the APC
<sabdfl> sivang: branch of what? bzr should be pretty quick on small branches even with lots of commits
<sivang> sabdfl: well, it's not small anyore ;-) , and well, it has lots, and I mean lots of commits.
<infinity> sabdfl: That's better handled by d-i diverting fc-cache, then running it once at the end.
<infinity> Kamion: It's that meant to be done currently?
* sivang checks network
<infinity> Kamion: s/It's/Isn't/
<sladen> sabdfl: the fc-cache request is done by the postinst scripts IIRC.  What I suppose fc-cache could do is be wrapped so that it accepts all the input and then actually does its work after 60seconds
<pitti> hm, is it just me and a mutt bug, or do Malone email threads arrive 'backwards' for a few days/weeks now?
<pitti> (sometimes)
<sivang> sabdfl: see how fast you can branch it , http://mercury.linuxguru.net/~sivan/upbackup--main/ (might be my network, am checking)
<trappist> pitti: I've noticed it on kubuntu-bugs
<trappist> pitti: using kmail
<infinity> sabdfl: OTOH, if you want to pay some folk to implement dpkg hooks once and for all, I don't think any of us would complain terribly about them suddenly appearing. :)
<infinity> sabdfl: But for the installation case, we just handle these issue by diverting the binaries we don't want running, then running them all at the end of the installation.
<sabdfl> infinity: sounds like a dapper+1 sort of thing, if you're up to it :-)
<infinity> I made a personal vow to never touch dpkg code.
<sabdfl> i've just noticed the install hanging regularly for a while as it does the fontcache thing
<infinity> Then again, I made that same vow in relation to many other things I keep touching. :/
<sabdfl> infinity: you could always figure out the appropriate bribes to get it higher on keybuk's list
<sabdfl> erk. 
<infinity> sabdfl: Yeah, that likely means Colin's missing a diversion in d-i.  Easy solution for the installation case (but that doesn't fix upgrades)
<sabdfl> wish those two thoughts had not arrived sequentially
* infinity smirks.
<sivang> nope, it's not the network, seems fine. It's being terribly slow on the "fetch phase" 
<sivang> great, it suddenly finished :)
<bddebian> infinity is still up?  WTF :-)
<sivang> bddebian: guess it's one of his not sleep 3 days in a row days :)
<bddebian> heh
<hile> 2-12 jos muistan
<hile> sorry, wrong channel... again
<jordi> Riddell: ping
<sivang> anybody mind that we drop the waiting time in cdrecord? I've seen it patched in other distros, it will make the user wait less when bunring his backup through HUB and I suppose other frontends could enjoy from it.
<trappist> sivang: can that be done in /etc/default/cdrecord, or must the source be patched?
<sivang> trappist: seems the code must be patched.
<infinity> sivang: Is a two-second wait really a huge problem for HUB users?
<Riddell> jordi: hi
<KaiL_> hmm, still no gstreamer0.10-dvd?
<sivang> infinity: you mean reducing the time to 2 seconds as the minimum allowed? 
<KaiL_> infinity, as burning a CD normally takes below 1 min today, it might extent the overall time a lot
<sivang> infinity: well, come to think of it, even with the 2 seconds, with al the waiting they have to do on the ISO building, and archiving, I'd like to cut wait time whereever I can. does it look like nitpicking in your opinion ?
<jordi> Riddell: remember that kontact template?
<jordi> it was broken, a html file was uploaded
<Riddell> jordi: .pot file?
<jordi> Robot101: yes
<jordi> Riddell: yes
<infinity> sivang: I think it's nitpicking, yes. :)
<Riddell> jordi: a .pot file is actually an HTML file?
<Riddell> that's crazy
<jordi> Riddell: a pot file was uploaded to rosetta for kontact
<jordi> the content was HTMl though
<jordi> rosetta rejected it
<jordi> can you do whatever necessary to get it uploeaded correctly?
<Riddell> jordi: uploaded in the kdepim package or separately?
<jordi> in the product series
<jordi> https://launchpad.net/products/katapult/+series/kde-playground
<jdthood> jordi: Hi there
<Riddell> oh, katapult, that makes more sense
<Riddell> ok, I'll poke mez
<jordi> oh, kontact
<jordi> sorry
<jordi> Riddell: tell him to upload all the pack, with po files
<Amaranth> fabbione: a user claims the patch fixes 26341 (late)
<Amaranth> err, bug 26341
<Ubugtu> Malone bug 26341 in xserver-xorg-driver-i810 "[i855]  dual-head configs are ill" [Normal,Unconfirmed]  http://launchpad.net/bugs/26341
<infinity> pitti: Your cdbs upload fails in the test suite (fails 9 out of 10 tests; impressive)
<pitti> infinity: wohoo, it worked just fine here
<pitti> infinity: thanks for poking, will look at it
<infinity> pitti: Is it doing complete package builds in the testsuite?  If so, you may need to make use of that wonderful NO_PKG_MANGLE envvar. :)
<pitti> infinity: ah, due to the clean_workdir failure, that rings a bell
<pitti> infinity: no, it's much simpler I believe
<pitti> infinity: it's just the test suite's cleanup function itself that fails
<pitti> . o O { which code actually tests test suites? }
<infinity> Oh, that does sound vaguely familiar.  I remember hunting something like that a year ago or so...
<jcole> does dapper include the latest dri
<sivang> infinity: that is failing the automatedTesting tests ?
<sivang> infinity: (nice that cdbs already has a test suite for that)
<infinity> sivang: Lots of packages have test suites.  Doesn't have much to do with AutomatedTesting, per se.
<sivang> infinity: yes, it's only a mattr of hooking it up to the AT magic I guess
<bddebian> Sheesh infinity, do you EVER sleep? :-)
<pitti> infinity: hm, no; I thought I dropped an Ubuntu patch I shouldn't have dropped, but that wasn't the case; anyway
<infinity> bddebian: Sometimes.
<pitti> bddebian: infinity's ACPI has some serious bugs :)
<bddebian> Heh
<jcole> fyi dudes, i get this error with samba.. just simply removed the "+" sign in smb.conf--> "params.c:Parameter() - Ignoring badly formed line in configuration file: +########## Domains ###########"
<infinity> jcole: It's already fixed.
<jcole> infinity: ok
<pitti> 'rm: cannot remove `/build/buildd/cdbs-0.4.34ubuntu1/test/workdir/cdbs/debian/cdbs' -> strange
<jcole> ah, i see a new xserver-xorg-core for dapper... looks like latest dri is in there
<Seveas> pitti: filesystem remounted ro?
<infinity> No.
<pitti> Seveas: on the buildds? I don't believe that
<Seveas> likewise, but pigs have flown before
* infinity tests locally.
<infinity> Man, cdbs has some bizarre build-deps.
<pitti> yes, ocaml stuff and the like :/
<sivang> infinity: it is just evil, isn't it?
<pitti> some tools which generate the documentation use ocaml apparently
* ogra wouldnt expect anything else from the "creating debs blackbox system"
<sivang> anybody know how to adjust the contrast in a thinkpad? (not talking about the brightness Fn+home/end)
<sivang> ogra: indeed.
<infinity> FAIL: hdparm.sh
<infinity> Okay, 1st thing.  I get different failures on a local build, but do get failures.
<infinity> Second thing.  hdparm.sh?  WTF? :)
<ogra> lol
<infinity> Some logging on this testsuite sure would be nice.
<infinity> pitti: Okay, with pkgstrip enabled in my chroot, I get the 9/10 failures.  Using NO_PKG_MANGLE, I get one failure on hdparm.sh, which is clearly something else.
<pitti> ah, cool
<infinity> Hahaha.
<infinity> cdbs has developed a build-dep on itself. :)
<infinity> (Or, we should disable the hdparm test)
<infinity> dpkg-buildpackage: source package is hdparm
<infinity> dpkg-checkbuilddeps: Unmet build dependencies: cdbs (>> 0.4.5)
<infinity> (dapper)adconrad@cthulhu:~/cdbs/cdbs-0.4.34ubuntu2/test$ dpkg -l cdbs | grep ^p
<infinity> pn  cdbs           <none>         (no description available)
<infinity> (duh)
<pitti> 'ooops'
<infinity> Let me run the hdparm test by hand to make sure it passes, then I'll just upload with that test disabled.
<infinity> I don't think I like the idea of cdbs build-depending on itself.
<pitti> infinity: ah, debian bug 354361
<Ubugtu> Debian bug 354361 in cdbs "Subject: cdbs: FTBFS: FAIL: hdparm.sh" [Serious,Closed]  http://bugs.debian.org/354361
<pitti> infinity: I'll fix the test instead
<infinity> Oh, yeah, I'll do that.
<infinity> (I already have the rest fixed, so let me just upload) :)
<pitti> alright :)
<pitti> thank you
<bddebian> infinity: Oh sure, I see where I rate.. :-)
<infinity> Oh crap, it's 6am...
<ajmitch> morning
<pitti> hey ajmitch 
<Surak> Kamion: where does espresso gets the languages' names? u'Thai returns error on 0.99.42 on language.py line 61
<sivang> infinity: what has hdparm.sh with cdbs?
<infinity> Is that sentence missing a few words?
<pitti> sivang: it's just a test case which was based on the hdparm package
<sivang> infinity: could be, too much PHP test engine mungling during the dayjob damaged my thought to speech engine..:)
<KaiL_> ndiswrapper in dapper is rather old, as I just saw. newer versions making problems?
<sivang> pitti: Ah, I see. thanks.
<Surak> Kamion: espresso 0.99.42 shows no languages for selection. The problem is that /usr/share/localechooser has no "thai". However, localchooser list it as available. espresso 0.99.42 must depend on updated localechooser-data-0.27ubuntu13 (it will fail with 0.27ubuntu11). Updating localechooser-data will fix this.
<dholbach> night guys
<mdke> night dholbach 
<dholbach> night mdke
<Surak> night dholbach
<dholbach> night Surak
<Surak> I closed one bug on espresso, but opened three. I think Kamion will not happy with me tomorrow :-)
<sivang> heh
#ubuntu-devel 2006-04-16
<jcole> $ dmesg | grep drm
<jcole> [4294686.182000]  [drm]  Initialized drm 1.0.0 20040925
<jcole> isn't that pretty old?
<Surak> jcole: more than ubuntu :-D
<jcole> this guy has a newer version -->  http://ubuntuforums.org/showthread.php?t=134069&highlight=20060119
<jcole> maybe that's why there are so many xgl problems with i810
<jcole> on ubuntu... my colleague has suse running fine with xgl... ubuntu wouldn't work
<jcole> i've got: [4294686.185000]  [drm]  Initialized i915 1.1.0 20040405 on minor 0:
<mdz> mjg59: around?
<mdz> mjg59: is it at all expected that sleep/hibernate via  the Fn key combinations is no longer working on my T42, and what can I do to remedy it?
<theCore> why Gnome create an icon for NTFS drives, even when the user doesn't have the permission to access it?
<mdke> theCore, it's a known bug, and fixed, I think
<theCore> mdke: oh, well 
<theCore> mdke: thanks for the info
<mdke> I think it's https://launchpad.net/distros/ubuntu/+source/partman-basicfilesystems/+bug/25071
<Ubugtu> Malone bug 25071 in partman-basicfilesystems "More reasonable defaults for ntfs mounts during installation" [Major,Fix released]  
<mjg59> mdz: It ought to work
<mjg59> mdz: What's the sleep button action in gnome-power-preferences?
<mdz> mjg59: hibernate
<mjg59> mdz: Hm.
<mjg59> mdz: If you run xev and focus it, do fn+f4 and fn+f12 generate keycodes?
<lifeless> mdz: hi
<jcole> do you think drm being so old in ubuntu might be the cause of alot of these bugs? -> https://launchpad.net/distros/ubuntu/+bugs?field.searchtext=direct+rendering
<jcole> my /lib/modules/2.6.15-20-686/kernel/drivers/char/drm/i915.ko kernel module is dated 20040405
<jcole> 2.6.15-20 is the latest kernel i can find in synaptic
<Surak> hum. is gnome's bugzilla down?
<HiddenWolf> yes
<HiddenWolf> too many connections error. :)
* jcole brb, booting ubuntu with suse kernel...
<mdz> mjg59: need to get the laptop back in hand later today...should it generate keycodes or not?  I thought those were acpi events
<mdz> lifeless: hi?
<KaiL_> that was only 1, not 20 ;)
<jcole> lol, that was a bad idea
<KaiL_> "suse" is mostly something, which has to do with bad ideas ;)
<Kamion> Surak: yes, I knew about the localechooser-data thing but wasn't terribly worried; after all for most people it's a live CD and they won't bother upgrading it
<Surak> Kamion: so I shall close the bug.
<Kamion> also I'm more likely to be unhappy at people for closing bugs than for opening them
<Kamion> Surak: no, don't
<Kamion> please leave closing espresso bugs to espresso developers :)
<Surak> there are two or three regressions from 0.99.36 to 0.99.43.
<Surak> Kamion: ok. Even fixed bugs? Sorry. I closed one of them. Just as triage, to make your time better used on coding.
<Kamion> please don't close bugs on the basis that it now works for you if you aren't the original submitter
<Kamion> that actually uses up more of my time, because I have to go back and check
<Surak> sorry.
<mjg59> mdz: Ot's all done via keycodes now
<Surak> Kamion: did you remove the resize partition option in 0.99.43? It was there friday.
<Kamion> Surak: no, I did not
<Surak> Kamion: forget it. I zeroed the hard drive to test some GRUB bugs.
<Kamion> Surak: you almost certainly no longer have a partition table that partman can resize and insert more partitions into; this often happens because you have too many primary partitioner
<Kamion> partitions
<Kamion> ... or that would do it too
<lifeless> mdz: I heard there was a distro sprint coming up soon
<Surak> specifically, bug 35614
<lifeless> mdz: I'd like to come along to that to get a stronger sense of the QA challenges you guys face
<Ubugtu> Malone bug 35614 in espresso "grub fails" [Normal,Confirmed]  http://launchpad.net/bugs/35614
<Kamion> I wish people would open new bugs for that
<Kamion> grub can fail for all sorts of reasons
<Surak> it works here. I'm doing some testing to make it break so I can help you, but it insists in working!
<Kamion> with Flight CD 6, it will only break if there's a candidate version of grub in the archive newer than what you have installed
<Kamion> I believe the bug to be fixed in more recent versions of espresso, and so I've just closed the bug
<Kamion> (thought I'd already done so, thanks for the reminder)
<Surak> Oh, you just closed it. It was still as open here, as I probably opened the window about 2h ago :-)
<Surak> Kamion: bug 37199 was fixed too. 
<Ubugtu> Malone bug 37199 in espresso "Espresso does not check wheter the entered passwords are the same" [Normal,Needs info]  http://launchpad.net/bugs/37199
<KaiL_> jcole, do you know, if there are known deadlocks with i915?
<mjg59> mdz: Oh, BTW - I'll be travelling during tech board tomorrow
<HiddenWolf> lmao, if you order packages by number of bugs, 81 is less than 9. :)
<HiddenWolf> someone confirm I'm not crazy? 
<Burgwork> HiddenWolf, linky?
<Kamion> Surak: thing is, I could never reproduce that problem in the first place
<HiddenWolf> https://launchpad.net/people/seb128/+packages is the page I was checking
<KaiL_> jup, same here
<Kamion> Surak: actually, no, ignore that, see my comment in the bug
<Burgwork> HiddenWolf, the sorting it is doing is by alphabetical, rather than numbeical
<Kamion> Surak: the bug should remain open
<KaiL_> doesn't say, that you aren't crazy, but that bug really exists :p 
<lifeless> I've put my name up to get universe upload rights in the next tb meeting. Its at 5am here - how much of a requirement is to be at the meeting ?
<HiddenWolf> Burgwork: makes the sorting for that column pretty useless
<Surak> Kamion: because of the last comment? About being empty instead of different?
<Kamion> Surak: yes
<Kamion> Surak: thanks for triage though, it helps remind me of things sometimes
<Burgwork> HiddenWolf, indeed
<Surak> Kamion: as I am not as good as coder as you, but I can still help anyway. Specially in this case, as I know python a little and I did that awful shell script which does the same thing as espresso... 
<Kamion> generally speaking, I'd rather not have people looking around for bugs to close (as mentioned, that mostly just creates more work, because in my experience at best 50% of those closures are valid), but anyone who can dig into a bug a bit and clarify what's going on can make themselves very useful
<Kamion> what my bug list needs is clarification more than anything else, particularly since many installer bug reports are pretty unclear
<Surak> Kamion: the translation is being done through rosetta's debian-installer item, isn't it? I noticed that the "next" "previous" and "cancel" button are never translated, and there are not such items there.
<jcole> KaiL_: the ubuntu drivers are just really outdated 
<Kamion> Surak: yes; next/previous/cancel are untranslated at the moment, that's a bug, although hopefully fairly easy to fix
<jcole> KaiL_: go here to get the latest videoa driver for your card -> http://dri.freedesktop.org/snapshots/
<Kamion> "fix up various untranslatable strings" is on http://wiki.ubuntu.com/UbuntuExpress/ToDo
<KaiL_> well, if you only go by the date of the file, something seams to be wrong on your system ;)
* Kamion -> bed before his wife starts dropping more and more obvious hints
<Surak> I would never look at it there. :-)
<KaiL_> here the file is dated 2006-04-05
<jcole> KaiL_: $ dmesg | grep drm
<jcole> KaiL_: [4294686.182000]  [drm]  Initialized drm 1.0.0 20040925
<Surak> Night Kamion: same thing here. Better go home and leave this for tomorrow. Thanks for your attention.
<Surak> duh- the first line in wiki is a bug i just opened.
<KaiL_> jcole, interesting - I wonder, from where this version comes..
<jcole> KaiL_:  [4302209.541000]  [drm]  Initialized i915 1.4.0 20060119 on minor 0: <-- notice this line http://ubuntuforums.org/showthread.php?t=134069&highlight=20060119
<KaiL_> really interesting
<jcole> KaiL_: it's the date the debian/ubuntu kernel maintainter(s) downloaded the driver which was a few years ago... i suspect that all drm/dri drivers in ubuntu are outdated
<KaiL_> maybe only the version number didn't get changed?
<jcole> KaiL_: suse and fedora are up to date
<jcole> KaiL_: no, i'm missing extensions that should be on my card
<KaiL_> I can't belive, that all these drivers are 2 years old...
<jcole> KaiL_: i suspect this update will make my 3d card work the same on these other distros
<jcole> KaiL_: probably because they are not part of the main kernel source tree?
<KaiL_> aren't they?
<jcole> KaiL_: no
<KaiL_> I remembered, that the kernel has DRM modules in it's main source tree....
<jcole> KaiL_: where?
<jcole> all right... here goes
<jcole> module compile done...
<KaiL_> let's see.. (didn't look into the source recently)
<Surak> night all.
<mdz> lifeless: where did you hear that?
<lifeless> mdz: some comment during the london sprint. May have misheard/misinterpreted.
<mdz> lifeless: happy for you to join us, but we won't get together again until after the release
<lifeless> mdz: thats cool. Wanted to raise it as soon as possible in case it was near
<lifeless> thanks
<csmall> I have a question that possibly only developers can answer. Regarding performance, comparing RPM based distributions to debian based distributions. Why do RPM based dist seem to run smoother, faster, softer (I know this sounds funny) while debian based dists seem to ...I dunno...hit the disk harder I guess...not the soft smooth feeling of RPM based dists
<csmall> I just could never figure it out
<Amaranth> uh
<Amaranth> how can writing new files to the disk not "hit the disk"?
<Kamion> RPM vs. .deb is just a delivery mechanism for files, so that cannot have anything to do with how the system runs
<csmall> thats all fine and I understand what you mean
<csmall> I am just trying to explain it in the best way I can
<Kamion> the difference must be elsewhere
<csmall> yes
<csmall> but there is a noticable difference
<Kyral> in a way, RPM and DEB are just frontends to Tar.gz :D
<csmall> yeah they are just compressed files
* Amaranth smacks Kyral
<Kyral> OW!!!
<Kyral> what?
<Kamion> presumably the kernel shipped by e.g. Red Hat happens to be better for your hardware
<Amaranth> you oversimplify things :)
<Surak> csmall: try a "apt-get dist-upgrade" in fedora and ubuntu. Then tell me how many minutes more you have to wait in fedora for it just show you the list.
<Kyral> I said "in a way"
<Kyral> jeez :P
<csmall> I am not really comparing the package managment
<csmall> Surak: agreed
<csmall> but I mean an overall feel
<Amaranth> csmall: perhaps you have dma enabled on the other distro and not on ubuntu?
<Surak> csmall: which means rpm can be, in fact, much slower on this particular case.
<csmall> Amaranth: thats what I was wondering I just installed dapper Iwill chekc if its on
<csmall> Surak: I mean an overall feel for the entire desktop experience
<csmall> Amaranth: I will check. I have been using debian religiously for years and I have always wondered why there is this difference in the feel
<lifeless> csmall: I dont think there is any relationship betwen the packaging and the feel
<HiddenWolf> ubuntu and debian are the only ones building for 386?
<csmall> Just thought maybe you guys could offer some insight
<Amaranth> HiddenWolf: probably
<csmall> lifeless: I agree, I only mentioned RPM to descibe the distributions I am refering to
<HiddenWolf> Amaranth: would that _really_ be noticable?
<lifeless> csmall: its misleading though, right.
<Amaranth> HiddenWolf: doubtful
* Amaranth gets lost
<Amaranth> HiddenWolf: iirc it's march=386 but mtune=p4 so i think it's just a matter of not using a couple of newer instructions
<jdub> 486
<Amaranth> jdub: oh, it's 486 now?
<Amaranth> can't really go any higher because of the via c3
<jdub> it always was iirc
<KaiL_> VIA should really repair their CPU crap..
<Amaranth> i'm out of my league here
<HiddenWolf> *chuckle* Well, whatever you do, current performance will always become the baseline. My dapper feels normal or slow, untill I boot up breezy. :)
<Amaranth> KaiL_: They don't do anything wrong, they just don't implement one instruction (cmov?) that others do
<Amaranth> HiddenWolf: hehe, yeah
<HiddenWolf> Just now, eog took more than a blink to show me a photo, and I was 'damn, slow' 
<KaiL_> Amaranth, bad enough - afaik except this single instruction, it's an i686, so it's only an i486 with many many additional instructions, which are mostly not used
<HiddenWolf> Must just have been a microsecond or 2. :)
<csmall> dma is on, so thats not it. maybeit will always be a mystery heh
<Amaranth> csmall: it's harder on the system but from what i've heard it's also faster, maybe that has something to do with it
<Amaranth> although that might be apt vs yum
<Kamion> KaiL_: actually no, it really is an i686, it's just that every other i686 happens to implement i686+cmov
<Kamion> oh god, changing gtk's language under its feet is incredibly tedious
<Kamion> it caches the translations of all stock items
* Kamion kludges madly
* bddebian hands Kamion the duct tape
<lifeless> Kamion: how can I tell if a motherboard has SATA without plugging it into a monitor and rebooting ?
<lifeless> Kamion: is there some regular device/driver that hints this ?
<Kamion> lifeless: lspci, look for SATA
<Kamion> or possibly Serial ATA, or similar
<lifeless> thanks
<lifeless> pity though, looks like my server box is sataless
<lifeless> :|
<HiddenWolf> lifeless: just get the model of moderboard and google for a product/review page
<lifeless> HiddenWolf: if I knew that, I'd just grab my manuals
<Lathiat> dmidecode perhaps?
<HiddenWolf> lspci grep ATA shows it for me.
<lifeless> Lathiat: good call. thanks
<Lathiat> dmidecode works for me on most things like that, if nothign else to get the motherboard model
<lifeless> problem is I have lost touch with hardware-level skills
<lifeless> been focused on software for long enough that I'm out of date
<lifeless> Lathiat: yeah, hindsight - bleeding obvious
<bddebian> dh_link creates hardlinks?
<ajmitch> bddebian: no
<bddebian> How do I symlink dirs?  The manpage isn't real clear.  Can I just do dh_link debian/foo/  debian/bar/ ?
<bddebian> dh_link
<bddebian> dh_link: link destination debian/qgis/usr/share/doc/qgis is a directory
<bddebian> ajmitch: So, how can I do a dir?
<desrt> is anyone else experiencing mime wonkiness?
<bddebian> mime is wonky to begin with :-)
<fabbione> morning
<bddebian> Hello fabbione
<dholbach> good morning
<sivang> morning !
<pitti> Good morning
<ajmitch> morning pitti 
* sivang hugs pitti and ajmitch 
<sivang> and dholbach  , ofcourse
<tepsipakki> g'morning. what component is responsible for showing the volume when pressing volume buttons on laptops?
<dholbach> hi sivang!
<pitti> hey sivang
<sivang> dholbach: :-)
<mdke_> morning dholbach 
<mdke_> dholbach, hey, we're thinking of branching the ubuntu-docs repo today sometime, ok with you?
<dholbach> mdke_: that's ok with me, sure - sorry for not answering the mail earlier
<mdke_> dholbach, no problem
<mdke_> dholbach, it might permit us to eliminate some of those unused icons and reduce the source package size :D
<dholbach> :-)))
<jdub> dholbach: upload u-a crack!
<dholbach> jdub: ok!
<mdke_> jdub, i will never be able to read something you write in irc again without asking myself whether you are writing from the "love-sac" or not
<Burgundavia> mdke: are you scarred for life?
* mdke nods sadly
<sivang> mdke: what, when did this happen??
<sivang> having such consequences, it must have been something very shocking..
<mdke> sivang, I'm reluctant to consign you to the same fate, but it happened when i read http://perkypants.org/blog/2006/04/09/tin-roof-rusted/
* sivang holds his breath and reads
<sivang> oh dear
<mvo> Riddell: https://launchpad.net/distros/ubuntu/+source/language-selector/+bug/37065/+index is about the kde interface guidlines. can you give me a hint please :) ?
<Ubugtu> Malone bug 37065 in language-selector language-selector-qt "[OK]  not working." [Normal,Confirmed]  
<pitti> dholbach: okay for me to upgrade clamav to new upstream release 0.88.1 (from 0.88)? it fixes three security bugs
<pitti> dholbach: http://changelogs.debian.net/clamav -> top entry
<dholbach> yeah
<pitti> hi slomo
<slomo> pitti: hi :)
<hunger> Currently I have about 1GiB logfiles each day! And that on a laptop that is turned of most of the time.
<mdke> you win
<hunger> klogd is eating up more than 35% CPU time with dd taking the rest... what did you change that produces so much data?!
<hunger> Looking into it I think I have problems with dm:-(
* mdke points hunger to the bugtracker
<hunger> Any idea how I can find out what devicemapper device dm-13 is in normal terms?
<hunger> Is that the minor number in /dev/mapper?
<stockholm> i need to reach clair davis urgently
<stockholm> is she online?
<stockholm> does someone have a phone number?
<fabbione> stockholm: what is the problem? she is in holidays
<stockholm> fabbione: the problem is that she was (i thought) supposed to write the paper for mark's debconf6 talk and did not do so
<stockholm> fabbione: and without a paper the talk wont take place
<fabbione> stockholm: i am pretty sure she will sort it out after eastern as soon as she is back
<stockholm> fabbione: i sent her reminderrs that the deadline was over last week
<fabbione> also.. no need to panic.. it's not like Mark really needs paper to talk for a few hours
<stockholm> fabbione: the stuff gets printed very soon
<stockholm> fabbione: we require it for the proceedings.
<fabbione> stockholm: nothing that can be done now.. she is not online and Mark isn't either.. 
<Treenaks> fabbione: The organisers want a basic description of what the talk is about, etc., probably
<Treenaks> stockholm: am I right?
<stockholm> yes
<Treenaks> I'd say: just wait for sabdfl to join, and ask :)
<fabbione> stockholm: ok, you know what is the status, you will be able to sort it out with Claire and Mark when they will be back next week.
<stockholm> hum, right, thanks
<hunger> It is amasing how quiet the system gets as soon as the FS in fixed again:-| sorry for the noise.
<mvo> jamesh: do you happen to know what magic I have to do to get something > 0 from gtk_get_current_event_time() ?
<jamesh> mvo: have some events pending
<infinity> dholbach: Are you doing UVF exceptions for universe?
<jamesh> mvo: with a bit more context, I could probably give a better answer
<dholbach> infinity: yes, with the motu-uvf team
<infinity> dholbach: I'd like a UVF exception for mailutils (fixes a bunch of bugs, looks happy in sid, makes people stop filing bugs about /usr/bin/mail not having an MTA)
<dholbach> infinity: go for it
* infinity goes for it.
* dholbach hugs infinity
<Kamion> FYI: ubuntu-server seeds merged back into main Ubuntu seeds
<Kamion> (with any luck)
<infinity> \o/
<fabbione> Kamion: cool
<jsgotangco> nice
<tseng> lamont: your beagle syscall change should go upstream, yeah?
<infinity> tseng: Yes.
<infinity> tseng: ia64 isn't the only arch without old-skool _syscall  magic numbers, and some day, they'll go away on all arches.  Eventually.
<tseng> infinity: cheers.
<mvo> jamesh: sorry, my isp hated me for a couple of minutes
<jamesh> 17:43 <jamesh> mvo: have some events pending
<jamesh> 17:44 <jamesh> mvo: with a bit more context, I could probably give a better answer
<Kamion> oh, damnit, silbs is on holiday IIRC
<mvo> jamesh: I need it for startup-notification support in gksu, I managed to get my events by sending a syntetic GDK_POPERTY_CHANGE event to a fake-window
<Kamion> any ubuntu-art moderators here? silbs is the only one listed
<jamesh> mvo: for startup notification, the time should be for the event corresponding to the user action that requested the window
<mvo> jamesh: hm, gksu is called by the menu, so  I would have to extract and use this time to have the exact time information? (gksu itself starts some other app then)
<jamesh> mvo: if the .desktop file says that the app supports startup notification, I think the time gets passed in the environment (iirc)
<mvo> jamesh: I think the problem is that gksu itself is a gtk application so the startup notification stuff (from the panel) things all is done when the password dialog is up
<jamesh> mvo: ah.
<jamesh> mvo: I guess gksu should be starting the privileged process with startup notification then
<jamesh> mvo: probably using the time the user pressed enter in the password dialog as the time
<mvo> jamesh: yes, that is what I'm currently working on
<jamesh> mvo: so a signal handler on the entry's "activate" signal and OK button's "clicked" signals would be appropriate
<jamesh> use gtk_get_current_event_time() there (they are called while the event is being processed)
<Riddell> mvo__: hmm, Ok is "make changes and quit" which Cancal is "quit without any changes being having been saved"
<Riddell> mvo: I think they should be changed to "Install" and "Close"
<mvo> Riddell: ok, fine with me
<mvo> jamesh: thanks!
<jamesh> mvo: it worked?
<mvo> jamesh: my approach with the fake-window works (tested it now). the trouble with using the event time from the dialog is that sometimes no dialog is needed (when the sudo password is cached). this just occured to me, so I may have to use (the rather ugly) fake-window approach
<sabdfl> mvo: ping, are you the right guy to forward some dapper Chinese issues to post l10n sprint?
<sabdfl> what's abel's email?
<dholbach> sabdfl: abelcheung@gmail.com
<mvo> sabdfl: yes, please forward the mails to me
<sabdfl> thanks guys
<sabdfl> Riddell: ping
<Kamion> sabdfl: on last night's fc-cache thing, yeah, as elmo/infinity said it's easy to take care of by a diversion - been meaning to do that for a while. I'm just waiting for a current install CD to rsync down so that I can test it now.
<Riddell> sabdfl: hi
<sabdfl> Riddell: mvo just answered my question in pvt msg, i was wondering if Kubuntu always uses the same fontconfigs as Ubuntu
<sabdfl> i have questions from Intel China re Kubuntu fontconfigs for China
<Riddell> sabdfl: yes it does
<mvo> sabdfl:  http://people.ubuntu.com/~mvo/bzr/language-selector/language-selector--mvo/fontconfig/zh_CN is the fontconfig for mainland china
<jamesh> mvo: if no dialog is needed, then the right time to use would be the start time for the application itself
<jamesh> mvo: I wonder if you can get at that easily?
<infinity> Kamion: divert update-initramfs while you're at it.
<jamesh> (application == gksu here)
<Riddell> mvo: slightly confusing how Language Selector is called Language Support in the menu
<Kamion> infinity: ok, I'll have a look, thanks
<Kamion> will do some stopwatch timing
<mvo> jamesh: the start-time of the app started via sudo? I'm not sure that this is possible at all because we need a server timestamp for the startup notification stuff
<mvo> Riddell: ups, I'm fixing this now
<mvo> Riddell: hm, hold on
<infinity> Kamion: We should compare lists sometime, so whatever speedups you do to d-i, I get in livefs, and vice versa.
<mvo> Riddell: IIRC there was some discussion about this at some point and that was why it was renamed ...
<infinity> Kamion: In the next week, pre-beta, might be nice for the installer case. :)
<jamesh> mvo: looks like gdk_x11_display_get_user_time() will give you gksu's startup time if it hasn't popped a dialog
<Kamion> infinity: at the moment I only divert scrollkeeper-{update,rebuilddb} and run scrollkeeper-update
<jamesh> mvo: and if it has interacted with the user, it'll return the time of the last user interaction, which is what you want
<jamesh> sounds perfect :)
<infinity> Kamion: Ahh, kay.  Well, fc-cache is a killer, update-initramfs can easily be another few minutes on slow hardware (another 20 or 30 seconds on fast machines)...
<infinity> Kamion: And I assume you already divert invoke-rc.d to avoid that hassle?
<Kamion> infinity: debootstrap installs a fake start-stop-daemon, but pkgsel doesn't at present
<Kamion> hasn't seemed to be a problem so far
<Treenaks> infinity: my /boot doesn't understand DMA, so I know what you mean :)
<jamesh> mvo: the only case where gdk_x11_display_get_user_time() will return 0 is if you haven't interacted with the user, and you weren't started with startup notification or the startup notification ID didn't include the timestamp
<infinity> Kamion: It's not a problem, per se (especially since you reboot right afterward anyway, to make sure the system is in a sane state), but if you're going to be rebooting anyway, it's pointless to start daemons in the postinsts and waste time there.
<jamesh> that last case shouldn't ever happen with recent libstartup-notification
<mvo> jamesh: that seems to be working nicely, thanks
* mvo goes to remove cruft from his patch
<mdke> infinity, thanks for the server guide reviewing *hugs*
<infinity> mdke: NP, sorry I was a bit cranky and harsh.
<mdke> infinity, i don't think you were. Much appreciated, thanks
<Kamion> infinity: yeah, not disagreeing, just seems to be higher-hanging fruit
<infinity> Kamion: Well, most postinst use invoke-rc.d (and, IMO, they're buggy if they don't), so just diverting that to /bin/true is pretty effortless, and works well.
<sabdfl> Kamion, infinity, Riddell: thanks muchly
<sabdfl> what's the best way to reset the system fontconfig? if I have a machine which has been around a while, and want a virgin config there to test with as if it were a new install?
<Treenaks> sabdfl: check if there's a .dpkg-new file, if so, replace config with that
<Treenaks> sabdfl: and there might be some stuff left-over in ~/.font*
* jdub prepares some fridge love that will make mjg59 cream his pants.
<Treenaks> Ok, launchpad _really_ needs a qdb module
* sivang waits anxiously for the news
* sivang clicked the pony on the fridge, and seeing the results made him cry
<desrt> Ubuntu 5.10
<desrt> Our Price:$3.95
<desrt> You Save:$4.00 (50%)
<desrt> uh.
<_ion> Mkay. :-)
<sivang> desrt: ?
<desrt> http://www.osdisc.com/cgi-bin/view.cgi/products/linux/ubuntu/inst_5x.html?ad=overture
<_ion> Quite a bargain.
<desrt> ya.  50% is a lot to save
<simira>  http://www.osdisc.com/cgi-bin/view.cgi/products/linux/ubuntu/inst_5x.html?ad=overture
<simira> au
<simira> sorry
<simira> are they really allowed to do that?
<desrt> of course they are
<desrt> an interesting hack would be to burn a slightly-altered version of the gold master containing some 'mere aggregation' of a trivial proprietary product with restricted commercial redistribution terms
<desrt> so that the CDs that ubuntu sends out for free can't be resold
<desrt> not sure what right of first sale would say about that, though
<Kamion> not to mention free software morality
<tseng> wait, these are canonical cds?
<desrt> tseng; maybe?
<desrt> Kamion; pah.  you can always download the official iso :p
<tseng> *that* would be immoral
<tseng> i dont see a problem with them selling their own cdrs with ubuntu
<desrt> Kamion; just prevents people from abusing the free-cd program for commercial purposes
<desrt> tseng; ya.  of course that's totally fine
<Kamion> desrt: over my dead body as cdimage guy, anyway
<Kamion> *shrug*
<desrt> Kamion; it's not a serious suggestion
<Kamion> a lot of people watch #ubuntu-devel, I'd rather not have a random unserious suggestion turn up on the news sites as Ubuntu's plans
<Kamion> so I figured an early refutation was a good plan :)
<desrt> eugenia lurking behind the bushes?  heh.
<ajmitch> desrt: given the quality of 'news' on there, I wouldn't be surprised :)
<desrt> Kamion; i say let these people do it :)
<Kamion> (not saying that folks reselling the Canonical-sent CDs aren't immoral)
<desrt> Kamion; just makes their sites look more ridiculous
<desrt> (as if osnews isn't already the laughingstock of our world)
* desrt reads osnews, sounds like the kubuntu project is about to be scrapped
<ajmitch> desrt: that, and the sky is falling
<Kamion> sabdfl: right, by my count in vmware, that fc-cache change saves 2 minutes out of 14 or so
<Kamion> (that 14 being just the pkgsel step, not the whole installation, obviously)
<Riddell> desrt: they published a retraction
<Mithrandir> heno: your accessibility changes have been merged now, you should hopefully see them in tomorrow's daily-live
<jdub> mjg59: http://fridge.ubuntu.com/node/332
<heno> Mithrandir: wooooo! Thanks :)
* heno looks forward to testing the live CD tomorrow
<heno> That gives me a chance to track down that keyboard issue I have too on a clean system
<Mithrandir> I need to fix casper a tiny bit too, but I'm hoping to get that done now.
<Mithrandir> gconftool is called as root, so the settings don't affect the ubuntu user. :-P
<Riddell> heno: what's the plan about kubuntu winfoss?
<heno> Riddell: we should get together and look at available disk space and any KDE-like apps you want
<heno> Riddell: then I'll tweak the look a bit for kubuntu
<heno> Riddell: what are you using now, the old one?
<Riddell> heno: currently it's the same as breezy
<Riddell> heno: disk space seems about right for now
<Riddell> heno: I wouldn't mind having scribus on there if it's any good
<heno> Riddell: ok, I'll use that as a starting point then
<Riddell> maybe replace audacity or something
<heno> Riddell: ah, yes that's a nice new addition
<heno> yep, I've tested scribus briefly. seems ok
<heno> I'll test it a bit more. It's a good candidate for theopencd as well
<Riddell> heno: also speedcrunch would be cool http://speedcrunch.digitalfanatics.org/download.html
<heno> Riddell: does it look as pretty as that icon now, or as ugly as it was in the past? ;)
<heno> I guess it has a rather small user group (but you decide)
<Riddell> heno: does which?
<heno> speedcrunch is rather plain looking, no?
<Riddell> heno: it's got a keypad now, which keeps the moaners quiet
<_ion> Does it support RPN?
<heno> Riddell: Right, I'll have a look. 
<heno> 3.8 MB is rather large for a calculator. Can these things be made to share the Qt libs in some way?
<heno> As gimp and gaim do with gtk
<Riddell> speedcrunch is qt 4, scribus is qt 3 so no
<heno> ah, ok
<heno> how is kexi and kde-pim, and hot new developments there?
<Riddell> oh yes, there might be a new version of kexi
<heno> or should I go with the same packages as before?
<heno> ok, cool. I'll look
<heno> ... kexi 2006 edition, released in march
<pitti> dholbach: tang{o,erine}-icon-theme approved, sorry for the delay
<pitti> doko: openoffice.org-en-au approved; however, I hesitate adding it to l-support-en, since it would blow up the CD
<pitti> mvo, jordi: ttf-lao approved for main; however, how should we handle that? will fontconfig etc. work well enough to include it into u-desktop? or should it become a l-support-lo dependency (ugly)?
<doko> pitti: ok
<mvo> pitti: it should work well enough for u-d, there are no common glyphs with other CJK fonts
<pitti> cool
<pitti> heno: xcursor-themes approved, so please seed it/depend on it/whatever is appropriate
<heno> pitti: great, thanks :)
<heno> Mithrandir: ^^ After testing the current CD I'll probably ask you to add xcursor-themes to the seed as well. I'll coordinate the config settings with Luke
<Mithrandir> sure
<Mithrandir> he will want to merge some changes I'm doing now first.
<ogra> Kamion, this fifo stuff seems to be a metter of luck, sometimes it works and sometimes the backgrounded process i try to read from just dies silently ... 
<ogra> *matter
<Lathiat> hrm, quagga
<Lathiat> has a question on prerm of medium priority which is "do you really want to stop quagga"
<Lathiat> which on ubuntu gets skipped, and causes prerm to fail
<Lathiat> would it be reasonable to bump that to high?
<Lathiat> breaks upgrading, for example
<Lathiat> (as it just did for me)
<infinity> If the prerm fails when the question is answered incorrectly, why does the question exist at all?
<Lathiat> infinity: the question is
<Lathiat> infinity: "do you relaly want to stop quagga"
<Lathiat> which is medium, and edefauls to false
<Lathiat> and is ignored so it just abortsd
<Lathiat> i assume in debian the default priority shows medium questions
<infinity> Yes, my point is that if there's only one correct answer, the question shouldn't be asked.
<Lathiat> i think the question is
<Lathiat> "i'm about to upgrade quagga"
<Lathiat> "if i stop it, you might lose connetivity"
<Lathiat> "you sure?"
<infinity> pcmcia-cs had a similar question, with equal irritation.
<infinity> See what that does now and follow suit.
<Lathiat> i mean, its a valid question, bu shoudlnt it be priority high?
<Lathiat> hrm
<infinity> My gut feeling would be to change the default answer.
<Lathiat> i'd be inclined otherwise
<Lathiat> to make it high?
<infinity> Most users just want to upgrade (and at that point have already downloaded packages)
<Lathiat> not tha ti have alot of experience in that area or on what others do
<ajmitch> most users wouldn't want to run quagga without really knowing what it does :)
<Lathiat> sure, but it might not be obvious why your dist-upgrade barfs halfway through
<Lathiat> hell it took me a few minues to figur eit out, and i had to dig aroudn the prerm file.
<Lathiat> infinity: it seems to lack the question entirely
<ajmitch> Lathiat: I'm not saying it should be kept broken
* Lathiat thinks that, a question, which if not answerre dbreaks the upgrade process, should be priority high, at least
<Lathiat> i guess whether or not to ask at all is another question
<maswan> heh, after a workalike to that xscreensaver vulnerability hit me in the late 90ies, I alwasy make sure to not have focus in any window when locking the screen. :)
<Diziet> Yay!  I finally managed to get firefox to start with a Spanish home page.  Now all I have to do is automate my fiddlings.
<sladen> Diziet: can you get it to replace the start-page URL with an empty URL too rather than file:///mucho-wankage
<Diziet> Err ?  You want it to start with a blank page ?
<lifeless> Diziet: I think he wants it to show the start page
<lifeless> Diziet: but not the url. 
<lifeless> so that users dont have to delete the url every-single-time-they-hit-ctrl-T
<Treenaks> replace about:blank with the intro pagE?
<Treenaks> scary :)t 
<Diziet> I'm definitely unconvinced by that as an idea.
<infinity> I'm fairly sure it's a simple XUL/JS one-liner to clear the address bar.
<infinity> The idea does have merit.
<Kamion> they don't have to put any effort into deleting the URL - just ctrl-L <type stuff>
<Kamion> or highlight the URL and type
<infinity> No one cares that they're looking at file:///usr/share/ubuntu-artwork/home/index.html, they care that they just started a browser and want to use it.
<infinity> (It makes the page feel more "built-in" that way)
<infinity> An empty address bar screams "type in my and see what happens!"
<infinity> s/my/me/
<Mithrandir> TheMuso: please merge my casper changes if you want to give me something to update from.
<infinity> It also resolves the "should a single click insert or hilight?" debate once and for all, I think, since the number one time a user wants to single-click-to-retype-the-url is when they start a fresh browser.
<infinity> If a fresh browser has nothing in the URL bar, problem solved. :)
<infinity> (For the record, I'm firmly on the "single click should insert" side of that debate)
<ploum> Is there a way to get the previous version of a package in Dapper ? I'm looking to the previous nvidia-glx one in order to track something. (if anyone has it in his /var/cache/apt/archives, I would appreciate)
<infinity> ploum: The 8178 driver, from lrm 2.6.15.7-4?
<ploum> infinity: yes, I guess it's that one
<infinity> ploum: Hang on a second.
<ploum> (I have a lot of freeze with nautilus and epiphany and I want to try if they are related to the driver)
<infinity> ploum: i386 or amd64?
<ploum> i386
<sladen> Diziet: yes.  intro-page (unless they have set their own start-page), but with empty URL bar and focus in the URL bar
<infinity> ploum: http://people.ubuntu.com/~adconrad/linux-restricted-modules-2.6.15_2.6.15.7-4/
<infinity> ploum: Be sure to downgrade all related packages (LRM and LRM-common as well), not just nvidia-glx.
<infinity> ploum: And reboot between tests.
<ploum> infinity: many thanks :-)
<ploum> I will do that
<freeflying-ibook> jdub: ping
<sladen> Diziet: I did look at it once.  It requires starting having that start page load with permission to talk to the chrome
<ploum> so, let's go for reboot.. (I hate that)
<ploum> cheers
<sladen> infinity: /proc/bus/pnp seems to have disappeared and the sysfs equivalent seems underpopulated.  what's a good way to 'lspnp' these days?
<bandini> mmh bug-buddy seems to segfault with today's update. anyone else seeing this? (crashes in md5_get_digest_from_file())
<seb128> that's not from today
<bandini> mmh ooutdated mirror of mine?
<bandini> 2.14.0-0ubuntu1, here
<janimo> infinity: any eta on xubuntu-live? thanks
<ogra> wow, fabbione, you made someone really happy in bug 3527 :)
<Ubugtu> Malone bug 3527 in Ubuntu Breezy "OpenGL screensaver freezes!!" [Normal,Rejected]  http://launchpad.net/bugs/3527
<dholbach> ogra: btw the new dia is in debian - it might only be a sync - just saw the upload mail, dunno how well it'd work for us
<ogra> i'll do a testbuild today and ask for the sync
<ogra> (in fact that was what i was hoping for)
<dholbach> rocknroll
<ogra> :)
<dholbach> seem it was the right day to sign up for debian-devel-changes :)
<ogra> hehe :)
<lifeless> ogra: gss is still bust for me
<lifeless> ogra: and when it goes bad, so does my metacity mouse-focus behaviour
<ogra> lifeless, with 2.14.1 ?
<lifeless> ogra: ah, no.
<lifeless> will try
<Diziet> Anyone here use es_ES, fi_FI, lt, pl_PL, ru_RU, sk, sv_SE, or zh_CN ?
<Diziet> And would you be willing to try an under-the-table m-f-l-* package for me ?
<Diziet> I've tried it myself of course and it seems to work but IWBN to test it in a `real' system.
<Diziet> OK, I'll try in #ubuntu.
<bddebian> How can I symlink dirs?  dh_link seems to fail on directories?
<Kinnison> according to the manpage it shouldn't
<Kinnison> the second example indicates a symlink of directories
<bddebian> I know but it does
<bddebian> fail that is
<seb128> maybe you don't use it correctly?
<bddebian> Gah, will guys quit fixing things, my dist-upgrades take forever.. :-)
<Kamion> bddebian: it won't work right if the target directory already exists
<bddebian> seb128: Probably not, that's why I'm asking
<bddebian> Kamion: Ahhh
<Kamion> i.e. it won't remove the target directory for you if something else already created it
<Kamion> such as make install or dh_install
<bddebian> Shite.
<Kamion> why so bad? it's usually easy to fix up paths in whatever's doing the installation
<bddebian> Hmm, can I wildcard it?  dh_link /foo/bar/* /bar/foo/* ?
<Kamion> no
<Kamion> just fix whatever's installing to the directory that you want to be a symlink
<Kamion> it should probably install to the target of the symlink instead
<seb128> speaking about link, I'm not sure but is there a bug 
<bddebian> Kamion: Well qgis's help path is hardcoded in the app for /usr/share/qgis/doc and Debian is installing in /usr/share/doc/qgis/
<seb128> if package n-1 has dir_name and package n makes it a symlink on other_dir_name
<seb128> does that work?
<azeem> bddebian: then that hardcoded path should be patched, IMHO
<Kamion> bddebian: change qgis' Makefile to install somewhere else, then
<bddebian> azeem: Agreed
<seb128> I think that's something known but I'm not sure
<Kamion> or mv and rmdir, whatever's needed
<bddebian> But it always comes bad to the question of how far to veer from Debian
<bddebian> Err s/bad/back/
<Chipzz> bddebian: given the rules of shell wildcard expansion, how *would* that work?
<azeem> bddebian: well, it looks like the right fix
<bddebian> Chipzz: It was just a question. :-)  I'm a little slow
<azeem> so submit the patch to Debian as well, maybe?
<ogra> mdz, the patch for fullscreen preview in g-s-s landed in g-s-s CVS today, if i could include it, that would make doko a happy man (we talked about it before and you said we'd have to wait if upstream accepts it)
<Chipzz> bddebian: ;)
<mdz> ogra: is the openGL visual problem fixed yet?  that is much more important
<bddebian> azeem: You Debian types ignore my patches.. ;-P
<azeem> whatever.
<bddebian> :-)
<ogra> mdz, nope
* bddebian hugs azeem
<ogra> (i know about its importance)
<bddebian> ack
<sladen> regarding #22045, I've also noticed that the openGL hacks aren't getting a z-buffer, so it's possible they're not getting double-buffered either
<ogra> mdz, i was hoping for the announced patch in that bug
<bddebian> whee
<ogra> else i could indeed need help with that one, i still have no machine where i could reproduce it
<mdz> ogra: announced patch?
<ogra> mdz, see the comment from Bart Hartgers in that bug
<mdz> ogra: many of us here in the channel can reproduce it
<ogra> "I might be able to help. I've a radeon 9200 in my desktop that has the same problem, and I am halfway done with a patch agains 2.14 to fix this on my system."
<mdz> that was a week ago
<mdz> ogra: I'm sure you can get an account on a machine you can use to reproduce the bug
<mdz> I can give you an account on mine, but it would probably be better with someone in a closer time zone so they could answer questions about the display if needed
<mdz> perhaps email Bart and ask if he can give you his incomplete work for you to use as a starting point
<mdz> anything but wait
<ogra> yep
<ogra> that was my plan, i wanted to give him some time since he volunteers
<mdz> there's no shame in asking for his code; you're offering to help him finish it
<ogra> yep
<mdz> ogra: also, was the xscreensaver patch for thin clients carried over to gnome-screensaver?
<mdz> or does it provide some other mechanism?
<ogra> its using gconf keys i was thinking about to just unset the key for the hacks ... 
<ogra> (g-s-s calls that throttling)
<mdz> how does it work?  does ldm set them on the ssh command line?
<ogra> but adding it to g-s-s is trivial (its a two line patch)
<mdz> oh, so that's currently broken?  is there a bug open?
<ogra> i'd set them from ltsp's postinst ... so we have a system setting and if the user insists to use hacks, he's still able to
<ogra> nope, i think you closed it ... it was the same bug i carried over ...
<ogra> its still on my TODO, so dont worry, wont get lost
<ogra> Mithrandir, did you set the RUNNING_UNDER_GDM env var from casper again (while we're at g-s-s)
<mdz> ogra: if I close a bug because it was fixed, and it has been unfixed without my knowledge, it is appropriate to correct me :-)
<ogra> mdz, ok, i'll reopen it (it were two bugs about the same issue in two packages and i have it on my list anyway)
<mdz> ogra: I didn't close it; it's bug #18595
<Ubugtu> Malone bug 18595 in xscreensaver "Needs to disable graphics-intensive modes for LTSP" [Normal,Unconfirmed]  http://launchpad.net/bugs/18595
<ogra> meh, right, but it indeed doesnt show up in the g-s-s buglist :)
<bddebian> Heya LaserJock
<ogra> (added)
<Riddell> Kamion: i18n working well in kde-espresso
<Riddell> Kamion: is there a way on the Ready label to not include "ubuntu"?  so it can be changed to Kubuntu?
<Riddell> and probably ogra will want his to say edubuntu somehow
<sladen> Riddell: could it be de-branded completely ?
<ogra> isnt that what espresso-ubuntu-artwork is for ? 
<Riddell> sladen: the string says "Ubuntu is now ready to install", that could be de-branded but it's not a bad string to have like that
<Riddell> of course I could just run s/Ub/Kub/ in the frontend easily enough
<Burgwork> Riddell, why not just say "Ready to install"?
<Burgwork> as branding in espresso is bad and should be avoided
<sladen> ogra: grep -rci opengl gnome-screensaver-*  = 0  does it actually do any  gdk_gl_ specific calls, or leave that to the hacks?
<Riddell> Burgwork: that could well be the best way, although it does seem quite nice to know what you're installing
<Burgwork> Riddell, you already do - Ubuntu
<Riddell> Burgwork: I'm not installing ubuntu, that's the point :)
<Burgwork> if an Ubuntu live cd installs Fedora, I would concerned
<sladen> Riddell: the image in the background, the desktop, the front of the CD, and the CD sleave should give you a good hint
<Riddell> I'm not against the idea, I just follow Kamion, poke him
<sladen> anything that is shipped with 'Ubuntu' in the name is unattractive for other derivers
<Burgwork> sladen, I am fairly certain this is a simple mistake, as Kamion is pretty busy and probably just missed it
<ogra> sladen, it sadly leaves it to the hacks, which is wrong, since you cant force the hacks visual in --root mode
<ogra> xss just selects the visuall according to what xscreensaver-gl-helper gives it
<ogra> and sets it in the daemon
<Kamion> Riddell: the "ready" label was awkward, I couldn't come up with a good phrasing that excluded Ubuntu
<Kamion> suggestions welcome
<Kamion> you can't do s/Ub/Kub/ as not all translations will include "Ub"
<Burgwork> "Finish Install"
<Kamion> the sentence needs to be rephrased from the current "Ubuntu is ready to install on this computer."
<Kamion> Burgwork: not a heading
<Burgwork> ah
<Kamion> the heading is "Ready to install"
<Burgwork> "You are now ready to complete the installation"
<Burgwork> ?
<Kamion> sounds clunky, I'm afraid
<sladen> or  Complete Installation.
<Kamion> to me anyway
<Burgwork> yes
<ogra> s/Ubuntu/The System/ ?
<Kamion> sladen: that's a heading, not appropriate
<Kamion> ogra: ugh
<Kamion> the system is ready to install onto your computer machine thing noun.
<Kamion> "system" works elsewhere, but not there, IMHO
<ogra> heh
<Kamion> the welcome label needs to be rephrased too
<Kamion>  Ready to install? Once you answer a few questions, Ubuntu can be installed
<Kamion>  on this computer so you can run the system at full speed and without the
<ogra> probably "I am" ?
<Kamion>  CD.
<ogra> has a personal note
<Kamion> ogra: I'm avoiding anthropomorphisation
<Kamion> doesn't sound right in espresso
<sladen> ogra: xscreensaver-gl-helper is only a separate binary to avoid linking xss against libGL.   gdk_gl_query() && gtk_gl_area_new([GDK_GL_RGBA, GDK_GL_DOUBLEBUFFER, GDK_GL_DEPTH_SIZE, 1, GDK_GL_NONE] );   should do what's needed.  (or abuse glXChooseVisual() directly on the root window)
<janimo> Kamion, for xubuntu art in the gfx boot will a .pcx file suffice?
<janimo> if so how do you prefer it? bug against d-i, personal mail etc
<ogra> sladen, thanks !
<Kamion> janimo: just point me to a usplash image and I can do the conversion
<Kamion> janimo: bug against debian-cd
<janimo> Kamion, oh cool. xubuntu-artwork has the usplash
<janimo> that's the source package
<Kamion> ok, file me a bug and I'll try to look at it tomorrow
<janimo> ok, thanks
<sivang> re all
* sivang gets back to HUBing
<mdz> Kamion: is the lack of an initrd.list in the archive a d-i problem or a soyuz problem?
<jordi> pitti: thanksf or ttf-lao
<Kamion> mdz: it's called udeb.list now, in line with changes made in Debian to help the archive track which sources it needs to keep around for GPL requirements; might have slightly different contents
<Kamion> it's a directory or two up, too
<mdz> thanks
<ogra> oh fun, libgtkgl2.0-dev is indeed in universe ...
<ogra> ergh, but gtkglarea5-dev (gtk 1.2) is in main ????
<wasabi_> http://www.amazon.com/exec/obidos/ASIN/032142722X/desktoplinuxa-20/104-8693816-3330301   <--- nice
<Burgwork> wasabi_, http://www.amazon.com/gp/product/0132435942/ref=pd_sxp_elt_l1/002-9576091-6069611?n=283155 <-- better ;)
<ogra> pitti, ^^^ didnt you clean up the gtk 1.2 mess already ? 
<pitti> ogra: ~ 7 packages still b-dep on it
<_mvo_> "foreword by Mark Shuttleworth"
<ogra> meh
<pitti> ogra: it's still on my wishlist to clean that up, but it's work
<wasabi_> mvo, grab latest GAptI. 
<wasabi_> When you get a chance. ;)
<ogra> i might need libgtkgl2.0-dev for g-s-s :/
<mdz> yay, awty unbroken now
<Burgwork> _mvo_, I might be a little biased of course...
<pitti> mdz: what does that tool do?
<_mvo_> Burgwork: sure ;)
<mdz> pitti: reports the versions of packages in many places, from the archive to the CDs
<_mvo_> wasabi_: pulling
<mdz> so we can see when a new version is propagated
<pitti> ah
<wasabi_> mvo, it's pretty much all implemented and works. Some parts are a bit hacky, because I need to find proper ways to do it.
<wasabi_> I also need a little better tie between gapti and synaptic for installation.
<_mvo_> wasabi_: anything you need in synaptic for this?
<pitti> mdz: it sounds like a tool that collects build failure states, anastacia inconsistencies, etc. and print a summary report :)
<mdz> Kinnison: is the drescher archive exported via http anywhere?
<wasabi_> Yeah. I'd like a way to add a key to apt-key, with the proper confirmation dialog.
<mdz> pitti: it can grow ;-)
<wasabi_> Right now I'm using some of your code in gnome-software-properties.
<mvo> wasabi_: you send a mail/bug-report for this, right?
<wasabi_> the apt_key class in dialog_apt_key.py
<wasabi_> Yeah.
<sivang> Burgwork: I'm honnored to know you :)
<mvo> wasabi_:  ok, I'll have a look. loads of stuff going on currently, sorry for the lag
<wasabi_> I was also considering writing my own package installation dialog for it, like update-manager. I would like to talk with you 1on1 about it though.
<wasabi_> Since it might actually fit into Synaptic.
<wasabi_> I don't just want to initiate an install for whatever packages are listed. Would rather have a screen so the user can see what is going to be installed, and not just as "raw" as synaptic.
<mvo> wasabi_: update-manager is using synaptic as backend, the dist-upgrader is independent 
<mvo> wasabi_: if you want your own (based on apt.InstallProgress/FetchProgress) we should probably move it into python-apt or python-apt-gtk or something like this
* pitti yays at cups 1.2rc2 - the spooler, authentication, etc. finally works fine :) of course it doesn't print, but who needs that anyway...
<wasabi_> Something akin to how OS X and windows installers are.   It shows a list of what will be installed, top leve items, like "Photoshop", and then under that has conditionals that you can choose like "Extra Brushes"... see wha tI mean? Those are recognized as Suggests and Recommends.
<wasabi_> But the interface needs to be a bit better at conveying the idea.
<wasabi_> And not inunduating the user with tons of things like package-common package-base, package-foo, libfoo, libbar, etc.
<sivang> pitti: hehe
<sivang> pitti: yes, paper is going to deprecated in not time anywyas
<pitti> sivang: still, rc1 was a real mess, as were previous snapshots; so I'm hopeful again
<mvo> wasabi_: right. if it's only about installing that shouldn't be a problem
<wasabi_> It's something which we could benefit from in synaptic primem but which makes a real lot of sense when real users start clicking on .apt files.
<wasabi_> I'm going to put together at least a little UI mockup for it.
* mvo looks up primem
<mvo> wasabi_: cool, thanks!
<wasabi_> Anyways, gapti actually works. Adds the key, etc.
<wasabi_> Installs the packages.
<wasabi_> Not sure ow to tell the browser it's allowed to open the file yet, though. ;0
<Mithrandir> ogra: running_under_gdm has always been set.
<ogra> uuh, really 
<ogra> thats odd, then something in g-s-s is wrong
<wasabi_> Obviously it's not set in stone yet. I think I'm going to change the .apt file format... and want some other input on that.
<wasabi_> Instead of having PublicKey, require the entire file to be cleartext signed by the key.
<wasabi_> That way the file must originate from the same source whose archives are being added.
<mvo> right, that sounds sensible
<Riddell> pitti: will you be able to review kmplayer and knetworkmanager for main inclusion before beta freeze?
<wasabi_> Also, I want to talk about this in a better forum. For the entire idea to succeed, there has to be some marketing push behind it.
<pitti> Riddell: yes, will process the list in the next days
<wasabi_> We want ISVs to actually support it, and publish their software with it.
<pitti> Riddell: kmplayer sounds suspicious :) is it *that* mplayer/
<pitti> ?
<Riddell> pitti: we use the xine plugin
<pitti> ah
<Riddell> and don't even build the mplayer one as I remember
<jordi> Riddell: any news about that pot?
<Riddell> jordi: which one?  katapult?
<jordi> yah
<Riddell> jordi: no response from mez yet, I'll send him another e-mail
<bddebian> Uhm, interesting new background :-)
<Riddell> bddebian: where?
<jordi> ok
<bddebian> Riddell: Gnome 
<pitti> wow, cups prints!!!
<netstar> It seems the r200_dri.so is not bundled with Dapper
<Mithrandir> I'd be more surprised if cups was scanning.
<pitti> Mithrandir: after all the mess and failures I have seen in the last weeks, this is a miracle, really!
* mvo giggles
* Chipzz pokes mvo ;)
* mvo send Chipzz a private msg but suspects that freenode ate it
<Chipzz> arf!
<Chipzz> 20:33 -NickServ(NickServ@services.)- You have already identified
<Chipzz> ?
<netstar> how can I search all packages in repositories for a file name?
<mvo> Kamion: re launchpad bug #36022, I understand that we work-around the problem for now?
<Ubugtu> Malone bug 36022 in launchpad-upload-and-queue "change-override can't handle pockets" [Major,Confirmed]  http://launchpad.net/bugs/36022
<sivang> indeed interesting background
<lucas> I've got a problem with librmagick-ruby. There are several bugs which would justify an update for breezy.
<lucas> I initially asked mdz and Kamion about an upload through breezy-updates. I was asked to contact the breezy-backports team instead. I did, and after a long delay, I'm told that packages in breezy-backports must be backported without modifying the dapper source.
<lucas> this is not possible with librmagick-ruby.
<lucas> what should I do ?
<mdz> lucas: why do you feel that it is impossible?
<mdz> lucas: it is acceptable to modify the package in dapper to allow it to build correctly on breezy as well
<lucas> because, for example, there's a build-dep on debhelper >= 5
<lucas> I don't understand why breezy-backports packages should be built using dapper sources
<tseng> because it would be a mess to have specific breezy-backports sources
<lucas> ok. I'm tired of those librmagick-ruby issues. What should I do : mark the bugs as rejected, or leave them open, hoping that somebody will fix them someday ?
<pitti> lucas: these bugs aren't fixed in dapper?
<lucas> they are
<lucas> they are Fix Released for Dapper, but still open in breezy
<Burgwork> infinity, do you enjoy doing janitor work as other people play in the sandbox? :)
<mdke> who knows what the "P" stands for in the ubuntu-server "Install a LAMP server" option?
<tseng> mdke: thats a trick question
<sivang> mdke: python probably :)
<tseng> mdke: it stands for php/perl/python, take your pick.
<mdke> tseng, I've written: to install a LAMP server (Linux, Apache, MySQL, PHP/Perl/Python), select blah
<mdke> oh good
<mdke> thanks
<tseng> i am not sure that it installs all those, though
<sivang> mdke: we hae something like that in ubuntu server?
<tseng> is there a meta package?
* mdke pats wikipedia
<mdke> tseng, I'm not sure... there is an option in the boot screen, it seems: http://www.flickr.com/photos/jsgotangco/126410755/
<tseng> oh
<tseng> is that something he has made custom?
<tseng> i havent seen that.
<tseng> the official server cd installs ubuntu-minimal and ubuntu-server, not lamp out of the box last I saw
<mdz> pitti,Kamion: would it make sense to consider Malone for UbuntuMainInclusionQueue, or do you prefer the wiki workflow?
<mdke> tseng, I think that's a screenshot from flight 6
<mdke> (of the server cd)
<janimo> mdz, hi. I can answer your mail in detail tomorrow
<mdz> janimo: ok, thanks
<luopio> hi all. I was hired to develop a live-cd for the IOI (International Olympiad in Informatics). The current live cd uses Morphix, but I'm leaning toward switching to Ubuntu. I'd be interested to hear how stable 6.06 live cd is. Any experiences?
<bluefoxicy> "The kernel freeze is a deadline for kernel updates, since they require several lockstep actions which must be folded into the CD building process."
<Tm_T> luopio: toimii
<bluefoxicy> Someone explain to me why exactly this can't be automated
<Tm_T> luopio: I mean. works, though this is wrong channel for that kind of questions
<luopio> Tm_T: mutta kauanko? :)
<tseng> bluefoxicy: because its a waste of time to solve something in software when you don't have to
<Tm_T> luopio: see you in #ubuntu-fi, ok?
<luopio> Tm_T: ok
<Tm_T> thanks
<bluefoxicy> tseng:  so as opposed to changing the kernel package, you have to...?   Change the kernel package, alter scripts to copy vmlinuz-{version}{thing}-01, change the location of modules hard-coded into a script...?
<tseng> uh, what
<bluefoxicy> tseng:  I just don't understand the problem at all, perhaps you could explain what it takes to build a CD besides picking packages and running a build script
<bluefoxicy> is there an #ubuntu-mkcd or such?
<tseng> exactly that, but you dont just change core packages like the kernel in the middle of the process
<tseng> "lockstep actions" include having a matching version of linux-restricted-modules
<bluefoxicy> I would assume you would do something like drop in a new kernel core package, rebuild the CD, burn/qemu, test, and then nod and smile when it works
<bluefoxicy> ah
<tseng> which can sometimes lag by days
<tseng> and would give you a broken cd image
<bluefoxicy> yes I've seen that
<tseng> and the testing process for flight cds is a litle more involved
<tseng> including installs and livecd tests on at least 3 archs
<bluefoxicy> however I'm assuming that you don't release kernel-x without -restricted-modules-x
<tseng> you assumed wrong
<bluefoxicy> ah
<tseng> rolling a flight release is a big production.
<ogra> the kernel is also part of the installer and bootprocess of the CD ... that needs manual intervention
<Mithrandir> tseng: for each of ubuntu, kubuntu, edubuntu and now xubuntu, yes.  So it's a large amount of testing.
<tseng> Mithrandir: indeed.
<bluefoxicy> this isn't fairly distributed between devs?
<bluefoxicy> I would think for each project there's a dev sitting around who can test it
<bluefoxicy> as opposed to one guy in his basement with 60 hot pockets rabidly changing CDs between 5 machines and 2 qemu installs
<tseng> there are about 30 "core dev" folks atm
<ogra> you still have to download the isos, burn them and install them before testing
<Mithrandir> bluefoxicy: sure, it'd be ideal if we had an army of testers who jumped at every opportunity to test a new fresh image.  Unfortunately we don't.
<tseng> only a handful are responsible for release management
<bluefoxicy> ah
<ogra> edubuntu are 6 CDs i have to sync ... if i discover something critical i can rebuild the whole set and start over 
<Mithrandir> bluefoxicy: it's also that we don't want to have to stop development for a day or two every second week because we're releasing a flight.  Just freezing the archive slows us down enough.
<ogra> testing flights is very time consuming ...
<bluefoxicy> so one more question
<bluefoxicy> kernel freeze is may 18, 2.6.16 is out, 2.6.17 is in RC1 so it probably won't be out by next month, unless tehy release before RC9 this time
<bluefoxicy> (what was Linus' record, RC14?)
<Mithrandir> our 2.6.15 is probably fairly close to 2.6.16.
<bluefoxicy> is it likely we will see 2.6.16 in Dapper, or is it more probable that we're sticking with .15 + bug fixes?
<bluefoxicy> probably
<tseng> .15 is a sure bet
<ogra> .15
<bluefoxicy> alright
<tseng> if you have a bug solved in a later release, file it now
<tseng> get it backported
<bluefoxicy> I don't, I am more trying to find a bug solved and don't know if it is even relavent.  The LKML totally ignored the message I posted asking.
<tseng> well
<tseng> I have some ideas why :)
<bluefoxicy> that would, btw, be that the via DRM driver in the kernel causes hard freezes
<bluefoxicy> when i boot X using driver 'via' I pretty much die on screen savers :/
<bluefoxicy> if I look in time, dmesg starts piling up with oopses on various things, once in a while there's a NULL pointer deref in kernel space, etc.
<bluefoxicy> I have no idea if it's fixed in a newer release, maybe I should build a 2.6.17 some time and see.
<bluefoxicy> it's a mix between plain laziness, and not wanting to test something that's going to crash my production PC, which I hate shutting down anyway
<crimsun> (you're already running dapper on your production...)
<bluefoxicy> but either way, it otherwise works
<ogra> crimsun, shhh
<bluefoxicy> crimsun:  yes, witth visible effects
<bluefoxicy> (rhythmbox:16578): GStreamer-CRITICAL **: gst_pad_push: assertion `GST_IS_PAD (pad)' failed
<bluefoxicy> Segmentation fault
<bluefoxicy> That being a recurrant one :)
<bluefoxicy> crimsun:  my strategy is pretty much, "If it breaks, I find a work-around to keep the system alive until they fix it, and file a bug."
<bluefoxicy> at least I'm contributing something ;)
<dieman> wow
<bluefoxicy> at any rate, no chance of 2.6.16+ in dapper, not a big deal.  I was just curious.
<dieman> tetex-bin paper size bugs are 6 years old in debian
<bluefoxicy> tseng:  what I'm hoping for is Dapper+1 having the network authentication stuff.  Fedora and RHEL already have a nice quick set-up interface for that on first boot, just check off LDAP and configure it.
* bluefoxicy <3 where ubuntu is going :)
<bluefoxicy> of course they also have rpm rollbacks, which is important too.  deb rollbacks would be great, install a broken package, roll it back to a working one.  That's an important feature for enterprise data centers.
<Mithrandir> it'd be really sweet to have a proper AD killer.
<bluefoxicy> Mithrandir:  you can set up roaming profiles on LDAP, what else does AD do?
<Mithrandir> central handling of user accounts, both the user info and the password part.
<bluefoxicy> yes
<bluefoxicy> ldap does that
<Mithrandir> it also gives you nice things like two-way authentication of services.
<Mithrandir> single-sign-on.
<wasabi_> I've been having some probs with restricted-modules.
<bluefoxicy> what we need is a UI to configure OpenLDAP and administrate it (Directory Administrator is nice... but something closer to our current utils would be good)
<wasabi_> Not running depmod properly.
<bluefoxicy> A configuration util for OLDAP is non-existent
<Mithrandir> bluefoxicy: you shouldn't have your passwords in ldap.
<wasabi_> Havne't been able to pinpoint the problem, beacuse running depmod fixes it. ;0
<bluefoxicy> we'd need something to set up the server, initialize the things for storing passwords and accounts in MD5, import or generate an openssl X.509 cert, set up TLS...
<wasabi_> bluefoxicy: I've written a large wiki article describing such a utility.
<wasabi_> And how it would fit into the entire lifecycle.
<wasabi_> what was it called. one sec.
<wasabi_> https://wiki.ubuntu.com/DomainAuthenticationUtility
<wasabi_> Basically it just becomes a meta model around a few pieces of knowledge: domain name, computer account, etc.
<pitti> mdz: I don't have a problem with the wiki, it's fast to handle; you think about handling reports like specs?
<mdz> pitti: just a thought; since you two are most directly involved, do what works best for you
<mdz> the sync processing in malone seems to be working very smoothly
<dieman> wasabi_: oo
<dieman> wasabi_: very interesting
<wasabi_> THe individual pieces should really be fixed before we move on though.
<dieman> yeah
<dieman> i just skimmed it
<wasabi_> libnss_ldap should discover it's info from DNS properly, which it doesn't.
<wasabi_> libpam-krb5 barely functions.
<dieman> we're actually still a nis shop here
<dieman> heh
<wasabi_> Doesn't create keys right.
<wasabi_> Need a daemon per-user and per-machine that keeps cache updated
<wasabi_> needs a daemon per machine that changes password on a schedule.
<wasabi_> Needs something to keep /etc/krb5.keytab uptodate with all of that.
<wasabi_> libnss_ldap needs to fall back properly to a slave LDAP server.
<wasabi_> it finds one from DNS< but it if fails it doesn't look again.
<bluefoxicy> Mithrandir:  why sohuldn't passwords be in ldap
<wasabi_> Nothing wrong with storing passwords in LDAP imo... Just shouldn't use LDAP for actual auth. ;0
<wasabi_> krb5 is there. ;)
<bluefoxicy> wasabi_:  ldap over TLS
<wasabi_> Not much need for that with krb5.
<wasabi_> Which provides channel encryption on it's own.
<bluefoxicy> KRB5 does what
<wasabi_> kerberos
<bluefoxicy> I know
<bluefoxicy> TLS does certificated authentication with X.509 certificates verifiable against a certificate authority
<wasabi_> Ticket based auth. It's what AD uses.
<bluefoxicy> ticket based auth?
<wasabi_> A user logs in by asking kerberos to send them a ticket.
<wasabi_> They use that ticket to access subsequent services, without being reasked for password.
<bluefoxicy> ah
<wasabi_> single sign-on, etc.
<bluefoxicy> you could LDAP with KRB5 as a backend
<wasabi_> For instance, reading the user list from LDAP should be a privledged operation.
<bluefoxicy> err.
<bluefoxicy> other way
<bluefoxicy> KRB5 with LDAP as a backend
<wasabi_> Sure, but mit krb5 doesn't do that well, and heimdal only does that with samba built extensions.
<Mithrandir> wasabi_: uh, how can that be a priviledged operation?
<bluefoxicy> so security wise they're equivalent, but functionality wise KRB5 allows for single sign-on?
<wasabi_> Mithrandir: You log onto your system with a kerberos password and get a ticket. 
<wasabi_> You use that ticket to list users later.
<wasabi_> LDAP shouldn't allow non-ticketed connections, ideally.
<wasabi_> in AD it doesn't, etc.
<Mithrandir> wasabi_: stuff run from cron needs to be able to see who owns a file too.
<wasabi_> Stuff run from cron should have a keytab.
<wasabi_> as it does in windows.
<bluefoxicy> Mithrandir:  easily, you remove NULL BASE dn listing, turn off anonymous LDAP, and set up each authenticating system to use a privileged cd,dn + password to access the data needed to authenticate?
<wasabi_> Each machine in AD has a network user account. When the machine boots it logs in, just like a user.
<wasabi_> And uses that account for network access.
<bluefoxicy> Mithrandir:  Or just put krb5 in front of ldap, either or.
<wasabi_> It also changes it's own password randomlly, etc.
<bluefoxicy> wasabi_:  does krb5 allow other information to be stored, as ldap does?
<wasabi_> cron jobs that run as root should be able to access LDAP using the computer account.
<wasabi_> No.
<Mithrandir> bluefoxicy: congratulations, you just broke ls -l if your network is down. :-P
<wasabi_> Mithrandir: more underlying stuff that needs to be fixed.
<bluefoxicy> wasabi_:  public keys, roaming profiles..?
<wasabi_> Mithrandir: need a client cache in front of NSS.
<wasabi_> Or behind it. ;)
<Mithrandir> uh, what information is it that you store in ldap which is secret?
<bluefoxicy> Mithrandir:  if you're already logged in ls should work o.o
<wasabi_> nscd, if it didn't suck horribly, would be it.
<bluefoxicy> Mithrandir:  user names are secret.
<wasabi_> Mithrandir: the user's themselves.
<wasabi_> A random computer sitting on my network should not be able to access that.
<bluefoxicy> Mithrandir:  haven't you noticed using a bad user or password gives "bad username or password"?
<Mithrandir> bluefoxicy: no, they're not.  User names are usually trivially discoverable.
<bluefoxicy> not "That user doesn't exist" or "bad password"?
<wasabi_> Mithrandir: Might also be a requirement of corporate/gov policy.
<bluefoxicy> Mithrandir:  yeah, by hitting www.foo.com/~user with various users
<wasabi_> Mithrandir: for example, AD doesn't allow non kerberos authetnicated connections, by default.
<wasabi_> So somebody can't walk in with a laptop and access the user list.
<wasabi_> They actually have to hack something.
<Mithrandir> wasabi_: that doesn't say anything about why being able to list the users on a system which you have authenticated to is bad.
<wasabi_> It's not. I didn't say that.
<wasabi_> If you've authenticated, you can list the users.
<wasabi_> But you must be authenticated.
<bluefoxicy> Mithrandir:  being able to list users on a system you don't have access to.
<wasabi_> being able to walk onto the company premisis and plugin a laptop and access the company user list is bad.
<bluefoxicy> Mithrandir:  I want to hack Accounting, I'm pretty sure Larry's password is something about his dog spot, probably spotty1 or such
<wasabi_> That's all.
<wasabi_> Some privacy laws even protect against it.
<bluefoxicy> Mithrandir:  Either A) I don't work for the firm; or B) I can get the users for my area, but not for the accounting network, which stores its data in a separate privilege area.
<bluefoxicy> Mithrandir:  So I have to guess what Larry's accounti s first, blindly.
<wasabi_> too many cooks.
<bluefoxicy> Or, I just dump a list of users, notice lwall06, figure out this is Larry, and try 2 attempts and get in.
<wasabi_> Blue, that doesn't matter. You need to be doing so from a company system.
<lamont> pitti: ping
<wasabi_> It needs to be auditable.
* Mithrandir shrugs; user names are not passwords.  Don't treat them like they are.
<wasabi_> Mithrandir: they aren't, but they are secret.
<wasabi_> Mithrandir: ie you shouldn't be able to get a big list of user names unless you're allowed to.
<bluefoxicy> confidential, perhaps not secret.
<wasabi_> Sure.
<wasabi_> Also it needs to be auditable. The LDAP server needs to be able to record what human being requested the list, so they can be investigated.
<bluefoxicy> wasabi_:  I do not understand how kerberos auth is supposed to work, though.  Where is the ticket stored?
<wasabi_> bluefoxicy: local machine.
<bluefoxicy> wasabi I  mean Icould set up krb5 here right? I have an ldap server behind me
<wasabi_> Yup.
<bluefoxicy> and I could rig pam to use krb5 auth right?
<wasabi_> I have it set up at home, because I do this a lot.
<bluefoxicy> but what would that get me
<wasabi_> All my computers, laptops included, use pam_krb5 and libnss.
<bluefoxicy> besides pam logging in with krb5 auth?
<wasabi_> Get you?
<bluefoxicy> I could try to modify stuff in the ldap directory
<bluefoxicy> and it would probably not run to pam and say "You have a ticket right?  Lemme use it"
<wasabi_> My needs are a) to test it, because I deploy it in companies. I need to know it works. b) single sign on.
<bluefoxicy> explain single sign on
<Mithrandir> hmm, I wonder if you could write a dhcp extension to tell the computer about its kerberos domain and such.
<Mithrandir> or if somebody has already done that.
<wasabi_> bluefoxicy: I log into my computer once, open my email client, and read my email. Then I browse to a corporate web page, and it says Hello Jerry.
<wasabi_> Neither the email client nor the web page has a stored password.
<bluefoxicy> wasabi I mean the underlying mechanics
<bluefoxicy> I am sure if I log into my mail client it will be like "what?"
<wasabi_> Evolution supports kerberos auth to IMAP.
<wasabi_> Mozilla doesn't yet.
<bluefoxicy> thunderbird doesn't though?
<wasabi_> IE and Outlook both do.
<wasabi_> I doubt it.
<Chipzz> Mithrandir: not necessary
* bluefoxicy has all his mail in thunderbird, doesn't really want to migrate to evo
<Chipzz> Mithrandir: kerberos can do realm discovery via dns
<wasabi_> Mithrandir: In AD the machine has two pieces of info. It's domain name and it's machine name.
<wasabi_> It uses the domain name to do service discovery in DNS.
<wasabi_> And it's machine name to login.
<wasabi_> Oh and it has a machine password. ;)
<wasabi_> Which is basically random and very long.
<bluefoxicy> wasabi_:  so the target service or PHP script has to have krb5 authentication built-in?
* mvo goes to bed
<wasabi_> bluefoxicy: Yup. IIS supports it. Most internal windows apps are built that way.
<Mithrandir> wasabi_: you don't need to try to teach me how kerberos works.
* ogra really wonders what he should do with bug 38893 apart from printing and framing probably ...
<Ubugtu> Malone bug 38893 in gnome-screensaver "Screensaver Still NOT Working!! CRASH INSTANTLY!!" [Normal,Unconfirmed]  http://launchpad.net/bugs/38893
<bluefoxicy> wasabi_:  mind, I don't quite get how to do krb5 over a web browser :)
<wasabi_> Mithrandir: Well, you were asking for a DHCP extension thing... which is covered by those two.
<torkel> bluefoxicy: google SPNEGO
<wasabi_> bluefoxicy: SPENGO WWW-Authenticate header. MS invented it. Firefox implemented it.
<wasabi_> SPNEGO I mean.
<Mithrandir> bluefoxicy: you use another authentication mechanismn than the regular basic authentication.
<bluefoxicy> sweet.
<wasabi_> Firefox's implementation doesn't read from the ticket cache though.
<wasabi_> At least last I checked.
<Mithrandir> huh?  It sure does when I tested it a year ago.
<Mithrandir> or rather, did.
<bluefoxicy> wasabi_:  and krb5 can be used as an authenticaton server to IPSEC, TLS, and PPTP (fuck PPTP) authenticators?
<wasabi_> Really? It asks me for my username and password.
<wasabi_> It uses kerberos, but it still asks.
<wasabi_> Thought it was a bit silly. ;0
<wasabi_> bluefoxicy: yeah.
<wasabi_> Err, wait, no.
<wasabi_> PPTP sure. :0
<bluefoxicy> oh
<bluefoxicy> shit.
<bluefoxicy> hmm.
<wasabi_> AD also has services which auto generate certificates for each user.
<LaserJock> Who decides the name of Dapper+1? sabdfl, TB, CC ?
<bluefoxicy> LDAP will work for IPSEC and TLS?
<wasabi_> For various purposes.
<Mithrandir> bluefoxicy: pptp and ipsec both work on a host level, not on a user level, so it's slightly muddy when you try to do that.
<wasabi_> LDAP doesn't work for it. LDAP stores the certs.
<wasabi_> yeah and also that. MS figured it out though, mostly it's a hack.
<sabdfl> LaserJock: me, with some help
<mdke> LaserJock, some say that the name comes in a dream
<bluefoxicy> wasabi_:  I am trying to find the best way to implement a network authentication system over here so I can help small businesses get their IT shops started for a small fee ;)
<wasabi_> Cool.
<wasabi_> I still use AD.
<LaserJock> sabdfl: is there a name yet? I'm working on some shipped documentation (Ubuntu Packaging Guide) and since people should be packaging for Dapper+1 when they install Dapper (for the most part) it would be good if I could include the name
<wasabi_> The pieces just aren't there to compare yet.
<wasabi_> I mena, the pieces are, but nothing tying them together in any way usable by most small shop IT admins.
<sabdfl> LaserJock: there's a proposal, not yet confirmed or announcd
<bluefoxicy> wasabi_:  I'm thinking all open source with OSX and Windows able to use it for auth/roaming profiles
<sabdfl> i expect it will be out tihs week or next
<wasabi_> bluefoxicy: Windows cannot auth against non-Windows kerberos.
<wasabi_> bluefoxicy: Samba guys are working hard on it, but not yet.
<bluefoxicy> wasabi_:  red hat active directory server?
<wasabi_> There's code where it works, but it's not released.
<mdke> dholbach, y0
<wasabi_> Red Hat Directory Server, not Active.
<wasabi_> It's just LDAP.
<dholbach> mdke: hm? :)
<wasabi_> Windows requires the machine kerberos tickets to have a special piece of data in them called the PAC.
<wasabi_> Which contains group membership and SID values.
<LaserJock> sabdfl: ok thanks, will look forward to the announcement and try to make the necessary changes
<mdke> dholbach, just branched ubuntu-docs to repos/branches/dapper
<ogra> LaserJock, i think that justifies a string freeze exception :)
<dholbach> mdke: ok, cool - good to know
<wasabi_> They've sort of made it hard to implement with licensing restrictions.
<Kamion> mdz: hmm, I think I'm happy with the wiki workflow for now for main inclusion
<mdke> dholbach, I'm now busy rampaging through the source package to make it 1/10 of the size
<pitti> lamont: pong
<LaserJock> ogra: heck yeah! We love exceptions
<mdke> dholbach, can you do an upload tomorrow?
<dholbach> mdke: yeah, can do that
<mdke> danke
<dholbach> good night guys
<mdke> night
<mdz> night dholbach
<bddebian> Gnight dholbach
<Kamion> bluefoxicy: changing the kernel ABI is a lot easier now than it used to be, now that we've got it down to a fairly fine art; it's four uploads distributed across about three people, plus a seed change which I normally do
<dholbach> night mdke, mdz, bddebian :)
<Kamion> bluefoxicy: but that doesn't mean that we shouldn't be conservative about changing such a core part of our system just before a release
<Kamion> bluefoxicy: the CD build process itself is entirely automated; what goes into it is not necessarily
<bddebian> I've broken 11,000 just uploading .desktop files.  How lame :-)
<bluefoxicy> Kamion:  of course, you want a wide testing buffer before changing the kernel out.
<bddebian> Whoops, sorry, wrong window
<bluefoxicy> Kamion:  Just I'd rather the wiki reflect reality, and not made-up excuses :)
<tseng> < bluefoxicy> Kamion:  Just I'd rather the wiki reflect reality, and not  made-up excuses :)
<tseng> erg stupid mouse
<tseng>  /topic amature hour in #u-d
<bluefoxicy> haha
<bluefoxicy> tseng he just said it was fairly easy, the wiki says it's massively complicated
<bluefoxicy> but whatever 
<bluefoxicy> wasabi_:  so the next krb release from samba should auth windows?
<tseng> fairly easy is relative
<wasabi_> No. Samba doesn't release krb.
<bluefoxicy> oh
<wasabi_> They are working with Heimdal though.
<bluefoxicy> you just said ... ah.
* bluefoxicy has not done this :>
<wasabi_> Either way, kerberos is just one part of authing with windows.
<wasabi_> You really lose a lot of windows features when not using AD.
<wasabi_> Enough to make AD worth it.
<bluefoxicy> there isn't an AD server on linux though :(
<wasabi_> Now, integrating AD into a Unix domain. That has promise.
<wasabi_> ie so you can share kerberos keys and LDAP.
<tseng> wasabi_: what is a "unix domain"
<wasabi_> But windows systems still use AD abilities.
<wasabi_> tseng: a mad up term for what we're talking about
<wasabi_> made
<seb128> Keybuk, Diziet: around?
<Keybuk> I'm around
<bluefoxicy> wasabi_:  I would rather be able to build a full open source solution but have it flexible enough to add Windows and OSX later.
<Keybuk> what's up?
<wasabi_> bluefoxicy: Then start coding for Samba.
<seb128> Keybuk: 
<wasabi_> There are massive amounts of work to be done still.
<seb128> <seb128> epiphany-browser 2.14.0 ships a /usr/share/gnome/help/epiphany-browser folder
<seb128> <seb128> epiphany-browser 2.14.1 ships a /usr/share/gnome/help/epiphany folder and a /usr/share/gnome/help/epiphany-browser symlink to
<seb128> <seb128> to it
<seb128> <seb128> after upgrade /usr/share/gnome/help/epiphany-browser is an empty folder, not a symlink :/
<seb128> <seb128> that's a "classic" one, no?
<Keybuk> yup
<Keybuk> classic dpkg
<seb128> k
<bluefoxicy> wasabi_:  what else does AD do?  Application servering?
<seb128> what is the usual way to workaround it? :)
<Keybuk> can't replace a directory with a symlink
<Keybuk> fix it in postinst
<wasabi_> bluefoxicy: certificate authority, group policy, client side extensions to that.
<Keybuk> if it's left as an empty directory, remove it and restore the symlink
<seb128> Keybuk: like, if that's a dir, rm and redo the symlink?
<Keybuk> yup
<seb128> k, thank you
<pitti> Keybuk: is that a bug or a feature?
* bddebian curses qgis
<bluefoxicy> wasabi_:  OpenLDAP can function as a CA AFAIK.  Group policy...?
<wasabi_> openldap can store CA data, but not function as a CA.
<bluefoxicy> oh
<wasabi_> openldap is a ldap server.
<Keybuk> pitti: feature
<bluefoxicy> hm.
<wasabi_> group policy are objects in AD which machines can apply to enable/disable features and change settings, network wide.
<wasabi_> Such as automated software installs, hiding the run menu, changing hte home page.
<wasabi_> To stuff such as distributing certificates.
<bluefoxicy> oh, very windows specific then
<mdke> seb128, did you see my mail ages ago about making epiphany take different default homepages, depending on locale? Any idea if it's possible somehow? np if not
<wasabi_> Yup.
<Burgwork> bluefoxicy, gpo are very powerful but also fairly arcane and a source of much headache
<wasabi_> I think some PADL project actually made headway there.
<seb128> mdke: yeah, sorry, it's on my pile of "to reply" mails, I'm catching up atm
<wasabi_> http://www.padl.com/Articles/PADLReleasesXADIdentitySe.html
<seb128> mdke: I've just replied to the "utch, no quality control from translations on rosetta" replies on the l10n french list
<dieman> group policy is evil stuff
<bluefoxicy> wasabi_:  okay so, is there a way to implement authentication through an open source server such as OLDAP or Heimdal KRB5, storing the roaming profiles on an open source samba server
<mdke> seb128, no problem. I thought the answer might be a simple "no", so I thought I'd ping you. if the answer is "possibly yes", then awesome!
<dieman> we've already got cfengine
<dieman> really
<wasabi_> bluefoxicy: Sure, Samba. ;)
<bluefoxicy> wasabi_:  and then set up a Windows Active Directory Server to get its auth info from those sources?
<wasabi_> Nope.
<seb128> mdke: they forwarded your mail to discuss how to organize the team
<mdke> seb128, in french, I guess?
<dieman> cfengine can exact its policy from netgroups specified via LDAP
<bluefoxicy> wasabi_:  so in other words I can't set up the network to be expanded later?
<mdke> seb128, my french is rubbish
<wasabi_> You can't do what you want to do right now.
<wasabi_> And if you kill AD, you will lose windows features.
<seb128> mdke: yeah, but nothing really useful. I pinged carlos today, my idea of an easy way would be "lock when somebody starts a translation, mail the diff when he unlocks it"
* bddebian misses seb128 in #u-bugs :-)
<bluefoxicy> wasabi_:  what I want to do right now is set up small IT shops with full open source setups
<wasabi_> bluefoxicy: then use Linux desktops.
<dieman> you can do roming profiles on samba, at least in old school pdc mode.
<mdke> seb128, sounds like a decent idea. 250 is a big group to handle :)
<dieman> im not sure the extent of what samba doing ad can do
<wasabi_> Yeah. You still do NT4 mode.
<seb128> mdke: mail going to a list, so it's easy to read what the person did and to fix errors and notice if the guys does it wrongly
<dieman> i thought the newer releases have reasonable ad capabilities
<seb128> mdke: yeah :/
<seb128> mdke: for epiphany I don't know but I'll ping upstream ;)
<mdke> seb128, rocking. thanks dude
<wasabi_> dieman: For joining to AD, not for hosting it.
<dieman> wasabi_: ahh, ok
<bluefoxicy> wasabi_:  I'm waiting for Ubuntu having the easy network authentication setup, like RHEL and Fedora do, because then I can use Ubuntu desktops ($250 for 1 year of support up to 10 incidents?) and RHEL servers ($2500 service contract???) in a mixed shop.
<wasabi_> Linux can join to AD wonderfully.
<wasabi_> CIFS support still sucks bad.
<seb128> mdke: np
<bluefoxicy> wasabi but AD costs too much money :)
<bluefoxicy> if someone so desired they could go supportless fedora core/ubuntu desktop and CentOS/Ubuntu server.
<pitti> Keybuk: what's the use case for that feature?
<wasabi_> Well, I know of no open source/free alternative to AD which actually delivers on what AD does.
<wasabi_> Which is massive ease of use, for a small shop.
<wasabi_> And automatic configuration of each host.
<bluefoxicy> wasabi a small shop may not have the $3000 for Win2k3 server
<wasabi_> The pieces are there, but you set them up yourself.
<bluefoxicy> they may have a good $100,000 start-up loan sitting around, but you don't want to blow a grand here and there.
<wasabi_> I'd charge any shop more than $3000 for the man hours involved to set up a Linux LDAP/kerberos setup to serve windows.
<wasabi_> Nuff said.
<seb128> mdke: <chpe> seb128: the home page is stored in gconf, and gconf supports localised prefs, so yes :)
<wasabi_> And win2k3 server is actually like $800.
<mdke> seb128, wooo
<wasabi_> Or get SBS. It's less. ;)
<bluefoxicy> wasabi start-ups can start on full linux but I'd like to make an expansion path that allows for integrating OSX and Windows if desired.
<wasabi_> Or help with the programming heh.
<mdke> seb128, we've already started shipping translations (or links, where I haven't got translations yet), they are in /usr/share/ubuntu-artwork/home
<bluefoxicy> nothing would be cooler though then setting up a small 5-10 PC linux shop for a small business and 4 years down the line they have 40,000 machines and no Windows in site.
<dieman> omfg, the russians want to drive a gold plated golf ball of the ISS
<dieman> off of
<dieman> as a stunt
<bluefoxicy> dieman so, they're russians, they're up there drinking wodka
<dieman> oh, and im in the wrong chan for this :)
<dieman> i thought i was in my idle chan
<dieman> sorry about that :)
<bluefoxicy> send them some female astronauts, they'll stop worrying about driving golf balls...
<ogra> mdz, haha, see bug 22045  :-D
<Ubugtu> Malone bug 22045 in gnome-screensaver "Poor performance / flickering with OpenGL hacks" [Normal,Confirmed]  http://launchpad.net/bugs/22045
<bluefoxicy>  - turn 3D acceleration on
<Chipzz> is it just me, or did X get a whole lot faster to start recently? :)
<bluefoxicy> I heard X7 was going to have SE-X
<bluefoxicy> wasabi_:  i am in general untrusting of microsoft's products.  I don't pretend to understand them, but I fear the defaults.  SQL server had default users and passwords that got owned by SqlSlammer.F ><
<wasabi_> I'm not suggesting to use WIndows. I'm just telling you what it is and what it does, and what *I* have yet to find a replcement for.
<wasabi_> And this has become offtopic. PM or something.
<bluefoxicy> My idea of installing something is that anything that requires attention, such as administrative passwords, dangerous default settings (i.e. unencrypted connections?  OpenLDAP without tls!) are mandatory for you to set up
<mdke> #ubuntu-offtopic?
<bluefoxicy> that's a better idea.
<bddebian> Please
<seb128> mdke: k, noted. I'll think about the best way to do that and let you know
<Surak> Kamion: espresso 0.99.44 is calling the systems $username+"-desktop" in the "who are you?" screen. however, it does not accept the dash. Should I open it? Did you already notice?
<Surak> hello folks
<mdke> seb128, thanks so much.
<seb128> np, thank you for pinging me on the topic and for the translated pages ready to use :)
<mdke> :)
<mdke> Surak, it's very late evening Kamion's time, he might not be around. if not, maybe file a bug
<ogra> grmbl ...
* ogra kicks evolution
<Surak> mdke: Yes. He tends to be awake working these days until late hours, for desperation of his wife :-)
* pitti kicks himself
<pitti> so I wasted TWO HOURS with diff -Nur, tar, dpkg -P and sudo make install/uninstall just to discover that a simple dangling stupid symlink broke cups *grrrr*
* sivang hugs pitti and cheers him up
<Keybuk> pitti: :(
<Keybuk> pitti: I'm having one of those "I *know* this worked once, because I tested it; so why is it flat-out not working now?" moments
<pitti> Keybuk: I wish diff -Nur would consider symlinks :/
<Keybuk> pitti: I tend to use comm on the file lists
<pitti> Keybuk: what broke for you?
<Keybuk> pitti: if you rename eth1 to "foo", it still calls "ifup eth1"
<pitti> 'it' being?
<Keybuk> udev
<pitti> oh, udev ifup's stuff?
<Keybuk> this is why it sometimes hangs on "Configuring network interfaces"
<Keybuk> both devices call "ifup eth0", leaving the "ifup -a" to do eth1 later
<Keybuk> I know it damned well worked when I wrote the patch
<Keybuk> so something in udev changed since, and we didn't notice (other than the occasional "hangs for a minute at ifup -a" bugs)
<pitti> hm, I never encountered that one
<Keybuk> yeah, it's a hard one to spot ;)  most people have eth0 and eth1, and both on auto, and it looks like it works :p  it doesn't matter that the wrong event is ifuping the wrong interface <g>
<Keybuk> but is a *bad* bug
<Keybuk> I know what's causing it now, fortunately
<Keybuk> the $env{INTERFACE} in the RUN rule is expanded *before* the device is renamed
<Keybuk> so there must have been a change in the way that works
<Keybuk> and then, after this, I have to work out why "blacklist pcspkr" doesn't
#ubuntu-devel 2007-04-09
<gabriel_> hi, can anyone point me to where i can get some help with some feisty upgrading issues? I dont know if this is the right place
<crimsun> #ubuntu+1, please
<gabriel_> ok, thanx
<ant_ipop> i need help reporting a bug: its a problem about kde freezing, what package/product should i choose for the report ? (no response in #kubuntu, ubuntu+1, and the bug wiki didnt help me)
<Riddell> ant_ipop: it depends on what is doing the freezing
<ant_ipop> happens only if im downloading several large files at the same time, happens with KGet or Firefox's own downloadmanager, also with download-managing firefox extensions
<Riddell> so not a kde issue
<Riddell> what are you unable to do when it freezes?
<ant_ipop> i did a memtest and a badblock search, no errors there, and its happening with kernel -13 -14 maybe with -12 too, dont remember when it started
<ant_ipop> no input possible: mouse not moving, ctrl alt backspace or ctrl alt f1 dont work
<ant_ipop> music played by amarok falls into a quick loop
<Riddell> so sounds like a linux problem
<Riddell> yes
<ant_ipop> but happens without amarok playing too
<Riddell> report on linux-source-2.6.20
<ant_ipop> thanks
<ant_ipop> and prduct?
<Riddell> ubuntu
<Riddell> but test with the latest linux first
<Riddell> have feisty beta installed at least
<ant_ipop> "There is no project named 'ubuntu' registered in Launchpad"
<ant_ipop> yes its a up-to-date feisty installation
<Riddell> oh, -13, not .13.  that's fine
<Riddell> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/
<ant_ipop> allright
<Riddell> make sure you say what network driver is being used since you say it's a network issue
<ant_ipop> sorry, may i use" linux" as product, cant find ubuntu in the search form there
<ant_ipop> i have to tell a package, and a product
<Riddell> I just gave you the URL
<ant_ipop> i have to reproduce the bug now to have some errors ins the logs
<ant_ipop> because when im not downloading several files at the same time it wont happen
<makuchaku> Hello all, which package provides me with debug symbols for libdbus-1-3?
<makuchaku> I could not locate anything ilke libdbus-1-3-dbg on packages.ubuntu.com :(
<makuchaku> *like
<cypher1> will vesafb be used always while booting up ? Or are there any chances it may not be loaded ?
<cypher1> also it is confusing that in my machine i can see "vesafb" in /etc/modprobe.d/blacklist-framebuffer.. but "lsmod" shows "vesafb" as loaded ! am i missing anything ?
<mjg59> It'll be loaded, but it won't be used
<cypher1> mjg59: thanks
<cypher1> mjg59: but will it not then unnecessarily take up memory ?
<mjg59> If you need 9K that desperately, you may already have lost
<zyga> is main totally frozen now?
<zyga> no chance to get anything updated?
<mjg59> Unless it fixes critical bugs
<zyga> mjg59: not really critical but the bugs are annoying :/
<ajmitch> hey pitti 
<zyga> mjg59: what is the final date of closing feisty?
<zyga> (as in making cd masters)
<pitti> hi ajmitch, happy Easter holidays!
<pwuertz> hi, I built a deb package with debhelper, added a menu file and ran dh_installmenu
<pwuertz> so the package includes / installs the menu file... but my application does not appear in the gnome panel after installing
<pwuertz> whats wrong?
<Adri2000> pwuertz: menu files are debian specific, you should use a .desktop file
<pwuertz> i also installed a .desktop file to /usr/share/applications
<pwuertz> Adri2000: do I have to symlink it somewhere else?
<Adri2000> no, in /usr/share/applications/ should be ok
<pwuertz> well... its there... but nothing happens
<pwuertz> its definately working, because the mime handler seems to recognizes the .desktop file
<pwuertz> but how to get a menu entry
<Adri2000> pwuertz: /join #ubuntu-motu, it's a better place for this kind of questions
<pwuertz> ok.. will do
<pwuertz> thanks
<Lutin> glatzor: may I /query you ?
<stub> Launchpad is going down in 15 minutes for a scheduled update. Estimated downtime is 10 mins.
<Fujitsu> Thanks stub.
<glatzor> Lutin: for sure
<TheMuso> c
<TheMuso> gah
<Hobbsee> d
<bddebian> Heya
<_ion> Hi pitti!
<_ion> pitti: Please take a look at the change at my restricted-manager branch.
<_ion> pitti: Oh, i pushed one more change to the hook.
<pitti> _ion: looks nice, thank you!
<jdong> if anyone who works on the upgrader is around.... is there any reason why we don't enforce that linux-generic be installed?
<jdong> I have a feisty user complaining to me about restricted-modules not being installed.... partly due to user error (he popped off linux-generic while fiddling with nvidia earlier)
<jdong> but I think dist-upgrader should enforce that linux-generic be installed ,like it does ubuntu-desktop
<mjg59> Because linux-generic isn't generic?
<mjg59> What I mean is, linux-generic isn't inherently the right answer
<mjg59> There should be at least one kernel metapackage installed, though
<mjg59> pitti was looking at making sure that was the case
<jdong> well it should find the appropriate one....
<jdong> but yeah, some metapackage should be installed
<hyperactivecrond> is pidgin going to replace gaim 2.0betax in feisty?
<hyperactivecrond> o-kay didn't see the /topic
<superm1> BenC, ping
<BenC> superm1: yo
<superm1> BenC, i'm updating the feisty lirc wiki pages, do you think that patch I put together before will end up making it in before feisty release?
<BenC> superm1: I'm doubting it...mostly my fault for not getting it in for the last kernel upload
<BenC> I need to check the "has patch" filter for kernel bugs more often
<superm1> oh thats a shame :(
<superm1> and since we're past kernel freeze, little likliness of a "feature patch" being added i take it
<BenC> superm1: Maybe we can get it in for an update later, but for release, it's a no-go
<BenC> right
<superm1> okay, i'll update the text to reflect that then
<superm1> did it look good elsewise though?
<crimsun> BenC: I presume that policy follows for the trivial ones I've sent, too, correct?
<BenC> crimsun: Yours were minor additions to PCI tables, so I included them
<crimsun> BenC: ah, ok. Thanks.
<BenC> lirc is an entire subsystem :)
<superm1> hehe
<crimsun> ah, scale of invasiveness. Understood.
<OwlEye> usually, there are lots of messages scrolling by during boot that can be reviewed in /var/log/dmesg later. ubuntu has a feature where it only shows a summary of these status messages in a graphical box. how that feature is called?
<pochu> OwlEye: do you mean usplash?
<OwlEye> could be, let me look that up
<OwlEye> pochu, hm. i am not sure now. what i dont mean is the typical bootsplash, where a custom image is displayed during boot. i mean that graphical box where the boot messages are displayed
<BenC> OwlEye: that's usplash
<pochu> OwlEye: oh, but that isn't anymore in the Feisty Fawn release :-)
<BenC> OwlEye: but usplash by default is less verbose now
<jdong> OwlEye: if you remove quiet from yoru boot options, the text will show up again
<OwlEye> awesome. i found it packaged for debian. thats what i needed. thanks a lot guys :)
<OwlEye> and so much friendlier than debian developers :)
* jdong waves at BenC :)
<BenC> jdong: hey
<jdong> BenC: hey you got any ideas on the ti flashmedia thing?
<jdong> it seems like the new release fixed mine but broke a bunch of others :D
<jdong> (bug 53923)
<ubotu> Malone bug 53923 in linux-source-2.6.20 "tifm: Texas Instruments Card reader not working" [Medium,Confirmed]  https://launchpad.net/bugs/53923
<jdong> the world of device drivers seems quite... exciting :)
<mjg59> People who were doing the setpci hack probably lose
<jdong> hmm
<mjg59> It works properly now
<jdong> you think the guys with broken drivers still have setpci magic around?
<mjg59> Well
<mjg59> There's been no code changes
<mjg59> I just changed udev to make sure tifm_sd is loaded
<jdong> right, but from -12 to -13 was when tifm 0.8 was added in, right?
<jdong> maybe I'm thinking of something else
<pochu> pitti: is the LP retrace service broken? I added two or three tags this morning and it hasn't retraced them yet :-/
<pitti> pochu: yes, due to LP downtime this morning; I restart them
<pochu> cool, thanks :)
<bluefoxicy> does Seveas still maintain a FreeNX repo?  That software kind of died in obscurity ....
<jdong> bluefoxicy: his repo seems to have died in the freenx department :-/
<jdong> at least the last time I checked
<tepsipakki> bluefoxicy: it's not freenx anymore
<bluefoxicy> oh o.o it's called something else?
<tepsipakki> yes, although I can't remember what :)
<jdong> really?
<jdong> http://freenx.berlios.de/
* bluefoxicy had been hoping forever for GDM/FreeNX integration and Vino/FreeNX and all :(
<tepsipakki> jdong: oh
<tepsipakki> seems that someone did continue that project
<tepsipakki> but there was another fork from freenx which is essentially another nomachine.com
* bluefoxicy ponders ssh --NX ... X forwarding but using the FreeNX protocol over ssh.  He can dream.... running Nessus over ssh is so slow :(
<tepsipakki> that would be cool, merging the protocol in Xorg
<tepsipakki> since freenx is still carrying it's own X
<tepsipakki> which kinda sucks
<Mithrandir> tepsipakki: it would be the right way to do it, as an X server extension.
<bluefoxicy> actually I was thinking more of emitting X packets at the client end
<bluefoxicy> like ssh -X does
<bluefoxicy> so the client program pulls over the FreeNX packets, and draws the screen with them, utilizing an X server (separate) to do so.
<Mithrandir> bluefoxicy: that would be trivial to do, but you wouldn't gain the latency boost you get from nxagent
<Chipzz> mjg59: wtf is up with wouter?
<bluefoxicy> side note becomes that it'd be incredibly cool if ssh could, on the server side, compress X forwarding packets with NX and then, on the client side, decompress them :)
<bluefoxicy> Mithrandir:  ?  Why not?
<tepsipakki> I tried to package freenx last fall to replace our nomachineNX-servers, but it was far from trivial..
<Mithrandir> bluefoxicy: because that requires having an X server on the SSH server end.
<bluefoxicy> Mithrandir:  ssh can't pick up the packets and encode them itself?
<bluefoxicy> what's it doing, maintaining a synchronous X state between 2 X servers?
<bluefoxicy> (does that even make any sense)
<Mithrandir> bluefoxicy: do you understand why NX is faster than regular X forwarding?
<bluefoxicy> Mithrandir:  no, I always thought it was because it has better compression than VNC ... i.e. compression of X packets instead of compression of screen caps.  Whereas SSH has poor compression and regular X forwarding/XDMCP has no compression
<shawarma> bluefoxicy: NX is not just a compression algorithm for X. If that's all you want, you can just add -C to your ssh command line and you've added gzip compression to your ssh tunnel. 
<bluefoxicy> shawarma:  and if you believe that, you can compress all your 15MB .bmp images with gzip too :)
<bluefoxicy> shawarma:  I'd think a specialized algorithm for the correct type of data would do better than general purpose (see FLAC vs ZIP)
<Mithrandir> bluefoxicy: NX consists of two bits:  One which is a smart proxy where it will return the same set of results for each query, which reencodes pixmaps as jpegs or pngs, etc.  That reduces bandwidth consumption, but not latency (much).
<shawarma> bluefoxicy: right.
<Mithrandir> the other bit is implemented by nxagent, it allows disconnection, it allows clients to do complex tasks (since they talk to nxagent which is a regular X server, not just a small shim)
<Mithrandir> nxagent is responsible for the large decrease in latency.
* bluefoxicy huhs
<bluefoxicy> I'm not following.
<bluefoxicy> Mithrandir:  so what's it do, frame skip when the screen is being redrawn 40 times a second and only send 1 or 2 of those across the pipe?
<tepsipakki> http://en.wikipedia.org/wiki/NX_technology
<Mithrandir> bluefoxicy: yes, as well as reencode stuff as jpegs and such.
<tepsipakki> bluefoxicy: ^^
<bluefoxicy> Sorry! This site is experiencing technical difficulties.
<zyga> oh please tell me that michael vogt works tommorow
<Mithrandir> he does
<shawarma> Mithrandir: Is anything in particular keeping https://bugs.launchpad.net/ubuntu/+source/apcalc/+bug/99993 from happening? Just holidays?
<ubotu> Malone bug 99993 in apcalc "[UVFe Sync Request]  apcalc 2.12.1.13-2" [Medium,Confirmed]  
<Mithrandir> shawarma: nothing but holidays, no.
<shawarma> Mithrandir: Ok, great.
<_ion> Re: the earlier discussion, it's amazing how much better NX is than plain ssh -C.
<zyga> _ion: NX?
<_ion> zyga: http://en.wikipedia.org/wiki/NX_technology
* zyga was puzzled due to no-execution bit, I was wondering how ssh compares to that ;-)
<_ion> A "no-exec bit vs. ssh" flamefest would be a welcome change for the usual Gnome vs. KDE, Emacs vs. Vim fights. ;-)
<jwendell> asac, around?
* poningru wonders why mako doesnt hang with use any more
<LaserJock> poningru: to busy changing the world, and getting vegan-friendly anti-RFID wallets :-)
<poningru> buh?
<poningru> oh s/use/us
<poningru> oh s/to/too
<poningru> gotcha
<jdahlin> Hi there, is there a directory in ubuntu which I can use to install python packages that are compatible with multiple python versions?
<zyga> jdahlin: I think python-central is there to solve this kind of issue
<mako> poningru: i don't think i ever really "hung out" here.. i idle here in case any anyone has questions for me
<poningru> not here dude #freeculture
<poningru> I just hope it wasnt because of the openmako jokes
<mako> poningru: oh, i think i just forgot to add it to my irssi config and the server i run screen on crashed :)
<poningru> oh awesome
<poningru> well... you know what I mean
<Seveas> bluefoxicy, NX is quite crappy -- too bad it's the only thing that does what it does
<jdahlin> zyga: /usr/lib/site-python seems to be the answer
<LaserJock> mako: thanks for the RFID wallet post, btw. I'm thinking of getting a passport wallet for UDS ;-)
<jdahlin> but python's distutils does not install packages there by default.
* poningru hands LaserJock his hammer
<bluefoxicy> Seveas:  yeah there was a lot of buzz about it back then.
<Seveas> bluefoxicy, all the buzzers (including myself) woke up and smelled the problems
<Treenaks> Seveas: back to vnc then? :P
<bluefoxicy> Seveas:  it seems to be an X server on the client end with a display over network, according to what I've gathered today.  Traditional X forwarding/XDMCP is a server away from the client; and and VNC is a server forwarding rectangular regions instead of redrawing specifically based on what the X packets say to change.
<Seveas> bluefoxicy, it's worse
<Seveas> bluefoxicy, it's an X server running on the server, proxying X calls via its own protocol to the X client on the client which basically is an xnest
<bluefoxicy> o_O
<Seveas> so you need an X server and NX proxy on both sides
<Seveas> good way to solve it: fix the X protocol to include these enhancements and do some x-servr-reconnection magic
<Mithrandir> Seveas: GTK is growing support for letting apps disconnect easily.
<Seveas> but that requires working with open sourc people, which nomachine apparently cannot do
<Seveas> Mithrandir, that's awesome!
<mako> LaserJock: i don't have an rfid passport yet
<Mithrandir> at least keithp claimed so in SF, and he tends to know what's going on in the crazy world of X
<Seveas> Mithrandir, but isn't that a layer too high?
<Mithrandir> Seveas: well, X as such should support it fine with XCB-using apps, at least..
<Mithrandir> it's just a socket
<Seveas> ah
<Mithrandir> nothing says you can't do XCloseDisplay and then XOpenDisplay again
<mjr> it would be fun though if that could be said without requiring spesific co-operation from the client application (from the X libraries, sure)
<LaserJock> mako: I don't know if mine is or not, issued last year for UDS Paris, but as I don't have much of any wallet right now I thought I might try them out
<zyga> whoo, feisty mirrored :D
<freemind> hello mates, ubuntu's init doesn't seem to like interactive shellscripts, how to enable interactive mode?
<keescook> Mithrandir: what do you want me to do with security updates for main during the next two weeks?
<Mithrandir> keescook: for the coming week, just upload and I'll wave them through.
<Seveas> freemind, this channel is not for support
<freemind> sorry then mates :)
<keescook> Mithrandir: okay, I wasn't sure if it would cause headaches for image builds, etc.
<Mithrandir> keescook: I'm not going to hold back any releases for you, though, so you might need to re-upload (to -security) if you're too close to release.
<Mithrandir> but that's just bandwidth
<keescook> Mithrandir: sure, no problem.
<keescook> I just want to know how when/where to be doing the uploads so it doesn't get in your way.  :)
<Mithrandir> keescook: just upload them normally, they'll end in an unapproved queue.
<Mithrandir> keescook: if you tell me about the uploads when you do them (or beforehand), that's useful so I understand why random packages suddenly show up in the queue
<ajmitch> morning
<pochu> hey ajmitch
<smokie_> dir
<jdong> dir :D
<jdong> Directory of C:\ Volume Serial 0000-0000
<jdong> ;-)
<zyga>  jdong: huh?
<jdong> zyga: I am command.com-compliant ;-)
<jdong> or broken.
<jdong> but that seems to be one and twelfth dozen.
<zyga> fortunatly I have no knowledge of that :D
<zyga> dos had volume serial numbers/
<jdong> yeah, it did :-/
<keescook> Mithrandir: okay, cool.  Well, this recent upload (ipsec-tools) is for a DoS on IPSEC tunnel traffic.
<jdong> zyga: echo "dir C:\\" | wine cmd.exe
<zyga> wow :D
<zyga> I'll install wine just to see that
<_ion> I think it was on this channel that someone once complained that someone had set his shell to wine cmd.exe as a prank. :-)
<jdong> zyga: we prank people by setting that as their login shell ;-)
<jdong> _ion: me :)
<jdong> _ion: it's more fun when you do it to others :D
<_ion> :-)
<shawarma> jdong: What the... Mine enters and infinite loop, apparantly.
<zyga> hehe
<jdong> shawarma: speaking of brokenness......
<shawarma> Ah, the stupid thing doesn't stop when there's no more input.
<jdong> cmd.exe does not take EOF too well
<jdong> :)
<jdong> so no echo pipe
<smokie_> EXIT
<jdong> because ^D doesn't work ;-)
<zyga> ahh, apt-get remvoe wine
<zyga> that's soo nice :-)
<BenC> Anyone know why dbus would send just Pause for KEY_PLAYPAUSE ?
<BenC> and where does dbus get the event from anyway
<zyga> BenC: lsof may hint you on the latter
<BenC> I'm pretty sure dbus has a lot of connections :)
<zyga> dev ones are most interesting problably
<zyga> does cannonical publish ubuntu download stats?
<BenC> zyga: No idea
<BenC> Ah, I found out that Keyboard Shortcuts prefs is what I wanted
<BenC> anyone know how these defaults are stored?
<_ion> gconf probably.
<BenC> gnome-settings-daemon is the main app, stores the values in gconf
<mcgrof> anyone use Eyas for UDS seville?
<N6REJ> hey guys we STILL have a problem with the adept updater.
<ajmitch> mcgrof: trying to
#ubuntu-devel 2007-04-10
<evand> mcgrof: me as well.  If you're waiting to hear back, I just did.
<ajmitch> evand: yay, hopefully I'll get a reply soon too
* ajmitch pinged them by email just before
<evand> ajmitch: Probably.  Without copy and pasting from the email, it sounds like they're getting through the backlog.
<ajmitch> yeah, they must have to deal with a few
<_ion> Eyas?
<ajmitch> travel agent
<mcgrof> evand: I'm under the impression that going through them you don't have to arrange payment through your own credit card, know if that is accurate?
<evand> mcgrof: Correct, at least for UDSMTV that was the case.
<mcgrof> great, that helps
<jcole> i'm having apps like gaim, firefox and evolution freeze hard consistently on feisty... i'm on gaim now and it will probably lock up as i start talking more... any suggestion on what i can do to figure out what is going on?
<jcole> doing an strace on firefox it stops at this when it locks up:
<jcole> futex(0x8bf0030, FUTEX_WAIT, 1, NULL)
<jcole> i *thought* it maybe aspell since firefox last froze up it in a text edit box and evolution froze when i was composing a message
* bluefoxicy ponders a bug bounty; then realize it's a stupid idea, because security companies will give you somewhere between $1000-$5000 for a good remote exploit
* lamont tries to remember when breezy drops from supports view
<bddebian> Not soon enough :)
<Seveas> lamont, 3 days to go :)
<michaelfavia> jus reading the #ubuntu+1 topic and looking at https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/96430 and i was interested to know if this nvidia legacy driver issue woudl be resolved for 7.04. I'm not trying to fix my computer (that would be a simple task) but considering adopting the platform for a large number of workstations that depend on this issue...
<ubotu> Malone bug 96430 in linux-restricted-modules-2.6.20 "MASTER: Request for new-legacy nvidia drivers (9631)" [High,In progress]  
<michaelfavia> a simple informed yes or know would be very much appreciated. thx.
<michaelfavia> s/know/no
<_ion> mu
<michaelfavia> _ion, my question cannot be answered because it depends on incorrect assumptions?
<Hobbsee> michaelfavia: see the comments from Ben Collins on it.
<desrt> hello hackers!
<desrt> wazzup?
<Hobbsee> hi desrt 
* desrt is starting to get pumped about UDS
<ajmitch> hey desrt 
* desrt steals ajmitch's nametag and refuses to believe that the person sitting in front of him is, in fact, ajmitch
<desrt> ajmitch; seville4u?
<desrt> Hobbsee; going to seville?
<Hobbsee> michaelfavia: i think https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/96430/comments/48 sums it up pretty well
<ubotu> Malone bug 96430 in linux-restricted-modules-2.6.20 "MASTER: Request for new-legacy nvidia drivers (9631)" [High,In progress]  
<Hobbsee> desrt: yep
<_ion> When is UDS Tampere going to be held? ;-)
<ajmitch> desrt: assuming I can get plane tickets, sure
<michaelfavia> Hobbsee, apologies.. i missed comment #48 from ben... and didnt know if the #ubuntu+1 message had any priority oer his comments in the bug.. thanks for the input. it seems safe to assume...
<desrt> Hobbsee; elite.
<desrt> ajmitch; what's wrong?
<ajmitch> desrt: still waiting on eyas
<desrt> ah
<Hobbsee> michaelfavia: it doesnt.  you're looking for the comments from developers.  
<desrt> if yr having trouble, "clickair" has super-cheap flights from schipol to seville
<ajmitch> desrt: the main part will be NZ->london
<desrt> (since a lot of airlines don't fly to seville)
* desrt toronto -> london -> amsterdam -> seville
<desrt> lots of flying... but cheap.
<desrt> Hobbsee; you been at a UDS before?
<desrt> !
<desrt> were you at lca?
<Hobbsee> desrt: nope.  and iwas at the open day
* desrt meant to look you up but forgot
<Hobbsee> heh
<ajmitch> shame
* Hobbsee was one of those strange people with a high voice, so should be fairly easy to find
<desrt> quite.
* desrt tries to remember if we succeeded in finding your picture last time we had a conversation like this
<_ion> I've got a small amount of ground work done for a nice implementation of three installed nvidia drivers, of which the correct one would be automatically chosen in runtime based on connected hardware. I haven't got around to doing the whole implementation at least yet, but it should be at least of some help to Ben.
<mneptok> ajmitch: Eyas has became increasingly unresponsive as of late :/
<ajmitch> mneptok: given that the travel agent I talked to today said that flights are getting scarce, it is annoying
<mneptok> ajmitch: are you a strong swimmer?
* desrt grins
<ajmitch> I can swim
<desrt> "have you ever swam across the equator?"
<ajmitch> but it may be a bit cold for a bit
<ajmitch> it's only 20000km or so
<mneptok> ajmitch: coat yourself with lard and Nembutol
<desrt> ajmitch; that's a tough swim
<desrt> ajmitch; better start training now
<ajmitch> desrt: no time for that, I'd better start swimming now
<mneptok> not for the swim so much. but we'd dig the entertainment value
<desrt> ya.  no kidding :p
* desrt wonders if the crazy sysadmin quotient of UDS will be filled this time around
<tepsipakki> still no update to the UDS wiki about sponsoring..
<mneptok> desrt: Canonical sysadmins or in general?
<desrt> uh
<desrt> sysadmins named kurt, mostly
<ajmitch> oh, scary ones?
<Hobbsee> desrt: it's on planet, there's a dodgy version on LP
<desrt> ya.  psychos.
* mneptok isn't a sysadmin for Canonical :)
<desrt> Hobbsee; i see how it is.
<mneptok> GNOME yes. Canonical no.
* desrt is a planet gnomer
<lifeless> mneptok: we knew you already you see.
<ajmitch> Hobbsee: scary
<mneptok> lifeless: and you still hired me? that raises new concerns about Canonical's viability. ;)
<Hobbsee> ajmitch: heh
<desrt> er
<desrt> your hackergotchi isn't a hackergotchi
<mneptok> it's as close as i'm coming.
<desrt> rob is crazy
<desrt> there's something weird in the air in au/nz
<lifeless> mneptok: you're our grain of sand.
* ajmitch wonders what it'll take to get plane tickets for UDS
<lifeless> ajmitch: usually a phone call.
<Hobbsee> desrt: i know.  hackergotchis of me look terrible.
<desrt> Hobbsee; i'll have my camera on hand.  we'll see what we can do.
<pitti> Good morning
* desrt tackles pitti
<pitti> hey desrt, *hug*
<desrt> sup dude?
<Hobbsee> desrt: heh, good luck with that
<Hobbsee> hi pitti 
<pitti> hey Hobbsee
<desrt> Hobbsee; dunnot worry.  i am an artiste.
<micahcowan> Hey, pitti, is there any particular critereon for what packages end up in the dbgsym repo?
<pitti> desrt: 'sup? bugz, bugz, bugz :)
<desrt> pitti; good man.
<desrt> make my feisty feisty
<pitti> micahcowan: all which have at least one ELF file in it, in theory
<fabbione> morning guys
<micahcowan> But there aren't comparatively very many in there yet, yes?
<micahcowan> Is it pretty much whatever you personally have had to have debug syms for? :)
<pitti> micahcowan: only those which have been rebuilt in the last 7 months or so
<pitti> no, it's not personal :)
<micahcowan> Others are removed, then?
<pitti> actually it should be pretty well-covered now
<pitti> micahcowan: no, they need a build with pkg-create-dbgsym enabled in order to produce dbgsyms
<pitti> micahcowan: and I only wrote it about 7 months ago
<micahcowan> coreutils was missing, was why I noticed. :)
<micahcowan> enabled... as in a rules target?
<pitti> micahcowan: no, as in 'put it into the buildd chroots'
<micahcowan> Oh... I see. Cool.
<mneptok> pitti: rumor has it Tollef was poking at NetworkMangler issues earlier today?
<pitti> mneptok: I don't know for sure; but earlier today? how earlier can it get? :)
<fabbione> mneptok: he was.. yesterday (our time)
<Hobbsee> 15 hours, at least :P
<desrt> lies
<desrt> 1 hr 25 minutes :)
<fabbione> desrt: go sit in a corner :)
<Hobbsee> desrt: you're just backwards.
<desrt> omg its that guy
<desrt> who goes to uds and spends all his time in smoking bofs
<desrt> fabbione; haven't talked to you in a while.  what's up? :)
<jsgotangco> smoking bofs lol
<fabbione> desrt: you have no idea how much more work you get done outside in open air.. sun shine and standing still in a smoking bof compared to those dark rooms etc :)))
<mneptok> Ubuntu would not exist without smoking BOFs
<desrt> fabbione; it's true...
<fabbione> desrt: not much really... just woke up and still very tired
<desrt> google was a fantastic venue for smoking bof
<fabbione> mneptok: true that :)
<desrt> with that stone island thing outside in the middle of the lawn
<fabbione> desrt: it was good yes...
<mneptok> Linux: Brought to you by caffeine, nicotine, tetrahydrocannibinol, and poor social skills.
<fabbione> the best smoking bof was at mataro'.. we were allowed to smoke inside
<desrt> ew.
<desrt> smoking inside is gross.  srsly.
<fabbione> desrt: well Spanish law did allow that at the time.. it's changed tho.. no more smoking inside
<fabbione> desrt: and note.. i don't really care either way
<desrt> that's good.
<desrt> i don't think i could ever bring myself to smoke inside... it's just so ... wrong
<Treenaks> fabbione: as long as it's not as cold as Montreal, right? :P
<mneptok> desrt: man, you're young. ;)
<desrt> mneptok; :p
<Treenaks> desrt: s/inside/at all/ :)
<mneptok> Treenaks: screw you, too :)
<desrt> montral was _not_ cold
<fabbione> Treenaks: Montreal as in UDS or Montreal as in February when i was there?
<Treenaks> fabbione: uds
* desrt went back in january and then it was cold
<fabbione> Treenaks: UDS was warm
<fabbione> desrt: yeah.. i was there too.. -30
<desrt> brutal.
<mneptok> please stop.
<mneptok> i have to sit here and wait for spring.
<mneptok> ;)
<fabbione> mneptok: why? i was sharing the pain with you?
* Hobbsee sends mneptok to antarcica
<desrt> just move to .au
<mneptok> Hobbsee: already there.
<desrt> it's still warm there
<Hobbsee> mneptok: heh.
<mneptok> desrt: can't. too old.
<Hobbsee> indeed.  sorta :P
<Treenaks> Hobbsee: gives a whole new meaning to 'UDS' (Down South)
<desrt> mneptok; eh?
<Hobbsee> Treenaks: yes.  the next UDS should clearly be in the snow
<mneptok> desrt: can't emigrate to Australia over the age of 40.
<desrt> mneptok; you only have to do it for another month or two before the northern hemisphere comes around
<desrt> huh?
<Hobbsee> mneptok: we dont want you here anyway.
<mneptok> Hobbsee: what about if i commit a crime? :P
<micahcowan> Is there a "patch-attached" tag or something to let core devs know about bugs with suggested fixes provided?
* mneptok wonders if "transportation" is still a valid court sentence
<Treenaks> mneptok: yes, but to Siberia, not Australia
<Treenaks> .. wait ..
<mneptok> Australia, the gulag with dingoes!
<desrt> the dingo stole my passport!
<desrt> s/the dingo/ian jackson/
<Treenaks> mneptok: sounds like one of those lines on travel brochures
<Hobbsee> mneptok: nope.  they stopped that.
* desrt always assumed hobbsee was in .au after being deported from the .uk for being a freedom-loving hippie
<Hobbsee> haha
* Hobbsee was born in au, she's afraid...
<desrt> ah.  so your parents were the criminals, eh?
* desrt gets tired of the cliche already
<desrt> it's _so_ time to go to bed :p
<desrt> night, hippies.
<micahcowan> I'm not expecting to try and get something in before feisty... I just want to ensure it's not forgotten after feisty...
<desrt> micahcowan; you'd be best to personally bug the appropriate maintainer in 1 month time
<desrt> micahcowan; when they have more time to breathe...
<pitti> micahcowan: you can search for bugs which have patches attached, yes
<ajmitch> micahcowan: universe or main?
<micahcowan> ajmitch, main (linux-kernel)
<micahcowan> linux-source, rather
<ajmitch> right, then I'd probably leave it as-is rather than trying to subscribe someone
<micahcowan> Right; if it were universe, I'd assign to ubuntu-universe-sponsors (as I was recently directed to do for my gawk fix).
<micahcowan> Anyway, I know mvo will have seen it (when he's around). 'Course, I'm sure he's swamped, so by the time he has some time to think about it, I'm sure he'll have forgotten it... I'll bug him in a month or something. :)
<micahcowan> Thanks, folks. :)
<pitti> Mithrandir: can you please approve the l-r-m in unapproved soon? I need to adapt restricted-manager to it
<_ion> pitti: What's new in it?
<pitti> _ion:
<_ion> The modalias change perhaps?
<pitti>    * Change nvidia back to 9631, add epoch for nvidia-glx packages.
<pitti>    * Add nvidia-news package at version 9755. This is the path of least
<pitti>      surprise.
<pitti>    * Add module alias override patch from Johan Kiviniemi
<pitti>      <johan@kiviniemi.name>.
<_ion> Cool
<pitti> but we now need to get along with three nvidia packages instead of one :/
<pitti> apparently the merging was too complicated for feisty
<_ion> Ok
<_ion> When the merging happens, my small hardware_connected program might be helpful. bzr branch http://johan.kiviniemi.name/software/bzr/hardware_connected/
<_ion> For example: nvidia_version() { for nv_ver in 9755 9631 7foo; do if modinfo -F alias nvidia-$n
<_ion> v_ver | hardware_connected; then echo $nv_ver; return; fi; done; return 1; }
<_ion> Oh, i pasted the example with the old syntax.
<_ion> nvidia_version() { for nv_ver in 9755 9631 7foo; do if hardware_connected -m nvidia-$nv_ver; then echo $nv_ver; return; fi; done; return 1; }
<_ion> It also allows things like hardware_connected 'usb:*' && echo USB hardware connected; hardware_connected 'pci:*bc03*' && echo PCI display adapter connected; hardware_connected -m usbhid && echo USB HID connected
<Mithrandir> pitti_: sure, looking.
<jtholmes> can anyone tell me how to open a private channel with another nickname
<Mithrandir> pitti: apart from the fact that the librarian is b0rked atm
<lifeless>  /msg nickname
<pitti> Mithrandir: yay LP updates at release time :/
<Mithrandir> pitti: (try q -Q unapproved fetch linux-restricted-modules on drescher)
<pitti> Mithrandir: I did already
<pitti> Mithrandir: just as an early warning, I have to introduce a new class for the nvidia-glx-new driver package, and remove all the modinfo detection stuff (since that's now in l-r-m); so this will become quite a large diff :(
<pitti> Mithrandir: the new class will be tiny, though
<mdke> hi pitti 
<pitti> hi mdke
<mdke> pitti: any further thoughts on ubuntu-docs?
<pitti> mdke: just what I mailed you
<mdke> pitti: on Sunday? or is there an email since then?
<pitti> mdke: the second proposal (only ship languages which we ship on the CD, and do the full version in -updates) is a bit crude, but easy to do
<pitti> mdke: I mailed you yesterday, didn't I?
<pitti> mdke: Date: Mon, 9 Apr 2007 13:21:52 +0200
<mdke> pitti: I haven't received it yet
<zyga> hey
<pitti> mdke: weird; shall I bounce it again?
<pitti> hi zyga
<mdke> pitti: please do, thanks
<pitti> mdke: should be there by now
* zyga is very happy today :-)
<zyga> a full dataset for cnf is fresh and ready :-)
<zyga> for every arch :D
<kagou> good morning
<pitti> hi kagou
<kagou> hey pitti , whats up ?
* pitti throws a chocolate easter egg at kagou :)
<highvoltage> what other kinds of easter eggs do you get? I thought they were all chocolate?
<kagou> thanks pitti  ! :)
<kagou> pitti, should i assign you to Bug #99498 ?
<ubotu> Malone bug 99498 in hal "Nautilus and hal can't umount usb hd disk" [High,Confirmed]  https://launchpad.net/bugs/99498
<Mithrandir> highvoltage: marzipan at least.
<pitti> kagou: please don't; I'll grab hal bugs when I have time for them, I am bug contact
<kagou> ok pitti :) 
* Hobbsee grabs one of the easter eggs, and munches
<Hobbsee> aww, there was only one :(
<mdke> pitti: nope :( Can you send it to matthew.east@tiscali.co.uk instead as a temporary measure while I find out what is wrong with my email?
<pitti> mdke: forwarded
<mdke> pitti: haven't got that one either... is your email working ok? test emails seem to be arriving to me
<kagou> seb
<pitti> mdke: I'll check the logs
<pitti> mdke: erk, indeed, postfix cannot resolve names on my server, sorry
<mdke> np
<pitti> mdke: ok, flushed; and now I'll find out why the recent kernel update on my server broke iptables configuration
<mdke> pitti: whoos, 9MB? I thought you said it was 2.5?
<pitti> mdke: the bzip2'ed .deb is 2.5 MB now, but the live system isn't bzip2, it's more like gzip
<mdke> oh I see
<mdke> even with the symlinking it's 9MB?
<mdke> pitti: would it be possible to have an update ready in -updates for the release, which is called by gnome-language-selector, with all the languages? if so, then probably the second solution would be ok. The first solution sounds like it is fairer to translators though
<pitti> mdke: if it's in -updates, update-notifier will install it anyway
<pitti> mdke: fairer> I agree,  just a bit more effort to implement
<mdke> pitti: sure, but not everyone uses that
<zyga> is it possible to know which arch I'm on (as in the arch specifiers that dpkg understands?)
<mdke> I've seen my girlfriend use the computer and never wonder what that little orange square is about :)
<zyga> i386, powerpc, amd64, sparc
<pitti> zyga: dpkg --print-architecture
<zyga> pitti: thank you!
<zyga> :D
<zyga> mvo: hey!
<zyga> mvo: It's ready it's there :D
<mvo> hey zyga!
<zyga> I have everything we need if there is still time
<mvo> zyga: if its just data, that should be fine :)
<zyga> mvo: it may be just the data
<zyga> I made the clinet a tiny bit nicer but the data is fine 
<mvo> zyga: could you give me a download location for the data?
<zyga> sure, just a sec
<zyga> mvo: http://suxx.pl/~zyga/feisty.dump.gz
<zyga> fetch that first, it's about 80MB
<zyga> the built data is much smaller
<mdke> pitti: maybe we should ask the translators teams or wider community which solution they think is better as well, what do you think?
<dholbach> good morning
<pitti> mdke: it's just really urgent now
<mdke> ok
<mdke> pitti: so you would prefer to do the second solution, but without language-selector?
<pitti> mdke: if we have the time to implement the msgfmt --statistics one, that seems to be better to me
<mvo> zyga: and I need to update my tree from you branch I assume?
<mdke> pitti: ok. Do you want to have a quick look at debian/rules and see if there is something you can slip in there which changes the value of $lang?
<zyga> yeah, just a sec, I'll push the branch
<mdke> pitti: also, as I mentioned in another email, we need to do an update from our repository, hopefully dholbach will do that for us :)
<dholbach> mdke: i will do that in a bit
<mdke> dholbach: :D
<pitti> mdke: hmm, 'change the value of $lang'? it just traverses ubuntu/<langs>, right?
<mdke> pitti: yes. I was thinking if you could do something with msgfmt which excludes languages with low levels of translation
<pitti> mdke: ah, that for loop would be the place to stick the --statistics test in, and if it fails, do 'continue'?
<mdke> something like that. We'd need to make the --statistics test actually have a yes/no result though
<zyga> mvo: you can pull now
<pitti> mdke: right, of course; I thought of some awk or perl bit
<mdke> pitti: ok! Maybe see if 20% reduces the package size dramatically (I think it will), but if not, go higher, like 40%?
<zyga> mvo: to build just move the feisty.dump.gz to the root of cnf source code
<pitti> mdke: yes, I'd adjust it so that it ends up as roughly 2 MB or so, let's find out
<zyga> I didn't want to include in the branch as it's just too large
<pitti> mdke: ok, let me play around with this a bit
<mdke> pitti: I have to go to work now, and can't read irc, but will be checking email during the day
<mvo> zyga: downloading
<pitti> mdke: a second
<mdke> sure
<pitti> mdke: did you change anything in svn head so far?
<zyga> mvo: ping me when you're done
<pitti> mdke: i. e. how to coordinate your changes, mine, and dholbach's upload?
<zyga> mvo: the feisty.dump.gz contains info for i386,amd64,powerpc and sparc
<mdke> pitti: best to let dholbach go first, then get his source, I think. 
<mdke> or you can checkout https://docteam.ubuntu.com/repos/branches/feisty for playing around purposes
<pitti> mdke: alright, I'll just send him my rules patch then; I guess that didn't change too much
<dholbach> pitti: thanks a lot
<mdke> thanks both
<carlos> dholbach: could you confirm whether gtkhtml3.8 is going to be moved to universe now that evolution is not using it anymore?
<carlos> or will it remain in main for Feisty ?
<mvo> zyga: info for universe as well ?
<zyga> yes
<mvo> cool!
<dholbach> carlos: looks like a safe assumption - nothing in main is depending on it
<carlos> dholbach: anyway to convert the assumption in a fact?
<carlos> I would like to reuse its current .pot file for the new gtkhtml version
<carlos> but if it remains in main, I shouldn't
<Mithrandir> carlos: I'd rather remove it, tbh
<dholbach> Mithrandir: why?
<Mithrandir> at least if we can get the packages in universe depending on it fixed.
<Mithrandir> dholbach: it's obsolete, isn't it?
<carlos> Mithrandir: well, I think is a bit late to change code just to depend on a new version, isn't it?
<carlos> It's only a single package, peacock
<dholbach> Mithrandir: no, unfortunately not - let me find the relevant part of the discussion
<carlos> but even a single package, we could break it two weeks before release...
<Mithrandir> carlos: no, it's more: balsa, gnomesword, gnotime, gnucash, gtk-sharp, mysql-query-browser, peacock
<carlos> hmmm
<carlos> carlos@aragorn:~$ apt-cache rdepends gtkhtml3.8
<carlos> gtkhtml3.8
<carlos> Reverse Depends:
<carlos>   peacock
<carlos> isn't that supposed to list all dependencies?
<Mithrandir> you're just checking one arch, and you're not checking build-depends.
<carlos> oh, I see
<_ion> apt-cache rdepends libgtkhtml3.8-15
<Mithrandir> and you're checking on gtkhtml3.8, not all binaries from the source package
<carlos> right
<dholbach> Mithrandir: maybe you're right (it was just gtkhtml2 and gtkhtml3 which are separate things)
<dholbach> but I'm not sure we'll be able to remove 3.8 for feisty
<Mithrandir> dholbach: if the API is unchanged, it should be doable.
<dholbach> Mithrandir: I think it's not just a matter of rebuilding
<carlos> Mithrandir: well, I guess something changed
<carlos> gtkhtml3.8 version is 3.13.5
<carlos> so it makes no sense to change its package name unless there is an API change
<carlos> anyway, dholbach who decides whether it will be moved to universe and when?
<dholbach> carlos: Mithrandir can do that
<cjwatson> see the changelog, there's been some fun with gtkhtml3.8's API/ABI
<cjwatson> carlos: ubuntu-archive, in general
<cjwatson> we probably should try to clear anastacia before RC
<Mithrandir> carlos: moved to universe.
<cjwatson>  o libgimme-codec: libgimme-codec-bin libgimme-codec-dev libgimme-codec0
<Keybuk> cjwatson, Mithrandir: any objection to demoting grepmap to universe?
<cjwatson> I thought that was needed for easy-codec-installation?
<cjwatson> Keybuk: none
<carlos> Mithrandir: ok, thanks
<Mithrandir> Keybuk: no, sounds sane to me
<cjwatson> grepmap-udeb should be removed from the installer seed too now
<cjwatson> I'll do that
<Mithrandir> ps3-kboot should probably be seeded somewhere
<cjwatson> supported
<Mithrandir> cjwatson: care to fix?
<mneptok> Mithrandir: thanks for the NetworkMangler hacking!
<cjwatson> yes, hadn't realised pitti had approved that already
<Mithrandir> mneptok: $ pwd
<Mithrandir> mneptok: $ /home/tfheen/nm/mangler/manual-interface-hack-hack-hack/gnome/applet
<Keybuk> cjwatson, Mithrandir: tbh, given that we're upstream, I'm inclined to just remove grepmap from the archive -- it's served its purpose
<pitti> cjwatson: sorry, postfix on my server was stuck due to DNS failure, so you only got the mail about an hour ago
<mneptok> Mithrandir: :D
<cjwatson> Keybuk: up to you
<cjwatson> pitti: yep, seen it now, just hadn't checked mail this morning yet
<Mithrandir> Keybuk: I'm fine with it; nothing in the archive (except for hppa stuff) depends on it.
<mneptok> Mithrandir: i have some interesting logs that seem to point the finger at dbus. i can send when i get home.
<Mithrandir> mneptok: the suspend/resume bug or something else?
<Keybuk> ok, gone
<mneptok> hppa? oh dear. jbailey is back as of today. he might actually notice.
<Mithrandir> he'll be stuck in email until release. :-)
<mneptok> Mithrandir: ath0 does not configure itself at boot with a known-good /e/n/interfaces and /e/wpa_supplicant.conf from Edgy. but it succeeds with an invoke-rc.d networking stop-start
<Mithrandir> mneptok: does it work if you remove or disable NM?
<mneptok> dunno.
<Mithrandir> if you could check that, that would be useful
<mneptok> and until i'm physicalrly in front of the machine, i don't want to test ;)
<Mithrandir> obviously not.
<Hobbsee> mneptok: be brave :P
<mneptok> in 3.5h when i'm home. first thing.
<Mithrandir> pitti: shouldn't some language support package depend on myspell-da?
<pitti> Mithrandir: right, it should; I'll care for that
<dholbach> pitti: tell me when you have the u-docs patch ready
<pitti> dholbach: working on it
* dholbach hugs pitti
<mneptok> pitti: i'll give you a nickel if you work the word "suave" into the official docs.
<zyga> mvo: do you have it?
<Mithrandir> cjwatson: any idea why lrm doesn't build nic-restricted-firmware-2.6.20-14-386-di nic-restricted-firmware-2.6.20-14-generic-di nic-restricted-firmware-2.6.20-14-powerpc-di nic-restricted-modules-2.6.20-14-386-di nic-restricted-modules-2.6.20-14-generic-di nic-restricted-modules-2.6.20-14-powerpc-di any more?
<dholbach> heno: I just uploaded accerciser 0.1.0 - let's hope we get it through NEW for release
<heno> dholbach: ah cool! the LSR people will be very happy :)
<cjwatson> Mithrandir: is it possible it just hasn't built yet? lrm's .dsc isn't accurate
<cjwatson> so you need to wait for the binaries to actually appear before it'll realise
<Mithrandir> cjwatson: ok
* Keybuk is trying to work out why his laptop has a mutant mix of GNOME and KDE all of a sudden
<Mithrandir> Keybuk: openoffice.org-style-crystal is installed
<Keybuk> Mithrandir: this drags in all of kde?
<Mithrandir> and that pulls in lots of kde-y bits
<Keybuk> why is that installed?
<Mithrandir> unsure
<Keybuk> Mithrandir: openoffice common depends on it
<pitti> Mithrandir: how so? Depends: openoffice.org-common (= 2.2.0-1ubuntu2), that's everything
<Mithrandir> hm, at least it looked like that was the cause last night when I poked at it
<Mithrandir> there, old kernels removed from the archive
<Hobbsee> Mithrandir: that's what i saw when i looked, too
<siretart> Keybuk: btw, I managed to make a qemu image with root on lvm on raid in order to test cryptoroot. while doing that, I think I experience other races regarding AsyncUdevBoot
<Keybuk> siretart: what races did you experience?
<Mithrandir> zul: any reason not to remove xen-restricted-modules-2.6.17 from feisty?
<siretart> Keybuk: similar symptoms as before: raid volume (/dev/md{0,1,2}) appear, initramfs drops to busybox, issueing `lvm vgchange -ay; logout` continues booting
<fabbione> siretart: is that initramfs updated?
<Keybuk> siretart: and how did you fix it?
<siretart> Keybuk: udevtrigger seems unreliable here. sometimes it kicks lvm in, sometimes not
<fabbione> siretart: make sure to fire up an update-initramfs -k all -u
<siretart> Keybuk: not yet, I put the qemu image (800mb) on tiber
<Keybuk> siretart: ignore udevtrigger
<siretart> fabbione: k
<Keybuk> all udevtrigger does is replay missed events
<siretart> Keybuk: I know. funnily, sometimes it doesn manage to bring the volume up, so I suspect another race there
<Keybuk> sounds like it
<Keybuk> please let me know what you can find out
<cjwatson> Is Thomas Hotz here?
<dholbach> cjwatson: he's not around - his nick is 'thotz' and he's in #ubuntu-bugs every now and then
<cjwatson> thanks
<Keybuk> so, err, who's fixing openoffice?
<StevenK> What's broken?
<Keybuk> it depends on openoffice.org-style-crystal, which recommends the entirity of KDE
<Keybuk> and since we obey recommends, that installs of KDE into Ubuntu
<Keybuk> and utterly screws over the default session
<StevenK> Oh that.
* StevenK has seen a bug report about that.
<Keybuk> Mithrandir, cjwatson: ok to upload fix for bug #74317 ?
<ubotu> Malone bug 74317 in evms "race with devmapper" [Critical,Unconfirmed]  https://launchpad.net/bugs/74317
<pitti> dholbach, mdke: ubuntu-docs debdiff emailed
<dholbach> ogra: dunno if seb128 already told you, but there's a new gnome-power-manager and gnome-screensaver
<dholbach> pitti: thanks
<seb128> Mithrandir: would an upload for https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/105025 be accepted?
<ubotu> Malone bug 105025 in gnome-panel "Extra separator in System menu" [Undecided,Unconfirmed]  
<ogra> dholbach, no, he didnt and i didnt notice, thanks for telling !
<dholbach> ogra: np
<seb128> the change was made because of the apport entry and pitti dropped it now
<Mithrandir> Keybuk: please
<Mithrandir> seb128: sure, please get it in asap
<pitti> Mithrandir: whops, myspell-da doesn't have a MIR; it seems useful, though, so I create one and promote the binaries, ok?
<seb128> Mithrandir: ok
<Mithrandir> pitti: we traditionally haven't bothered for dictionaries?
<pitti> Mithrandir: right, it's a fairly pathologic MIR; I'll review the .debs anyway, though
<Mithrandir> YAY.
* Mithrandir beats NM with a large stick
<pitti> Mithrandir: oh, dsdo builds a new version anyway, so we don't even need this; so I'll just demote
<Riddell> pitti: is anything being done to stop ppc being oversized?
<pitti> Riddell: eventually we have to, but I'm not at it ATM
* ogra steals Hobbsees pointy one and joins Mithrandir
<pitti> Mithrandir: instead, I'll upload a new support package for the myspell-pt one in anastacia, ok?
<Mithrandir> pitti: please.
<amit> if it not the right room for that, i am sorry, please tell me and i'll go away :). in #ubuntu non seem to be able to help me. when i run a demanding cpu app (such as chess) my cpu temperature goes above 90C. i am not sure about that, but i think my fan used to spin faster on edgy. any suggestions?
<pitti> Mithrandir: done
<Mithrandir> ogra: can you test a new NM package for me, please?  http://err.no/patches/network-manager-0.6.4-disabled-means-online.diff should make your LTSP stuff happy.
<Mithrandir> mdz: I've spent a fair amount of time trying to reproduce bug 45696, but I still can't.  Can you?
<ubotu> Malone bug 45696 in network-manager "NetworkManager can't find interface on resume from suspend" [High,Confirmed]  https://launchpad.net/bugs/45696
<doko> Keybuk, Mithrandir: OOo dependency assigned to me now; ok to upload a package just with that fix?
<Mithrandir> doko: yes, please.
<Mithrandir> seb128: was it so that https://bugs.launchpad.net/ubuntu/+source/gnome-cups-manager/+bug/91218 is still broken because of an ineffective fix?  If so, any chance you could take a look at fixing it properly?
<ogra> Mithrandir, building ...
<ubotu> Malone bug 91218 in gnome-cups-manager "MASTER: [apport]  gnome-cups-manager crashed with SIGSEGV in g_signal_emit_valist()" [High,Confirmed]  
<seb128> Mithrandir: ah right, thank you for the reminder, will do that next
<Keybuk> does anyone here have a USB CD-ROM drive?
<Mithrandir> seb128: cheers.
<cjwatson> Mithrandir: still working on setting up a proper environment to test my fix for bug 102148
<ubotu> Malone bug 102148 in grub "grub doesn't properly migrate from incorrectly-detected-as-evms root filesystems" [High,Confirmed]  https://launchpad.net/bugs/102148
<cjwatson> (fyi)
* ogra waves to Keybuk 
<Keybuk> ogra: could you plug it into a feisty machine for me
<ogra> Keybuk, what do you want tested ? 
<smurf> doko: are you (or somebody else, in fact) going to do something about bug 78282 ?
<ubotu> Malone bug 78282 in vnc4 "vnc4server does not start Desktop environment after security update" [High,Confirmed]  https://launchpad.net/bugs/78282
<ogra> Keybuk, i dont have an up to date one, anything that needs to be latest version for that ? 
<smurf> basically, vnc4server + any Gnome program => not working
<Keybuk> ogra: udev
<ogra> ok
<doko> smurf: no, I know that keescook did look at vnc4server recently
<Mithrandir> cjwatson: thanks, looks good at a glance.
* Mithrandir goes to take a small break.
<ogra> Keybuk, gimme a second then to finish that NM build, i need a reboot then anyway
<Keybuk> thanks
<zyga> mvo: any progress?
<mvo> zyga: not yet, sorry
<mdz> Mithrandir: will try later, at lunchtime
<seb128> mdke: around? what happened to about-ubuntu-C.omf? you stopped using it?
<smurf> doko: Hmm. Assign the bug to him?
<doko> smurf: subscribing seems to be better
<smurf> doko: OK
<fabbione> Mithrandir: do you think we can give PPC some give-back love? looks to me like most of the gnome stuff just needs that
<fabbione> Mithrandir: (looking at feisty_probs
<ogra> Mithrandir, that doesnt look good ... during upgrade the package already killed my eth0
<ogra> Mithrandir, what do i have to set in /e/n/i ?
<shirish> hi all, I have drafted a spec. at https://blueprints.launchpad.net/apport/+spec/shirish can somebody take a look at that?
<seb128> hum
<pitti> shirish: I saw your bug report and mail, I didn't yet have time to answer
<seb128> the documentation team dropped about-ubuntu-C.omf, the panel has no "about Ubuntu" now :/
<pitti> shirish: that's pretty complex, and multiple things thrown into one bug/spec
<shirish> pitti: ok so when u have time, either drop me a mail or whichever way, how I can reduce the complexity of it
<pitti> seb128: uh, htat might be my fault (I didn't check)
<pitti> seb128: current package has /usr/share/gnome/help/about-ubuntu/C/about-ubuntu.xml
<seb128> pitti: the omf is the index
<seb128> I don't get how it's working without it
<seb128> pitti: how do you get it registred by scrollkeeper?
<pitti> seb128: not sure, I didn't actually remove files in the current version in Feisty
<shirish> pitti: I will be also be here for some-time so maybe after you have finished with seb128
<pitti> seb128: which version do you have?
<seb128> pitti: 7.04.1
<pitti> seb128: oh, not my fault then; I only uploaded .2 and .3
<pitti> seb128: indeed, I just built .1 again, no about-ubuntu-C.omf there
<seb128> grumpf
<pitti> seb128: dholbach currently prepares a new upload, can you please coordinate with him?
<seb128> pitti: yeah, will do, thank you
<dholbach> seb128: the new ubuntu-docs has about-ubuntu-C.omf
<seb128> dholbach: ok, cool
<pitti> dholbach: how's the deb size of your version now?
<dholbach> pitti: 8.9M vs 2.6M
<pitti> dholbach: urgh, 2.6MB? with my current patch against .2 it is 1.2 MB
<pitti> dholbach: 2.6 MB bzip2'ed deb will inflate to some 5 or 6 MB on the live fs
* ogra wonders why schoolbell still shows up in his daily CD health reports ...
<ogra> oh, its in supported ...
<tepsipakki> Mithrandir, pitti: what should I do with the -intel driver? The missing license document is an upstream problem, right?
<pitti> tepsipakki: if there is a license file somewhere, you can repack the orig.tar.gz
<tepsipakki> pitti: so maybe I should poke the debian guys to do it..
<tepsipakki> since it's basically the same package which is in experimental
<tepsipakki> wonder how it got through ;)
<pitti> tepsipakki: an oversight maybe
<tepsipakki> probably
<Mithrandir> ogra: what does your interfaces file look like?
<ogra> # This file describes the network interfaces available on your system
<ogra> # and how to activate them. For more information, see interfaces(5).
<ogra> # The loopback network interface
<ogra> auto lo eth0
<ogra> iface lo inet loopback
<ogra> #iface eth0 inet dhcp
<ogra> iface eth0 inet static
<ogra> address 192.168.0.254
<ogra> netmask 255.255.255.0
<Nafallo> no auto for eth0?
<ogra> thats how the network-admin tool has set it 
<ogra> <ogra> auto lo eth0
<Nafallo> right. I always have them on seperate lines, sorry :-)
<shirish> guys how do I subscribe to ubuntu-devel@lists.ubuntu.com ?
<Mithrandir> ogra: with that configuration, eth0 should not be managed by NM at all, is that consistent with what you're seeing?
<ogra> Mithrandir, well, i didnt reboot yet ... during package upgrade NM teared down the interface and i had to ifdown/up it
<tepsipakki> pitti: the reply was "the files have license headers"
<pitti> tepsipakki: not all of them :)
<tepsipakki> true, just checked :)
<Mithrandir> tepsipakki: if all the files have full licence headers, that's fine.  The MIT/X11 licence is usually short enough that it fits comfortably at the start of the file
<pitti> Mithrandir: right, but not all files in there is source code
<ogra> Mithrandir, rebooting now ... lets see 
<Mithrandir> ogra: I care less about how it looks during upgrade than whether it behaves correctly after a reboot.
<Mithrandir> ogra: thanks.
<smurf> Mithrandir: But people who update over the network might become somewhat unhappy if it happens...
<pitti> Mithrandir: I'll process NEW to free l-r-m
<Mithrandir> pitti: cheers.
<Mithrandir> smurf: people who are running feisty and have a statically configured interface in /etc/network/interfaces, yes.  If you want to fix that, please, but I'm not going to.
<smurf> Mithrandir: unfortunately, "want" != "have time to".  :-(
* ogra hugs Mithrandir 
<ogra> on less :)
<ogra> *one even
<_ion> fakeroot debian/rules binary  3538.02s user 470.72s system 60% cpu 1:50:57.11 total
<_ion> Building linux-restricted-modules takes patience. ;-)
<Mithrandir> ogra: coolie, it works correctly?
<ogra> yes
<ogra> as expected :)
<pitti> _ion: I just free'd the debs from NEW, btw
<shirish> tepsipakki: are you not the one who made the 2.0 rc3 deb for xf86-modesetting-intel driver?
<tepsipakki> shirish: merged from debian, yes
<shirish> tepsipakki: ok, I have had put my comments in there, perhaps we can l8ter talk in a nice quiet corner without disturbing the other developers, when you are free. After all, I am just a user.
<_ion> pitti: Alright.
<tepsipakki> shirish: "in there"?
<shirish> yup
<tepsipakki> shirish: what do you mean by that :)
<_ion> Well, *there*! ;-)
<shirish> tepsipakki: I mean I am the same shirish who was trying to get your attention, bug you in the bug report.
<shirish> sorry was cut off
<tepsipakki> shirish: okay, what was the bug number?
<shirish> tepsipakki: ok just a minute.
<shirish> bug #90213
<ubotu> Malone bug 90213 in xserver-xorg-video-i810-modesetting "xf86-video-intel 1.9.91 (2.0 RC1) is out, and would be nice to have as the source for the xserver-xorg-video-i810-modesetting package" [Undecided,Needs info]  https://launchpad.net/bugs/90213
<tepsipakki> oh that one
<shirish> yup there is also a 1.9.94 in works though, do not know whether it is better or worse off. Have a look at it when u have time, and whatever info. is required, I will be happy to provide.
<tepsipakki> shirish: I uploaded that, but there are some issues with the upstream tarball which need to be sorted out
<shirish> tepsipakki: yup i have noticed that (long sigh!), although much better than before. I know it is not going to be released with the Feisty Live CD but perhaps we can test it enough so most of the bugs get sorted out, maybe u have some sort of test case & can be released with the next live CD.
<shirish> I know this is not the proper place/forum to speak about it, but you are hard to find.
<tepsipakki> seems that ubuntu-x-swat is not listed as a bug contact for modesetting..
<tepsipakki> fixed
<Mithrandir> cjwatson: if you could review and accept the new network-manager once it hits the unapproved queue, I'd appreciate.
<tepsipakki> shirish: hard to find?-)
<tepsipakki> shirish: anyway, it's in progress. the next livecd with intel on it is going to be for feisty+1
<shirish> tepsipakki: I know, perhaps its wishful thinkful to have it happen on alpha1 of feisty+1
<shirish> tepsipakki: anyway feel free to connect with me on the mail id provided. Always interested in getting this one fixed.
<shirish> tepsipakki: also if you do know of any drivers for AMD-based machines which provide the same modesetting feature, I have looked but failed to find a  .deb for it. please lemme know
<seb128> doko: gnome-python FTFBS on a python crash, could you have a look?
<tepsipakki> shirish: you mean ATI? There is none available yet.
<doko> seb128: that's 1.2, or the current one?
<shirish> ok cool, could u add that to the bug-report as some sort of link as & when it comes along
<seb128> doko: python-gnome2
<seb128> doko: the archive version ftbfs and it built fine at some point so it's likely to be a python2.5 regression
<seb128> doko: you can try with 2.18.0-0ubuntu1
<mvo> zyga: just placing the dump file into the root dir seems to do nothing. do I have to merge from the "ubuntu-feisty-release" branch?
<Keybuk> ogra: ping
<ogra> tepsipakki, do you see a way to fix bug 30969 ? 
<ubotu> Malone bug 30969 in xorg "monitor goes to standby when playing a movie in totem fullscreen" [Undecided,Unconfirmed]  https://launchpad.net/bugs/30969
<ogra> Keybuk, pong ... five mins ... i'm not near the CD
<Spads> man I hate that bug
<ogra> Spads, easy fix ...
<ogra> s/fix/workaround/
<ogra> the fix might be hard :)
<ogra> i wnder if KDE needs the dpms setting in xorg.conf
<ogra> *wonder
<ogra> or xfce ... 
<ogra> or if we could just drop it
<Riddell> in theory we shouldn't need it, although I'd be hesitant to make such a change a week from release
<tepsipakki> ogra: the fix would be easy, but I don't know how it would affect other people
<ogra> it would only be easy if you can switch it off completely ... it gets very hard if you need to switch it off conditional based on which desktop is used
<tepsipakki> exactly
<ogra> Riddell, well, how do the KDE screensaver/powermanagement cope with that ? 
<ogra> *does
<ogra> i think xorg will override their settings as well or not ? 
<Riddell> ogra: dunno, my monitor turns itself off after a while.  not sure if KDE or X is doing that.  KDE does have a tickbox to set it but I'd rather not sit idly waiting to see if it affects it or not
<Riddell> ogra: shouldn't totem just be fixed?
<ogra> Riddell, totem is fine
<ogra> as g-p-m is ...
<ogra> but Xorg doesnt listen to either of them if DPMS is set in xorg.conf
<tepsipakki> oh, right
<Riddell> can't say I've ever seen the problem in kaffeine
<ogra> well, if KDE can live without, i'd suggest dropping it from X
<ogra> Keybuk, ok, ready, waht do you want me to do ? 
<ogra> (thats a DVD btw ... hope that works too)
<Keybuk> ogra: plug it in
<ogra> ok
<Keybuk> check /dev/sd* is group cdrom
<Keybuk> are they?
<ogra> ogra@edubuntu:~$ ls -l /dev/sd*
<ogra> ls: /dev/sd*: No such file or directory
* ogra scratches his head
<ogra> aha
<ogra> ogra@edubuntu:~$ ls -l /dev/scd0 
<ogra> brw-rw---- 1 root cdrom 11, 0 2007-04-10 13:01 /dev/scd0
<ogra> ogra@edubuntu:~$ ls -l /dev/cdrom 
<ogra> lrwxrwxrwx 1 root root 4 2007-04-10 13:01 /dev/cdrom -> scd0
<ogra> looks fine
<Keybuk> err, yes, scd 
<Keybuk> could you check the sg* as well
<ogra> ogra@edubuntu:~$ ls -l /dev/sg0 
<ogra> crw-rw---- 1 root root 21, 0 2007-04-10 13:01 /dev/sg0
<ogra> ogra@edubuntu:~$ ls -l /dev/sr0 
<ogra> lrwxrwxrwx 1 root root 4 2007-04-10 13:01 /dev/sr0 -> scd0
<zyga> mvo: no
<zyga> mvo: put the dump file in a checkout of my trunk
<zyga> mvo: then simply build the package
<zyga> btw: do not uncompress the dump
<zyga> mvo: I'm sorry I did not update the feisty release branch as I did not know if it will be okay with pushing a UVF exception
<zyga> the feisty release branch is the one you can currently find in feisty
<zyga> the trunk contains the new goodies
<zyga> the trunk can build data files for feisty-release as well
<zyga> mvo: do tell me if you have more questions
<Keybuk> ogra: ok
<Keybuk> ogra: udevinfo --query=all --name=sg0
<Keybuk> paste that to me
<ogra> ogra@edubuntu:~$ udevinfo --query=all --name=sg0
<ogra> P: /class/scsi_generic/sg0
<ogra> N: sg0
<ogra> L: 0
<ogra> not much to paste here :)
<Keybuk> ok
<Keybuk> ogra: udevinfo --attribute-walk --name=sg0
<Keybuk> paste that
<ogra> whoo
<smurf> pastebins are your friend ;-)
<ogra> http://paste.ubuntu-nl.org/14842/
<ogra> quite a bit longer :)
<Keybuk> ogra: hmm
<Keybuk> ogra: udevtest /class/scsi_generic/sg0
<ogra> http://paste.ubuntu-nl.org/14843/
<Keybuk> bah
<Keybuk> another silly udev bug
<mneptok> Tonio__: 'lu!
<Keybuk> Mithrandir: ok to upload udev to fix bug #75753 harder?
<ubotu> Malone bug 75753 in udev "Wrong group for IDE cdrom/cdwriter/dvd devices" [High,Confirmed]  https://launchpad.net/bugs/75753
<Keybuk> ...
<Keybuk> .
<Keybuk> Thread 1 (process 2573):
<Keybuk> #0  0x080524b4 in ?? () from /lib/ld-linux.so.2
<Keybuk> #1  0x00000000 in ?? ()
<Mithrandir> Keybuk: looks good, go ahead
<Keybuk> thanks apport, really useful, cheers
<tkamppeter> pitti, ping
<Mithrandir> tkamppeter: is it on purpose that m2300w isn't seeded?
<tkamppeter> This I have discovered now and wanted to ask you why it is not seeded. It should be seeded. I have asked once here on the IRC for getting it seeded. So please seed it whoever has access rights.
<tkamppeter> Another oddity: SpliX got approved for main:
<tkamppeter> https://wiki.ubuntu.com/MainInclusionReportSplix
<tkamppeter> But no one moved it. Pitti, can you move it?
<tkamppeter> Same for pxljr, approved but not moved:
<tkamppeter> https://wiki.ubuntu.com/MainInclusionReportPxljr
<tkamppeter> Can this also get fixed? Thanks.
<Mithrandir> I'll fix it
<tkamppeter> Thanks, Mithrandir, many users complained about missing printer drivers, especially Splix. And they are small. Moving them to Main and seeding them will not break the CDs.
<bhale> Mithrandir: would you mind if i pop two small patches into beagle
<cjwatson> tkamppeter: "whoever has access rights"> I trust that you have read http://wiki.ubuntu.com/SeedManagement? I know you aren't in ubuntu-core-dev yourself and therefore don't have commit access to the seeds, but you ought to know who does by this point.
<bhale> Mithrandir: one quiten's general logging, one saves the mono stacktrace in the debug log in a crash
<cjwatson> the seeds are a core part of our distro infrastructure and it's important to understand them
<Keybuk> dholbach: ping
<Mithrandir> tkamppeter: m2300w is 500kb, that's not small
<dholbach> Keybuk: pong
<bhale> Mithrandir: both are in svn
<Keybuk> dholbach: you last uploaded pilot-link
<Mithrandir> splix is 50k, that's fine for CDs
<ogra> Keybuk, do you still need the DVD or can i get out of the cellar again ? (its so dark around here)
<Keybuk> there's a bug in the pisock udev rules file it shipped
<cjwatson> you should also know the difference between "in main" and "on the CD", as in the various different seeds
<Mithrandir> bhale: sounds sane, please upload
<Keybuk> ogra: nope, that's all I needed, thanks
<bhale> Mithrandir: danke
<ogra> thanks :)
<dholbach> Keybuk: I think that was fixed in debian already
<dholbach> Keybuk: I just didn'T have the time to merge it yet
<Keybuk> SUBSYSTEMS!="usb" doesn't actually dtrt
<Keybuk> that bug?
<Mithrandir> we should proabably decide what to do about uncommon hardware wrt seeds.  I don't see the point in adding printer drivers to -desktop for everybody when they'll be used by a small minority.
<dholbach> Keybuk: i just noticed an upload in debian that changed the udev rules
<tkamppeter> cjwatson, I know what the seeds are.
<dholbach> Keybuk: ah no, it was just debian bug 415960
<ubotu> Debian bug 415960 in pilot-link "pilot-link: 60-libpisock.rules is contained in two packages" [Serious,Closed]  http://bugs.debian.org/415960
<Mithrandir> tkamppeter: m2300w, splix and pxljr, those should be all?
<tkamppeter> Yes.
<Mithrandir> tkamppeter: added
<the_dennis> Hi there!
<Hobbsee> when exactly is breezy EOL'd?
<Hobbsee> hi the_dennis 
<tkamppeter> Thanks, Mithrandir.
<Hobbsee> presumably it's this month, sometime...
<ogra> wasnt there a EOL mail notice ?
<ogra> it should have a date
<Hobbsee> ogra: for hoary, i beleive
<ogra> ah, k
<pitti> no, there was one for breezy
<imbrandon> Hobbsee, afaik its when feisty is released ( or the end of the month )
<ogra> i thought that was breezy aready
<Hobbsee> right
<Mithrandir> Hobbsee: Friday 13th
<imbrandon> hehe
<imbrandon> btw moins *
<pitti> carlos: can you generate a list of packages without a pot?
<carlos> hi
<Hobbsee> Mithrandir: great.  so i can send a mail to hte bugsquad telling them to feel free to EOL all the breezy only bugs?
* _ion misread the line as "...without pot"
<carlos> pitti: without a .pot but with a .po ?
<Mithrandir> Hobbsee: not yet.  Friday.
<carlos> or just the ones without translations?
<Hobbsee> Mithrandir: well, i can send the mail, and tell them to start on friday.  or something :P
<Mithrandir> Hobbsee: yup, please. :-)
<Hobbsee> Mithrandir: :)
* Hobbsee is sure we could start a couple of days aerly...
<StevenK> We did with Hoary, if I recall.
<StevenK> "Hoary is buggering off. Upgrade already" etc etc
<pitti> carlos: yes, the former (missing .pot)
<carlos> pitti: yeah, I can do it
<carlos> pitti: I'm on the phone, once I finish I will give you the list
<pitti> carlos: thanks
<Keybuk> Mithrandir: ok to upload ifupdown to fix #102675 ?
<Mithrandir> indeed, feel free
<dholbach> Keybuk: I have no idea what to fix in the udev rules - if you want to fix it, that'd be cool
<Keybuk> dholbach: basically SUBSYSTEMS!= (or indeed, any S!=) doesn't do what it might appear
<Keybuk> whoever wrote that rule *thinks* that it means that one of the underlying objects must have SUBSYSTEM=="usb"
<Keybuk> (which is what SUBSYSTEMS=="usb" means)
<Keybuk> err, I mean none of the underlying objects
<dholbach> Keybuk: I have no clue about udev rules
<\sh> pitti: should we file "wishlist" bugs for removing some packages from the feisty archive? (e.g. php4 packages who have also php5 brothers, like phpunit (php4) and phpunit2 (php5)) ?
<pitti> \sh: yes, please, and subscribe ubuntu-archive
<pitti> \sh: I'm happy to clean them up
<\sh> pitti: cool...thx :)
<Mithrandir> seb128: you'll tell me when all the GNOME tarballs are done?
<pitti> Mithrandir: I have a new r-m ready with adaptions to new l-r-m and four bug fixes; details at http://codebrowse.launchpad.net/~ubuntu-core-dev/restricted-manager/trunk/changes, revision 126 onwards
<Mithrandir> pitti: go for it
<carlos> pitti: http://paste.ubuntu-nl.org/14852/
<carlos> pitti: some of them is just a matter of blocking them 
<pitti> carlos: so if I cut out the source package column and uniq it, I should have what I want, right?
<carlos> wait, I will give you it directly
<pitti> carlos: oh, only for feisty
<carlos> pitti: http://paste.ubuntu-nl.org/14853/
<carlos> pitti: but I think the path information would be helpful
<carlos> because some of them doesn't need to be fixed to get the .pot file
<pitti> carlos: ah, thanks
<pitti> carlos: well, this list is small enough for manually checking, if I throw out kde-i18n and universe
<carlos> if you have an easy way to check whether some of them are in universe, please, give me that list
<pitti> carlos: since I have both lists now, I can use the first one for cross-checking
<pitti> carlos: thanks a lot!
<carlos> so I can just delete them from the queue without having to check it too
<pitti> carlos: alpine, for example
<carlos> I already remove it (I forgot to remove it from the second list, sorry)
<carlos> pitti: ignore compiz too, that has the .pot file
<pitti> carlos: rest looks main-ish
<carlos> and compiz-extras is too in universe
<seb128> I fixed gtkhtml3.14 yesterday
<pitti> carlos: and the two network-manager additions
<carlos> seb128: indeed, I approved it this morning. I forgot to remove it from the list too..
<carlos> pitti: so -vpnc and -openvpn are universe packages?
<pitti> carlos: yes
<carlos> ok
<carlos> Riddell: around?
<Riddell> carlos: hi
<seb128> carlos, pitti: fixing pessulus
<cjwatson> Mithrandir: grub uploaded for bug 102148; please review
<cjwatson> (tested now)
<carlos> Riddell: Would you send me the .pot files for Edgy noted on http://paste.ubuntu-nl.org/14852/ so I do a manual upload?
<ubotu> Malone bug 102148 in grub "grub doesn't properly migrate from incorrectly-detected-as-evms root filesystems" [High,Confirmed]  https://launchpad.net/bugs/102148
* iceman is away: shopping
<carlos> Riddell: I need to check whether the Feisty ones are valid ones or just for universe (like the kdevelop ones)
<carlos> Riddell: I can provide you a specific list for kde-i18n-* packages if you prefer it
<Riddell> carlos: you want the edgy .pot files for the various desktop_* listed there?
<carlos> Riddell: yes, please
<carlos> that way all those files will be translated in Edgy, right?
<Riddell> carlos: shouldn't rosetta have those?
<carlos> Riddell: it does for Feisty
<carlos> but seems like Edgy was not complete...
<carlos> either that or we added the .pot files to the wrong place...
<carlos> Riddell: if you think you fixed all those for Edgy
<carlos> don't worry, I will check whether we added them to the wrong place
<Riddell> I've no idea, edgy was ages ago :)
<ogra> when we were young :)
<carlos> I know :-P
<highvoltage> and sometimes you close your eyes and see the ubuntu you used to use... when you... were young
* ogra found a pressed warty CD during cleaning on the weekend ... felt really nostalgic
<ogra> Mithrandir, gnome-power-manager uploaded for approval ...
<fabbione> udev 5 - fabbione 0
<zul> hey fabbione 
<fabbione> hi zul
<cjwatson> Mithrandir: were you going to do anything with bug 84591?
<ubotu> Malone bug 84591 in casper "feisty 20070210/herd5 persistent mode doesn't work" [Undecided,Confirmed]  https://launchpad.net/bugs/84591
<Mithrandir> cjwatson: if I find the time, yes, but realistically, I don't think I'll manage.
<cjwatson> does anyone else have time to take that? it's a headline feature documented in various places ...
<Keybuk> fabbione: what was up?
<Mithrandir> cjwatson: ugh, I didn't realise it was well-documented.. I'll need to conjure some time to fix it, then.
<fabbione> Keybuk: iwj did help me with the dm-* stuff but now i am hitting my head against some strange race and can't figure out exactly how to solve it
<Keybuk> did you find the cause?
<fabbione> Keybuk: yes.. a kernel behaviour change in device mapper
<fabbione> for the race? not really
<Riddell> pitti: can I turn off the linux calling apport thing automatically?  I'm wanting to test it in another language
<pitti> Riddell: you mean killall adept-notifier?
<gone|win> does fawn include pidgin?
<pitti> Riddell: because the backend does not have any i18n
<Hobbsee> gone|win: no
<Riddell> pitti: groovy, that all works
<cjwatson> (the short name is "feisty", not "fawn")
<gone|win> Hobbsee: what about as an update? or will feisty officially be stuck to beta6?
<gone|win> cjwatson: thanks
<gone|win> cjwatson: i noticed something weird about my shortening but i couldn't tell what it was
<Mithrandir> dholbach,seb128: how much is left of the new GNOME?
<seb128> Mithrandir: we are mostly uptodate on what has been rolled, they still have a bunch of tarballs to roll though
<seb128> Mithrandir: I would say there will be something like 7-8 other uploads today
<ogra> i'm just doing the final gss build ... 
<Mithrandir> seb128: ok.
<ogra> Mithrandir, there is a screensaver in the queue for you :)
<Mithrandir> ogra: thanks
<fabbione> Keybuk: i think i figured out the issue...
<fabbione> Keybuk: the race seems to be triggered by a broken partition table of somekind..
<Keybuk> oh?
<fabbione> Keybuk: it's the multipath udev rule that i am hunting down
<fabbione> it fires up 2 commands.. one to check the passive path and one to add partititions to the multipath device
<fabbione> the first one i *now* know it works fine
<fabbione> the second one.. well it's doing some strange things
<fabbione> and it seems due to a broken partition table
<fabbione> so it's not really udev to be blamed
<ogra> Mithrandir, there is one consmetical fix for ltsp i'd like to see in final, diff is under http://paste.ubuntu-nl.org/14867/, would that be ok to upload ? (its not critical but small enough imho)
<ogra> *cosmetical
<fabbione> Keybuk: see /msg
<fabbione> Keybuk: the last entry for donotouch1 should be *empty*
<fabbione> Keybuk: but it's reporting a partition bigger than the disk
<Mithrandir> ogra: we're really past the point where we do cosmetic fixes, but ok.
<ogra> thanks 
<ogra> i wouldnt have asked if it werent a one liner :)
<Keybuk> Mithrandir: ok to upload lsb to fix LP: #104371
<Keybuk> ubotu: oi, bug #104371
<ubotu> Sorry, I don't know anything about oi, bug #104371 - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<ubotu> Malone bug 104371 in lsb "/etc/lsb-base-logging.sh causes some initscripts to abort if console is unavailable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104371
<Keybuk> heh, neat, it responds to itself
<ogra> Keybuk, see the fast scrolling in #ubuntu-bugs ... its busy :) 
<Mithrandir> heh
<Keybuk> "and this is why jarno gave us NOTICE"
<Mithrandir> which is why bots should use notice and not msg, but I digress
<Mithrandir> Keybuk: looks ok, please upload
<_ion> It's in the IRC spec that all automatic messages should use notice instead of privmsg. If a bot/script doesn't comply with that, it's broken.
<dholbach> Mithrandir: what do you think about bug 105112?
<ubotu> Malone bug 105112 in gthumb "UVF gthumb: 2.10.1 -> 2.10.2" [Medium,Unconfirmed]  https://launchpad.net/bugs/105112
<stalker> just switched to ubuntu, i have dev question, how do i apt-get libiconv?
<stalker> i already asked on #ubuntu, nut nohing
<stalker> problem is...i can't find iconvctl function
<stalker> it's not in /usr/include/iconv.h
<conn> Hi, I realize this isn't a support channel, but I'm looking for a little guidance with squashing a bug. Using a zd1211-based USB wireless card, NetworkManager isn't connecting to WPA networks properly on the first attempt, but does on the second. I suspect that it's trying to associate and set the wireless key before the interface is brought up (which is necessary/unique for zd1211rw). What configuration file should I look at to tweak this behaviour?
<mjg59_> conn: I'm looking into this issue. It affects all softmac drivers.
<Mithrandir> dholbach: looks ok.
<conn> mjg59, this bug report may be helpful (the last post links to the developer's list with a discussion re: the same issue, I believe): https://bugs.launchpad.net/ubuntu/+source/zd1211/+bug/103366
<ubotu> Malone bug 103366 in zd1211 "NetworkManager cannot connect to WPA network at first boot" [Undecided,Unconfirmed]  
<dholbach> Mithrandir: thanks
<stalker> anyone have at least slightest idea how i can compile my program which uses iconvctl()
<mjg59_> https://bugs.launchpad.net/ubuntu/+source/lilo/+bug/88219 - is update-initramfs still generating 0-sized files, or am I misinterpreting that?
<ubotu> Malone bug 88219 in lilo "lilo won't add the new kernel 2.6.20" [High,Fix committed]  
<stalker> or at least what's package name for iconv on ubuntu
<mjg59_> conn: It's not limited to zd1211rw or wpa - it's an issue with all softmac-based drivers
<conn> mjg59_, I only have a zd1211rw based wireless card, so I assumed it was limited to that chipset, thanks.
<mjg59_> And I can reproduce it on my unencrypted network
<TheMuso> stalker: You may have more luck asking in #ubuntu-motu. People are quite busy here with getting feisty out the door.
<stalker> k, ty
<conn> mjg59, the script on the bugreport I linked usually solves the connection trouble, with the exception of networkmanager's first attempt to connect, or manually entering a key for an encrypted network (perhaps a timing issue). It's not a fix, but it may help you figure out how to fix it properly
<fabbione> iwj: something amusing.. most of the issues were coming from some broken partition that had a partition table in it
<bddebian> Heya
<conn> mjg59_, I linked to my bug on your report. I happen to have two different brands of zd1211-based cards, can I help out with any logs/troubleshooting?
<iwj> fabbione: Lovely.  Why did that cause this trouble ?
<fabbione> iwj: because kpartx was spinning waiting for sde1p4 to appear...
<fabbione> of course nothing was creating it because it was an invalid partition entry
<iwj> IC
<iwj> Or I'm sure I would if I knew what kpartx was :-).
<ogra> tsk, all this kde stuff in the kernel nowadays
<schwuk> will Gaim's name change be reflected in Feisty?
<ogra> kswapd0, kacpid, khubd ...
<Hobbsee> seb128: what's teh final position on that?
<Hobbsee> seb128: (the gaim name change)
<seb128> Hobbsee: I don't care? ;)
<Hobbsee> no, presumably, for all of feisty?
<seb128> Hobbsee: do we *have to*?
<jdong> lol I like that reaction :D
<mjg59_> Does the name change change the name of the dbus interface and the command?
* jdong erects a monument to seb128, labeled "Do we *have to*?"
<seb128> did they roll any tarball with the new name yet?
<Hobbsee> seb128: i'm trying to figure that out...
<jdong> at this point I don't see like RHEL4 scrambling to change all their gaim references to pidgin...
<Hobbsee> Now that the settlement is signed, we hope to have the final Pidgin 2.0.0 release late this week or early next.
<schwuk> seb128: no we don't, but I'd like to know if it's likely due to obvious changes in the Ubuntu book...
<conn> seb128, they brought out snapshots, equivalent to 2.0.0beta7devel
<StevenK> That's because RHEL5 is out
<jdong> StevenK: and?
<Hobbsee> (which was on the 6th)
<seb128> schwuk: no reason to change imho
<jdong> StevenK: they're still regularly patching RHEL3 you know ;-)
<fabbione> iwj: eheh sorry... it's part of multipath-tools. it's used to create partitions related to multipath devices.. for example /dev/mapper/multi is made of sda and sdb.. but then.. you can have sda1 and sdb1.. those need to be reflected into /dev/mapper/multi1 and multi2.. kpartx takes care of that
<seb128> it's too late to use a new version
<seb128> and they didn't roll any renamed tarball anyway
<jdong> agreed on the new version thing
<schwuk> that's what I figured, but I wanted to check
<jdong> that's a nightmare for extensions packages...
<seb128> so if there is no legal reason against keeping the new, no reason to change
<StevenK> Yeah, couldn't their lawyers fit in with our schedule? :-P
<fabbione> iwj: the problem is that we pass all dm-* devices to kpartx including the one used for let say multi2.. multi2 in my case had this bad partition table entry
<conn> seb128, you're right, the only problem is AOL's enforcement of their IP right (ugh). Pidgin would belong in backports, though, considering how close Feisty is to release
<seb128> s/the new/the name
<Hobbsee> seb128: then again, if we're using a beta already, why not use teh file.....
<Hobbsee> conn: or updates
<schwuk> I'll mark it for review before publishing anyway. Worst case is a search and replace and some new screen grabs.
<Hobbsee> s/file/final/
<seb128> Hobbsee: because it's not available?
<Hobbsee> seb128: i meant once it was
<jdong> Hobbsee: what final? ;-)
<jdong> Hobbsee: they break their ABI every snapshot
<jdong> Hobbsee: every extension package needs rebuilding at minimum...
<Hobbsee> jdong: ahh.  fun.  i love upstreams like that.
<jdong> yeah :(
<seb128> Hobbsee: because we are frozen and I don't trust them enough to upload a new version during hard freeze and expect it having no bug
<Hobbsee> seb128: yeah, that's what i thought
<geser> Hobbsee: and you would need to rebuild all extensions with libpurple
<Hobbsee> geser: yeah, i'll be right
<seb128> and update code using the dbus interface
* Hobbsee updates the factoid
<seb128> or the command line tools
<jdong> sounds like a nightmare to me :)
<Hobbsee> seb128: factoid updated, hopefully people will stop asking now
<seb128> Hobbsee: any URL? ?
<Hobbsee> seb128: of the factoid?
<seb128> yes
* Starting logfile irclogs/ubuntu-devel.log
(Mithrandir/#ubuntu-devel) seb128: I saw
(cjwatson/#ubuntu-devel) otherwise e.g. security updates to that package will end up having to go through NEW and it'll all be hopeless confusion
(seb128/#ubuntu-devel) is there a way to tell from a crash file what version of a lib was being used?
<seb128> like gnome-panel crash
<cjwatson> if it's removing *all* binaries, then surely the source package should be removed
<seb128> libgtk2.0-0 2.10.11-0ubuntu3 was installed
<seb128> is there a way to know if the gnome-panel was using it
* Keybuk realises his brain has gone cross-eyed
<crimsun> cjwatson: ok, thanks. Will get consensus in -motu before further action.
* Starting logfile irclogs/ubuntu-devel.log
(seb128/#ubuntu-devel) the app being gnome-panel it's possible
(seb128/#ubuntu-devel) as long as you don't restart your session the panel is running
<Mithrandir> doko: weren't you doing an OOo upload to fix the -style-crystal problem?
<seb128> pitti: I think all those gnome-panel crasher we get a due to some GTK corruption
<seb128> pitti: which might be fixed with the revision uploaded on thursday
<seb128> pitti: we still get dups though
<seb128> pitti: not sure on how to know if those guys restarted their panel since they upgraded libgtk2.0-0
<seb128> anyway not a lot we can do even if the bug is still there
<seb128> we need somebody getting the crash to provide a valgrind log
<seb128> might gnome-panel is valgrind clean since the gtk update, but it might be to some theme, applet, or something else I'm not using
<seb128> s/might gnome-panel is/my gnome-panel is
<doko> Mithrandir: ohh, I was looking at a problem with the human icon them (our current default). will upload just the dependency fix tonight if I don't find the problem with the icon theme
<Tonio_> hi
<Tonio_> I'm concerned by the legal status of libxine1-ffmpeg in companies....
<Tonio_> that's in main, but I always thought mp3 support required royalties
<mvo> Mithrandir: #92875 needs a sru-verification from bdmurray first (or we make a exception for this and just let it through). #95598 should be in progress (talked with zyga about it earlier) and I just closed #102773. do you have more than those three on your list of fix-commited that is releated to me? I did a big cleanout of those before the weekend, but maybe malone is not giving me all of them
<Tonio_> did canonical pay so that the package can be in main ?
<Tonio_> that important regarding to the french parliament migration to ubuntu :)
<Mithrandir> doko: please do it now rather than later.  We're less than 48 hours from RC and OOo takes time to build.
<Mithrandir> mvo: so 92875 doesn't need any changes in feisty at all?
<seb128> Tonio_: what is important? they need ffmpeg player officially supported?
<Tonio_> seb128: they want mp3 support, but legally :)
<mvo> Mithrandir: no, its a about the update-manager-core upload to edgy-updates to allow server updates with the release-upgrader. 
<Mithrandir> mvo: ok, cool.
<Tonio_> I must say the legal status on that point as always been a mess to me...
<mvo> Mithrandir: its in -proposed since ~4 weeks 
<jdong> Tonio_: heh not only the mp3 part, but playback of all the mpeg* codecs is pretty grey
<jdong> Tonio_: in fact the whole thing is pretty grey.
<Mithrandir> mvo: I'll ask bdmurray to poke at it tonight.
<seb128> Tonio_: no, it's not legal, nobody payed the patent to ship it and it's not officially supported
<pitti> Tonio_: it's no legal difference whether the package is in main or universe; what matters is whether it is on the CDs, and it's not
<jdong> Tonio_: Novell's lawyers have stripped away every codec from their distro except WAV and the two oggs....
<mvo> Mithrandir: I did so earlier, but two pokes will not hurt I guess :)
<seb128> Tonio_: if they need legal mp3 playing they can buy the fluendo plugin
<Keybuk> Mithrandir: ok to upload sysvinit to fix LP: #83741 and LP: #96851 ?
<Tonio_> seb128: okay, I thought so because the package is in main
<Tonio_> seb128: yup that's what they'll try now
<seb128> Tonio_: dunno why it's in main but it's not on the default install nor supported officially
<Tonio_> seb128: okay, thanks for the info :)
<seb128> np
<pitti> seb128: just to get rid of the xine main/universe split, which was a PITA
<pitti> seb128: (AFAIR)
<seb128> pitti: we should just move xine to universe
<pitti> seb128: and due to the sheer popularity of audio and video codecs we provide security updates for them anyway
<Mithrandir> Keybuk: looks ok, go ahead.
<Mithrandir> ogra: can you please respond to svu on https://bugs.launchpad.net/ubuntu/+source/libxklavier/+bug/97342 ?
<ubotu> Malone bug 97342 in libxklavier "keymap support regression between version 3.1 and 3.2" [High,Unconfirmed]  
<ogra> Mithrandir, yup, will do ... i'm currently a bit busy with bug 81227
<ubotu> Malone bug 81227 in hal "Logout screen appears twice [Feisty] " [Medium,Confirmed]  https://launchpad.net/bugs/81227
<seb128> Mithrandir: would you accept a xkeyboard-config update with the po directory updated with the translations from rosetta?
<mjg59_> Anyone have any experience with netlink?
<ogra> hah, and i think i got the fix
<mjg59_> ogra: Can you run the diff past me?
<Mithrandir> seb128: hmm, unsure.
<ogra> funny that hughsie wrote functions to ignore all other duplicate button events ... just not the powerbutton
<ogra> mjg59_, if i have one ...
<seb128> Mithrandir: do you think that can cause any new bug?
<Mithrandir> seb128: I'm wondering if it can.
<pitti> seb128: hmm @ evince-gtk pot -- I would hope that it uses the evince translation domain?
<ogra> mjg59_, emit_button_pressed in src/gpm-button.c has a note that events are doubled (one from foo_Kbd_Port_logicaldev_input and one from acpi) for lid, and brightness buttons he has ignore functions ... for power thats missing
<seb128> pitti: I don't know anything about evince-gtk, it's outdated and buggy anyway :/
<ogra> so i think just adding that check for the powerbutton will help here
<pitti> carlos, seb128: the only real item on the 'missing POT' list seems to be libbtctl, rest is red herring or already fixed; I'll fix libbtctl now
<seb128> ok
<seb128> good ;)
* seb128 hugs pitti
* pitti hugs the great seb128
<carlos> pitti, seb128: Cool!
<carlos> If you do the uploads today, I will approve everything today too
<Mithrandir> doko: https://bugs.launchpad.net/ubuntu/+source/python-central/+bug/93795  ; will you have a chance to actually get this fixed?
<ubotu> Malone bug 93795 in python-central "[apport]  restricted-manager crashed with ImportError in <module>()" [High,Confirmed]  
<crimsun> Mithrandir: for bug 104130, is http://adhd.irule.net/~crimsun/feisty-freeze-exception-request-alsa-lib/alsa-lib_1.0.13-1ubuntu5.debdiff acceptable for upload?
<ubotu> Malone bug 104130 in alsa-lib "USB-Audio.conf uses the card_name function, which is not defined" [High,Needs info]  https://launchpad.net/bugs/104130
<doko> Mithrandir: actually not fixed, but this is due to `ls -l /usr/bin/python`:
<doko>      lrwxrwxrwx 1 root root 18 2007-03-18 02:04 /usr/bin/python -> /usr/bin/python2.5
<Mithrandir> doko: how so?
<doko> Mithrandir: see my email "proposed updates for feisty"
<Mithrandir> crimsun: ok
<crimsun> Mithrandir: thanks
<doko> Mithrandir: afaiu you only get these errors if you did modify the python symlink by hand; the updates are meant to explicitely fail on such hosed systems
<Mithrandir> doko: ok, so I'll just unmilestone it.
<pitti> Mithrandir: I have a two-lines patch to debian/rules of libbtctl to build a .pot file; no actual changes to the .debs; ok to upload?
<Mithrandir> pitti: yes
<Mithrandir> doko: if people break their systems, they get to keep both parts.
<doko> Mithrandir: it would be nice to fix it for feisty as suggested
<pitti> carlos: libbtctl uploaded
<carlos> pitti: thank you
<Mithrandir> doko: where is that email sent?
<pitti> seb128: urgh @ evince-gtk; I'd like to kick this out of the archive if the xubuntu guys don't care for it
<doko> Mithrandir: to you and Colin, 06.04.2007
<pitti> seb128: indeed, xubuntu-desktop does not need it any more
* pitti gets his removal knife out
<seb128> what are they using now?
<seb128> maybe ask them first
<seb128> they Recommends it
<Hobbsee> pitti: heh.  is anyone doing an archive day before release?
<pitti> Hobbsee: I wanted to do some cleanup right now, \sh also mentioned some things
<pitti> seb128: oh, I see: Recommends: evince-gtk | evince
<\sh> pitti: do you know any problems with libgcc1-dbgsym? apport-retrace throws some errors on my laptop :(
<pitti> \sh: yes, due to bug 92747
<ubotu> Malone bug 92747 in pkg-create-dbgsym "strips off epochs" [Medium,Confirmed]  https://launchpad.net/bugs/92747
<doko> Mithrandir: the bash update was reviewed by cjwatson on Friday (including the upstream patches up to bash32-013); the readline5 update has the same fix as in bash32-013. still ok to upload that at this time?
<\sh> pitti: ah ok 
<pitti> \sh: this is hard to fix, though, it requires a very intrusive diverting etc.
<pitti> \sh: workaround so far is to use -u
<Hobbsee> pitti: so will you do a full archive-run, or do you want us to give you special bug #'s?
<pitti> \sh: or just use the retracers in the DC :)
<pitti> Hobbsee: define archive run
<pitti> Hobbsee: I was planning to look over the bugs, do last syncs, removals, etc.
<Hobbsee> pitti: archive run == doing syncs and removals
<Hobbsee> cool, thanks
<\sh> pitti: well, looks like that 94446 already was worked on...but I'm missing debug syms actually...
<Mithrandir> doko: yes, please upload them.
<Mithrandir> doko: in general, it's much better to upload packages and they'll end up in the queue rather than having them somewhere else where I have to chase the uploader down.
<pitti> seb128: mailed Jani about evince-gtk
<seb128> pitti: ok, thank you
<doko> Mithrandir: ok, uploading eclipse (universe) as well
* pitti sulks after seeing the huge list of sync requests and spells out FREEZE again
<mvo> doko: if you could update the status #93795 with your proposed fix, that would be cool. I got some dup reports that gnome-app-install is not work for it and I would be interessted in what causes the problem and how to fix/work-around it
<Hobbsee> pitti: heh.  yes.
<mvo> doko: or just bounce me that mail you send 
<Mithrandir> pitti: just reject them all. >;-D
<doko> mvo: http://people.ubuntu.com/~doko/tmp/
<Hobbsee> Mithrandir: but some of them have gone thru the proper process :P
<doko> pitti: ronne is slow ...
<doko> apport running unniced ...
<pitti> whoops, it's spinning on a broken coredump.gz
<pitti> doko: will nice again, sorry
<mvo> doko: if I understand the debdiff correctly then this will make the first python postinst fail with a error if the users have modified the symlink? 
<doko> mvo: correct
<doko> and giving a clear error message
<Keybuk> I want a faster Internet Connection
* Keybuk looks into emigrating to a country whose local-loop bandwidth doesn't suck
<mvo> doko: I should probably implement that check in the release-upgrader as well then before the upgrade. otherwise it will fail pretty badly during the upgrade with bad side-effects. Mithrandir are you ok with that?
<doko> mvo: yeah, would be nice to have
<doko> Mithrandir: openoffice.org uploaded; please try to build on palmer to half the build time
<ogra> Keybuk, just move to a place near the backbone in any country i guess :)
<wwoods> pitti: ping?
<pitti> hi wwoods 
<ogra> and get a direct cable in your house from there :)
<wwoods> pitti: howdy! I'm messing with apport - trying to get it working in Fedora (well, RPM-land in general)
<pitti> wwoods: oh, great!
<pitti> wwoods: let's do that in /msg
<Keybuk> ogra: wouldn't work for the UK
<ogra> hmm
<Keybuk> since the local loop is controlled by just one company, who give pathetic speeds and extortionate prices
<ogra> i bet it would here if i moved to frankfurt
<ogra>  /me knows some people working at neuralgic points there :)
<fabbione> Keybuk: got time for a couple of questions?
<Keybuk> fabbione: sure
<fabbione> i am having a strange issue with dapper udev...
<fabbione> when i trigger a multipath command, i can see the udev events passing by (ADD), but none of the rules are executed?
<fabbione> if i restart udev the rules are executed..
<fabbione> ACTION=="add", SUBSYSTEM=="block", \
<fabbione>         RUN+="/bin/sh -c 'echo foo >> /tmp/foo.%k'"
<fabbione> as simple as it can be
<Keybuk> what's the output of "udevmonitor -e" ?
<fabbione> Keybuk: paste in /msg
<fabbione> it looks pretty normal to me
<fabbione> and that rule should catch it easily.. but it doesn't
<Keybuk> see /msg
<Keybuk> you have OPTIONS+="ignore_device" for dm-*, because it's dapper
<Keybuk> I suspect they're executed on restart because of a bug in udevplug or something
<Hobbsee> requestsync is borken :(
<pitti> Hobbsee: ISTR seeing a fix yesterday
<Hobbsee> pitti: right
* Hobbsee wonders where that might be, and checks out motu-tools
<pitti> Hobbsee: devscripts
<Hobbsee> pitti: ahh, thanks.
<Hobbsee> pitti: ah well.  time for bed.  if that doesnt go thru, i'll manually request the sync, adn poke someone about it tomorrow.
<cjwatson> Mithrandir: partman-auto translation update in unapproved; I have a bug complaining about the missing translations being very noticeable in the installer
<Hobbsee> yay, it's gone through!
* iceman is back (gone 03:09:46)
<ogra> mjg59, about bug 81227, i get events from computer_logicaldev_input_1 and from acpi_PWRF handed out from hal ... my plan is to make it ignore computer_logicaldev_input_* completely and only listen to acpi events here (like edgy did) , do you think thats ok or could there be HW that doesnt have acpi but logicaldev events for the powerbutton ? 
<ubotu> Malone bug 81227 in hal "Logout screen appears twice [Feisty] " [Medium,Confirmed]  https://launchpad.net/bugs/81227
<mjg59_> Yes, lots of it
<ogra> meh
<ogra> thats odd 
<mjg59_> Oh, hm.
<mjg59_> Maybe not.
<ogra> seems upstream does know about the problem ...
<ogra> its clearly stated in the code that there are duplicate events 
<cjwatson> hmm. Well, it's pretty clear why casper persistence is broken. Now, how to fix it ...
<mjg59_> The issue isn't a change in hal or gpm, the issue is the change in the kernel that also makes the power button an input device
<ogra> right
<ogra> but i suspect we wont change the kernel this late to make it not do that :)
<mjg59_> The kernel's entirely correct
<ogra> not in providing two events for one hardware imho
<ogra> it should one ...
<ogra> *+provide 
<mjg59_> They're via entirely separate interfaces
<ogra> anyway, we should have a fix befre release, so do you think disabling the input device event is right ? 
<ogra> s/disabling/ignoring/
<mjg59_> If what you're ignoring is the ACPI power button input device and not all input devices, that would work
<ogra> well i have: udi=/org/freedesktop/Hal/devices/computer_logicaldev_input_0, condition=ButtonPressed, details=power
<mjg59_> Yes, but that's not telling me a great deal
<ogra> with the details value that should work
<mjg59_> You can't just ignore all power buttons from input devices
<ogra> there are others ? 
<ogra> i mean others that expose themselves as "power" =
<ogra> ?
<mjg59_> details=power means that the power button was pressed
<ogra> right
<mjg59_> Yes, there are keyboards that will send that
<ogra> gah
<mjg59_> Macs, for instance
<mjg59_> (PPC ones, not Intel)
<ogra> hmm
<ogra> while it looked so easy in the beginning it now turns into being bloated :(
<ogra> there should be a way to differentiate between the different classes of power buttons :/
<Keybuk> ?! WTF
<Keybuk> how can you have different "classes" of power buttons?
<Keybuk> "this little power button went to market ...
<Keybuk>  ... this little power button stayed at home ...
<Keybuk>  ... this little power button had roast beef ...
<ogra> well, there is the system powerbutton and there are the ones mentioned above ... 
<Keybuk> they're still power buttons
<ogra> like keyboard buttons 
<Keybuk> they should still do the same thing
<ogra> i think mjg59 meant power buttons to switch off the keyboard, no ? 
<Keybuk> no
<mjg59_> ogra: ...
<mjg59_> ogra: No
<Keybuk> the key on the mac keyboard is to switch off the computer
<ogra> hrm ....
* ogra blushes
<Chipzz> Keybuk: but they don't do the same thing to start with
<Keybuk> it just happens to be an ordinary key, with a scancode, not an acpi event (afaiui)
<Keybuk> Chipzz: they should do - switch off the power
<Chipzz> Keybuk: for example, when you're in the BIOS/bootloader, and no OS is even involved yet, they may do different things
<ogra> well, but then its easy again, i just need to ignore all acpi events ... at least as long as i can be sure i always get an input and acpi event
<Keybuk> Chipzz: we fundamentally don't care about that :)
<Keybuk> that's akin to "when the computer is off, they may do different things"
<ogra> which *seems* to be the case
<Keybuk> or "when the computer is still in its box"
<mjg59_> ogra: For this specific instance, that should work
<Chipzz> the power button on the case would connect to a connector on the motherboard, while the power button on the keyboard will send a keyboard signal which needs to be interpreted
<ogra> yay, thanks, i'll prepare a patch then 
<Chipzz> Keybuk: the point is, they *are* different things
<mjg59_> Chipzz: You're not adding new information
<ogra> will send it to you for reviwew tonight
<Keybuk> Chipzz: frequently the connector on the motherboard needs an operating system to interpret the acpi code to decide what to do
<mjg59_> Pressing a power button generates an input event
<mjg59_> Under all possible circumstances
<Chipzz> Keybuk: yes, but holding down the button on the case *will* shut down the computer even if no OS is involved
<mjg59_> The issue is that ACPI ones also generate an ACPI event
<Keybuk> Chipzz: that is irrelevant to this discussion
<Chipzz> Keybuk: IMHO it isn't, since you cannot entirely control what the power button on the case does, no matter how hard you try
<AlinuxOS> pitti, hello
<Chipzz> which makes it fundamentally different
<pitti> Hi AlinuxOS 
<Chipzz> but I'll just shut up now
<AlinuxOS> pitti, how are you ?
<pitti> busy and well
<AlinuxOS> pitti, I was searching for this: mozilla-firefox-locale-ka ;) some news ?
<pitti> I'm afraid not
<AlinuxOS> pitti, why not ?  problems ?
<pitti> AlinuxOS: yes, days not having 48 hours, and Easter holidays :)
<AlinuxOS> pitti, dont worry, I'm only hopping for 19.
<AlinuxOS> pitti, simply I saw that 12 april is LanguagePackTranslationDeadline, so I've asked.
<pitti> AlinuxOS: I'll talk to asac and coordinate that
<AlinuxOS> asac new mozilla stuff coordinator ?
<pitti> yes
<AlinuxOS> pitti, ah great...
<AlinuxOS> pitti, thank you.
<asac> pitti: we want a last locale update round, right?
<pitti> asac: yes
<asac> pitti: ok ... lets see
<asac> pitti: anything special/tricky about firefox locale packs you remember?
<Lutin> seb128: could you have a look at the debdiff attached bug #92538 when you have 1 min. free ?
<pitti> asac: only thing is to rename the upstream .xpis
<pitti> asac: for new languages, there should be no renaming, of course
<pitti> asac: and removing re-appeared languages from debian/unavailable.txt (or so)
<asac> pitti: ok ... and run update-debian-files ?
<pitti> asac: right
<AlinuxOS> asac, in my case: mozilla-firefox-locale-ka
<AlinuxOS> ;)
<asac> AlinuxOS: does it exist in mozilla repos?
<AlinuxOS> asac, official 2.0 version ?
<asac> yes
<AlinuxOS> asac, http://www.mozilla.com/en-US/firefox/all.html - Georgian -  2.0.3
<Mirv> pitti: was the software-properties mo file supposed to be moved to general language packs from KDE language packs already?
<Mirv> or was it forgotten
<desrt> jono; wake up
<jono> desrt: woken :)
<desrt> jono; we need to talk... like, yesterday
<desrt> jono; did you read my email?
<jono> desrt: which mail?
<asac> AlinuxOS: if its on ftp.mozilla.org as .xpi it will get in automatically
<desrt> i sent you an email
<desrt> about joko
<jono> desrt: the ubuntu-se one?
<desrt> no.
<jono> oh
<jono> which one?
<desrt> the one from desrt@desrt.ca
<AlinuxOS> asac, I don't know this.
<AlinuxOS> asac, I'll check
<desrt> i need your reply approximately... now.
<desrt> :)
<jono> desrt: heh, you will have to wait, on phone :)
<desrt> k.
<desrt> can you give me an idea of when you're done?
<AlinuxOS> asac, where is .xpi directory here ? http://releases.mozilla.org/pub
<AlinuxOS> asac, I can't found any .xpi file on ftp.mozilla.org
<pitti> AlinuxOS: if you can point us to an URL, we can put it into the package, too
<asac> somewhere hidden :) ... its not in source, but in binary directory of the release
<maswan> http://releases.mozilla.org/pub/mozilla.org/extensions/
<pitti> asac: btw, after updating the XPIs I usually do  for loop with -UILocale to test them all (including help); sometimes they are broken
<asac> what do you mean by "including help" ?
<pitti> asac: pressing F1 and checking that it is sane
<pitti> asac: i. e. translated or English, as opposed to empty or crashing
<asac> crashing?
<pitti> *shrug* just testing ;)
<AlinuxOS> pitti, asac I can't realy find -ka locale :D
<asac> AlinuxOS: but me :)
<asac> http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.3/linux-i686/xpi/ka.xpi
<asac> its in win binary folder as well afaik
<pitti> that sounds right, ISTR grabbing them from linux-i686, although they should really be platform independent
<asac> yeah ... previously they have been released *only* from win32 directory iirc
<AlinuxOS> asac, ops :D
<asac> so maybe in a year, they will end up in source, where they belong imo
<asac> :)
<AlinuxOS> asac, yes it is Georgian locale! :)
<asac> AlinuxOS: so it will be in update (probably tomorrow)
<AlinuxOS> asac, pitti :) thanks you Guys! :)
<bddebian> Thanks pitti!
<pitti> bddebian: :)
<Keybuk> I'm going to have t-shirts made
<Keybuk> "No, your bug will not be fixed before feisty releases"
<Keybuk> :p
<Keybuk> we could have a button on Launchpad
<AlinuxOS> lol :D
<Keybuk> it could cafepress you a t-shirt with "I filed Bug #XXXXXX, it wasn't fixed for feisty, and all I got was this t-shirt"
<Keybuk> (guess the average theme of mails in MY Inbox :p)
<cjwatson> Mithrandir: any particular reason you didn't merge the parse_cmdline stuff along with the rest of casper from Debian?
<Treenaks> hmm... all the code/configs I see say that if( system_is_laptop && ac_power ) { cpufreq_governor = ondemand; }
<Treenaks> but for me it's "performance"
<Treenaks> or am I reading the wrong config files?
<seb128> Lutin: looks good, I'll upload it
<Treenaks> (or am I reading the right config files the wrong way?)
<cjwatson> ogra: where did the -t option to chvt in your ltsp patch come from? chvt(1) only documents 'chvt N', not 'chvt -t N'.
<dholbach> tepsipakki: heya do you have any idea about crashers in XInternAtom?
<dholbach> tepsipakki: bug 96615 gets a bunch of duplicates and they're somehow not retraceable
<ubotu> Malone bug 96615 in at-spi "[apport]  yelp crashed with SIGSEGV in XInternAtom()" [Undecided,Needs info]  https://launchpad.net/bugs/96615
<ogra> cjwatson, that very line was copied from dappers gdm ... and was like that in edgy ... i disabled it in the beginning of feisty and just re-added it as it was ...
<cjwatson> I'd be more comfortable relying on documented behaviour
<cjwatson> please change that to 'chvt 7'
<ogra> oki
<cjwatson> thanks
<cjwatson> (rejecting)
<ogra> it works fine though ... :)
<cjwatson> for now
<ogra> right 
<tepsipakki> dholbach: freedesktop bug 3959 is the only upstream bug which could be related
<ubotu> Freedesktop bug 3959 in Server/general "X freezes when freeing data that shouldn't be freed" [Critical,New]  http://bugzilla.freedesktop.org/show_bug.cgi?id=3959
<tepsipakki> make that the only one that I could find :)
<dholbach> tepsipakki: hum, it does not seem to crash the X server for the affected people
<tepsipakki> oh, heh
<ogra> yay, the fix for g-p-m seems to work 
<cypher1_>  is the image shown by usplash is in initramfs ?
* pitti attempts some anastacia cleanup
<tepsipakki> cypher1_: yes
<ogra> pitti, school* can go (if it still shows up there)
<cypher1_> tepsipakki, but i am not able to find it when unpacked initrd.. is it inside usr/lib/usplash/usplash-artwork.so ?
<pitti> ogra: it does, thanks; demoting
<cjwatson> cypher1_: yeah
<cypher1_> cjwatson, thanks
<cypher1_> tepsipakki, thanks
<cypher1_> cjwatson, one more question, is there any way to extract it ?
<cjwatson> it's in the usplash-theme-ubuntu source package
<cypher1_> cjwatson, ok
<pitti> tkamppeter: we need foomatic-filters-ppds as transitional package in main, right? I'll seed it
<j1mc> so i can coordinate for xubuntu testing, anyone have an idea as to when the RC testing candidates will be available?
<cjwatson> j1mc: best to ask again tomorrow; we're not sure yet
<tkamppeter> pitti, no, do not seed foomatic-filters-ppds. It is big and conflicts with foomatic-filters and probably also openprinting-ppds (at least it produces duplicate printer listings).
<cjwatson> Mithrandir: give me a shout when you get back?
<pitti> tkamppeter: oh, so is there anything in that package which is not provided by openprinting-ppds?
<cjwatson> Mithrandir: (want to talk about casper, and release bits)
<pitti> tkamppeter: if not, can we remove it entirely?
<tkamppeter> pitti, foomatic-filters-ppds is obsolete, as all PPDs in it are either auto-generated by cupsys + foomatic-db-engine + foomatic-db + foomatic-db-hpijs or ready-made in openprinting-ppds + openprinting-ppds-extra.
<j1mc> cjwatson: thanks.
<pitti> tkamppeter: ok, so I can just kick it out of the archive then?
<tkamppeter> So, pitti, we can remove foomatic-filters-ppds completely.
<pitti> great
<pitti> tkamppeter: what's the situation in Debian for this package?
<tkamppeter> Yes, pitti, you can do so.
<pitti> tkamppeter: it's still in Debian, I blacklist it then
<tkamppeter> pitti, I do not know about the Debian situation, but Debian often provides several methods to achieve the same goal.
<tkamppeter> For example Debian ships also spooler alternatives to CUPS.
<pitti> right
<pitti> removed
<tkamppeter> pitti, thanks, I already did not maintain this package due to its unnecessity and I thought that it already went away.
<ogra> mjg59, http://paste.ubuntu-nl.org/14921/ ok with you ? or should i do more compilcated string fiddling there ? 
<pitti> heno: gnopernicus wants to go to universe, is that ok?
<keescook> mornin'
<pitti> seb128: libgimme-codec wants to go to universe; shouldn't that be a dependency of something?
* pitti hugs keescook 
<keescook> hiya pitti!
<seb128> pitti: no, it should be nuked
<pitti> seb128: 'nuked' as in removed from the archive, or demoted?
<seb128> removed
<seb128> gstreamer does the job now
<seb128> they though it was making sense this way rather than having yet another lib
<pitti> cool
* pitti loves cleaning up junk
<seb128> pitti: you can remove with a "deprecated by new gstreamer API"
* seb128 hugs pitti
<seb128> pitti: cleaning the archive today, I think I'll not lot of archive work to do tomorrow ;)
<pitti> seb128: yes, I already killed syncs, backports, removals, and binary NEW, doing anastacia now
<tkamppeter> pitti, I am closing/moving all bugs on foomatic-filters-ppds.
<pitti> seb128: however, source NEW and anastacia should give you some fodder tomorrow ;)
<pitti> tkamppeter: thanks
<seb128> pitti: ok ;)
<pitti> seb128: hmm, gtranslator wants to go to universe, too?
<pitti> seb128: and gnome-doc-tools
<tkamppeter> pitti, was foomatic-filters-ppds a default installation part of a former Ubuntu? Do we need certain tags or transitional packages in any other to smoothly update from all old Ubuntu versions?
<pitti> tkamppeter: that's independent from the removal; if files conflict, there needs to be a Replaces:/Conflicts: somewhere
<seb128> pitti: I would be surprised if gtranslator was a Depends of something once, somebody has likely changed a seed
<pitti> tkamppeter: presumably in openprinting.org-ppds, since the others are autogenerated?
<seb128> pitti: I'll look at gnome-doc-tools tomorrow, I think it's useful for GNOME
<pitti> seb128:
<pitti> committer: Daniel Holbach <daniel.holbach@ubuntu.com>
<pitti> branch nick: ubuntu.feisty
<pitti> timestamp: Tue 2006-11-28 11:21:30 +0100
<pitti> message:
<pitti>   drop gtranslator from supported. Jordi, Danilo and Carlos agreed on it not qualifying for main (crashy, unmaintained)
<seb128> ok
* pitti demotes then
<seb128> pitti: makes sense to demote it
<seb128> pitti: keep g-d-t for today
<pitti> seb128: right, I'll leave that to you tomorrow
<Adri2000> pitti: when you have some time, could you update http://people.ubuntu.com/~pitti/scripts/requestsync (it is linked from the wiki) as it is in the package devscripts, because it currently doesn't work
<pitti> Adri2000: I rather remove it, I think; the devscripts version is the authoritative one now
<pitti> Adri2000: removed, thanks
<Adri2000> ok, I'm updating the wiki page then
<pitti> Adri2000: can you please update the wiki?
<Adri2000> :)
* pitti hugs Adri2000, thanks again
<mlankhorst> I used my knowledge of python to figure out why guidance-power-manager stopped working and added a few cpu scaling governors, where should i submit the patch?
<pitti> Mithrandir: I uploaded a new language-support-lt to add thunderbird-locale-lt dependency (anastacia)
<ogra> mlankhorst, file a bug and attac the patch there
<ogra> *attach
<tkamppeter> pitti, I was thinking about older versions perhaps not having foomatic-db, foomatic-db-engine, foomatic-filters, and foomatic-db-hpijs installed by default but foomatic-filters-ppds, and when updating these to Feisty, they would perhaps stay without printer info. There it would be nice that foomatic-db, foomatic-db-engine, foomatic-filters, foomatic-db-hpijs, and cupsys 1.2.x get automagically installed when updating such an old Ubuntu t
<tkamppeter> o Feisty.
<pitti> tkamppeter: then one of the newer source packages should build a transitional package which depends on those
<tkamppeter> pitti, would it work if foomatic-db produces a binary package named foomatic-filters-ppds which does not contain any files but depends on foomatic-db, foomatic-db-engine, foomatic-db-hpijs, foomatic-filters, and cupsys >= 1.2.0?
<pitti> tkamppeter: that sounds appropriate
<pitti> tkamppeter: well, I'd avoid the cupsys dependency
<tkamppeter> pitti, foomatic-filters-ppds is bug-free now.
<pitti> tkamppeter: and foomatic-db-engine is certainly already a dependency of foomatic-db or so?
<heno> pitti: yes please
<tkamppeter> pitti, the cupsys dependency is for the PPD auto-generation.
<mlankhorst> zary boogs found
<pitti> tkamppeter: hmmkay; it's just a transitional package after all, but cupsys dependency looks weird
<heno> my amd64 test machine just broke down :(  That's going to be a problem
<tkamppeter> pitti, imagine an old Ubuntu has CUPS 1.1.x and foomatic-filters-ppds and we update foomatic-filters-ppds. Without the cupsys dependency I would get all new Foomatic packages but stay with cupsys 1.1.x and due to missing auto-generation the user will only see the 10 PPDs which come with CUPS.
<pitti> tkamppeter: ok, convinced :)
<pitti> seb128: erk, the new libnet-dbus-perl dependency of system-tools-backends requires a handful of perl modules, i. e. some MIRs
<tkamppeter> pitti, or would a "Conflicts: cupsys < 1.2.0" also force a cupsys update when upating foomatic-filters-ppds (and do nothing if no cupsys is installed)?
<pitti>  tkamppeter: that works, too (use Breaks:, though), if the package makes sense without cupsys
<cjwatson> also use << rather than <
<doko> Mithrandir: OOo upload not yet accepted, correct?
<mlankhorst> sent patch :-)
<tkamppeter_> pitti, what is different when I use "Breaks:" (Internet connection was interrupted)?
<pitti> tkamppeter_: it causes less disruption in apt, and can be resolved easier
<pitti> mvo, iwj: ^ just to confirm, Breaks: now fully works in feisty?
<zyga> re
<crimsun> pitti: apologies for the many sync requests; we're pulling them from a Debian RC bug list that Andrew's script generated for universe
<pitti> crimsun: no apology needed, that script is great!
<pitti> crimsun: can it also be run on main?
<crimsun> pitti: he has spoken about extending to it main, yes.
<mvo> Mithrandir: could you please approve the recent command-not-found upload? it fixes bug #95598 (targeted for feisty) and conatins a general datafile update for current feisty
<ubotu> Malone bug 95598 in command-not-found "recommends packages in universe in preference to packages in main" [High,Fix committed]  https://launchpad.net/bugs/95598
<seb128> pitti: what new system-tools-backend? did we upload any new version recently?
<pitti> seb128: no, they are probably lingering in anastacia for a long time already
<seb128> hum
<seb128> what are they in anastacia
<pitti> seb128: or, alternatively, libnet-dbus-perl itself changed to require those new dependencies
<seb128> they are already in main and having something depending on them, no?
<zyga> mvo: yay for cnf! :D
<seb128> have
<pitti> seb128: http://people.ubuntu.com/~ubuntu-archive/anastacia.txt, first section
<pitti> zyga: cnf?
<seb128> pitti: weird, we build CD with packages from universe?
<zyga> pitti: command-not-found, mvo helped me greatly today :-)
<zyga> so that we can make much better cnf for feisty :-)
<pitti> zyga: ah, that one; indeed, that rocks
<pitti> seb128: no, I don't think so
<seb128> weird
<seb128> s-t-d didn't change since beta
<pitti> seb128: OIC: those are just build deps
<seb128> ah ok
<pitti> which doesn't change the MIR situation, but explains why they are installable
<seb128> I'll do MIR, is there any hurry?
<pitti> seb128: maybe we can even change the package to build without all those additional stuff?
<seb128> it has an copy
<pitti> seb128: not that urgent, we just need to settle it before release
<seb128> ok, "before release"
<seb128> that was my question
<pitti> seb128: I can take a look at it as well, I guess you are busy with gnome still
<pitti> seb128: and I changed to 'do fixes here and there' mode already
<seb128> pitti: I'll have a look tomorrow
<mvo> zyga: heh :) thanks! I can only give that back, you worked hard on it today 
<mvo> too late
<bluefoxicy> Feisty Fawn will be available on shipit CDs for a small fee right?
<bluefoxicy> And can we start getting these on labeled CD-RWs instead, and order them during the development cycle?  It'd be neat to have Feisty Fawn CDs early in the dev cycle, and burn them up to the latest release.  Save me time on waiting for CDs to arrive ;)
<tkamppeter> pitti, or any dpkg expert, on using "Breaks: cupsys << 1.2.0" I get:
<tkamppeter> dpkg-gencontrol: warning: can't parse dependency cupsys << 1.2.0
<tkamppeter> dpkg-gencontrol: error: error occurred while parsing Breaks
<pitti> mvo: ^ ?
<tkamppeter> Does "Breaks:" really exist?
<seb128> did you try "cupsys (<< 1.2.0)"?
<Keybuk> bluefoxicy: afaik, we're doing ordinary shipit for feisty; so free CDs, etc.
<Keybuk> they're pressed CDs, not burned, so labeled RWs wouldn't be possible right now
<pitti> tkamppeter: right, of course you have to enclose it in parentheses
<bluefoxicy> Keybuk:  nods.  I suppose pressing is easier when you have the facility.  I just don't like waiting the month or two to get them
<mvo> pitti, tkamppeter: breaks should be fully supported now, yeah
<tkamppeter> pitti, will try it. Thanks.
* bluefoxicy laughs as someone complains about the ugly orange/brown color again
<wasabi_> I have thought of a really fun extension to launchpad-integration I want to make.   "Open Source". I want it to be able to pop open the source code for any app. =)
<bluefoxicy> I have blubuntu so I no longer have to care
<mvo> wasabi_: that is a cool idea!
<tkamppeter> pitti, mvo, now it works perfectly. Thanks. Will make the new foomatic-db files available for upload.
<pitti> tkamppeter: great
<pitti> wasabi_: bringing the 'source' button of OLPC to Ubuntu!
<mvo> tkamppeter: cool!
<pitti> have a good evening everyone!
<jcole> why does network-manager get installed in feisty?
<jcole> when i remove network-manager, my whole system destabilizes
<jcole> $ liferea
<jcole> libnm_glib_nm_state_cb: dbus returned an error. (org.freedesktop.DBus.Error.ServiceUnknown) The name org.freedesktop.NetworkManager was not provided by any .service files
<jcole> so, my question is, since network-manager is a dependent of ubuntu-desktop, is it a bug?
<ScottK> So your question is if you remove standard system files and the system no longer works is that a bug?
<seb128> jcole: looks like a bug of the app, if it needs network-manager it should use a Depends then
<jcole> ScottK: i'm not sure i would label every package in ubuntu-desktop as a "standard system file"
<ScottK> jcole: True, but only so many configs can be tested and if you step outside those configs, I tend to think it's on your own nickel, but what seb128 says makes perfect sense.
<cjwatson> ScottK: removing packages that are Recommends of ubuntu-desktop is supported.
<ScottK> cjwatson: Thanks.
<cjwatson> which is not to say bug-free
<jcole> seb128: i originally removed network-manager since my networking was really slow with it, so i removed it... after removal though, apps i use consistently such as firefox, gaim, and evolution freeze up constantly
<seb128> that's weird
<seb128> did you restart dbus?
<mlankhorst> I prefer knetworkmanager O_O
<mlankhorst> which is same as network-manager
<giskard> how can be the network slow with n-m?
<giskard> mlankhorst, knm is a front-end, as nm-applet
<jcole> seb128: my system has been rebooted a few times since due to kernel updates
<seb128> mlankhorst: not the right chan
<mlankhorst> I'm aware
<jcole> try to remove network-manger for a day
<jcole> manager*
<mlankhorst> then I wouldn't have wireless networking
<seb128> jcole: it's only configuring your network, no reason for it to be slower if the config is done correctly
<capiira> hi all anyone know where i can get the feisty kernel source for linux-image-2.6.20-14-generic? so i can compile it by myself
<mlankhorst> linux-source
<capiira> is there no ubuntu kernel source with all the defaults that ubuntu use?
<capiira> i just need to disable USB_SUSPEND kernel option to make my scanner work
<mlankhorst> capiira: just copy the /boot/config-* file to /usr/src
<capiira> yeah but ubuntu also added extra drivers etc. to the kernel
<jcole> seb128: after a fresh feisty install i knew network-manager was the culprit to my slow networking cause everything sped up after i removed it... i notice there has been some updates to network-manager recently so maybe all is good... i'll keep testing
<jcole> damn
<jcole> heh
* jcole should probably quit griping and acknowledge that feisty is still in a bit of a flux 8)
<Mithrandir> cjwatson: casper> I didn't like it, but I guess I might be inclined to change that for feisty+1
<capiira> so there is no download location to have a 100% identical ubuntu kernel with just USB_SUSPEND off?
<capiira> and i will need to use the kernel.org one?
<cjwatson> Mithrandir: so I found a couple of obvious-ish problems in casper that were breaking persistency
<cjwatson> Mithrandir: one is that the Debian merge was half-done, and root_persistence et al were unset
<cjwatson> Mithrandir: the other is that the lack of parse_cmdline means that PERSISTENT could never be set even if you put persistent on the command line
<cjwatson> Mithrandir: however, having fixed both of those, I still can't quite get it to work
<cjwatson> Mithrandir: even after having stuck in a udevsettle, the USB disk seems to appear somewhere between looking for $root_persistence and looking for $root_snapshot_label
<cjwatson> maybe I should try adding a udevtrigger as well
<cjwatson> Mithrandir: are you dealing with the unapproved queue? in particular I'd really like console-setup and partman-auto (which I uploaded so can't review)
<Mithrandir> cjwatson: yes, I'm doing it right now
<cjwatson> thanks
<Keybuk> this is damned odd ... my DNS server has randomly stopped working
<RoTeR> borschty is you interested in look at a disabled people having sex movie?
<seb128> Mithrandir: would you accept http://bugzilla.gnome.org/attachment.cgi?id=85207&action=view (https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/82322)? it adds a string to the evolution encoding menu
<ubotu> Malone bug 82322 in evolution "Arabic encoding not included" [Low,Confirmed]  
<RoTeR> borschty is you interested in look at a disabled people having sex movie?
* mode/#ubuntu-devel [+o Keybuk]  by ChanServ
* mode/#ubuntu-devel [+b *!*roter@*.dip.t-dialin.net]  by Keybuk
* RoTeR was kicked off #ubuntu-devel by Keybuk (no, we are not interested)
<Mithrandir> seb128: yes, please.
<seb128> Mithrandir: ok, doing an upload soon then
<cjwatson> Mithrandir: I've committed my casper changes, but as I say they don't quite work for me. :-(
<cjwatson> (they don't make things any worse, but ... still no great drive to upload them unless they work for *somebody*)
<Mithrandir> cjwatson: thanks; I'll see if I can find the time to look at them while spinning CDs.
<harpreet> Colin: Hi Colin - Harpreet here from Sun
<cjwatson> harpreet: hi
<cjwatson> harpreet: the description you sent of your changes looked reasonable to me
<harpreet> Colin: I wanted to upload the GlassFish packages. Double checking to see if revu is still the place to upload.
<harpreet> Colin: Thanks - sigh of relief :-)
<cjwatson> harpreet: if that's how you worked last time, it's still good
<shawarma> Does the ubuntu user on the liveCD have a password?
<cjwatson> I was kind of hoping dholbach would reappear to upload them, but I guess he's done for the night
<harpreet> Colin: great I will upload the packages and send you an email.
<cjwatson> thanks, if all else fails I'll see if I can extract them from revu to upload them myself
<cjwatson> harpreet: sorry again for the speed-bumps in the process
<harpreet> Colin: So what happens next? When do you get back to me with a final green signal?
<harpreet> Colin: speed bumps - I have bitten away all my nails :-). Thanks for  the review.
<cjwatson> harpreet: it's a hectic time for us right now, but I guess it will probably be (very) late tonight
<harpreet> Colin: Thanks - I will sign off now. I will upload and send an email to you in the next 2 hours.
<cjwatson> great
<cjwatson> Mithrandir: give me a ring if you need anything; my mobile's switched off but my home number is available
<Lutin> seb128: thanks for the python-gpod upload
<Mithrandir> cjwatson: thanks.  I think I'm fine, but having a backup is useful.
<seb128> Lutin: np, thank you for the patch
<jcole> ok, my guess is network-manager "registers" with dbus but does not "unregister" when it's uninstalled affecting all apps that use dbus
<jcole> after reinstalling network-manager networking does not seem slow and my apps have not froze up yet
<giskard> jcole, did you reload dbus? (but this should be done by the postrm script)
<smurf> giskard: n-m does not *have* a postrm script
<Keybuk> debug1: An invalid name was supplied
<Keybuk> Cannot determine realm for numeric host address
<Keybuk> ^ never seen that from ssh before
<Mithrandir> Keybuk: kerberos enabled by default, afaik
<Keybuk> damn
<Keybuk> rebooting everything cured my DNS problem
<giskard> Keybuk, http://www.debian-administration.org/articles/276
<jcole> giskard: ya, after a reboot and a login, dbus seems to reload via the gnome-settings-daemon
<giskard> only after a reboot due to the dbus init script, afaik
<jcole> crap, gaim froze up agian
<jcole> so did evolution
<jcole> *sigh*
<jcole> well, i'm not sure how to debug this
<jcole> http://jcole.org/gaim_freeze.png
<Mithrandir> seb128: are all the tarballs done and uploaded?
<seb128> Mithrandir: yes, I've not uploaded gnome-python it ftbfs due to a python2.5 bug (archive version does the same) but we don't need it
<Mithrandir> seb128: ok, thanks.
<seb128> np
<cjwatson> Mithrandir: ubiquity uploading in a few minutes
<Mithrandir> cjwatson: few enough that I can review it before the publisher hits or should I hold it back?
<cjwatson> hmm, and need a d-i upload too
<cjwatson> that will have to be one publisher run hence though
<cjwatson> (for console-setup)
<Mithrandir> ok, so I should just let it run, then?
<cjwatson> Mithrandir: err ... depends how fast I can build it
<seb128> Mithrandir: I've just uploaded evolution listing arabic encoding
<Mithrandir> seb128: thanks a lot.
<seb128> Mithrandir: it fixes also the "opening evolution calendar from the gnome-panel applet broken"
<seb128> Mithrandir: np
<Mithrandir> seb128: yay, you rock.
<seb128> ;)
<Mithrandir> seriously, you do.
<seb128> you rock as well!
* seb128 hugs Mithrandir
<Mithrandir> cjwatson: you don't need the new console-setup for ubiquity too?
<cjwatson> Mithrandir: *handwave* pay no attention to the man behind the curtain
* Mithrandir nods.
<cjwatson> (that's done at source upload time, so I can fake it into place)
<Mithrandir> I know
<Mithrandir> I just thought you didn't want to fake it.
<cjwatson> nah, don't mind doing it there, I do it often enough and it's easy
<cjwatson> Mithrandir: in unapproved now
<shawarma> Does the ubuntu user on the live cd have a password?
<Mithrandir> shawarma: blank one.
* shawarma slaps his forehead.
<Mithrandir> I should really write that queue-to-rss tool at some time, so I can hook an IRC bot into it.
<shawarma> I didn't even think of trying that.
<shawarma> Mithrandir: Thanks.
<Mithrandir> it's documented in the casper script, but I don't know of any other useful places to document it.
<Mithrandir> the idea is the user should never see it.
<shawarma> True.
<Mithrandir> cjwatson: accepted; publisher running.
#ubuntu-devel 2007-04-11
<pygi> someone who is either a soc mentor or admin would be welcomed to #duplicate-resolution on slashnet
<pygi> otherwise some of the candidates will GET DROOPED!
<pygi> thank you very much
<pygi> siretart, poke :P
<pygi> ajmitch, poke :P
<pygi> hm, who else to poke :)
<mc44> I think its doko_ or Keybuk
<pygi> fabbione, ogra , Mithrandir , and seb128 :)
<pygi> doko_, poke you as well :p
<pygi> mc44, yup, they are :p
<pygi> they have 3 more minutes
<keescook> anyone a GSoC admin?
<keescook> google has some issues with ubuntu's GSoC project, it seems.
<pygi> keescook, I'm hunting them!
<keescook> pygi: ah, you're way ahead of me, thanks!
<Mithrandir> Scott is our gsoc admin.
<pygi> Mithrandir, well, you can do same as he can
<Mithrandir> I can?
<pygi> Mithrandir, let me tell you situation, you have 2 mins
<pygi> you have students above the line without assigned mentor
<Mithrandir> what's an irc server on slashnet?
<pygi> please do assign the mentors
<pygi> irc.slashnet.net
<pygi> I guess
<pygi> #duplicate-resolution
<Mithrandir> doesn't seem correct, no
<pygi> hm, ah , it's .org
<pygi> Mithrandir, talk with lh, or Gammara, or someone, but you have 2 mins :P
<mc44> pygi: they sure give a lot of notice :)
<pygi> hm, you can't assign a mentor as a regular mentor, true :(
* pygi just remembered that from last year
<pygi> Mithrandir, do poke them
<pygi> this is great lol
<pygi> mc44, one minute warning :P
<ajmitch> pygi: you were poking me for something?
<pygi> ajmitch, yes, it's over now tho
<ajmitch> pygi: ok
<ajmitch> I see it was soc stuff, I'm not involved there
<pygi> oh, not this year
<pygi> oki then
<shawarma> apcalc fails to build in sparc buildd's, but works fine in a sparc pbuilder. The only way to debug this, it seems, is to add a tiny bit of debugging to the build, upload a new version, and see why it breaks.. Would that be ok at this point?
<Mithrandir> it's needs-build on sparc, it seems
<shawarma> Mithrandir: Sorry, I meant ia64.
<shawarma> Mithrandir: It's the same problem as the previous version.
<Mithrandir> it's bailing on not having a tty, it seems?
<shawarma> No, it's bailing on a regression test that tests if isatty works as it should.
<Mithrandir> hm, ok
<pygi> mc44, keescook : you're students?
<shawarma> According to infinity there's no significant difference between the ia64/sparc buildd's and the rest of the buildd's, so there's no particular reason why it should fail on those.
<mc44> pygi: nope
<keescook> pygi: nope, just know other people watching that channel that alerted me to Ubuntu's pending SoC doom.  :)
<pygi> haha :)
<shawarma> ...so either isatty is broken, apcalc's isatty is broken, or an assumption made by that regression test is not properly fulfilled on those two arch's buildd's...
<Mithrandir> no idea.
<shawarma> ..but works in a pbuilder (at least on sparc).
<ajmitch> keescook: just not enough mentors?
<pygi> Mithrandir, dunno if you're happy about that, but my conflict has been resolved in ubuntu's favor
<keescook> ajmitch: I guess?  I'm not really paying attention; I was just passing along the alert.
<shawarma> Mithrandir: Me neither. That's why I want to upload a version that just adds a tiny bit of debugging, so I can look at the build logs. 
<Mithrandir> we're going to lose a bunch of spots due to missing mentors, I suspect.
<ajmitch> keescook: right :)
<Mithrandir> shawarma: sounds sane to me.
<ajmitch> Mithrandir: that's unfortunate
<Mithrandir> pygi: yes, I noticed, good. :-)
<shawarma> pygi: Ah, so you already know that you're accepted? Lucky. :-)
* ajmitch would have offered to be a mentor, but it'll be far too late for that, and then there's the time issue
<pygi> shawarma, yup, I was in a conflict
<shawarma> pygi: What was the other org?
<pygi> ajmitch, that's not the problem. We don't have soc admin here
<pygi> shawarma, mono
<shawarma> pygi: Oh.
<pygi> Mithrandir, yup, sadly :-/ How many slots did ubuntu got this year?
<shawarma> Wow, I hope I had a mentor assigned..
<pygi> shawarma, so you are a student :P
<shawarma> pygi: That too. I have many hats.
<shawarma> :-)
<pygi> shawarma, which project?
<shawarma> Ubuntu. 
<pygi> I know that ergh
<pygi> what is it about
<shawarma> Oh.. It *did* seem like a silly question. :-)
<ajmitch> heh
<shawarma> I've proposed a couple of web based configuration interfaces for... well, stuff.
<shawarma> One is for managing large numbers of servers (essentially by managing a set of metapackages) and the other is for configuring "small business servers" (ie. groupware stuff, printer sharing, file sharing).
<pygi> ie. ubuntu-instant-server :P
<shawarma> I don't really dig web interfaces myself, but I'm tired of setting that stuff up for clients, so this seemed like a good idea.
<shawarma> pygi: Well, yes. I've created spec's for both my applications, so mine is called ubuntu-easy-business-server. Yes, it sucks.
<shawarma> I would have hijacked one of the existing ones, but Launchpad thinks it's a bad idea.
<pygi> shackan, you do know me and matt initially created the specs, right :P
<shawarma> pygi: mdz?
<pygi> not that one :)
<pygi> galvin
<shawarma> pygi: ah. No, I didn't. It was a UBZ thing?
<pygi> nop
<shawarma> pygi: Or UDU?
<pygi> just out-of-the-blue-sky kind of thing :P
<pygi> which never really got anywhere, since it was just an idea
<shawarma> Oh, ok. I believe there was discussion about it at either UBZ or UDU (I didn't attend either).
<shawarma> pygi: Right. well, depending on the outcome of the gsoc election process, this one will actually come around.
<shawarma> Well, I'm off to bed. I've got an early start tomorrow.
<pygi> night
<shawarma> G'night guys. 
<ajmitch> night shawarma 
<cjwatson_> Mithrandir: d-i uploaded
<Mithrandir> cjwatson: \o/
<Mithrandir> cjwatson: if you happen to be up when it and ooo finishes building, care to start spinning CDs?
<Mithrandir> I'm off to bed now.
<Fujitsu> Night, Mithrandir.
<cjwatson> Mithrandir: ok, not sure whether I will be but we'll see
<keescook> Mithrandir: if you want to snag them, I've just uploaded two security fixes for KDE (kdelibs, qt-x11-free)
<Mithrandir> keescook: can you get cjwatson to poke at them, if he has the time?  I'm off to bed and am very very tired.
<keescook> Mithrandir: okay, cool.  g'night
<keescook> cjwatson: ^^ some security updates waiting in the feisty queue, if you want to grab them.
<micahcowan> mako, do you mind if I PM you, regarding membership application?
<mpt> Can someone give me an example of an Ubuntu package that is so simple and reliable it won't have had any bugs reported on it ever?
<mpt> ("hello" had one bug reported about it)
<jdong> hahaha
<desrt> muine-shell, i hope :)
<jdong> xserver-xgl!
<jdong> prevu probably doesn't have any yet
<jdong> never mind
<jdong> grr.
<mpt> desrt, thank you
<desrt> there are bugs that mention muine-shell but none against it :)
<bhale> desrt: nice :)
<desrt> bhale; thx :D
<desrt> mpt; might i ask why?
<mpt> desrt, bug 104027
<ubotu> Malone bug 104027 in malone "cannot go from package overview to package bugs" [Undecided,Needs info]  https://launchpad.net/bugs/104027
<desrt> ahh
* micahcowan goes to see what bug hello had...
<cjwatson> mpt: ed
<fabbione> morning
<ajmitch> hi fabbione 
<pitti> Good morning
<Fujitsu> Hi pitti.
<Mithrandir> hiya pitti, Fujitsu 
<pitti> hey Mithrandir, how's it going?
<Fujitsu> Hey Mithrandir.
* pitti grumbles about nvidia-glx-new b0rkage and files a bug
<Fujitsu> Why do we have a -new now?
<Mithrandir> pitti: just woke up, I'm hoping the world hasn't blown up yet.
<Mithrandir> pitti: what's borken with -new?
<pitti> Fujitsu: it was apparently too late to get the grand unified package working
<pitti> Mithrandir: the driver modprobes nvidia instead of nvidia_new, so that you get an ABI failure
<Mithrandir> ugh.
<Fujitsu> pitti: But why do we need the third variant in the first place?
<pitti> Fujitsu: it's a really ugly hack to not break upgrades from Edgy
<Mithrandir> Fujitsu: because the nvidia driver doesn't work with the 8xxx series of cards, AIUI
<pitti> I think this was a very expensive bug fix, since now we have three versions chained to our testicles
<pitti> s/bug fix/workaround/
<Fujitsu> I love binary drivers.
<pitti> the rationale for upgrading to 97xx in the first place was 'we cannot ensure security support for 96xx'
<pitti> and now they are back :(
<Fujitsu> 97xx breaks some cards, does it?
<Mithrandir> pitti: does that only break if you have -new installed or in all cases?
<pitti> Mithrandir: if you have -new installed
<pitti> Mithrandir: i. e. enable desktop effects with a new card -> b0rk
<Mithrandir> ok
<pitti> Mithrandir: this seems sufficiently milestoneish to me? (not for RC)
<Mithrandir> I'm trying to make up my mind if this is RC-critical or not.
<Mithrandir> I think it is.
<pitti> but should be fixed for final, or we should otherwise revert to a more sane state
<Mithrandir> I'll roll ISOs now so we can start the testing
<Mithrandir> and I'll just accept the fix if we have it, even if it doesn't make it onto the cds.
<fabbione> Mithrandir: i am about to upload multipath-tools to make it working with feisty.. it would be really good to have it in for RC...
<fabbione> Mithrandir: it took a bit longer than i expected due to hem.. a lot of other bugs
<Mithrandir> fabbione: probably too late for RC, but please upload it so I can review it.
<fabbione> Mithrandir: i am just finishing the last QA tests on sparc that has a much heavier setup for testing
<fabbione> Mithrandir: ok.. for final is good enough
<Mithrandir> thanks.
<fabbione> Mithrandir: i might have to drive you trough some of the changes if you have never used multipath before
<Mithrandir> I haven't.
<fabbione> unfortunately some of the bugs just show up with the latest changes to dmsetup & co.
<fabbione> so there was no way to really see them all before
<fabbione> ok.. if you need help reviewing the changes you just ask me and i can give you access to the test plant
<fabbione> pitti:  i have a fix for #98518 in feisty.. finally!
<pitti> fabbione: yay; any changes from the last attached version?
<fabbione> pitti: the changes there are for dapper.. feisty is different
<fabbione> pitti: dapper will need another patch and rework
<fabbione> pitti: i decided to focus on feisty now.. and fix dapper a bit later
<fabbione> given release is in 8 days and i can avoid an SRU
<fabbione>   65    16  248901180 sdr
<fabbione>   65    17  248895013 sdr1
<fabbione> ROFL
<Mithrandir> pitti: are you looking into the lrm problem or should I?
<pitti> Mithrandir: I took a quick look at lrm-video, but it actually looks correct to me
<pitti> Mithrandir: but I don't actually know what's going on when you start X with the nvidia driver
<Mithrandir> urgh, ok
<pranav_> doko: ping
<doko> pranav_: pong
<pranav_> hi
<pranav_> I am PRANAVA SWAROOP
<pranav_> I read your comments on my GSOC application
<pranav_> Sir I will be using the same persistent layer if needed
<pranav_> doko: may i get your opinion please??
<doko> pranav_: could you just reply (as a comment) to the application proposal?
<pranav_> ok 
<pranav_> but i wanted to know if it has to be done using the same layer
<pranav_> doko: the important thing is after the module is made I wanted to make it web-based
<pranav_> ??
<pranav_> doko: ??
<Mithrandir> pitti: take a look at linux-restricted-modules-common.modprobe in the lrm source package
<Mithrandir> I'd guess there should be a -new there as well?
<pitti> Mithrandir: aah, point; I'll try that
<pitti> Mithrandir: although the X driver should try to modprobe 'nvidia', which should get routed to nvidia_new with the script already; weird
<pitti> Mithrandir: I added the line to /etc/modprobe.d/lrm-video, I'll try it now
<pitti> Mithrandir: meh, it works now without modifications; seems that today's upgrade from .16 to .18 finished some configuration
<pitti> Mithrandir: it's not the first time that an l-r-m upgrade misconfigured something, but I could never pinpoint it
<Mithrandir> ugh. :-/
<pitti> so let's declare this a red herring for nwo
<mdke> morning all
<mdke> pitti: thanks for that work yesterday.
<pitti> hi mdke, you're welcome
<mdke> I'm just looking at the archive, seems that the debs aren't there
<mdke> is something wrong with it?
<pitti> mdke: it just seems that the debs are old
<pitti> oh
<mdke> .2 and .3 aren't there
<pitti> Mithrandir: ^ I think we really want ubuntu-docs 7.04.3
<pitti> Mithrandir: it reduces .deb size from 9 MB to 1.2 and livefs size from 9 MB to about 2 MB
<Mithrandir> go for it.
* pitti figures out what is necessary for 'go'
<lifeless> wow
<lifeless> what happened ?
<pitti> lifeless: bzip2, symlinking identical files, and dropping documents which are less than 25% translated
<pitti> a solid diet :)
<pitti> bz2 doesn't help for the live fs, of course, but for the alternates at least
<Mithrandir> pitti: might not make it for RC though, but please upload it anyway
<pitti> Mithrandir: hm, the debs built successfully; failed-to-move, perhaps?
<pitti> Mithrandir: .3 was uploaded yesterday already
<Mithrandir> I reran f-t-m an hour ago
<Mithrandir> ok
<pitti> the source is in the archive
<pitti> not yet in drescher's archive
<pitti> accepted queue is empty
<pitti> where TF are those .debs?
<Mithrandir> publisher started running five minutes ago
<pitti> ah, let's hope they are in there
<mdke> strange that even .2 isn't there - it was uploaded last week, iirc
<pitti> right
<pitti> mdke: so, I wasn't aware that ubuntud-docs contained server docs, too, so for feisty+1 we can add the 25% barrier for those as well
<pitti> mdke: but let's not worry about it now, too late to tear apart everything again
<mdke> pitti: that's fine by me if it's fine by you
<doko> fabbione: please could you install eclipse on a feisty/sparc system and check if it starts up?
<fabbione> doko: how urgent is it?
<macd_> sidenote, eclipse dapper/edgy/feisty will not run the subclipse plugin.
<macd_> have tried gcj/sun
<doko> fabbione: before final release?
<fabbione> doko: ok
<doko> macd_: known issue; if you want to help, join #ubuntu-java and ask man-di
<macd_> I poked around LP looking, guess I didnt look hard enough, thanks.
<fabbione> doko: doing...
<_ion> pitti: Oh, btw, i talked with BenC yesterday and he said it's good for Feisty that the nvidia 97xx driver is only used as a fallback if the other drivers don't support a card. That will be changed for Feisty+1.
<Treenaks> _ion: just wait for the ex-Windows-gamers to come crying 'my nvidia driver is too old!'
<Treenaks> (they do that already, I know)
<_ion> They are still able to install the 97xx driver manually, but restricted-manager will offer the 96xx one if it supports the card. :-)
<_ion> That is, they will be able to install nvidia-glx-new
<Treenaks> _ion: but then $gamer is not Teh L33t! and he'll be laughed at by his friends who get 3fps more
<_ion> Heh
<Mithrandir> 14:23:35 INFO    Rejected:
<Mithrandir> 14:23:35 INFO    ubuntu-docs_7.04.3_all.deb uses bzip2 compression but doesn't Pre-Depend on dpkg (>= 1.10.24)
<Mithrandir> 14:23:35 INFO    ubuntu-serverguide_7.04.3_all.deb uses bzip2 compression but doesn't Pre-Depend on dpkg (>= 1.10.24)
<Mithrandir> 14:23:35 INFO    packaging-guide_7.04.3_all.deb uses bzip2 compression but doesn't Pre-Depend on dpkg (>= 1.10.24)
<Mithrandir> mdke,pitti: ^^ ; plz fix.
* mdke passes onto pitti 
<pitti> Mithrandir: oops, doing now
<mdke> pitti: if you post me the diff I'll put it in svn
<pranav_> doko: ping
<pranav_> doko: I am sorry i had a network problem 
<pitti> mdke: urgh, .3 doubled size again
<mdke> the build I just did is 2.8MB
<Mithrandir> mdke: how bad would it be to release RC with .1?
<pitti> Mithrandir: just an extra 7 MB on the CDs
<mdke> Mithrandir: the about-ubuntu panel entry is broken, and more disk space
<Mithrandir> mdke: ok, so it's fine for RC, but we should get it fixed for release.
<mdke> right. 
<mdke> having said that, I would have thought that pitti can upload .4 within a few minutes, right?
<pitti> mdke: well, give me 20; that package is monster-big, so it takes a while to up/download
<mdke> oh right
<Mithrandir> yes, but any upload takes a couple of hours to get through LPs bowels.
<mdke> fair enough
<pitti> Mithrandir: but I guess I can upload it anyway, just in case when we need to re-roll images for a different reason?
<Mithrandir> pitti: yes.
<mdke> pitti: in that case it might be worth reducing the deb size; if you want to have a look at increasing 0.25 and/or applying the same patch to the server material?
<Mithrandir> (please do so)
<pitti> mdke: yes, that's what I had in mind
<mdke> :)
<pitti> mdke: I'll build the debs with gzip for comparison; that should give an estimate of live fs size
<mdke> ok
<pitti> mdke: generic/server does not have any .po files?
<mdke> great phrase that, launchpad's bowels
<mdke> pitti: yeah, we use the same ones as in generic/serverguide
<pranav_> doko: i am not getting any reply??
<_ion> :-)
<pranav_> is it the network problem??
<pitti> mdke: are those the same documents, or do you only use parts of the msgids then?
<mdke> pitti: nearly the same documents with the vast majority of the msgids
<pitti> mdke: ok, so it should still work to use the --statistics approach, I guess
<mdke> yep
<pitti> mdke: generic/serverguide/po/serverguide.pot or generic/serverguide/serverguide.pot?
<mdke> pitti: they are the same.
<mdke> I hope
<pitti> not quite
<mdke> different dates?
<pitti> 336823 vs. 344869 bytes
<mdke> well, the former is the one we generate ourselves for inclusion in rosetta, the latter is the one which rosetta includes when you choose to download all po files
<mdke> i guess it's reordered or something :(
<pitti> mdke: right, seems to be just formatting
<mdke> pitti: it's the same with all of our documents I think
<mdke> I'll talk to danilo about that sometime
<mdke> pitti: is there anything that you need to resolve about that before you can upload?
<pitti> mdke: no, that's fine
<mdke> great, I'll go to work then
<mdke> cya and thanks
<pitti> thanks to you!
<dholbach> good morning
<mvo> good morning dholbach
<dholbach> hey mvo
<tkamppeter> pitti, m2300w is in main now, but when will splix and pxljr be moved? On http://archive.ubuntu.com/ubuntu/pool/ they are still in universe.
<pitti> tkamppeter: they are not seeded or depended on by anything
<Mithrandir> pitti: I seeded them in supported yesterday.
<pitti> Mithrandir: hm, they aren't in anastacia yet, and it updated since yesterday's cleanup run
<pitti> anyway, that's something I can do post-RC
<Mithrandir> pitti: : tfheen@xoog ~/seeds/ubuntu.feisty > grep pxl *
<Mithrandir> supported: * pxljr
<pitti> Mithrandir: right, I'll just wait for the next anastacia run; it's not critical for RC
<dholbach> Mithrandir: I have zenity update (only translations) and gtk2-engines update (a few bugfixes) pending - none of them are terribly important - should I wait with uploading?
<Mithrandir> dholbach: doesn't zenity use langpacks?
<Mithrandir> dholbach: gtk2-engines bugfixes, anything release-critical?
<dholbach> Mithrandir: it does use langpacks, it's a gnome update, no rc bugfixes in gtk2-engines
<capiira> hi all i tried to compile my own kernel and downloaded the linux-source 2.6.20 and used the config-2.6.20-14-generic from /boot and now i have a big 230mb kernel :) and wonder why
* pitti arghs at ctrl+alt+Fn b0rkage in gdm
<dholbach> capiira: try #ubuntu-kernel
<pitti> dholbach: ^ shall I file a bug about that or is it known already?
<capiira> thx
<Mithrandir> dholbach: put the changelog somewhere?
<dholbach> Mithrandir: http://daniel.holba.ch/temp/gtk2-engines.changelog
<dholbach> pitti: which b0rkage do you mean?
<pitti> dholbach: well, it doesn't work any more, for a couple of weeks; I believe there's an Ubuntu bug already
<Mithrandir> dholbach: please upload it, I'll accept it post-rc
<dholbach> Mithrandir: ok, thanks
<lappy> howdy all
<lappy> I am looking for Matthias Klose
<pitti> dholbach: hmm, I can't find a LP bug about that
<pitti> lappy: that's doko
<lappy> does he hang in this channel?  I have a question about the google summer of code comment made and need a response quickly before the end of GSoC deadline.
<lappy> pitti: thanks
<pitti> dholbach: oh, here it is: bug 97060
<ubotu> Malone bug 97060 in gdm "Can't switch VT from GDM" [Low,Confirmed]  https://launchpad.net/bugs/97060
<lappy> doko: you had a comment about my google summer of code spec. PyStart was the program idea.  You wanted further information but I don't quick know what you want. Could you clarify?
<doko> lappy: continuing in query
<lappy> thanks
* lappy hopes that means he is commenting aobut it now :S
<pitti> Mithrandir: ubuntu-docs uploaded
<pitti> Mithrandir: I could reduce the livefs size from 6.2 to about 5 MB, and added the Pre-Depends: to dpkg
<Mithrandir> pitti: thanks.
* pitti notices that libnet-dbus-perl never built in feisty and does the MIR stuff for it
<pitti> Mithrandir: urgh, we probably need to upgrade to libnet-dbus-perl 0.33.4 (from .3); new upstream version actually works with dbus 1.0
<pitti> Mithrandir: the current source package is really broken, and only the depwait saved us from getting it on the CDs (so the CDs still use the edgy version)
<pitti> seb128: hmm, ^ but I figure the edgy version has the same dbus_connection_close() problem? did you see any system-tools-backends bug reports which could be related to that?
<seb128> pitti: what?
<seb128> edgy version of s-t-b-? 
<pitti> seb128: Applications must not close shared connections - see dbus_connection_close() docs. This is a bug in the application.
<pitti> seb128: you certainly remember this issue?
<seb128> right
<seb128> where do you get it now?
<pitti> seb128: libnet-dbus-perl is FTBFS and dep-wait, so  it never built for feisty
<pitti> seb128: so we still have the edgy binaries for it
<seb128> you are pulling new bugs out of a hat since yesterday, stop doing that :p
<pitti> seb128: Debian has 0.33.4 now which works with dbus 1.0
<seb128> hum
<seb128> you are saying that we have a version which doesn't work with dbus 1.0
<seb128> we didn't get any bug about it, weird
<pitti> seb128: no, I just wondered whether libnet-dbus-perl not working well with our dbus could be responsible for some s-t-b bugs you saw
<seb128> ah
<seb128> no recent bugs like that, no
<pitti> seb128: well, s/doesn't work/does not close connections properly/, we might have reverted that assertion check
<seb128> would be a good idea to have a version made to work with 1.0
<pitti> seb128: ok
<pitti> seb128: anyway, we can't ship edgy with an FTBFS and outdated binaries
<pitti> erm, ship feisty
<tepsipakki> that reminds me, checkinstall fails to build on amd64 and ia64
<Mithrandir> pitti: well, what needs to be done to get it fixed?
<seb128> doko: did you look at the gnome-python build bug?
<pitti> Mithrandir: afaics, syncing libnet-dbus-perl from Debian
<pitti> Mithrandir: and I need to MIR/promote libxml-twig-perl to make it actually build
<Fujitsu> tepsipakki: Is that a bad thing?
<pitti> Mithrandir: that twig module has a whole lot of build deps which might be unnecessary (they are not binary deps), I'll try to cut them down in order to avoid 8 more MIRs
<Mithrandir> pitti: ugh, ok.  Thanks.
<doko> seb128: still fails for me early in the python2.4 build, so I don't see your problem yet
<pitti> Mithrandir: I'll mail you a diff of the upstream versions and ask for formal approval
<Mithrandir> pitti: rather ask me here on IRC
<seb128> doko: ok
<pitti> Mithrandir: http://pastebin.ca/434201
<pitti> Mithrandir: a lot of clutter due to the renamed macro :(
<pitti> Mithrandir: but it looks sane to me
<tepsipakki> "error: previous declaration of 'readlink' was here", is that error familiar to anyone?
<tepsipakki> on 64bit systems
<bluefoxicy> this is freaking weird.
<bluefoxicy> I just reinstalled feisty beta, sound still doesn't work.  gstreamer-properties TEST buttons can output sound, nothing else (even ogg123) can... hurm.
* bluefoxicy has 2 sound cards.. wonders if that has something to do with it.
<Mithrandir> pitti: please get it uploaded.
<pitti> Mithrandir: synced; it won't build anyway until I created those silly 8 MIRs for the missing perl modules build-deps
<lappy> AndrewB: howdy
<AndrewB> Hey lappy 
<ogra> Mithrandir, did you accept my gpm fix for bug 81227 ? i dont see an accepted mail
<ubotu> Malone bug 81227 in hal "Logout screen appears twice [Feisty] " [Medium,Confirmed]  https://launchpad.net/bugs/81227
<Mithrandir> ogra: post-rc.
<ogra> ok
<saispo> where i can grab the latest seeds files ?
<saispo> http://people.ubuntu.com/~ubuntu-archive/seeds/ubuntu.feisty/
<saispo> are not up2date :/
<saispo> seb128: hi :)
<seb128> lu saispo
<Mithrandir> heno: 20070410 images are up, would you like to coordinate the testing?
<seb128> saispo: are you sure it's outdated?
<ogra> that would be very strange :)
<saispo> seb128: i think, it take the kernel 2.6.20-13 and not 2.6.20-14
<ogra> 945: Martin Pitt 2007-04-10 support apport-cli ... is what i get as latest change on that branch 
<Riddell> Mithrandir: are there CDs I should be testing or not yet?
<saispo> seb128: i change them, remaster a new iso, and confirm :)
<ogra> which was yesterday night ...
<heno> Mithrandir: 20070411 images; yes
<Mithrandir> Riddell: yes, but I have some trouble with cdimage and the mirroring, it seems like it's either going very slowly or something else is up
* ogra guesses the same applies to edubuntu
<seb128> saispo: hum, indeed
<seb128> saispo: you can "bzr checkout --lightweight http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.feisty"
<cjwatson> Mithrandir: /bin/sh: unapproved-source-publish: command not found
<cjwatson> Mithrandir: ^-- cron mail for ubuntu-archive@rookery
<tepsipakki> wow, cdimages.u.c is speedier than before
<tepsipakki> a _lot_
<lifeless> seb128: you can also skip the --lightweight there, faster to update :)
<seb128> cjwatson: http://people.ubuntu.com/~ubuntu-archive/seeds/ubuntu.feisty is outdated, is that now?
<cjwatson> seb128: yeah, I already saw saispo's question and I'm looking into it
<seb128> lifeless: ok, I was just copying from the wiki :p
<seb128> cjwatson: thank you
<saispo> seb128: i talk with cjwatson about it on another chan ;-)
<saispo> seb128: thanks
<seb128> saispo: np
<cjwatson> ubuntu-archive@rookery:~/public_html/seeds/ubuntu.feisty$ bzr pull
<cjwatson> Using saved location: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.feisty/
<cjwatson> bzr: ERROR: These branches have diverged.  Use the merge command to reconcile them.
<Mithrandir> cjwatson: uh, I wonder where that's gone.
* cjwatson adds a --overwrite there
<pitti> seb128: alright, the perl goo in anastacia is all settled now; I MIRed, reviewed, and promoted everything
* seb128 hugs pitti, you rock!
<pitti> seb128: and libnet-dbus-perl is synced, so all should be well now
<heno> *** Release Candidate images are listed here: https://www.stgraber.org/ubuntu/isotesting/ Please report test results via that page ***
<pitti> heno: yay!
<Mithrandir> heno: can you mail u-d too?
<heno> Mithrandir: heh, was just doing that
<Mithrandir> great.
<Mithrandir> cjwatson: ubuntu-archive@rookery> thanks, should be fixed now.
<ogra> heno, wow, thats nice !
<heno> stgraber: ^ :)
<heno> thanks ogra
* pygi also has to thanks heno for coming yesterday (today!) late for SoC :)
<stgraber> ogra: thanks
<ogra> stgraber, what did i do ?
<stgraber> 12:11 < ogra> heno, wow, thats nice !
<stgraber> 12:12 < heno> stgraber: ^ :)
<highvoltage> ogra: probably for being fabulous?
<ogra> stgraber, ah, thats yours :)
<heno> ogra: stgraber did the coding for that web app
<ogra> hmm, according to my "Edubuntu daily CD health check" yesterdays seed change wasnt picked up for edubuntu ...
<ogra> cjwatson, Mithrandir ? it still lists schoolbell which i dropped from supported yesterday morning ^^^
<ogra> and apprently linux-backports-modules-* is broken for me as well :/
<Mithrandir> ogra: there was a problem with the seed mirror on rookery
<ogra> ah, ok
<zwnj> i have the iranian timezone problem on dapper back, in php5.  we (##php) couldn't find where the problem is yet, so just a little question.  does dapper's php5 uses systems tzdata, or something else?
<ogra> hmm, and why is my DVD oversized by 400M ....
<ogra> oh, the DVD build i have happened on the 8th ... that might be it :)
<pitti> Mithrandir: hm, cdimage.u.c behaves very weird for me; what is the definitive md5sum for amd64/desktop/Ubuntu?
<pitti> Mithrandir: first it didn't show a 20070411/ directory, now it does, but looking at it gives a 404, and the md5sum of my downloaded iso (.info is correct) doesn't match
<Mithrandir> 5f558d93b02bcacf0bc7d00f566c6b41  feisty-desktop-amd64.iso
<Mithrandir> bbe0f9dd92494784adc05a23707a7a4b  feisty-desktop-i386.iso
<pitti> hm, weird, how can I have an image from today with a different md5sum?
* pitti rsyncs again
<Mithrandir> pitti: sure you didn't rsync kubuntu or edubuntu?
<pitti> Mithrandir: oh, right, my md5sum is right, http://cdimage.ubuntu.com/daily-live/current/MD5SUMS is wrong
<pitti> Mithrandir: alright, thanks for confirming
<Mithrandir> pitti: no, it's correct.
<pitti> 074e958b10f8a8b6bb5dc463b11b84bb *feisty-desktop-amd64.iso
<pitti> 8998a16ecc7842b5d841845ea193a370 *feisty-desktop-i386.iso
<pitti> ^ for me
<Mithrandir> pitti: but use dates in there, not current since the sync isn't quite done yet.
<pitti> http://cdimage.ubuntu.com/daily-live/20070411/MD5SUMS is 404
<Mithrandir> pitti: on one of the cdimage mirrors, yes.  Not on both.
<pitti> ok, just bad luck then
<iwj> The two c.u.c hosts seem to have different files.  Ah, yes.
<fabbione> pitti: much better.. i think i fixed all of feisty into a udev rule and killed an init script :)
<Mithrandir> 91.189.88.34 is updated, 91.189.89.4 isn't, yet.
<heno> mdz, kylem, cjwatson, mvo, bdmurray, mikebro, cburg, fabbione, Riddell, kwwii, rtg, pkl, Keybuk, doko: Just a mass-ping to make sure everyone is aware the 20070411 is published and these are candidates for RC emails have gone out with instructions
<heno> Results are posted here: https://www.stgraber.org/ubuntu/isotesting/
<fabbione> heno: yes thanks i got the email but i am fixing a bug that must be done by final right now.. will start testing once this is finished
<heno> fabbione: great, thanks
<mdz> heno: thanks
<pitti> cjwatson: do you already know about the ubiquity language list being too narrow and jumpy? (that's new since beta)
<Riddell> kubuntu seems to only have empty 20070411 directories, are those still syncing Mithrandir ?
<Mithrandir> Riddell: yes.
<cjwatson> pitti: no, what do you mean?
<cjwatson> jumpy?
<cjwatson> I don't think that widget has changed since beta
<pitti> cjwatson: it's too thin, and when I change the selection it changes width
<pitti> cjwatson: and you cannot resize it manually
<fabbione> Mithrandir, pitti: multipath-tools for feisty is up.. let me know if you need help to understand the diff (and yes i know it won't make RC).
<cjwatson> no, I hadn't heard about that
<fabbione> pitti: i will attach the debdiff to the bug after lunch.. i am in a big need of food
* Mithrandir goes to take a small break while the CDs sync.
<pitti> cjwatson: http://people.ubuntu.com/~pitti/tmp/ubiquity.png, I'll file a bug then
<pitti> cjwatson: the release note button is a bit poorly placed as well, I'll mention that
<cjwatson> pitti: whoa, I've never seen it looking like that
<cjwatson> oh, I suppose it could be due to the release note URL on the CD being fixed
<cjwatson> sigh @ world
<cjwatson> pitti: please milestone the bug for ubuntu-7.04
<pitti> cjwatson: yup, will do
<ogra> funny http://cdimage.ubuntu.com/edubuntu/daily/20070411/current/
<ogra> something is cleartly wrong with the sync script for me
<ogra> *clearly
<ajmitch> the dates?
<ogra> no, the /current subdir doesnt belong there
<ogra> and it apparently contains images from january
* ajmitch only noticed them being from jan
<cjwatson> ogra: removed, thanks
<fabbione> pitti: can i do a small flood in /msg ? :)
<pitti> fabbione: sure
<pitti> cjwatson: filed, bug 105470
<ubotu> Malone bug 105470 in ubiquity "language selection table is too narrow" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105470
<fabbione> pitti: it works :)
<fabbione> (proof of concept with 16 paths to 2 devices ;))
<fabbione> pitti: /dev/sds looks sexy :)
<cjwatson> /dev/ssds
<fabbione> cjwatson: ROFL
<fabbione> fooooood
<cjwatson> the release notes hbox and both its children are set to expand=False fill=False
<cjwatson> I wonder if this is GtkLabel layout hatefulness
<ogra> grrr, where do these 400MB come from that make my DVD explode :/
<cjwatson> workaround might be to stack the release notes label and the linkbutton vertically
<ogra> hmm, looks like kde is the evil thing breaking it ...
<cjwatson> ah, perhaps linkbutton labels don't line-wrap
<cjwatson> so the length would change depending on the selected language, which would explain the jumpiness
<ogra> hrm ... why is bind9 on my DVD ?
<cjwatson> because it's supported
<ogra> hm
<cjwatson> bind9 should hardly break the bank :)
<ogra> there is no way to drop single items from the DVD, right ?
<ogra> (or a mass of items fwiw)
<Riddell> remove them from your supported seed
<ogra> Riddell, tricky for things that are not in there :)
<cjwatson> <cjwatson@cairhien ~/src/ubuntu/seeds/edubuntu-feisty>$ grep bind9 *
<cjwatson> dns-server:Task-Key: bind9
<cjwatson> dns-server: * bind9
<cjwatson> dns-server: * bind9-doc
<cjwatson> I very much doubt bind9 is a sensible target for dropping though
<Riddell> I removed linux debug from the kubuntu supported seed
<cjwatson> otherwise, Riddell is quite right, subject to usual dependency tree following
<ogra> cjwatson, i wasnt thinking about dropping it ... it wont gain me the 400M :)
<ogra> i was just wondering where it comes from whoile i was looking
* ogra just dicovered "Extra-Exclude:" in the seeds :)
<cjwatson> extra-exclude is only for packages pulled in by extra-include
<cjwatson> if you try to use it for anything else it will have no effect
<ogra> oh, ok
<ogra> i just dont want to change my CDs ....
<ogra> but seems i have to do *something* to have a DVD
<cjwatson> removing linux-image-debug as Riddell did is probably a reasonable start
<ogra> indeed
<ogra> but i suspect there has to be more ... a lot more ... i have to drop
* ogra stands stunned in front of his DVD
<ogra> i ship *all* flavors of the debug image ? 
<ogra> oh my ... ok, that should solve something then *g*
<ogra> oh and my DVD has -13 as well ... hey edubuntu gives its users choice :P
<ogra> erm, and -12 ??
<pitti> ogra: easy fodder, it seems :)
<ogra> pitti, well, probably i should rename it to the edubuntu kernel DVD :)
<ogra> three versions in all flavours :)
<Nafallo> haha
<pitti> yay, empty archive-cruft-check
<cjwatson> ogra: (pitti's obviously fixed that already, but that's best fixed on the archive admin side rather than in the seeds, FYI)
<pitti> hmm, but I already removed old kernel stuff a week ago or so
<pitti> maybe the DVDs are a bit out of date?
<Nafallo> pitti: langpacks are always initial release. makes me smile everyday ;-).
<pitti> Nafallo: due to the way they are built for the development release
<Nafallo> pitti: yea, just looks funny :-)
<cjwatson> DVDs are always a bit out of date, because they aren't normally built daily
<cjwatson> Tollef may well not have built them in the recent run
<Mithrandir> yes, the DVDs are outdated.
<pygi> seb128, around?
<pitti> erk, that /dev/hdX -> /dev/sdX transition a week ago did not transition the CD-ROM node in fstab
<pitti> Keybuk: ^ any idea about that?
<pitti> (/me grumbles about such changes a week before RC)
<Keybuk> pitti: did you use update-manager?
<pitti> Keybuk: sometimes I do, sometimes not
<Keybuk> that has a thingy to do that
<Keybuk> the problem is that the installer seems to have been writing /dev/hdc -> /media/cdrom
<Keybuk> rather than /dev/cdrom
<pitti> right
<pitti> ok, if u-m fixes it, that's fine
<pitti> I wasn't sure which thing put the UUID stuff into fstab
<Keybuk> udev puts the UUIDs in
<Keybuk> but obviously it can't put the UUID of your CD-ROM drive in ... because drives don't have them, only filesystems
<pitti> right
<Keybuk> and it'd be a bit inconvenient if it only let you mount one particular disc :p
<Nafallo> hehe
<cjwatson> pitti: do you still have that desktop CD booted to reproduce the ubiquity bug?
<cjwatson> 'cos it'll be a while before I can pull one down here
<pitti> cjwatson: I can boot it again quickly
<Keybuk> 60kB/s ... goddamnit rsync!
<Keybuk> uh-oh, it heard me, 27 now...
<cjwatson> pitti: the files in http://people.ubuntu.com/~cjwatson/tmp/105470/ should fix it; gtkui.py goes in /usr/lib/ubiquity/ubiquity/frontend/, ubiquity.glade goes in /usr/share/ubiquity/glade/
<iwj> I thought that unreadable dark blue on black text was supposed to have been fixed ?
<cjwatson> there's a similar KDE adjustment but it's simpler
<iwj> (The text console bit in usplash)
<cjwatson> so did I, usplash-theme-ubuntu 0.13
<cjwatson> doesn't seem to have been reverted in 0.14 (it was nearly reverted by mistake, but I caught that in unapproved)
<iwj> `Fix broken palette indices' ?
<cjwatson> yes
<iwj> I don't think my complaint was ever broken palette indices.
<Keybuk> interesting
<iwj> It's just that small blue text on a black background is hard to read.
<Keybuk> rsync has now gotten so slow, it would be quicker for me to get on a train, go to millbank, download onto my laptop, and take the train home again
<cjwatson> the patch in question changed the palette index used for the text
<cjwatson> and thus changed the colour ...
<cjwatson> or at least it was supposed to
<iwj> It's possible it's a slightly less dark shade of blue.
<cjwatson> I can't claim to have checked, I just remember that that was supposed to be the change that fixed that bug, that's all.
<Qalash> is smart the default package manager in feisty?
<cjwatson> Qalash: no
<StevenK> Keybuk: Surely not? The British rail system being what it is...
<cjwatson> Birmingham<->London is not exactly a minor route
<Qalash> cjwatson: what are the arguments against smart?
<hile> it's in beta?
<cjwatson> Qalash: er - the work just didn't get done
<Qalash> hile: smart?
<hile> yes
<Qalash> cjwatson: ubuntu-side, or smart?
<cjwatson> we had discussions a year or so ago about switching to it, but it hasn't made it
<Qalash> i see, thanks
<Qalash> any hopes/
<cjwatson> bit of both, I think, can't say I'm overly familiar with it
<Qalash> any hopes?
<hile> at least the package in universe says it is still beta
<cjwatson> I do know that some work would need to be done on a number of Ubuntu-specific tools (including the installer) to make it happen
<cjwatson> and smart would need extensions to support some of those
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/smartpm
<cjwatson> a number of specific issues are enumerated on the wiki page linked from there
<cjwatson> they're not "arguments against", more a to-do list
<Qalash> thank you
<iwj> So should we use importance `Serious' in the isotesting form to mean `release critical' ?
<pitti> cjwatson: confirmed, works fine with those files
* iwj reopens bug 64408
<ubotu> Malone bug 64408 in usplash-theme-ubuntu ""Urgent" text is poorly readable due to low contrast (blue on black)" [Medium,Confirmed]  https://launchpad.net/bugs/64408
<seb128> pygi: hi
<pitti> heno: btw, amd64/desktop tests include 'WinFOSS', which is not applicable?
<heno> pitti: why is that not applicable? the amd64 images should contain 32 bit winfoss?
<pitti> heno: oh, if they do, that's fine then
<heno> I tested a whole bunch for beta :)
<pitti> heno: it's hard to check without Windows :)
<pitti> (check whether it's there)
<heno> indeed
<StevenK> Yes, like anyone has a Windows XP x64 install
<pitti> I'd assume it's just the normal 32 bit win stuff
<imbrandon> heh
* iwj targets bug 105510 to feisty.  It's a very strange user experience which I think ought to be fixed somehow.
<ubotu> Malone bug 105510 in notification-daemon "hardware database notification has poor ui" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105510
<iwj> How is the livecd supposed to figure out your timezone ?
<Mithrandir> it doesn't.
<iwj> I mean, when you just boot it.
<Mithrandir> how so?
<iwj> So when Testing/Short says "If you are connected to the Internet, does the clock show the correct time?" this should be disregarded for the livecd.
<iwj> It seems wrong to me to display a time if it's quite likely to be wrong.
<Mithrandir> yes, or check if it's correct UTC.
<iwj> Well, yes, correct UTC is fine for the system clock but I don't think it's fine for a clock applet in the corner.
* Hobbsee wonders why it doesnt use the hardware clock time
<iwj> Hobbsee: In my case as it happens it is using the hardware clock time which is set to UTC.
<Hobbsee> iwj: ahh
<iwj> Since my firewall isn't letting it do ntp but that's beside the point ...
<Keybuk> iwj: should this be a show stopper?
<Keybuk> ie. if we don't fix it, should we delay feisty's release?
<iwj> Keybuk: It's not a regression so no.
<Keybuk> so file a bug, and move on
<Keybuk> there's no need to raise it at this point
<Keybuk> since there's nothing we can do about it
<iwj> Keybuk: Right but I just wanted to check with someone that there wasn't some freaky machinery for guessing your timezone that was going wrong, since that would affect what I put in the bug.
<iwj> (And would be worth looking at to see why it hadn't worked.)
<Mithrandir> iwj: I see your point, but at the same time it's easy enough to right click and choose "adjust time zone".
<Keybuk> at this point, the time would be better spent moving on to further testing
<Mithrandir> I don't think we should disable the clock on the live cd.
<Keybuk> you can always file a bug, and fill it in later
<pitti> iwj, mvo: I triaged bug 105510 a bit
<ubotu> Malone bug 105510 in hwdb-client "hardware database notification has poor ui" [Undecided,Confirmed]  https://launchpad.net/bugs/105510
<iwj> pitti: Oh, good, thanks.
<saispo> squid maintainer is in the room ? :)
<pitti> saispo: there is no Ubuntu squid maintainer
<seb128> saispo: there is no squid maintainer
<pitti> saispo: it's a collective effort
<seb128> saispo: you are welcome to help maintaining it ;)
<saispo> seb128: ;-)
<saispo> seb128: will make a patch and will send you
<seb128> saispo: thank you
<dholbach> hum - when did the nvidia driver stop working for nvidia 7100 gs?
<dholbach> it worked like two weeks ago
<saispo> hi dholbach :)
<dholbach> hi saispo
<iwj> Oh dear: bug 105523
<ubotu> Malone bug 105523 in firefox ""get help online" produces default start page" [High,Unconfirmed]  https://launchpad.net/bugs/105523
<seb128> iwj: bug #105519 is not a gnome-panel bug, it's only using the timezone configured
<ubotu> Malone bug 105519 in gnome-panel "livecd clock is (inevitably) wrong" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105519
<seb128> owand #105523 is a dup of bug #104072
<ubotu> Malone bug 104072 in launchpad-integration "Clicking "Help->Get help online" in supported applications does not work" [Low,Needs info]  https://launchpad.net/bugs/104072
<iwj> re 104072: I'll triage it.
<iwj> re 105519: Well, feel free to reassign it but as Keybuk says it's hardly urgent.
<dholbach> ok, using nvidia-glx-legacy fixes it
<dholbach> maybe restricted-manager should know that in feisty+1
<seb128> iwj: I've reassigned the clock to casper, not sure that's the right place though
<seb128> grumpf
<seb128> launchpad doesn't respond now
<Kmos> it's slowly
<poningru> so quick question will RC come out tomorrow?
<mvo> pitti, iwj: its rather late for string changes for bug #105510 :/
<ubotu> Malone bug 105510 in hwdb-client "hardware database notification has poor ui" [Undecided,Confirmed]  https://launchpad.net/bugs/105510
<poningru> bah just got the email nvm
<Kmos> bug 105520
<ubotu> Malone bug 105520 in Ubuntu "No sound after kernel upgrade (2.6.20-13 -> 2.6.20-14) in Feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105520
<poningru> heno: ping
<iwj> mvo: That's a bit unfortunate.  I think the current situation is likely to confuse the poor users.
<seb128> iwj: please use the milestone setting, the "target to release" is mean for backport to stable version
<iwj> seb128: Oh.
<Keybuk> bugs should only be milestoned if they are release critical
<cjwatson> mdz has a bug open about not offering the current development release in "target to release", IIRC
<Keybuk> any milestoned bugs left open by the end of tomorrow could delay the release
<iwj> Is bug 105525 release critical ?  (Is it even a bug?)
<ubotu> Malone bug 105525 in gnome-panel "about ubuntu menu item missing" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105525
<Keybuk> it's certainly not critical
<seb128> iwj: dholbach told me that it was supposed to be fixed with an ubuntu-docs update
<seb128> iwj: the bug is ubuntu-docs not shipping an about-ubuntu-C.omf
<seb128> dholbach: what happened to the upload?
<seb128>  ubuntu-docs (7.04.3) feisty; urgency=low
<seb128> ...
<seb128>    * Unbreak about-ubuntu panel menu entry
<seb128> iwj: ^ do you have this version ?
<iwj> /dev/sdb1: POSIX tar archive (GNU)
<iwj> Oh, so that's why it's not mounting it.
<iwj> seb128: No, I have 7.04.1.
<iwj> (20070411 livecd)
<mvo> pitti: I added somethin gto #105510 (just FYI)
<seb128> https://launchpad.net/ubuntu/+source/ubuntu-docs/7.04.3
<seb128> 7.04.3 should be available
<Mithrandir> seb128: no, it was rejected because of a missing pre-depends.
<seb128> ah
<cjwatson> 7.04.4 is in unapproved
<cjwatson> and fixes thatt
<seb128> ok, will be fixed after candidate probably then
<seb128> ok, cool
<seb128> cjwatson, Mithrandir: thank you
<Mithrandir> s/probably// :-)
<Mithrandir> it'll be accepted once RC is out
<poningru> anyone know if dvd for today will be released? for the candidate for RC?
<Mithrandir> poningru: yes, I'm going to spin DVDs too
<Kmos> poningru: you'll see it when released.
<poningru> Kmos: only asking because downloading the dvd right now and wondering if I should cancel it
<cjwatson> poningru: that's what rsync's for
<Mithrandir> poningru: rsyncing it goes much faster if you have something which is semi-up-to-date.
<poningru> !
<poningru> oh true
<poningru> ok wont stop the gig already downloaded
<poningru> also can someone here help me write something about teh sparc installer?
<poningru> https://wiki.ubuntu.com/sparc64-installer
<poningru> for the release notes/walk through
<poningru> 0.0
<mdz_> Mithrandir: is the mirroring issue fixed now?
<Mithrandir> mdz_: seems to be, yes.
<seb128> iwj: I'm fixing the launchpad integration firefox bug
<iwj> seb128: Excellent.
<geser> when is the dev meeting tomorrow? fridge list the dev meeting twice and the first collides with the motu meeting
<Mithrandir> geser: 20 UTC
<geser> then we have a problem as a MOTU meeting is also scheduled at 20 UTC
<poningru> geser: ubotu says 21UTC
<poningru> @schedule
<ubotu> Schedule for Etc/UTC: 11 Apr 20:00: Edubuntu | 12 Apr 20:00: MOTU | 12 Apr 20:00: Development Team | 12 Apr 21:00: Ubuntu Development Team | 13 Apr 20:00: Forum Council | 17 Apr 15:00: Kernel Team
<pitti> mvo: thanks
<iwj> Uh, freaky.  The update-notifier bubble has appeared wedged against the left hand side of the screen.
<iwj> Now it's timed out and gone away.
<cjwatson> were we going to have the dev meeting at all tomorrow?
<StevenK> poningru: There's two Development Team entries
<seb128> cjwatson: might be useful to discuss what we still need to work on for next week?
<seb128> cjwatson: I expect next week we will not need a meeting though ;)
<mdz> cjwatson: sent you an email about this yesterday
<saispo> seb128: where i send you the patch for squid in feisty ?
<mdz> I think we need to have a meeting if only to round up release issues, though the timing may need to be adjusted
<cjwatson> so you did, I missed that
<seb128> saispo: open a bug on launchpad if there is none and attach it there
<saispo> ok
<cjwatson> cancel next week's, leave this week alone or reschedule to Friday?
<pitti> mvo: hm, for feisty I lean towards 'keep it or disable it entirely'
<pitti> mvo: for feisty+1 such a new key was what I thought as well
<mvo> pitti: either is fine with me
<mdz> cjwatson: I think a meeting post-RC would be best
<mvo> pitti: I target the bug as "later" so that its attacked early
<pitti> iwj: that one is indeed a notification-daemon bug
<cjwatson> how about Friday 1600 UTC, and keep it short and to the point?
<iwj> pitti: Is it known about ?
<cjwatson> we'll all be tired
<pitti> iwj: not sure
<Mithrandir> cjwatson: any reason to not do it earlier?
<AnAnt> Hello, which package is responsible for scancodes ? I ran showkey -m now on both Edgy & Feisty, I found that some key combinations (for example CTRL+ALT+O) have different scan codes on Edgy & Feisty
<mdz> Mithrandir: I just got ENOENT trying to grab the i386 server ISO from one of the mirrors; a retry succeeded
<mvo> iwj: yes, sort of. we get it sometimes, but its very hard to reproduce (I wasn't able to when I tried)
<AnAnt> on Edgy it gives: keycode 7 release, on Feisty it gives:
<AnAnt> keycode  66 release
<AnAnt> keycode  32 release
<cjwatson> Mithrandir: TZ I guess
<cjwatson> any earlier is pretty hard on Brian
<iwj> mvo: Evidently a race.  Maybe it pops up before the panel has finished faffing ?
<Mithrandir> cjwatson: the regular early meeting is an hour earlier.
<iwj> Right, this install is installing and I need food.  BIAB
<Mithrandir> iirc?
<AnAnt> anyone knows what is responsible for this scan code change from Edgy to Feisty ?
<cjwatson> oh maybe I meant 1600 London
<cjwatson> AnAnt: that's a keycode change not a scancode change. scancodes are in hardware.
<AnAnt> TheMuso: ok, what is responsible for it ?
<mvo> iwj: yes, something like that. the thing is that it has a check to not show up if the location is (0,0) so it seems to be some weird in-between state in not-shown-up-yet and almost-shown-up 
<cjwatson> console-setup does keycode mapping according to /etc/default/console-setup
<cjwatson> "it changed" is not a bug per se ...
<AnAnt> cjwatson: thanks
<mvo> hrm, why can't target https://bugs.launchpad.net/ubuntu/+source/hwdb-client/+bug/105510 as later? I only get 7.04 as option 
<ubotu> Malone bug 105510 in hwdb-client "hardware database notification has poor ui" [Undecided,Confirmed]  
<Mithrandir> mvo: because "later" is an edgy milestone.
<Mithrandir> (yes, this is crack)
<heno> did we decide that bug 105523 was non-critical? If so I'll make it less red on the tracking page
<cjwatson> Mithrandir: ubiquity 1.4.10 in unapproved; I think we should have it for RC if possible
<ubotu> Malone bug 105523 in firefox ""get help online" produces default start page (dup-of: 104072)" [High,Unconfirmed]  https://launchpad.net/bugs/105523
<iwj> mvo: Maybe it needs to check periodically rather than give up looking.
<ubotu> Malone bug 104072 in launchpad-integration "Clicking "Help->Get help online" in supported applications load start page instead" [High,In progress]  https://launchpad.net/bugs/104072
<mvo> Mithrandir: heh :) 
<Mithrandir> mvo: there's no way to add a milestone for ubuntu, it has to be connected to a release.
<saispo> seb128: https://bugs.launchpad.net/ubuntu/+source/squid/+bug/105532
<saispo> the bug and the patch :)
<ubotu> Malone bug 105532 in squid "compilation error on feisty in aufs/store_dir_aufs.c" [Undecided,Unconfirmed]  
<Kmos> bug 99150
<ubotu> Malone bug 99150 in avahi "Feisty beta can't install avahi-daemon on partial upgrade" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99150
<Kmos> someone can check this uot
<Kmos> out
<pitti> saispo: does that affect the standard feisty package? if it doesn't build, that's inded a critical bug that needs to be fixed by the release
<seb128> saispo: weird, the archive version built fine according to https://launchpad.net/ubuntu/+source/squid/2.6.5-4ubuntu2
<seb128> saispo: do you have some special flag? -Werror?
<pitti> seb128: maybe the default build doesn't use USE_TRUNCATE
<pitti> hm, weren't we supposed to have a rebuild test and bug filings anyway?
<cjwatson> is anyone looking at bug 104602?
<ubotu> Malone bug 104602 in Ubuntu "root password visible at emergency console" [Undecided,Confirmed]  https://launchpad.net/bugs/104602
<Lathiat> uh
<Lathiat> how on earth did that happen
<Lathiat> init script isnt there but the package is installed
<pitti> cjwatson: yay password exposure! we seem to develop a certain tradition for that...
<cjwatson> Lathiat: you removed it before, and dpkg doesn't reinstall removed conffiles unless you use --force-confmiss
<pitti> cjwatson: I can have a poke at this; do you have a hint where to start looking?
<Lathiat> cjwatson: ok so someone has deleted /etc/init.d/avahi-daemon and not purged the package?
<Lathiat> so i guess theres nothing we can do about that then
<saispo> pitti: seems fixed in the upstream version
<cjwatson> we could not fail in that case
<saispo> seb128: yes i have some different build options
<cjwatson> it's not critical but it's still a bug IMO
<Lathiat> cjwatson: just refuse to stop/start avahi in that case?
<cjwatson> pitti: unfortunately not - my only suspicion would be some interaction between sulogin and whatever mode upstart puts the console into
<mdz> heno: are the verified current md5sums available somewhere to ensure that one has the latest images?
<saispo> seb128, pitti : http://www.sourcekeg.co.uk/squid/Versions/v2/2.5/squid-2.5.STABLE9-STABLE10.diff
<pitti> cjwatson: ok, I try to reproduce that first
<mdz> heno: (especially since there seem to be problems with the cdimage mirrors)
<seb128> saispo: not something for feisty ;)
<cjwatson> Lathiat: that's what openssh-server does (first thing I looked at for comparison)
<cjwatson> if [ -x /etc/init.d/ssh ] ; then ...; fi
<Lathiat> cjwatson: ok
<Lathiat> i doubt this is goign to go in for feisty however
<Lathiat> pretty unlikely side case
<Lathiat> but yeh fix for post
<cjwatson> yeah, like I say I don't think it's critical
<cjwatson> there are many things I think are bugs but which don't need to be fixed in feisty :-)
<heno> mdz: it should be in the MD5SUMS file; I have my rsync script download that and take the local md5sum each time
<saispo> seb128: yep, but the feisty original package rebuild fine ?
<cjwatson> you can't fix the old prerm anyway ...
<seb128> saispo: it does
<heno> mdz: did you want them posted somewhere else as well?
<seb128> saispo: https://launchpad.net/+builds/+build/313397
<mdz> heno: see above; the problem with MD5SUMS is that it's in the same place as the images
<cjwatson> Lathiat: avahi-daemon certainly violates policy by calling the init script directly rather than using invoke-rc.d
<mdz> heno: it's impossible to tell whether they're the current images or not
<cjwatson> I believe lintian warns about that these days
<Mithrandir> heno: I can give them to you and you can post them somewhere
<Lathiat> hrm, ok
<heno> Mithrandir: thanks, that saves me scraping them
<saispo> seb128: ok, for the next update of squid in ubuntu :)
<Mithrandir> heno: see /msg
<seb128> saispo: right, thank you for the patch!
<heno> Mithrandir: yep, thanks
<mvo> partman lvm paritioning calculation just took very long  (several minutes) for me (40G disk) - is that expected? 
<Lathiat> cjwatson: cheers for the pointers
<saispo> seb128: no problem :)
<cjwatson> Lathiat: np
<cjwatson> mvo: don't think so ...
<mdz> mvo: I'm seeing update-notifier come up in the live CD environment
<cjwatson> that's intentional now - pitti did that for the hwdb notification
<pitti> mdz: increase-hwdb-participation spec
<mvo> mdz: for updates? or the hwdb notification?
<\sh> pitti: do you have any detailed documentation of the launchpadBugs lib? or just "use the source, luke" ? :)
<pitti> \sh: the latter; it's not my library :)
<mdz> mvo: for updates
<mvo> \sh: you may try asking on #ubuntu-bugs
<\sh> mvo: yeah...
<cjwatson> updates> bugger. release-critical casper bug by the sound of it
<heno> mdz, Mithrandir: md5sums here: https://wiki.ubuntu.com/Testing/md5sums
<\sh> pitti: thx :)
<mdz> heno: those are for the really-truly-candidate images?
<mvo> mdz: urgh, that is bad news
<heno> mdz: according to Mithrandir, yes
<mdz> mvo: let me reboot and reconfirm; did anyone else see this?
<Mithrandir> mdz: they're from running cat of the MD5SUMS files on lithium, so yes, I would say so.
<pitti> heno: thanks, this is very helpful; I had the same md5sum problem already
<mdz> Mithrandir: thanks
<mvo> mdz: I haven't yet, but if anacron is triggered and it does a apt-get update in the background, that is entirely plausible. we need to disable that on the livecd 
<mdz> mvo: I thought we did that for...dapper
<mvo> a regression maybe? the livecd I have here contains a update-packages-list "1";
<mvo> mdz: I will report a bug now and look into it
<pitti> mvo: does it an apt-get update while adding the live CD apt source?
<mvo> mdz: hm, no anacron is runing here on the livecd
<mvo> hm, no. anacron is installed
<mvo> pitti. it shouldn't, but let me check
<mdz> mvo: I don't think that's what I was seeing, though; it looks like it was hwdb-participation (it just didn't look like I expected it to look)
<mdz> it says "information about newly installed packages available" which is clearly not the case
<pitti> mdz: bug 105510
<ubotu> Malone bug 105510 in hwdb-client "hardware database notification has poor ui" [Undecided,Confirmed]  https://launchpad.net/bugs/105510
<mvo> mdz: right. iwj reported that as https://launchpad.net/bugs/105510
<pitti> mdz: at this point, I'm inclined to say 'keep it as it is or ditch it'; fixing it properly is too late for feisty :(
<mdz> pitti: agreed, and given how high-visibility it is, I think keeping it as-is is not workable :-/
<pitti> mvo: argh @ edgy/feisty tasks on this bug
<pitti> Mithrandir: ok to upload a new hwdb-client without the notification?
<Mithrandir> pitti: yes
<mvo> pitti: malone badness, no idea how to make it sane again
<mdz> seb128: I'm not seeing previews in nautilus for the example content.  the system is fairly slow due to parallel installs in vmware; is this expected?
<Riddell> Mithrandir: new ubiquity means new desktop CDs at some point?
<mvo> pitti: if you disable the notification, we should probably disable update-notifier on the live-cd as well again
<pitti> mvo: 'again'? has it been disabled before?
<Mithrandir> Riddell: I'm trying to make up my mind over whether the number of small bits calls for a respin or not.
<seb128> mdz: depending on how slow, if it takes over 15 seconds or something it stops
<seb128> mdz: might be possible that video thumbnailing take over the limit if the system is really slow
<Mithrandir> Riddell: there are a bunch of problems, but none of them are showstoppers.  Just warts.
<mdz> seb128: ok, probably just that then
<seb128> k
<seb128> nobody else opened a bug about that for the moment
<mdz> seb128: I'll check it when the install is finished
<seb128> ok, let me know
<mvo> pitti: eh, right. I'm probably wrong here, I though it was, but if you didn't change anything, then I'm wrong
<pitti> mvo: casper disables notifications about new packages only
<mvo> pitti: ok, then all is good
<pitti> mdz, Mithrandir: new hwdb-client with disabled notification uploaded
<Mithrandir> cheers, pitti
<mdz> cjwatson: I've hit a snag on the alternate install
<mdz> cjwatson:  the progress indicator has stopped at 'Configuring x-ttcidfont-conf'
<mdz> dpkg --configure <the world> is running, with a debconf frontend as a child (hard to tell with busybox ps), then nothing further
<pitti> Mithrandir: btw, please consider accepting ubuntu-docs, so that it can build and go through soyuz, if we rebuild the CDs
<cjwatson> mdz: I've heard rumours of that before but never been able to track it down, and it seems transient
<cjwatson> there are rumours of it in Debian too I think
<cjwatson> mdz: any chance of an strace (anna-install strace-udeb) or other similar diagnosis?
<cjwatson> I suspect it may well go away if you reboot and try to do it again with debugging turned on
<mdz> cjwatson: I'm saving a vmware snapshot of it
<mdz> cjwatson: debconf frontend is blocked reading from fd 5
<cjwatson> IIRC that's just its normal input fd
<cjwatson> are there no child processes of the frontend? maybe it failed to notice SIGCHLD
<mdz> cjwatson: correct, no children
<cjwatson> should be possible to check by grovelling in /proc whether anything's connected to that pipe
<cjwatson> FWIW I do not believe that this is a new bug
<mdz> I can set the snapshot up for you to debug sometime
<cjwatson> that would be good
<cjwatson> could I have /var/log/syslog too?
<cjwatson> wondering if the x-ttcidfont-conf postinst exited in some particularly strange way
<cjwatson> perhaps if it spawned a background process and didn't disconnect it from debconf properly, that would do it
<mdz> I'm on a conference call now, will poke at it some more when I get back to my desk
<heno> mdz, seb128: I can confirm the video preview issue; it fails to make a preview on the live system but works fine on the installed one
<seb128> we had a such bug previous cycle
<seb128> somebody workarounded it to casper IIRC
<cjwatson> base-installer uploaded to fix ps3, although may be post-RC at this point
<bddebian> Heya
* pitti needs to check out something, brb
<Mithrandir> mvo: what is responsible for adding universe and multiverse to sources.list?
<tepsipakki> apt-setup?
<xtknight> you mean like Software Sources?
<Mirv> Mithrandir: did mdke bug you about whether there are those failed-to-move packages again? I asked him about the (still) missing ubuntu-docs deb package
<Mirv> and hinted that you had handled such situations before, too
<Mithrandir> Mirv: it wasn't accepted until recently.
<Mithrandir> Mirv: don't worry, I'm handling it.
<dholbach> Mithrandir: I filed a bug about that already (if you talk about the livecd)
<Mirv> Mithrandir: ok, thanks. I just looked that build succeeded early yesterday, and haven't found any further place to check where a package is going.
<dholbach> Mithrandir: http://launchpad.net/bugs/105511
<Mithrandir> dholbach: yes, which is why I'm asking mvo about what's responsible for it.
<ubotu> Malone bug 105511 in Ubuntu "Universe and Multiverse not enabled by default on the livecd" [Medium,Confirmed]  
<cjwatson> yes, apt-setup
<cjwatson> oh, on the live CD
<cjwatson> that's done in the livecd.sh script
<Mithrandir> mhm, I think we can just change it there, then.
<cjwatson> or not done, as the case may be. I suggest leaving it alone at this point unless the consequences are disastrous.
<Mithrandir> Mirv: the binaries were rejected due to a missing pre-depends, but that has been resolved now
<Mirv> Mithrandir: ok.
<mvo> Mithrandir: apt-setup, it was enabled there at feb, 8
<Mithrandir> yay, DVD almost there.
<mvo> Mithrandir: I do not have access to the livecd.sh script
<Mithrandir> mvo: that's fine, I can handle it.  Just trying to decide whether we should fix it or not.
<mvo> Mithrandir: its fine on the installed system, so we can probably leave it as it is but lets tag the bug as "later" to enable it on the livecd early
<_ion> benc: Btw, building l-r-m on my box: fakeroot debian/rules binary  3538.02s user 470.72s system 60% cpu 1:50:57.11 total :-)
<BenC> _ion: wow, took my about 15 minutes on my box
<BenC> s/my/me/
<doko> Mithrandir, ogra: the edubuntu DVD for amd64 is too big :-/
<Mithrandir> doko: known problem.
<doko> Mithrandir: ok, any estimate for an updated image?
<Mithrandir> doko: unsure if ogra has fixed the necessary bits yet.
<_ion> benc: P3 500MHz, 384 MiB, not very good ATA controller.
* doko goes back to SoC rating ...
<BenC> _ion: guess my 2 x quad-core 2.66Ghz xeon box has me spoiled :)
<_ion> :-)
<ogra> Mithrandir, the necessary bits ? i thought pitti had fixed that
<ogra> doko, erm, you shouldnt try the one for april 8th :)
<Mithrandir> I'm rebuilding the dvds now.
<ogra> thanks 
<iwj> mvo: That update-notifier race has happened to me again on the livecd on a different machine.  Is there any instrumentation you think it would be worthwhile bothering with ?
<mvo> iwj: I burn a desktop CD now and see if I see it as well. it seems like its triggered on the livecd much easier than on the real systems (because the sysstem is slower to come up with the desktop)
<iwj> Right.
<pitti> cjwatson: sexy! I just configured a raid-1 on alternate/expert without too much hassle
<Lutin> doko: what do you htink is the best to do for bittorrent-gui: use wxwidgets2.4 but stick to python2.4, or use python2.5 and use wxwidgets2.6 though it seems that could cause some issues ?
<doko> Lutin: use what works best with python2.5. maybe even use wxwidgets2.8
<pitti> mjg59: do you have a minute to discuss an usplash-related bug?
<Lutin> doko: how can I choose between 2.6 and 2.8 ?
<mjg59> pitti: Yes
<pochu> Lutin: try 2.8, and if it works better, then change the depends to 2.8 (since 2.6 is still the default)
<pranav_> doko: ping
<doko> pranav_: pong
<pranav_> is the ranking process over
<doko> Lutin: AFAICR import wxversion; wxversion.select('2.8')
<Mithrandir> heno: are we getting a new winfoss tarball from you for http://launchpad.net/bugs/105528 ?
<ubotu> Malone bug 105528 in ubuntu-winfoss "Edubuntu OpenOffice install has bad start menu links" [Medium,Unconfirmed]  
<heno> Mithrandir: IMO we should, but post-RC I think would be best
<Mithrandir> sure
<pitti> mjg59: oh, I just noticed that you aren't registered, so I didn't see any reply you might have sent me
<heno> Mithrandir: I'll make sure to test the images early after uploading
<Lutin> doko: btw..that whould break the 'support all supported python versions' thing as wxwidgets2.{6,8} are only available for python2.5
<doko> Lutin: wxwindows2.4 as well
<Lutin> doko: python-wxgtk2.4 uses python2.4
<shawarma> Could someone accept my recent apcalc upload, please?
<doko> Lutin: oh, you are right. iz' a bug
<Mithrandir> shawarma: accepted.
<shawarma> Mithrandir: Excellent. Thanks.
<Lutin> doko: oh, ok
<Lutin> doko: do you want me to update it so it uses python2.5 ?
<cjwatson> pitti: neat
<Mithrandir> ogra: your .iso is served.
<ogra> yummy :)
<ogra> still mirroring though ...
<Mithrandir> yes, DVDs take a little while to propagate
<Mithrandir> not much I can do about that, sorry. :-)
<ogra> heh, get bigger wires in the DC :)
<doko> Lutin: look at the current bug reports first (and maybe at packages using wxwidgets2.4 with python2.4)
<Lutin> doko: ok
<mdz_> cjwatson: I didn't find anything untoward about the apparent deadlock in x-ttcidfont-conf.postinst
<mdz_> cjwatson: nothing interesting in syslog, no stray processes talking on that pipe
<cjwatson> the frontend's meant to go away as soon as read() fails, but it sounds like read() isn't failing
<Mithrandir> read() could just be blocking, for some reason.
<mdz_> right, it's blocking
<ogra> Mithrandir, meh, still oversized :/
* ogra goes digging
<Mithrandir> ogra: tell me when you want a respin
<ogra> yep, will do ... 
<Riddell> Mithrandir: did you decide on new desktop CDs?
<cjwatson> right, so the question is why is it blocking
<Mithrandir> Riddell: yes, I think I've decided against respinning, unless something urgent shows up tonight.
<mdz_> cjwatson: defoma is nightmarish, I didn't go digging very far into ti
<Riddell> Mithrandir: good with me
<Mithrandir> Riddell: or do you have anything you really want in?
<Riddell> Mithrandir: nope :)
<cjwatson> reading from an empty pipe which no process has open for writing should return 0 immediately
<mdz_> the only curious thing it seems to do is re-exec itself under some circumstances
<cjwatson> so my hypothesis is that either the kernel has gone mad or there's a process with that pipe open for writing
<Mithrandir> cjwatson: does cdebconf close its own end of the pipe?
<cjwatson> it should be possible to tell the latter from ls -l /proc/*/fd | grep or something
<mdz_> cjwatson: there is a process with the pipe open for writing though
<cjwatson> which process?
<mdz_>  /usr/bin/perl -w /usr/share/debconf/frontend /usr/bin/debconf-apt-progress --from ...
<mdz_> one of its parents, several levels up
<cjwatson> so that would be frontend rather than d-a-p really?
<mdz> I imagine so; I don't know anything about d-a-p
<cjwatson> hmm, could be a passthrough frontend bug
* cjwatson wrote d-a-p
<cjwatson> not that that exonerates it :)
<mdz> it's fd #8
<mdz> of that perl process
<cjwatson> what's the process that is stuck on read again?
<mdz> cjwatson: which package contains d-a-p?
<cjwatson> debconf
<mdz> cjwatson: the process stuck on read is the frontend around the postinst
<Lutin> doko: yes, indeed that'd mean update all the packages depending on wxgtk2.4 to make sure they use python2.5. is it worth working on it or is considered as minor ?
<doko> Lutin: its universe, so I consider this as minor; you may want to ask on #ubuntu-motu however
<mdz> cjwatson: it's the first of the two pipes that process opens, so STATUS_WRITE I guess
<Lutin> doko: ok
<mdz> cjwatson: d-a-p is blocked reading fd #9, presumably COMMAND_READ
<cjwatson> mdz: is there a separate d-a-p process just below the frontend with the pipe open for writing?
<mdz> cjwatson: yes, as fd 0
<mdz> cjwatson: er, scratch that
<mdz> that's open for reading, of course
<mdz> the frontend process is the only one with the write fd that I could see
<cjwatson> I mean
<cjwatson> is there a separate d-a-p process just below (the frontend with the pipe open for writing)?
<mdz> yes
<mdz> and below that apt-get, methods/cdrom, dpkg and then the other frontend
<Zober529> Hey guys, is there any way to get my hands on the 7.04 RC1 yet?
<mdz> Zober529: you're welcome to help test the current candidate builds
<mdz> but we can't tell you which one will be the final one, of course, until it's ready for release
<Zober529> which is tomorrow right?
<Zober529> by the way were can i find the different candidate builds
<Zober529> i could only see the beta on the ubuntu main page
<mdz> Zober529: https://lists.ubuntu.com/archives/ubuntu-devel/2007-April/023552.html
<Zober529> Thanks so much!
<mdz> Zober529: heno can help if you have questions
<cjwatson> fd 5 is probably the passthrough fd
<cjwatson> which suggests that the read it's stuck on may be in Debconf/Frontend/Passthrough.pm:talk()
<cjwatson> which doesn't check errors properly, so it could be something to do with that
<Zober529> This is really cool actually
<cjwatson> though it shouldn't actually be erroring anyway
<Zober529> do you guys know anything about Sabayon?
<heno> Zober529: we are coordinating the community testing effort in #ubuntu-iso, people there can help you
<Zober529> when it first boots into the gui, it detects the video card, and allows you to pick AIGLX or XGL based on the video card and the drivers that it has, will ubuntu 7.04 attempt anything like this?
<cjwatson> mdz: can you see what that apt-get process is doing?
<cjwatson> since I think debconf-apt-progress is blocked trying to read status output from apt-get and apt-get isn't giving it any
<\sh> Mithrandir: re d-i: where do I change the location of the udeb sources.list? d-i pbuilder run just wants to get the udebs from dapper/main/debian-installer and not from dapper-proposed/main/debian-installer
* bluefoxicy takes a brick to feisty ><
<cjwatson> mind you, apt-get should basically be waiting for the process to exit, which it isn't doing because the frontend is still there ... hmm
<bluefoxicy> has anyone else been having sound problems at all?  I've got NO sound, I don't know why, I can't find out why .... :(
<Zober529> has anyone tested 7.04 yet?
* bluefoxicy is on feisty beta
* bluefoxicy just reinstalled from the beta CD
<cjwatson> Zober529: this is the developer coordination channel
<Zober529> i figured, but no one answered, so I wanted to confirm
<mdz> cjwatson: apt-get is spinning getting EAGAIN on fd 7
<cjwatson> interesting
<pygi> siretart, I'd need you if you are here =)
<siretart> pygi: I happen to be around ;)
<bluefoxicy> this is gonna suck horribly.  I can't file a bug report on a bug I can't figure out where it's coming from ><  no one will be able to fix it
<Zober529> cjwatson, have you had any experience with Sabayon linux? Its based on Gentoo
* bluefoxicy starts trying things like disabling restricted modules
<pygi> siretart, yay, well got some news. Wanna discuss it here or in private? (don't want some people to eat me =))
<cjwatson> Zober529: no, and I'm afraid I'm busy with preparing the 7.04 release candidate, as are most of the other developers here
<siretart> pygi: I think #ubuntu-motu would be less busy than here, let's move there
<mdz> Zober529: I'm afraid the development team is rather busy with the release at the moment, you might try emailing your questions to ubuntu-devel-discuss@lists.ubuntu.com instead
<LongPointyStick> or sounder
<cjwatson> mdz: would it be possible to dpkg -x the apt ddeb into /target so that /usr/lib/debug/blah is there, and gdb it?
<mdz> cjwatson: fd 7 is the read end of the dpkg status fd
<mdz> it's just polling that fd and waiting for a child to die
<mdz> dpkg specifically
<mooey> bluefoxicy: do you use intel hda sound driver?
<cjwatson> silly way to poll
<cjwatson> can't exactly help installer performance
<mdz> it has a tiny sleep in the loop, but yes, it's silly
<mdz> anyway it looks to be behaving as designed, waiting for dpkg to finish or write a status message
<\sh> grmpf...
<mdz> cjwatson: I had a /target icon displayed on the desktop while the ubiquity final dialog was displayed; I'd never seen that before (though I don't know why not)
<cjwatson> I've seen that before and I'm not too concerned
<mdz> cjwatson: is there a bug open about this deadlock issue?  I'd like to dump my observations somewhere and get on with testing
<cjwatson> I've seen it filed but would rather not sidetrack into searching Malone right now
<cjwatson> I think it's on pkgsel
<micahcowan> jono, do you mind if I pm you, regarding potential application for membership? mako said I should run it by you.
<cjwatson> I have a feeling that the postinst-frontend is trying to talk to its passthrough fd but the passthrough agent is waiting for something else
<pitti> ugh, restricted-manager is on crack; it claims that nvidia is in use on the live system, but it isn't
<pitti> dholbach: ^ did you notice this as well on the amd64/live?
<dholbach> pitti: I didn't check - but can check in a bit
<pitti> dholbach: it tells you right at session start in the notification ('new restricted drivers in use')
<dholbach> pitti: oh yeah, that it did
<pitti> crappy crap
<Zober529> Hey guys, how do I actually download the ISOs?
<Zober529> I see the bug tracking and etc, but where are the images?
<Zober> by the way, I'm sorry I was using a web based client, and didnt see if anyone replied, so one last time has anyone used Sabayon?  Thanks
<heno> Zober: you'll find useful documentation here: https://wiki.ubuntu.com/Testing/Community
<heno> (worth a read; it might have answers to your questions)
<mdz> mvo: after installation, update-notifier tells me there are 2 updates available.  I launch update-manager and it also tells me 2 updates.  however in the list immediately below, there is only one update listed (libnet-dbus-perl)
<ogra> Mithrandir, hmm, apparently 4.4G is fine for DVDs ...  i thought 4G is the magical threshold ... so i wont need new builds
<pitti> BenC:  the live session has the nvidia module loaded for me; any idea what could cause this? (xorg.conf has 'nv')
<pitti> BenC: might the reason be that /etc/modprobe.d/lrm-video does not assing lrm-video script to nvidia_new?
<BenC> pitti: PCI id's, module alias
<ogra> doko, so stop playing with your SoCs :) edubuntu iso is updated
<pitti> BenC: 10de:0322 (works fine with nvidia_new)
<pitti> BenC: alias is just the general catch-all pci:v000010DEd*sv*sd*bc03sc00i00*
<pitti> BenC: so I figure the missing entry in the modprobe.d script causes the module to be loaded automatically?
<doko> ogra: still syncing ...
<ogra> well, i wasnt expecting you to be ready :P
<ogra> just wanted to notify the iso is fine :)
<iwj> Excellent, no more showstoppers in i386 desktop .
<pitti> nnnnngg slow LP
<iwj> Yes, I had that earlier.  There was a point where I was filing 4 bugs simultaneously.
<iwj> Very confusing.
<iwj> And if you try to both (1) set the importance and (2) target to release (now I'm told I should use milestone instead but wtf why two things?) at the same time, you can make it oops.
<desrt> RC time, boys :)
<iwj> At the same time> In two browser windows, I mean.
<pitti> BenC, Mithrandir: bug 105593
<ubotu> Malone bug 105593 in linux-restricted-modules-2.6.20 "claims that nvidia is in use on live system" [High,Unconfirmed]  https://launchpad.net/bugs/105593
<pitti> Mithrandir: the sad thing is that we already discovered that thing this morning, but didn't notice the impact yet
<mvo> mdz: what does apt-get dist-upgrade --simulate tell you? one? two?
<mdz> seb128: what happened to "About Ubuntu"?
<Mithrandir> pitti: it's just the kernel module loaded, but the X driver isn't used?
<mdz> mvo: I let update-manager install the updates
<mdz> update(s)
<Mithrandir> mdz: about ubuntu> got lost, already fixed.
<mvo> did it install one? or two?
<mdz> mvo: only one that I saw
<mdz> mvo: I'll check the log
<mjg59> pitti: Looks like an easy fix
<mjg59> Mithrandir: The kernel module will screw with suspend/resume if it's loaded
<mdz> mvo: hmm, looks like it installed two
<mdz> mvo: libxml-twig-perl and libnet-dbus-perl
<Mithrandir> mjg59: not really an issue on the live cd.
<pitti> Mithrandir: right
<mjg59> Why does it only hit the live cd?
<mvo> mdz: but showed only one? hrm :/
<pitti> mjg59: the nvidia one? right, merely adding the line to /sbin/lrm-video should do it
<mjg59> pitti: Yeah
<pitti> mjg59: I think it will hit installed systems as well, but I just didn't test on an nvidia system so far
<ogra> hmm, weird http://pastebot.ltsp.org/95
<mjg59> Well, lrm is going to need rebuilding anyway
<pitti> there's no reason why it shouldn't affect installed systems
<mjg59> So might as well fix it properly
<ogra> Apr 11 12:10:20 in-target: Ign file: feisty/restricted Translation-en_US
<ogra> Apr 11 12:10:20 in-target: Get:2 file: feisty Release [24.3kB] 
<ogra> Apr 11 12:10:20 in-target: Ign file: feisty/main Packages
<ogra> Apr 11 12:10:20 in-target: Ign file: feisty/restricted Packages
<ogra> Apr 11 12:10:23 in-target: Failed to fetch file:///cdrom/dists/feisty/main/binary-i386/Packages.gz  MD5Sum mismatch
<pitti> right
<ogra> Apr 11 12:10:23 in-target: Fetched 24.5kB in 2s (8204B/s)
<ogra> Apr 11 12:10:23 in-target: Reading package lists...
<Mithrandir> agree, but post-RC?
<ogra> how can that happen ? 
<cjwatson> bust CD?
<pitti> Mithrandir: another nasty wart then?
<ogra> i mean the base system just installed fine 
<ogra> hmm
<pitti> BenC: can you confirm the problem and solution?
<Mithrandir> pitti: it won't cause problems on upgrades to final?
<ogra> cjwatson, but ltsp gets installed right before grub ... aparently the complete rest of the install finished properly
<BenC> pitti: reading
<ogra> thats a bit strange i think
<cjwatson> *shrug* bet you a tenner it got bad data from the CD
* \sh wonders how to get dapper-proposed udebs integrated into d-i, when SUITE is always dapper 
<BenC> pitti: Sounds correct, I'll have another lrm upload for post-RC...probably should make a note for RC
<cjwatson> it clearly worked before, and now it fails
<Mithrandir> \sh: localudebs?
<pitti> Mithrandir: shouldn't, as soon as /sbin/lrm-video gets fixed, the module doesn't get loaded any more at boot; it's just a very nasty first-time impression
<\sh> Mithrandir: that's what I'm doing now...but normally it should be ok to set SUITE ?= dapper-proposed in build/config/common , right?
<cjwatson> \sh: no
<cjwatson> \sh: make sure dapper-proposed is in the build system's sources.list
<pitti> Mithrandir: to a certain degree that's a r-m bug as well, testing for the module determines the 'active' state
<\sh> cjwatson: it is..
<pitti> Mithrandir: I have no idea how to ask X about its current driver :(
<cjwatson> then check build/sources.list.udeb
<Mithrandir> pitti: then we get it fixed and make sure the fix is in the archive by the time RC goes out so people will se an update.
<\sh> cjwatson: I'm building via pbuilder...
<\sh> anyways localudebs works
<pitti> Mithrandir: and mention the live system problem in the release notes?
<Mithrandir> pitti: yes, suspend isn't really well-supported on the live cd anyway.
<pitti> Mithrandir: suspend?
<pitti> Mithrandir: no, it appears right after booting it, nothing to do with suspend
<Mithrandir> pitti: yes, and just loading it is a problem because?
<Mithrandir> (apart from the "aiee, non-free" thing)
<cjwatson> taints the kernel
<cjwatson> (for a reason - might break it in arbitrary ways and we have no way to tell)
<pitti> Mithrandir: right, just the 'argh nonfree' reaction; which is just a red herring, of course (except for people who care about tainted kernels, but *shrug*)
<pitti> anyway, let me reboot into the installed system to finish this test
<TomaszD> hello, is there a person responsible for the software-properties package? It seems it doesn't pick up the whole Polish translation, just a small part of it. And both python-apt and software-properties are fully translated into Polish. I'm using yesterday's daily language pack.
<mdz> Mithrandir: when I launch "translate this application" from yelp, I get the default Firefox home page rather than Launchpad.  has anyone els ereported this?
<mdz> TomaszD: ->pitti
<TomaszD> mdz, ah-hah! Thank you.
<Mithrandir> mdz: yes, and it has been fixed already.
<TomaszD> pitti, hello again friend. 
<TomaszD> :] 
<seb128> mdz: "About Ubuntu" was broken due to ubuntu-docs, a fixed version has been accepted this morning
<TomaszD> pitti, it seems software-properties shows similar problems as restricted-manager. Not the same though. It's just that most of the interface remains stubbornly English
<TomaszD> I'll reload my session with today's language pack, but I doubt it'll help. I've finished that translation a good couple of days ago.
<shawarma> Mithrandir: The apcalc upload is not showing up on https://launchpad.net/ubuntu/+source/apcalc/ ? I thought that happened as soon as it got ACCEPTed?
<Mithrandir> shawarma: it needs to be published too, but I thought that had happened by now
<Riddell> Mithrandir: the kubuntu amd64 dvd was oversized, I've removed linux-source from supported, am I ok to rebuild?
<shawarma> Mithrandir: If it's just a matter of waiting a bit extra, don't bother.
<Mithrandir> Riddell: please.  Tell heno when you're done so the test tracker can be updated.
<Mithrandir> Riddell: also give him the md5sums for the images.
<shawarma> Mithrandir: I just thought it would be there right away and was curious if something was wrong.
<seb128> mdz: bug #104072 for the firefox launchpad-integration bug
<ubotu> Malone bug 104072 in launchpad-integration "Clicking "Help->Get help online" in supported applications load start page instead" [High,Fix released]  https://launchpad.net/bugs/104072
<mdz> seb128: thanks
<seb128> np
<Keybuk> Holy Crashing X Server!
<ogra> Riddell, whats that thing about KDEs screensaver and switching keymaps ? seems there are a lot of problems with it
<mdz> mvo: ok, I have the same updates situation on my laptop now
<mdz> mvo: the trick is that libxml-twig-perl is a new dep of libnet-dbus-perl
<mdz> mvo: so it's an additional package, but not an update as such.  I think it's correct that the list omits it, and the only issue is that the count is misleading
<pitti> TomaszD: hm, do you still see problems with r-m?
<pitti> TomaszD: it works to 100% for me now
<bluefoxicy> Keybuk:  I have not seen X crash since hoary dev ;)
<bluefoxicy> and that was more of an "X is completely fxkd" scenario than a crash
<Riddell> ogra: I don't know of anything like that
<ogra> Riddell, Y and Z switched for the password entry window for unlocking
<ogra> i saw it in #ubuntu on the weekend and there are some mails on ubuntu-users
<mvo> mdz: ok, thanks for digging into the problem. could you please file a bug and milestone it with "later" ? I will attack it quickly after release then
<Riddell> ogra: I can't recreate that
<Riddell> ogra: let me try with a german keyboard
<ogra> ok, i just noticed it showed up multiple times 
<mdz> Mithrandir: getty still says "feisty (development branch)"
<mdz> mvo: it's a minor issue, low priority, but I will file it so that it's recorded
<ogra> Riddell, here is one thread https://lists.ubuntu.com/archives/ubuntu-users/2007-April/110927.html
<pitti> dholbach: Bluetooth master, demoting libopenobex1.0 to universe is ok?
<Riddell> ogra: I cant recreate it with a german kezboard lazout either
<ogra> heh
<ogra> ok
<Riddell> it could just be that one person
<ogra> well, if you dont have a bug about it ...
<ogra> no, i saw it multiple times
<TomaszD> pitti, no go even with today's language pack, what might be causing the problem in s-p?
<pitti> TomaszD: let's look into this in a minute; you said that you still have problems with r-m as well?
<dholbach> pitti: I think we can even remove it
<TomaszD> pitti, no, no more problems with that
<pitti> TomaszD: ok, so there's no problem with glib and .desktop files in general and such
<pitti> TomaszD: what doesn't work in particular with s-p?
<TomaszD> pitti, no problems in any other programs
<TomaszD> pitti, well, all the labels of all the panels, the main bar label, all the buttons and most of the text inside the window is in English
<TomaszD> only the text beside checkboxes is in Polish
<micahcowan> jono, do you mind if I pm you, regarding potential application for membership? mako said I should run my current accomplishments by you prior to a meeting.
<TomaszD> the desktop file is fine
<pitti> dholbach: seems to have been superseded by libopenobex1?
<dholbach> pitti: yes
<pitti> dholbach: right, was removed from Debian as well; thanks
<dholbach> yooohoo
<TomaszD> pitti, maybe a simple re-run of some script would fix this issue, I don't know, the matter is that s-p and python-apt are both 100% translated in Rosetta
<TomaszD> https://translations.launchpad.net/ubuntu/feisty/+source/software-properties/+pots/software-properties/pl/+translate & https://translations.launchpad.net/ubuntu/feisty/+source/python-apt/+pots/python-apt/pl/+translate
<TomaszD> It's the last grudge I hold against Feisty's translation state at the moment, everything else is looking very well
<pitti> TomaszD: indeed, it's not translated for me as well; but I need to download langpacks, I just freshly installed this machine; give me some minutes
<TomaszD> pitti, no problem, I'll be back in a few
<mvo> pitti: if its not fixed with the updated langpacks, I can look into the issue. it might be something with the code
<micahcowan> Q: if foo-backports is for backports, is foo-updates for SRUs?
<pitti> micahcowan: yes
<micahcowan> thanks
<pitti> TomaszD: hm, do you actually have a .mo file for this?
<pitti> mvo: which translation domain does s-p use?
<pitti> mvo: oh, it's update-manager
<dthacker> lamont: ping
<pitti> mvo: I think I got several things here
<pitti> mvo: s-p sets textdomain("software-properties"), but its .desktop file says domain 'update-manager'; but there is no software-properties.mo <= TomaszD, do you have that?
<TomaszD> pitti, one moment
<pitti> TomaszD: should be in /usr/share/locale-langpack/pl
<mvo> pitti: I fix the wrong one in the in the desktop file as we speak
<pitti> mvo: so it's meant to have its own domain?
<TomaszD> pitti, no such file
<pitti> TomaszD: right, here too. That would explain the problem
<mvo> pitti: yes
<mvo> pitti: it was split during the feisty cycle into its own package
<pitti> mvo: ok, thanks
<pitti> TomaszD: bingo, it landed in the KDE language packs
<TomaszD> um, should I open a bug report, if yes, then against what package? :)
<TomaszD> heh
<pitti> TomaszD: I create one myself
<TomaszD> ok
<TomaszD> I honestly can't believe that no-one else from any other language team doesn't have the guts to just come here and ask questions
<TomaszD> it doesn't work for anybody atm right?
<cjwatson> on the contrary, translators come here relatively often
<pitti> TomaszD: many do, don't worry
<TomaszD> ok, ok :)
<ra21vi> ok here is a question
<TomaszD> what I meant was about this specific issue, and I come here relatively often as well, last time also to pitti
<ra21vi> I am not a good GTK programmer, just a computer sc student, but I have some ideas regarding the features to be included in Desktops, whats really users want.. so where do I put them
<Riddell> heno: kubuntu dvds 20070411.1 are up
<ra21vi> in Trash???
<TomaszD> ra21vi, go to launchpad and create blueprints
<pitti> TomaszD: bug 105611
<ubotu> Malone bug 105611 in langpack-o-matic "software-properties land in KDE pack" [High,In progress]  https://launchpad.net/bugs/105611
<ra21vi> TomaszD: but what if i have written a whole paper for it, not just a topic 
<TomaszD> ra21vi, create a blueprint and link to a wiki page with the whole article at wiki.ubuntu
<ra21vi> TomaszD: thanks, I will do it then
<TomaszD> you can also submit it to OSNews for a nice warm flamewar if you want
<TomaszD> ;)
<TomaszD> pitti, subscribed
<sn0> .getnotes
<sn0> oops wrong chan
<ra21vi> TomaszD: lol, ok
<fabbione> mvo: ping?
<sn0> :-)
<Kmos> http://www.tux500.com -> funny
<mvo> fabbione: pong
<fabbione> mvo: i saw you tested i386 server with LVM + LAMP... and PASS.. but it hangs on me on 3 machines...
<fabbione> mvo: are you sure you selected LVM during the test?
<fabbione> actually.. it's just taking AAGEEEES
<mvo> fabbione: when did it hang? during the install? or during boot?
<fabbione> hmmmmm
<fabbione> during computing partitions
<fabbione> it seems that it is extremely slow
<mvo> fabbione: I had that too and asked about it here
<fabbione> ok.. what was the answer?
<mvo> fabbione: that it shouldn't be slow, but I haven't done a lvm install in ages so I had nothing to compare against
<fabbione> mvo: hmmmm ok
<mvo> fabbione: I think its worth filing a bug if you have seen it too 
<fabbione> mvo: yes.. i will.. i just don't understand why lvm is so slow.. i can see the process waiting is lvcreate
<Zober> I have a couple of machines with somewhat interesting configurations.  Both AMD64 and Intel CPUs.  Would it be at all helpful to set those up for testing, and maybe someone in here would like to remote into them and get a crack at beta testing them?
<fabbione> mvo: checking if it's lvm2 or partman-auto-lvm the cause
<tepsipakki> fabbione: I netbooted a machine today, and can put logs available if needed..
<tepsipakki> fabbione: re: lvm being slow
<fabbione> tepsipakki: i have logs.. it's lvm invokation that's slow...
<fabbione> not sure why tho
<tepsipakki> ok
<mvo> fabbione: I have seen lvmcreate swap when I tested it
<fabbione> i can see it also for root
<fabbione> lvcreate -L $sizeinMB -n $partition $vgname
<mvo> fabbione: I probably looked into ps rather late when it was hanging for a while already
<ogra> did pitti say he'D come back ? 
<ogra> ah, no he said goodbye
<fabbione> mvo: no problem.. thanks for the info
<fabbione> mvo: ok the problem is somehow lvm2 or down to device-mapper.. partman-auto-lvm is ok
<fabbione> stat64("/dev/mapper/sunfire-swap_1", 0xfffe6ce0) = -1 ENOENT (No such file or directory)
<fabbione> iwj, Keybuk: ping?
<fabbione>   Rendezvous with udev timed out for 'sunfire-swap_1'; stat failed: No such file or directory
<fabbione>   Logical volume "swap_1" created
<mvo> fabbione: let me know if you need more testing, I can redo my install again if required
<fabbione> bzzzzzzt
<fabbione> mvo: no.. it's all good.. the problem is libdevmapper/udev
<ogra> mjg59, apparently the doubled logout screen is really a hal prob, here is a patch http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=f30d5efd1458cc43ec90563ea4028a26fdef7689
<ogra> but given that patch is pretty big i think we should go with the small (4 line) g-p-m fix for feisty instead
<mjg59> ogra: I'm not clear on how that patch alters this specific behaviour?
<mjg59> (The comment certainly doesn't describe it)
<ogra> mjg59, well, davidz told me it fixes the doubled events
<ogra> it doesnt seem to be feisty stuff anyway ....
<ogra> and feisty+1 will have 0.5.9 which includes this 
<mjg59> I'm not clear on how
<mjg59> It's certainly not obvious from the comment
<ogra> you mean the git comment ? 
<mjg59> Yes
<ogra> indeed, thats pretty sparse
<Treenaks> mjg59: Are laptops supposed to run in with cpufreq-governor = 'performance'? All config files I find seem to say 'ondemand', but somehow 'performance' gets selected :/
<mjg59> They're supposed to be ondemand
<Treenaks> mjg59: hmm.. how do I debug? (which config files/commands can I try)
<kylem> Treenaks, is this after a resume?
<poningru> Treenaks: now do I check?
<Treenaks> kylem: before and after
<kylem> odd.
<poningru> Treenaks: have a lptp here how do I checkthat status here?
<ogra> Treenaks, it was broken at some point 
<Treenaks> poningru: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<Treenaks> ogra: I just upgraded & rebooted -- and it's the same as yesterday
<Treenaks> (forcing it to ondemand myself, after boot, does work..)
<shawarma> Are the RC images just the daily images from today? I can't find anything called release candidate on cdimage.u.c or releases.u.c.
<poningru> ondemand here as well
<shawarma> heno's mail about it doesn't seem to mention it.
<ogra> Treenaks, check the g-p-m gconf keys
<Treenaks> hmmm
<shawarma> Well, either that or I can't read anymore. :-(
<fabbione> mvo: bug #105623
<ubotu> Malone bug 105623 in devmapper "race condition with udev" [High,Confirmed]  https://launchpad.net/bugs/105623
<Treenaks> ogra: Ah! that's it
<fabbione> mvo: i subscribed you too.. perhaps you want to mention it in your server install report
<Treenaks> ogra: but there's no gui for those options.. no wonder I didn't find them :) thanks
<Keybuk> fabbione: the name is really sunfire-swap_1 and not some other character instead of _ ?
<mjg59> How did that ever get set/
<mjg59> ?
<ogra> Treenaks, there *was* a gui for the first two feisty packages ... 
<mjg59> I've got "performance" set here as well
<mjg59> And this was a clean install from the beta
<mjg59> Oh, wait, no it wasn't
<ogra> oh, that shouldnt happen 
<mjg59> I swapped the hard drives
<ogra> ah
<Treenaks> mine's an almost-daily-upgrade since oh.. dapper?
<fabbione> Keybuk: name is not importnat.. it happens also with /dev/mapper/sunfire-root
<Treenaks> but still :)
<ogra> mjg59, you were the first who complained about the gui where you could set it ;)
<Keybuk> fabbione: ok, and you both can replicate it in vmware?
<mvo> fabbione: thanks, updated
<fabbione> Keybuk:  i can replicate it also on real hw
<fabbione> Keybuk: 4 machines now + mvo one
<Keybuk> oh, hmm
<Keybuk> this happens during the *installer* ?!
<fabbione> yes
<Keybuk> heh
<Keybuk> this is not a surprise
<mvo> Keybuk: I tested it on real HW, but I can do a vmware test too if you want
<Keybuk> bet you 10 that the rules aren't in the udeb
<fabbione> Keybuk: let me check also on installed box
<fabbione> Keybuk: works on installed machine....
<fabbione> works as in it's fast
<Keybuk> fabbione: confirmed :-/
<fabbione> Keybuk: well it should be easy to fix tho
<Keybuk> yeah, needs a few things added to the udeb
<Keybuk> several udebs
<fabbione> Keybuk: at least it's easy to reproduce.. 
<fabbione> look at the very positive side of it :)
<fabbione> Keybuk: are we going to have the distro meeting tomorrow? or are we going to skip the next 2 for RC and release?
<doko> ogra, Mithrandir: the edubuntu DVD (amd64) doesn't start at all, just getting a kernel panic. using nosplash works fine
<ogra> ouch
<ogra> the rest works ? install/livesession start ?
<ogra> if you run it with nosplash i mean
<doko> ogra: starting my tests ...
<Mithrandir> doko: ugh. :-/  Please make sure there's a bug filed with the kernel panic.
<doko> heno: the Edubuntu DVD entries are still disabled
<doko> what package to use for filing a bug for selecting the screen resolution at boot of the live CD?
<ogra> gfxboot ?
<ogra> Keybuk, 9:00 UTC ? thats in the middle of the night !
<heno> ogra: are the new Edubuntu DVDs up?
<ogra> heno, yes, should be
<ogra> can you do i386 DVD again ? 
<ogra> my iso is taking ages as usual
<ogra> s7iso/rsync/
<heno> ogra: I still only see this dir http://cdimage.ubuntu.com/edubuntu/dvd/20070411/ with images from 16.00
<ogra> yes, thats fine
<ogra> i missed the point when i thought they were oversized ....
<ogra> i thought 4G was the threshold for DVDs while its apparently 4.7
<ogra> so the ones from 16:00 should be fine
<Nafallo> 4.4G is correct AFAIK
<xtknight> a single layer DVD is 4.7GB (1024^1024^1024 bytes)
<maswan> xtknight: no, 4.7GB as in 10^9 bytes
<xtknight> my mistak
<xtknight> 4.38 in real gb notation
* ogra is off installing terminal servers ... bbl
<pygi> Keybuk, mind coming to #duplicate-resolution on slashnet ... lh needs you
<pygi> heno, doko : anyone here?
<lamont> dthacker: si?
<heno> doko: sorry I thought those images were oversized (see ogras comment) I'll reactivate them.
<ds> what does "dpkg-shlibdeps: warning: format of `NEEDED libplds4.so' not recognized" mean?
<gnomefreak> ds: ignore it :)
* gnomefreak learned my lesson on those type of warnings
<ds> gnomefreak: it causes missing dependencies
<gnomefreak> ds: shouldnt
<gnomefreak> ds: if you got far enough to get those errors you are in make. depends errors come in configure/compile
<ds> er, missing dependencies in the ${shlibs} replacement
<gnomefreak> look for the -dev package
<mjg59> gnomefreak: It's not during make
* gnomefreak gets them while make is running. dpkg-buildpackage (it maynot be make but acts like it) around line 7000+ is wher ei get them near the end
<mjg59> gnomefreak: I'd really recommend reading the dpkg-shlibdeps manpage
<mjg59> ds: I'm afraid I'm not sure what causes that
<ds> oh, duh
<ds> all the other NEEDED entries end in '\.\d$'
<ogra> meh ... my broadcom card doesnt really behave 
<ogra> mvo: did we fix the fsck stuff ?
<ogra> *didnt
<mvo> ogra: no
<ogra> i had an fsck again
<ogra> ah, ok
<mvo> ogra: duplicate of https://bugs.launchpad.net/bugs/63175
<ubotu> Malone bug 63175 in e2fsprogs "Edgy Beta -- fsck on every (re)boot" [Medium,Needs info]  
<ogra> edgy beta ?
<finalbeta> lol
<finalbeta> ohw, yeah, I had that bug though.
<ogra> mvo: hmm, right i remember ... if we reorder the installer items something else breaks 
<ogra> partitioning iirc ...
<ogra> apart from that and the fact that my broadcom *feels* unstable ... edubuntu i386 server seems fine 
<ogra> (the eth1 device of the broadcom just vanishes silently if i switch WLANs in NM)
<seb128> cjwatson: what do you think about dropping the "X-Ubuntu-Gettext-Domain=" from the Desktop/ubiquity-gtkui.desktop? It workaround the "launcher is not translated"
<Keybuk> does anyone know lilo? :p
<Mithrandir> (and wants to admit to it)
<Mithrandir> Keybuk: from a user POV or a developer POV?
<Keybuk> d-i gave me
<Keybuk> root=/dev/mapper/ubuntuvg-root
<Keybuk> # append=""
<Keybuk> is that right?
<Mithrandir> do you remember back in the days when you used rdev to set the boot device?
<fabbione> Keybuk: looks about right
<fabbione> root=/dev/mapper/mofo-root
<fabbione> this is from breezy or hoary install.. can't remember
<Keybuk> ok
<Keybuk> and booting I get root=fe00 on the command-line
<fabbione> ouch
<fabbione> hmmm lilo doesn't read the config on the fly afair
<fabbione> and it's stored somewhere in the MBR
<fabbione> there might be a few points where it fails
<Keybuk> random
<fabbione> like parsing from lilo.conf to MBR.. whatever you write in the MBR. reading it back.. passing it to the kernel
<Keybuk> isn't root=fe00 a short-cut to mean a device of 254, 0 ?
<Mithrandir> looks like it, yes.
<Mithrandir> since lilo doesn't know about the names, just the minor/major numbers.
<fabbione> oh that might be the reason... 
<Keybuk> aha!
<fabbione> fe00 is dm-0
<fabbione> but then
<Keybuk> and then initramfs mknods that
<fabbione> there is no guarantee that root is dm-0
<Keybuk> which means the "loop until $ROOT exists" test succeeds
<Keybuk> before lvm has even woken up
<Keybuk> and yes, as you say, there's no guarantee that it'll even get dm-0
<Keybuk> booting with either root=/dev/mapper/ubuntuvg-root or root=/dev/ubuntuvg/root works
<fabbione> Keybuk: probably lilo pass a pointer to a string to the kernel when root is specified as a boot arg instead of hardcoded in the MBR
<Keybuk> indeed
<fabbione> Keybuk: it's possible that lilo attempts to reduce space usage in the MBR using hte fe00 format
<Keybuk> the whole dm-0 thing wouldn't necessarily work if you had multiple PV/VG in the machine already
<Keybuk> no telling what way the dm's will get assigned
<Keybuk> especially if snapshots are involved
<fabbione> yeps
* Keybuk cafepresses a "I know LVM" t-shirt ;)
<Mithrandir> fabbione: no, it's just not updated for how linux 2.0 works.
<mvo> hm, what installs lvm2 on the server? it seems to be not part of a task
<fabbione> mvo: it's installed by d-i only if you use lvm for partitions
<fabbione> same for mdadm
<mvo> fabbione: I see. but mdadm is not installed explicitely in edgy it seems. I will need to work around #105663 (not difficult)
<_ion> "This is LVM, I know this."
<mjr> :P
<fabbione> mvo: the changes were done in edgy...
<fabbione> mvo: well you need lvm-common for lvm2..
<mvo> fabbione: I mean mdadm seems to be pulled in as part of lvm2 
<fabbione> mvo: that has been always true
<fabbione> mvo: it was.. it's no more
<mvo> fabbione: yeah, and that causes apt to think its now a unused dependency. no worry, I add something to the release-upgrader to fix it
<pygi> jdong, :)
<fabbione> yup ok.. apt-get tells the same too..
<jdong> pygi: NOOO AHHH IT BURNS!!!
<jdong> :D
<fabbione> movie time
<pygi> jdong, omg, stop that :P
<fabbione> if something is urgent just ping on IRC
<_ion> Hi pygi
<pygi> _ion, :)
<pygi> where are you lost? :) Haven't seen you in ages =)
<_ion> pygi: I have been online.
<_ion> benc: When l-r-m is moved to a VCS, are you going to use git, or perhaps bzr? Are you going to keep the upstream tarballs in the repository, or only the packaging?
<seb128> Mithrandir: I've just uploaded a network-manager update generating a translations template so the "_Static configuration" menu item can be translated on rosetta, would be nice to accept today so translators can work on it ;)
<Mithrandir> seb128: sure
<seb128> thank you
<ajmitch> morning
<seb128> hi ajmitch
<seb128> cjwatson: what component has the ubiquity translations?
<ogra> eeek
* ogra wonders what the german transaltos are smoking
<ogra> *translators
<pygi> lol
<ogra> GAIM-Sofortnachrichtendienst ... 
<ogra> i dont even think the second part is a word 
<highvoltage> ogra: I think these days the first part isn't either
<ogra> highvoltage: well ... but that translation is really weird ....
<pygi> highvoltage, indeed :)
<pitti> hi again
<ogra> seb128: hmm, gnome-session isnt really happy if i run asoundconf set-pulseaudio without having pulse installed
<ogra> in fact i cant log in anymore 
<pygi> pitti, !!!
<seb128> ogra: don't run that command then
<seb128> pitti: wb
<ogra> seb128: well, for ltsp clients teh asouncdconf gets set to a pulse emulation
<pitti> seb128: Kihap!
<ogra> *asoundconf
<seb128> ogra: file a bug, I'll read it in 10 months, time to catchup with the zillion of desktop bugs we get weekly
<ogra> heh
<seb128> why does everybody notice bugs now? ;)
<ogra> i'll fix it from teh ltsp side for now ... but gnome-session should not block ...
<seb128> ogra: I'll try having a look tomorrow, I've lot of other things on my plate though :/
<ogra> seb128: no idea, my inbox is flowing over as well :)
<seb128> grumpf hwdb-gui is the suck
<seb128> it's not translated :(
<ogra> seb128: i think we can live with it for feisty, i can fix my part from teh ltsp side and if people deliberately install pulse they should know what they do
<seb128> k
<seb128> I'll try to have a look anyway
<ogra> seb128: its not *translatable*
<seb128> ogra: that's what I complain about
<ogra> yeah, my fault ... i wanted to sit down with mvo and fix that ... but somehow it slipped ...
<mvo> fix what?
<ogra> translatability of hwdb
<mvo> oh, right
<mvo> yeah
<seb128> it was ok when we were not trying to make users go there
<mvo> it was on my list too, but too little time :/
<ogra> yeah
<pitti> seb128: we don't any more
<pitti> seb128: I removed the notification, but too late for RC
<seb128> pitti: ah, good
<seb128> yeah, I've read the change
<ogra> pitti: i had a short discussion about the "login appears twice" bug with davidz before ...
<seb128> I though it applied to desktop CD only though
<pitti> because the notification itself is ... not optimal yet
<pitti> ogra: oh, any result? I never saw it
<seb128> pitti: hwdb is far to be optimal as well
<ogra> he gave me a link to a fix thats in 0.5.9 
<pitti> seb128: heh
<pitti> ogra: cool, I'm happy to backport it
<ogra> pitti: but that fix is quite huge 
<seb128> pitti: it's like hundred of lines of code change :/
<ogra> it seems only g-p-m is affected and there i got a workaround thats only four lines big
<pitti> urgh
<pitti> ogra: the workaround is it, then
<pitti> ogra: we'll get 0.5.9 for feisty+1 anyway
<ogra> yeah
<ogra> thats what i thought 
<pitti> and they even decided for faster release cycles
<ogra> teh fix is surely 100 lines or more
<seb128> hum
<seb128> language packs are outdated on the CD
<seb128> not optimal to note translations that need to be changed :/
<pitti> seb128: current ones are 12 days old, and immediately after RC we'll refresh them
<seb128> pitti: yeah, it's slightly outdate
<seb128> current translation would have be nice to notice what needs to be done for next week
<seb128> "Report  Problem" is not translated at the moment
<pitti> seb128: well, just use the daily packages then
<seb128> right, will look at translations on the actual installation rather than on the CD
<seb128> my desktop is not good for that because I've installed many locale GNOME builds
<seb128> so I've a mixed between upstream and rosetta
<pitti> right, and /usr/share/locale/ .po files are prefered
<seb128> pitti: that was rather a note for next cycle, doing a language pack just before RC would be a good idea
<pitti> right
* seb128 hugs pitti
<pitti> seb128: ideally with the 2.20.1 upload, but that's pretty tight
<seb128> pitti: we will ship 7.10 with 2.20.0
<pitti> seb128: there was just not enough time for a LP upload today
<pitti> oh, why so?
<seb128> 2.20.1 is on octobre 17th
<seb128> normal schedule would be octobre 25th for 7.10
<seb128> UDS is on octobre 28th though
<pitti> hm, too tight
<seb128> doesn't work
<pitti> seb128: so .1 in (feisty+1)-updates?
* pitti wants a name for feisty+1
<seb128> pitti: no, 2.20.0 + SVN backports to feisty+1
<seb128> no whole SVN
<seb128> other fixes we want
<seb128> s/other/only
<k001> hile, i'm try  create packages .deb for Ubuntu but i do $debuild -S and sendme error 
<k001> this is the error http://pastebin.ca/435304
<seb128> k001: try #ubuntu-motu
<pitti> gambling gorilla!
<k001> is my first packages for UBuntu
<k001> seb128, ok thanks
<seb128> np
<pitti> ok, bedtime for me
<seb128> k001: you can ignore the debsign error, it means that your package is not signed only
<pygi> pitti, night
<seb128> 'night pitti
<pitti> *wave*
<seb128> pitti: see you tomorrow morning for the meeting
<k001> but if i sign?
<k001> seb128, how to do?
<seb128> you need a GPG key
<k001> sorry but my english es very bad 
<k001> seb128, i have a key
<seb128> does it list the email you use on the changelog?
<k001> seb128, :O i see my error thanks 
<seb128> np
<micahcowan> Is it intended that every package in main should have a core dev associated with it? Or does someone periodically check the bugs in main packages that have nobody assigned?
<Mirv> tepsipakki: speaking of packages, xserver-xorg-video-ati 6.6.3-2ubuntu5 .deb does not still seem to be in the archive:http://archive.ubuntu.com/ubuntu/pool/main/x/xserver-xorg-video-ati/
<Mirv> I wonder if there are many of these "stuck" packages, or are they all known
<mdke> that network manager bug is back, is it? "No network devices have been found"
<mjr> a,22
<tepsipakki> Mirv: true, since it doesn't build. -2ubuntu6 reverted the patch and is waiting in the queue
<Mirv> tepsipakki: ok.
#ubuntu-devel 2007-04-12
<tepsipakki> I don't think that the UYVY-bug is important enough to basically update radeon_video.c from git-master
<Mirv> nope, if it requires that. I'll reopen the bug in malone, btw.
<tepsipakki> Mirv: yep, thanks
<tepsipakki> soon we'll have 6.6.191 (or newer) anyway ;)
<ogra> edubuntu amd64 server and addon are fine 
<doko> ogra: don't need to test this one?
<ogra> doko: CD
<mdz> good evening
<mvo> good evening mdz
<mdz> mvo: how do things look?
<mvo> mdz: good so far, I send you a mail earlier
<mdz> mvo: the one to tollef, or a different one?
* ogra kicks LP
<mvo> mdz: that one to tollef that I CCed you, he asked about the upgrade test status
* ogra tries since 20 min to make the damned bug submit page react GRRR
<mvo> ogra: LP is a bit slow today for me too 
<ogra> mvo, 20min for one bug ?
* ogra copies and pastes the text and starts over
<mdz> mvo: right, ok
<stgraber> Is anyone working on this bug : bug 105573 ?
<ubotu> Malone bug 105573 in network-manager "gnome NetworkManager doesn't see any wired or wireless network" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105573
<stgraber> I just come accross it after an update ...
<stgraber> hmm, just found where the problem come from, no need to check it :)
<cjwatson> mdz: you know, I think that x-ttcidfont-conf bug may simply be that defoma-app is widdling all over stdout and confusing debconf
<Arby> cjwatson: can you spare a moment to look at bug 99908.
<ubotu> Malone bug 99908 in ubiquity "The ext3 file system creation in partition #1 of SCSI1 (0,0,0) (sda) failed." [Undecided,Needs info]  https://launchpad.net/bugs/99908
<Arby> just happened to me with kubuntu 20070411 build
<cjwatson> Arby: much of the problem seems to be that you're low on memory
<Kmos> bug 105234
<ubotu> Malone bug 105234 in network-manager "Netowrk manager says disconnected but is connected and working" [Undecided,Needs info]  https://launchpad.net/bugs/105234
<Kmos> someone need to fix this
<Kmos> 8 duplicates
<Arby> cjwatson: fair enough as long as that's all it is.
<cjwatson> after my earlier comment I realised my suggestion to edit commit.d/30parted was bogus, as update-dev is called by a later script
<cjwatson> Arby: it's not entirely clear
<cjwatson> but there are definitely signs in syslog of things failing due to out-of-memory, or processes being killed, or whatever
<cjwatson> if that's what it is then the installer should still respond more gracefully
<xtknight> how do i get gnome network manager to show up in my systray?
<Arby> cjwatson: anything else I can do?
<xtknight> ah it was  /usr/bin/nm-applet 
<Arby> cjwatson: as long as your happy it's not a show stopper it can be dealt with $later
<Arby> I just wanted to check
<cjwatson> Arby: add more memory and see if it still happens? :-)
<cjwatson> I think it probably isn't a showstopper, as I believe it's the only report I've received of this form
<Arby> cjwatson: pass some over then :)
<Arby> cjwatson: fair enough
<cjwatson> though that doesn't mean I'm dismissing it
<Arby> that's fine it just doens't need to be chased at this late stage
<Arby> as long as I know I'm fine with that
<Arby> if you want me to try anything in future just shout.
<cjwatson> will do, thanks
<cjwatson> mdz: can you reproduce that weird debconf-related hang at will? as in if you do the same install again does it still happen?
<cjwatson> mdz: if so, I'd appreciate /var/log/syslog from an installation attempt with DEBCONF_DEBUG=developer set on the kernel command line
<mjg59> cjwatson: Can I upload a new hotkey-setup? I'm not actually too fussed as to whether it's accepted for feisty (though it's approximately no-risk), but i'd rather have it sitting in a queue than depending on me remembering to upload it again when +1 is open
<mjg59> (Or does the queue not work that way?)
* Fujitsu wonders when Feisty+1 will be named
<Monk-e> Fujitsu, i think it's already named. But I don't know the name.
<shawarma> Who are the soc mentors?
<shawarma> They're wanted on slashnet..
<shawarma> ...or anyone who can speak on their behalf.
<BenC> anyone here experiencing bug #82314?
<ubotu> Malone bug 82314 in linux-source-2.6.20 "pata driver in libata not mounting /home" [Critical,In progress]  https://launchpad.net/bugs/82314
<BenC> basically Host Protected Area drives not being supported by libata-pata
<xtknight> about bug 105234 and duplicates: i think i have a fix.  i'm not certain it's not a "hack", but brief testing shows that it works fine and even if it is slightly hacky i dont believe it has any other side effects.  should i post & have someone else review this?
<ubotu> Malone bug 105234 in network-manager "Netowrk manager says disconnected but is connected and working" [Undecided,Confirmed]  https://launchpad.net/bugs/105234
<xtknight> may anyone who knows about NetworkManager take a look at this patch (last comment)?  bug 105234
<ubotu> Malone bug 105234 in network-manager "Netowrk manager says disconnected but is connected and working" [Undecided,Confirmed]  https://launchpad.net/bugs/105234
<mjg59> xtknight: What timezone are you on?
<mjg59> Most developers have hit bed, so tomorrow is almost certainly a better bet
<xtknight> eastern US Wed Apr 11 9:39pm
<xtknight> k
<mjg59> Ask Mithrandir about it tomorrow - he's been looking at NM a little
<mjg59> But he's pretty busy, so don't expect an immediate response
<rpereira> Does someone know which part of Launchpad is GPL and which part it isn't?
<mpt> rpereira, that question is better addressed to #launchpad
<mpt> oh, nm, you're there already :-)
<rpereira> mpt: yes, after I posted here, I used my brain.... :)
<microphone_not_w> hi
<Hobbsee> hi
<Enola_Gay> hi all
<Enola_Gay> Does anyone know when the RC will be released?
<fabbione> when it's ready
<Enola_Gay> :)
<Enola_Gay> So it isn't?
<fabbione> i haven't said that :)
<Enola_Gay> Does the yesterday daily live build has any disadvantage? 
<Treenaks> If you can install, you can always upgrade :)
<Enola_Gay> So theoretically they are build like the rc or beta candidate?
<Treenaks> afaik, all CD images are the same.. it's just that some images get to be blessed into 'Beta' images etc.
<Enola_Gay> cool, thanks
<Enola_Gay> Than the RC can be released when it is ready ;)
<fabbione> yesterday's image might be RC..might be not
<fabbione> but for sure they are pretty good
<Enola_Gay> If only some packages differ it is no real problem. It just should have no disadvantages for upgrading.
<pygi> I would like to congratulate everybody who got into SoC, so congrats folks ^_^
<Enola_Gay> Thanks and cu all.
<mdke> Mithrandir: I think bug 82335 reappeared yesterday. If not, another bug with the same symtoms :)
<ubotu> Malone bug 82335 in network-manager "network-manager should not set offline mode when it manages no device" [High,Confirmed]  https://launchpad.net/bugs/82335
<Mithrandir> mdke: no, that's intentional.  Apps think they're offline, but the NM doesn't manage any devices in that case, so it thinks it's offline.
<mdke> Mithrandir: well, you originally fixed that bug... the fix was reverted intentionally?
<mdke> all I know if that I have a big fat icon in my panel which tells me I have no network devices. That can't be a good thing
<Mithrandir> mdke: does gaim and epiphany believe you are online or offline?
<mdke> Mithrandir: no, that part is ok
<mdke> (online)
<Mithrandir> then the fix is working correctly.
<mdke> it's just the icon which is wrong
<Mithrandir> not really, it should just read "no managed devices" and not "no devices"
<mdke> what's the point of that?
<mdke> surely the whole point of the n-m icon is to allow people to quickly configure their network devices
<mdke> I was really loving it for switching wifi networks
<mdke> now I can't :(
<Mithrandir> hm, you have a static, wired eth0 and an dhcp, wireless eth1?
<Mithrandir> if so, it should list the wireless interface.
<mdke> dhcp everything
<mdke> even so, it seems that even people using static shouldn't get that red exclamation mark in their panel telling them something is wrong
<mdke> s/seems/seems to me
<mdke> oh, and the mouseover message is "No network connection"
<Mithrandir> can you paste your /etc/network/interfaces file somewhere?
<mdke> Mithrandir: ok. http://pastebin.ca/435901 - I've taken out all the white lines.
<mdke> dunno what eth2, ath0 and wlan0 are - I don't have any of those
<Mithrandir> "wireless-essid belkin54g" is a kind of static configuration and NM won't touch it because of that.
<Mithrandir> but it should list eth0 in the list, but it might be greyed out if you don't have a cable plugged in
<Hobbsee> how's the testing going?  kubuntu, specifically?
<mdke> Mithrandir: that's fine. My point is, n-m is wrong to tell people they don't have a network connection, and the whole point of that icon is that i provides them with a good indication of whether their network is up or not.
<mdke> until yesterday, I mean
<Mithrandir> mdke: except it doesn't when you have weird setups and those kind of weird setups were more common than I thought
<mdke> Mithrandir: was there something wrong with the way it was working since you fixed the bug and until the last upgrade? because loads of people commented on the bug report saying that their weird setups were being properly recognised
<mdke> certainly mine started working again
<Mithrandir> it broke with ipv6, for instance.  And it broke with mappings, and it broke LTSP and other cases where NM thought it could handle it, but couldn't.
<mdke> I see
<mdke> thanks for explaining that 
<mdke> so, the icon should be fixed
<Mithrandir> so I would have loved not to have gone back on this, but I think a small retreat is better than having something that breaks for lots of people.
<bimberi> bug 105234 might be relevant?  In particular comment 32 (xtknight's tentatively submitted patch)
<ubotu> Malone bug 105234 in network-manager "Netowrk manager says disconnected but is connected and working" [Medium,Confirmed]  https://launchpad.net/bugs/105234
<sid> I purged linux-restricted-modules-common; and I can't apt-get install it back. There is no installation candidate.
<mdke> Mithrandir: yep. We just need to make sure that people who's interfaces n-m can't handle aren't seeing the icon; maybe even show them the old Gnome icon that works properly
<Mithrandir> mdke: but you aren't seeing your wired interface at all in the dropdown list?
<mdke> Mithrandir: no. It says "no network devices have been found" and "no network connection" in the mouseover. (my eth1 is up)
<mdke> the Gnome icon tells me I'm up and running
<Mithrandir> hm
<Mithrandir> that's weird.  I'll see if I can reproduce this on my laptop.
<mdke> thanks. It's not so much my system that bothers me as in general though
<Mithrandir> something else, ubuntu-docs still has the codename (feisty fawn) in the firefox home page, can we get rid of that and just refer to it as 7.04?
<mdke> yes, if you wish
<hile> nm does not often understand the status of links it has not itself brought up or down 
<Mithrandir> hile: which is why it's told to stay away from them.
<torkel> eth0 and eth1 are not marked "auto". n-m requires that for them to show up, no?
<bimberi> Gutsy Gibbon!
<mdke> hile: that's fine. The problem is that it's giving a misleading impression to the users, and that the icon in the panel should tell *all* users whether they are up or down, as the Gnome icon does
<hile> of course, but I think only bug here is that nm still shows it's icon while there are no interfaces it's supposed to manage?
<hile> ah, not that, I got it
<Mithrandir> hile: that would be an acceptable way to fix the bug, IMO.  If there are nothing to manage, it can just hide itself.
<hile> yeah, as long as there is no menu entry in it 'look for network interfaces now'
<mdke> Mithrandir: it's a fix. But it's a regression from Edgy, which had a working icon for all users
<hile> depends what you mean by working, I haven't had working wireless with default gnome app for long time :) 
<mdke> and given that the default homepage is offline, there's no easy way for people to find out if they are online or not, short of typing a website address
<hile> ... because I have used nm only for over a year
<Mithrandir> mdke: they're free to add the old applet if that works better with their setup.
<hile> nm just isn't well enough integrated with debian-based systems, I think
<mdke> Mithrandir: if they can (a) guess it exists, and (b) find it
<Mithrandir> mdke: can you make sure the "About Ubuntu" page just has references to the version number too?
<Mithrandir> hile: but it'll never get there if we don't work on fixing that.
<mdke> Mithrandir: it's not really a great time to do that - we'll break the translations. It's always contained the version number followed by the codename, afaik
<hile> of course
<Mithrandir> mdke: hmm
<mdke> we could sed through all the translations too, I guess
<Mithrandir> mdke: https://wiki.ubuntu.com/CodeNamesToVersionNumbers claims otherwise.
<mdke> Mithrandir: as a result of that, we put the version numbers first and the codename as secondary
<mdke> but I suppose we should remove them, it's just very late
<Mithrandir> yes, I should have noticed earlier, but didn't since I overlooked a checklist on my checklist.
<mdke> heh
<mdke> I can't take care of it today, I need to get to work asap
<Mithrandir> ok, see you.
<mdke> maybe someone else can do it
<sid> mdke: See if you can reproduce my bug. I didn't see it listed on launchpad.
<mdke> sid: I don't have time I'm afraid.
<mdke> Mithrandir: thanks for your time
<pitti> Good morning
<pygi> morning pitti 
<pitti> Mithrandir: ah, it just occured to me how this lrm-video bug broke X yesterday: nvidia_new gets modprobed automatically, and thus X.org cannot load nvidia or nvidia_legacy any more, and you get that ABI mismatch
<pitti> hi pygi
<dholbach> good morning
<pitti> argh, metacity hid my other xchat window again, brb
<pitti> hey dholbach!
<doko> pitti, lifeless: please comment on bug 105764
<ubotu> Malone bug 105764 in python2.5 "apport exception hook negatively impacts startup of python" [Medium,Confirmed]  https://launchpad.net/bugs/105764
<mneptok> @lart 37 Mithrandir 
<mneptok> ukeoadi
* Mithrandir tickles mneptok 
* Hobbsee tickles Mithrandir 
* Hobbsee stomps on Mithrandir's feet
* highvoltage takes a few steps back
* pygi eats Hobbsee 
* Hobbsee kicks aroudn inside pygi, and pokes around with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
<Mithrandir> Hobbsee: both tickling and stomping.  Now, that's cheating.
<Hobbsee> Mithrandir: why?
<highvoltage> unfair advantage.
<pygi> Hobbsee, you know that won't work with me =)
<pygi> Hobbsee, I've got burning powers!
<Hobbsee> pygi: nto when you're being prodded inside...
<pygi> Hobbsee, won't help ya!
<pitti> hi Mithrandir 
* Hobbsee bursts out of pygi.  oops, pygi is blown up.  oh dear.
<Hobbsee> heya pitti 
* pitti hugs Hobbsee 
<pygi> Hobbsee, I know all of your tricks. :)
* Hobbsee hugs pitti 
<zyga> good morning everyone
* Mithrandir sews pygi back together.
* Hobbsee grumbles about havign to go to work
<pygi> Hobbsee, I won't be able to fix your cd-recording mess for kubuntu :P
<pygi> Mithrandir, thank you ^_^
<Hobbsee> pygi: oh dera.
<Hobbsee> pygi: well this is why you shouldnt eat people
* pitti tests out the proposed l-r-m bug fix, bbl
<pitti> Mithrandir: I did some tests and confirmed that http://paste.ubuntu-nl.org/15189/ really does what it should
<pitti> Mithrandir: hmm, I just saw that BenC set the bug to fixcommitted already
<pitti> Mithrandir: however, there's nothing in unaccepted; is this good to upload?
<BenC> pitti: I just did an upload about an hour ago
<Mithrandir> pitti: please.
<pitti> BenC: oh, weird; I checked unaccepted before starting with this
<BenC> but I never got an accepted email, so feel free to reupload
<pitti> BenC: while testing this I noticed another oddity
<pitti> BenC: lrm> ok, I assume it's more or less the same patch? (see paste)
<BenC> yeah, same thing
<pitti> BenC: regardless of whether I modprobe _legacy or _new, lsmod always shows 'nvidia'
<pitti> BenC: this makes it hard to figure out which module is actually loaded (and makes r-m display the wrong thing)
<pitti> any idea why it does that? can the module change its name?
<BenC> pitti: odd, lsmod should always show the filename
<pitti> BenC: hmm, so I better teach r-m about this special case
<pitti> Mithrandir: ah, my l-r-m upload is in unapproved now
<carlos> pitti: Is there any problem if we don't generate any language pack for two weeks after Feisty release?
<pitti> carlos: no, that wouldn't hurt at all
<carlos> pitti: that applies to Dapper and Edgy too
<pitti> carlos: you want to open the gutsy translations in that time?
<carlos> no, we are not going to do it so early
<carlos> we need the server where the language packs are generated to handle the release load
<carlos> so the server will be unavailable for the first two weeks
<pitti> carlos: hm, but it would be good to open them early
<pitti> carlos: feisty was a disaster
<carlos> pitti: I got the comprise with our translators in a public meeting to open it two months after Feisty + 1 opening
<Mithrandir> what is the reason for not just opening it when feisty+1 opens, apart from the server load?
<carlos> and once Feisty + 1 schedule is published, I will ask to include there when we expect to have translations open
<pitti> carlos: hm, I still don't understand why we cannot open it right after release; it will take a long time right after release or right before beta
<carlos> not sure whether it's already published...
<pitti> and right after release we don't need other tarballs so urgently
<carlos> pitti: maybe for feisty + 2 we could open it again after release, but with Debian sync the amount of files to imports will be huge, and we have another critical bug that we should address that makes hard to non ubuntu projects to use Rosetta while a huge Ubuntu import is in process
<pitti> carlos: right, but you have to import these files anyway at some time
<carlos> pitti: also, translators asked us to delay it those two months until everything is a bit more stable with the version updates
<carlos> pitti: well, those two months will give us time to deploy the solution
<pitti> carlos: hm
<pitti> carlos: if we can rely on the two months this time, I can live with that
<Keybuk> carlos: I'm just publishing the schedule now
<Keybuk> carlos: what date do you ned to know?
<carlos> Keybuk: well, the idea is to add a 'Traslations open in Launchpad' two months after Feisty + 1 development starts, but I would like to see the calendar to agree on a date with kiko and other Rosetta developers
<carlos> do you have a draft?
<Keybuk> carlos: no, I have the final schedule :p
<carlos> ok, URL?
<ogra> ENOSEB :/
<Keybuk> why do we have to wait for two months?
<Keybuk> carlos: http://wiki.ubuntu.com/GutsyReleaseSchedule
<Treenaks> ooh, release on my birthday :)
<carlos> Keybuk: because translators asked to wait until all Debian sync is done and packages are moved from universe to main and the other way and new GNOME version is imported
<Keybuk> June 21st for debian sync done
<carlos> Keybuk: and for this concrete release, because, as explained to Martin, we need to fix a problem that blocks non unbuntu projects to import files while we handle the initial imports for a new distro
<carlos> Keybuk: I guess then, we would open translations around that time
<fabbione> Keybuk: wow and the sprint doesn't even overlap with my holidays :)
<Keybuk> fabbione: this was deliberate :p
<Keybuk> it doesn't overlap with anyone's holiday afaik
<fabbione> Keybuk: eheheh
<Keybuk> (or any conference)
<fabbione> Keybuk: i *knew* you couldn't live without me ;)
<carlos> Keybuk: I will try to have a meeting with kiko today to discuss the final date and will send you it so you can add it to the schedule, ok?
<Keybuk> ok
<carlos> thank you
<siretart> Mithrandir: an news about the idea of removing broken binary packages (like unmet deps) from the (feisty) archive? I don't remember any feedback of this
<Mithrandir> siretart: yes, we are not going to do it.
<pitti> Mithrandir: I just committed a fix to bug 105812, see patch linked from the bug
<ubotu> Malone bug 105812 in restricted-manager "nvidia_new and _legacy not detected as 'in use'" [High,Fix committed]  https://launchpad.net/bugs/105812
<siretart> Mithrandir: ok. 
<Mithrandir> pitti: ok, looks good.
<pitti> Mithrandir: thanks, uploaded
<doko> ogra: is the keyboard layout reset to english after installation of the ltsp chroot on edubuntu installs?
<Seveas> Keybuk, gnome 2.12?!
<Seveas> Keybuk, are we going back to warty? =)
<tsmithe> damn Seveas i was about to say that!
<Mez> Keybuk, may I query ?
<Seveas> tsmithe, actually warty was 2.8, breezy was 2.12
<tsmithe> i dunno :P
<tsmithe> but i was gonna say something along those lines ;)
<ogra> doko, hmm, is it right after first reboot ?
<doko> ogra: no, noticed when entering the partition where to install grub
<ogra> and after first boot ?
<ogra> wrong or right ?
<cjwatson> mjg59: yes, feel free to drop things into the queue
<doko> ogra: wrong
<ogra> hmm, i could use  in gdm here ... weird
<doko> pitti: ok to upload the apport change?
<pitti> doko: hm?
<pranav_> doko: ping
<doko> ogra: I'll recheck after the meeting, but I'm sure I set the language to german
<ogra> doko, are you really sure ?
<Keybuk> Mez: sure, what's up?
<pitti> doko: sorry, I didn't check the bug yet, overlooked it over my reboots
<doko> pranav_: I don't know anything about SoC, sorry. Google will make things public soon
<Keybuk> Seveas: oops :p
<pranav_> doko: he he it ok
<ogra> i can imagine that the run of console-setup in the chroot affects the server through /proc but that shouldnt change the /etc/default values for the host
<pranav_> *its 
<ogra> so it *must* be the keymap thats set before chroot building starts after the first reboot ...
<ogra> i wouldnt know a technical reason why it should stay non-german 
<doko> ogra: checking agin
<ogra> thanks
<pitti> doko: erk, doesn't this require a new binary package, if you move the hook out of the apport/ module?
<doko> pitti: why?
<pitti> doko: also, apport_hook as a general module is really misleading, it should be python_apport_hook or so
<pitti> doko: since we have two other kinds of 'apport hooks' already
<heno> cjwatson: can you have a look at bug 105814 ?
<ubotu> Malone bug 105814 in Ubuntu "fails to resize ntfs partition on virtualbox" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105814
<pitti> doko: if the Python policy allows a python-foo package to ship components which are not in python package foo, then that's ok for me
<doko> pitti: the file is now called apport_hook; I don't care how its called
<pitti> doko: otherwise I'd rather ship the file in apport itself
<doko> pitti: not a policy issue at all
<pitti> ok
<dholbach> hey seb128
<mvo> good morning seb128!
<doko> seb128: you're late, slacker ;-P
<seb128> hi dholbach, mvo, doko
<pitti> doko: then let's call it apport_python_hook.py
<doko> pitti: fine with me
<dholbach> seb128: slap him :)
<seb128> doko: I was around at 8am european time already, just not on IRC
<seb128> cf my reply on the distro list :p
* dholbach hugs seb128
<pitti> doko: did you change anything in the file itself? the diff makes it hard to tell
* seb128 hugs dholbach back
<doko> dholbach: he would have to come to Berliiin, which will never happen :p
<seb128> don't say never
<seb128> we might have an UDS there one day ;)
<doko> pitti: just prefixed the fileutils and report imports with apport.
<pitti> doko: alright, I commit the change to the bzr with the new name, run some tests, and do the approval/upload jumping
<pitti> doko: right
<seb128> pitti: is that known that software-properties is not translated?
<doko> pitti: ok, let me know, so that I can change the pythonX.Y packages
<pitti> seb128: bug 105611, will fix right after RC
<cjwatson> heno: see my comment
<pitti> doko: will do
<ubotu> Malone bug 105611 in langpack-o-matic "software-properties land in KDE pack" [High,In progress]  https://launchpad.net/bugs/105611
<pitti> doko: thanks!
<seb128> pitti: danke
<seb128> launchpad is slow for other people as well?
<fabbione> seb128: yes
<seb128> it takes ages to load a page since yesterday :/
<pitti> yes, sometimes; yesterday was horrible
<ogra> seb128, my evo was evil to me today :/
<seb128> ogra: like crashing?
<ogra> seems my line dropped overnight ... it showed me the online icon but didnt want to show any folder contents
<ogra> and told me i have to be online ...
<heno> cjwatson: ok, cool. I'll give it some more testing anyway
<ogra> clicking the icon didnt help ... restarting evo did
<ogra> doko, oh, btw, so you ghhad the grub question as well if you noticed the breakage there ?
<ogra> doko, it would probably help to comment on bug 105712
<ubotu> Malone bug 105712 in os-prober "feisty grub osprober doesnt detect an existing feisty install on edubuntu alternate" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105712
<doko> ogra: let me check after the install
<ogra> yup
<ogra> do you have another OS on that machine ?
<cjwatson> other partitions are automounted which confuses os-prober
<cjwatson> this is a long-standing bug which I'm not concerned about for release
<ogra> not in manual partitionning mode ....
<cjwatson> yes they are
<ogra> at kleast if i choose "dont use"
<cjwatson> unless you manually deselect them
<doko> ogra: yes, having Windows and an Ubuntu install; but all other partitions are not mounted
<ogra> right, thats what i do in manual
<cjwatson> in any case, not release-critical IMO so I'm not going to look at it further now. If you want to help, attach syslog and partman logs from the installer
<ogra> no, not at all
<ogra> but something to notice and log :)
<Mithrandir> pitti: that r-m fix is needed too, right?
<pitti> Mithrandir: not absolutely for RC; it does give false information, but the impact is much less bad than l-r-m
<pitti> Mithrandir: OTOH it's probably much quicker to build than lrm :)
<pitti> Mithrandir: for the majority of users it should just work as it is, since the majority uses nvidia-glx (no new/legacy)
<Mithrandir> ok
<saispo> how can i say on which ubuntu version i'm ?
<doko> ogra: no, the keyboard problem persists
<Nafallo> saispo: lsb_release -a
<ogra> doko, weird, how can a setting in a chroot affect a host system ? and why didnt i see it in any installs here :/
<fabbione> ogra: because you are probably sharing /proc and /dev ?
<saispo> thanks Nafallo 
<fabbione> ogra: and if you are root in the chroot you can kill processes in the host
<doko> ogra: try the edubuntu DVD? with a german keyboard? I don't know what I can offer else for testing ...
<fabbione> etc.
<Nafallo> np
<ogra> fabbione, sharing /proc will rewrite settings in /etc/default/console-setup ???
<fabbione> ogra: hmm no it shouldn't
<ogra> i can imagine that its a temporary switch as long as /proc is mounted
<fabbione> but if it does.. and it's realiable.. tell pitti :)
<ogra> but after the first reboot it should work as expected
<carlos> pitti: yesterday we had a problem with the import queue so there are some files pending to be imported
<pitti> carlos: alright; I won't update the packs today anyway
<carlos> pitti: when will you prepare final packages for Feisty?
<pitti> carlos: that's unclear yet, just discussing in the meeting
<carlos> ok
<carlos> pitti: once you know it, tell me so I can try to prioritise things so everything is imported 
<pitti> carlos: most probably tomorrow
<carlos> so I should get everything imported before midnight
<carlos> to prepare the export tomorrow morning
<pitti> and I need to fix langpack-o-matic for this software-properties bug
<cjwatson> heno: do you believe that the red bug icons are a complete list of serious issues?
<carlos> which bug?
<pitti> carlos: bug 105611
<ubotu> Malone bug 105611 in langpack-o-matic "software-properties land in KDE pack" [High,In progress]  https://launchpad.net/bugs/105611
<carlos> oh, that one
<carlos> right
<heno> cjwatson: not sure the kernel issues are reflected there, but the other items raised in the meeting have red bugs
<carlos> pitti: hmmm, are you sure it should be in GNOME ones?
<pitti> carlos: yes
<carlos> pitti: isn't it used too from KDE frontend?
<cjwatson> bug 105631 we've decided to skip for this release, right?
<ubotu> Malone bug 105631 in debian-installer "LVM install incorrectly sets root partition in lilo.conf" [Undecided,Confirmed]  https://launchpad.net/bugs/105631
<pitti> carlos: oh, in the base ones, sorry
<carlos> pitti: the bug says GNOME ones, that's why I'm asking
<Riddell> pkl_: I don't see any test results from you for kubuntu alterntae amd64
<cjwatson> I'm a bit worried by the lack of Kubuntu upgrade tests in that list
<cjwatson> nothing else coverage-wise really concerns me
<pkl_> riddell: no, I'll put them in.
<heno> Riddell: I tried doing Kubuntu upgrades yesterday, but it was non-obvious, esp. with the CD
<hunger> Will l-backports-modules-generic and kvm get fixed before the release?
<heno> Riddell: can you point me at some URL
<Riddell> heno: https://help.ubuntu.com/community/FeistyUpgrades "Kubuntu Beta upgrade"
<heno> cjwatson, pkl_, BenC: btw, we had really no testing reports from the kernel team at all yesterday, which concerns me a bit. Though I know they were busy
<pitti> Mithrandir, CC: doko: I'd appreciate your verdict about bug 105764
<ubotu> Malone bug 105764 in python2.5 "apport exception hook negatively impacts startup of python" [Medium,Confirmed]  https://launchpad.net/bugs/105764
<cjwatson> heno: I think the kernel team has been sufficiently busy that it would be a good plan to assign testing away from them
<cjwatson> hunger: clarify?
<hunger> cjwatson: Both packages are not installable for a couple of days now.
<heno> cjwatson: yes I had a quick chat with Ben yesterday and did that, but it did put a dent in the coverage
<cjwatson> hunger: architecture?
<pitti> Mithrandir: I don't think that it is really necessary to push it into feisty at this point, but it was milestoned by someone
<hunger> cjwatson: x86, really primitive.
<hunger> cjwatson: AFAIK I did not install that t
<cjwatson> hmm, linux-backports-modules-2.6.20 may need to be rebuilt for the current ABI
<doko> pitti: I did milestone it; it's a severe performance regression over edgy
<heno> I also need to rethink timing. Assigning DVDs to Europeans is a bit pointless as they are always delayed, so thumbs are twiddled
<cjwatson> kvm is universe, no?
<hunger> stuff myself, so it was dragged into the system at some point.
<Mithrandir> pitti: hm, looks simple enough.  Has it been tested by others yet?
<pitti> Mithrandir: doko and my testsuite
<pitti> Mithrandir: (it has full test coverage)
<cjwatson> I'll rebuild linux-backports-modules
<pitti> Mithrandir: if we do this, then we need to accept all three of apport/python2.{4,5} together
<Mithrandir> pitti: ok
<pitti> Mithrandir: the python2.{4,5} diff is in my last comment
<doko> preparing the python packages
<Mithrandir> pitti: looks fine to me.
<pitti> Mithrandir: thanks; I did a tiny fix to the test suite as well, btw, I hope that's ok (doesn't affect any code running on installations)
<Mithrandir> pitti: yes
<cjwatson> Mithrandir: please accept linux-backports-modules-2.6.20_2.6.20-14.9_source.changes
<seb128> does anybody has a keyboard with multimedia key "play,pause", "play", "pause"?
<dholbach> seb128: I have play/pause
<seb128> and could tell me what codekey they are using
<iwj> seb128: Yes.
<iwj> Err, in X, or what ?
<seb128> dholbach: could you look what value it has (you can use the gnome shortcut dialog and try assigning it to something)
<iwj> If you mean in X, you mean xev ?
<seb128> iwj: system, preferences, keyboard shortcut (or whatever it's called in english)
<seb128> iwj: try to assign them to something
<seb128> and note the code listed
<Mithrandir> seb128: it varies between keyboards.
<dholbach> seb128: 0xa2
<seb128> Mithrandir: are you sure?
<Nafallo> seb128: if not, I'm sure :-)
<Mithrandir> seb128: fairly.
<seb128> dholbach: ok, thank you
<Nafallo> XF86PLAY should work? :-P
<seb128> Nafallo: isn't acpi_fakekey handling them?
<Nafallo> seb128: dunno. I just remember I had problems with that in some release cycle :-). the bug got rejected since I hadn't set my keyboard to what it was or something like that :-)
<Nafallo> I made a patch for my keyboard to the file that specified what keys it used :-)
<seb128> Nafallo: we use standard value for volume, eject, www, etc, seems to work correctly
<seb128> we didn't get any bug this cycle about volume key not working I think
<elmo> my laptop multimedia keys don't work anymore, FWIW, but then my laptop is apparently cursed
<Nafallo> things might have improved. I think it was hoary or breezy I was talking about :-)
<seb128> elmo: which one? none of them
<elmo> seb128: none of them, play/pause, stop, ff, rew
<elmo> err, except I'm  using xmms, not rhythmbox \o/
<Keybuk> elmo: do you have the double-dhclient issue?
<elmo> Keybuk: yes
<seb128> elmo: those are no default value assigned
<seb128> elmo: that's what I'm trying to change right now :p
<Keybuk> elmo: can I borrow your /e/n/i
<seb128> s/are/have
<Tonio_> Mithrandir: just uploading digikam, closing an important issue in the latest release (bug/102912
<Tonio_> Mithrandir: nothing critical for the release
<Tonio_> Mithrandir: I hope you'll approve :)
<Mithrandir> Tonio_: if it's not critical for the release, I'll reject it.
<elmo> seb128: I could swear they use to, but maybe I'm insane
<Tonio_> Mithrandir: sorry I meant that's important for the release, it breaks an important part of it
<Fujitsu> Isn't there a new dbus API that multimedia keys need to be accessed by?
<Tonio_> Mithrandir: I'm just tired :)
<seb128> Fujitsu: no
<Keybuk> elmo: have your hotkeys worked before?
<seb128> Fujitsu: that's an implementation detail
<elmo> Keybuk: yes
<seb128> Fujitsu: they still need to be configured to the same capplet
<Keybuk> elmo: when you push them, do you get invalid scancode type messages in syslog
<iwj> seb128: Plau/Pause: 0xa2 (which it thinks is pause).  Stop: 0xa4.
<Keybuk> (maybe try from console)
<Tonio_> Mithrandir: the all image editor is broken in fact... which for digikam is really a big issue :)
<iwj> seb128: I have no separate pause key.
<Mithrandir> Tonio_: how many people have tested the patch?
<seb128> iwj: ok, thank you. Do you have a pause different of the play/pause?
<seb128> iwj: ok
<Tonio_> Mithrandir: lots on kubuntu-devel, patch is fro msvn upstream
<iwj> Also missing are skip back and forth which are 0x90 and 0x99.
<elmo> Keybuk: nope
<iwj> `Skip to {previous,next} track'
<Tonio_> Mithrandir: I too have tested it, works perfectly
<seb128> iwj: right, those are on my list and ok
<Keybuk> elmo: in gnome's keyboard prefs, can you change an item, push one of those keys and have it set?
<Tonio_> Mithrandir: Riddell is okay for the upload (I just asked)
<iwj> seb128: Right.
<Mithrandir> Tonio_: ok
<Tonio_> Mithrandir: thanks
<elmo> Keybuk: yes
<Keybuk> elmo: iz gtk bug
<seb128> elmo: are they list by the keyboard shortcut configuration dialog?
<elmo> they're listed as 0x99 and similar
<elmo> or do you mean something else?
<seb128> elmo: no, just wondering if there was key associated to the actions
<seb128> since we don't do it by default atm
<seb128> with what app did you try them?
<Mithrandir> Riddell: what's up with https://bugs.launchpad.net/ubuntu/+source/kdebase/+bug/61946 ?  It looks like this should have been milestoned ages ago?
<elmo> seb128: xmms
<ubotu> Malone bug 61946 in kdebase "[Edgy Data Loss]  umount progress dialog missing" [High,In progress]  
<elmo> seb128: but it's all my hotkeys, including brightness, lock, sleep, etc.
<seb128> iwj: ok, so your stop button is 0xa4 and BenC mail on the distro list suggest using 0xe8
<seb128> elmo: hum, ok, dunno then
<cjwatson> Mithrandir: err that was on the milestone list a while back? and a fix went in a couple of days ago
<cjwatson> I assumed the uploader would take care of closing the bug
<pygi> hi jsgotangco :)
<Mithrandir> cjwatson: it was?  I'm fairly sure I haven't seen that before, but malone _still_ doesn't show milestoning in the activity log.
<cjwatson> assuming that it was in fact a complete fix
<cjwatson> yes, I am absolutely certain that was milestoned
<Mithrandir> but if it's been fixed, that's good
<cjwatson> https://lists.ubuntu.com/archives/feisty-changes/2007-April/008418.html
<jsgotangco> hi pygi!
<cjwatson> it sounds from the bug as though the uploader may not believe it's a complete fix
<cjwatson> nice of them not to even mention the upload in the bug though :P
<Mithrandir> indeed.
<Mithrandir> I'll follow up on that
<cjwatson> thanks
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/testing/feisty_probs.html is nothing like as empty as it should be
<iwj> seb128: Hmm.  Dunno.
<iwj> I've just double-checked it.
<ogra> cjwatson, well it has ppc ...
<seb128> iwj: thanks anyway, https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/37225 also lists 0xa4
<iwj> The keyboard is a Packard Bell thing I got free with some hard disks (!)
<cjwatson> it's nothing like as empty as it should be even aside from powerpc
<ubotu> Malone bug 37225 in control-center "asus multimedia hotkeys not handled" [Medium,Confirmed]  
<cjwatson> I'll move powerpc to ports there, but still
<Keybuk> (someone remind me how to send Ctrl-Alt-F1 to vmware)
<cjwatson> ctrl-alt-shift-f1?
<ogra> cjwatson, also it seems not to be up to date ... schooltool was removed from main some days ago
<Mithrandir> ogra: not the binaries
<Keybuk> cjwatson: that didn't work, ctrl+alt-space-f1 worked
<cjwatson> ogra: please always check facts in the archive before suspecting that the tools are broken
<ogra> cjwatson, well, pitti demoted everything i was told by him ...
<cjwatson> it is not the case that the tools can never be broken, but it's much less likely than that the archive state is simply not what you think it is
<cjwatson> schooltool | 0.11.4-1ubuntu4 |        feisty | all
<cjwatson> CHECK FACTS
<cjwatson> seriously, it's not that hard to fire up a browser and look
<cjwatson> I will demote the rest of school* now
<ogra> no, but do i really need to check everything if my colleagues tell me something ?
<pitti> hmm, I have 'change-override.py -c universe -S schooltool' in .bash_history
<cjwatson> pitti: failed because the binaries are out of date
<pitti> oh, I see
<cjwatson> ogra: if you're then going to tell another colleague that his tools are broken, yes, you do
<ogra> cjwatson, i didnt say anything is broken ... :)
<ogra> outdated though ...
<cjwatson> 11:50 <ogra> cjwatson, also it seems not to be up to date ... schooltool was removed from main some days ago
<pitti> cjwatson: so I had to demote the binaries separately? (for next time)
<cjwatson> outdated => broken for a tool that runs every hour
<cjwatson> pitti: yeah, unfortunately
<ogra> cjwatson, i didnt want to blame you or anyone ... i just noticed that the report didnt match my reality :)
<cjwatson> ogra: the output even has a timestamp at the top of it
<pitti> alright; sorry for the confusion
<ogra> cjwatson, ok, thats my fault then, i'll look more closely next time 
<cjwatson> ogra: I just really want your first response to a problem to be to check the facts, rather than to say that the thing that's outputting warnings must be wrong
<cjwatson> that's all
<cjwatson> pitti: no worries, fixed now
<ogra> cjwatson, i'll try :) sorry again
<cjwatson> ogra: powerpc is in testing-ports now; thanks for the report
<ogra> thanks for fixing :)
<pitti> cjwatson: ah, you already took care of the API bump for linux-backports-modules?
<pitti> cjwatson: then we only need to remove the -13 cruft and anastacia/feisty_probs should be a bit happier
<pitti> (I put that on my plate)
<cjwatson> pitti: yeah, it's in unapproved waiting for Mithrandir to check it
<Mithrandir> cjwatson: accepted
* cjwatson repeats some Xubuntu seed merges that got lost somehow, to get rid of lowlatency again
<elmo> woo, metacity crashes for me on boot reproducably \o/
<Riddell> Mithrandir: it wasn't milestoned because it's been an upstream bug for ages so I never expected anyone to come with a fix, but fdoving surprised me
<elmo> pitti: does apport only record one crash per program/uid ?
<pitti> elmo: yes, until you see it in the UI it won't be overridden
<ogra> Riddell, for gutsy i'd like to talk to you about a qt based greeter for ldm ... to make the kde people more happy that use ltsp 
<pitti> elmo: however, it counts the number of crashes per exe/uid
<carlos> mvo: ping
<ogra> Riddell, are you ok if i register a spec for that during next week and subscribe you to it ?
<pitti> elmo: I needed to prevent flooding
<cjwatson> As the discussion of an Ubuntu bug grows longer, the probability of an invocation of Bug #1 approaches one.
* cjwatson contemplates adding that as https://wiki.ubuntu.com/Watson's_Law
<Riddell> ogra: I have an edubuntu-kde spec on the canonical wiki for such things
<mvo> carlos: pong
<ogra> Riddell, well, thats unrelated to edubuntu
<ogra> ltsp != edubuntu ;)
<carlos> mvo: I have bad news for you
<Riddell> ogra: then the name of the spec should be changed
<ogra> Riddell, but its ok for a start i guess
<carlos> mvo: even increasing the amount of time before we think our poimport script is stalled, we get a timeout with your universe import
<carlos> mvo: our parser takes more than 1 hour to process that file
<ogra> Riddell, nope, we *should* have an edubuntu spec as well :) but this specific task should go under kubuntu-ltsp integration or so
<carlos> mvo: so I had to block it
<carlos> mvo: to allow all Feisty files to be imported in time before midnight
<carlos> mvo: we are going to fix that performance problem as a critical bug
<pitti> seb128: gnome-doc-tools in anastacia: demote or seed?
<carlos> but that would mean that I don't think you will be able to update that template in a week or so
<seb128> pitti: if nothing Build-Depends on it, demote
<carlos> mvo: talking only about universe one
<mvo> carlos: ok
<carlos> which is huge, not sure about the .po files...
<pitti> seb128: ladspa-sdk wants to go as well; in edgy, gst-plugins-good needed it; I assume that's alright? or was it inadvertedly disabled in feisty's gst?
<pitti> Riddell: compiz-kde: seed or binary-only demotion to universe?
<pitti> Riddell: IOW, does it work at all?
<Riddell> pitti: no idea, never tried it :)
<Riddell> pitti: as far as I know it's just a dummy package with only a stub in it
<pitti> -rwxr-xr-x root/root    126288 2007-04-04 09:58:19 ./usr/bin/kde-window-decorator
<pitti> Riddell: ok, so rather demote, I figure
<Riddell> pitti: I wouldn't call it supported whatever it is
<pitti> ogra: can you please seed student-control-panel? it's a transitional package, but as such it needs to be in main for feisty
<heno> *** All 20070411 images have been rejected for RC. 20070412 images being built. See https://www.stgraber.org/ubuntu/isotesting/ for status and md5sums ***
<jsgotangco> oucchhhh
<pitti> ogra: wb
<ogra> my broadcom doesnt like me today :/
<pitti> ogra: not sure whether you got that still: <pitti> ogra: can you please seed student-control-panel? it's a transitional package, but as such it needs to be in main for feisty
* fabbione starts rsync
<ogra> pitti, ok, no problem 
<pitti> ogra: thanks
<jsgotangco> ogra: i'll just wait for this day's build to be done,
<ogra> jsgotangco, well ... you could rsync on top of yesterdays ;)
<fabbione> Mithrandir: what images have been rebuilt? i can see sparc/server is still the old one
<jsgotangco> ogra: sure but you asked me to do DVD hehe
<Mithrandir> fabbione: -server is being rebuilt right now.
<fabbione> Mithrandir: ok thanks
<ogra> jsgotangco, exactly :)
<ogra> pitti, suported is sufficient i guess
<pitti> ogra: sure
<pitti> ogra: in the ubuntu seeds we have a paragraph for transitional packages
<pitti> so that we can clean this up over time again
<ogra> ah, yes i see it
<pitti> Mithrandir: I uploaded a new language-support-gl with two more oo.o l10n/help packages which linger in anastacia (doesn't affect CDs)
<heno> fabbione: I wasn't sure about that one, setting it inactive too
<fabbione> heno: you also want to clear netinstall/netboot
<heno> fabbione: I'll clear the sparc one. the other's never got tested anyway. Setting up to do that here now
<fabbione> heno: ok
<ogra> pitti, committed
<pitti> cheers
<ogra> doko, can you attach /etc/default/console-setup and /opt/ltsp/$arch/etc/default/console-setup to the keyboard bug ?
<ogra> i'd like to compare them
<doko> ogra: same files, and XKBLAYOUT is set to "de"
<ogra> right
<ogra> so console-setup should set it to de on boot ...
<ogra> cjwatson, is there anything that can override /etc/default/console-setup ? i wouldnt think so ...
<ogra> (in a default install that is)
<cjwatson> the initramfs could be broken
<ogra> hmm
<cjwatson> check /etc/default/console-setup in the initramfs
<ogra> but thas generated already if ltsp gets installed
<cjwatson> if 'sudo setupcon' fixes the keyboard layout, then the initramfs is definitely broken
<ogra> will do, doko, can you send that to me ? 
<ogra> or /etc/init.d/console-setup start i suppose
<desrt> gutsy?  seriously?
<Hobbsee> desrt: appears so.
<ogra> desrt, "all your source is eaten by us !"
<fabbione> desrt: yeah
<ant_ipop> for help testing rc i should go to https://www.stgraber.org/ubuntu/isotesting/ right ?
<Hobbsee> desrt: unless it's 13 days late
<fabbione> ant_ipop: yes
<ogra> ant_ipop, yep
<heno> ant_ipop: you can get advice in #ubuntu-iso and from https://wiki.ubuntu.com/Testing/Community
<ant_ipop> ah thanks for that
<desrt> eh.  what's in a name? :)
<Hobbsee> desrt: many misspellings
* desrt would have preferred gusty
* Hobbsee keeps saying it's gusty
* desrt forms the gusty alliance with hobbsee
<Kmos> how works in opera browser updates?
<Kmos> to assigne a bug report for the updated version
<doko> ogra: no, the file in the initramfs is the same as well
<desrt> ...or should i call you hosbee...
<cjwatson> doko: does 'sudo setupcon' at a console fix the layout?
<Hobbsee> desrt: wonder what jdub will call it
<heno> doko, ogra: FYI the Edubuntu amd64 DVD installed fine here. Both virtualbox and real hardware
<Hobbsee> desrt: no, you shouldnt.
<doko> cjwatson: wait, have to reboot
<desrt> i want jdub at UDS.  srsly.
<ogra> heno, no such glitches like doko saw ? 
<heno> ogra: no, on the default option it was fine. Will try safe graphics mode too
<heno> ogra: can I force it to use VGA?
<ogra> heno, any keyboard weirdness ? 
<ogra> i start to suspect dokos iso or media is broken 
<heno> ogra: didn't heck for that yet, will do
<ogra> thanks
<Hobbsee> desrt: yes, jdub is fun.
* desrt becomes exposed to a very interesting neologism
<desrt> "islamophobia"
<jsgotangco> crazy gnome madmen are always fun
<doko> cjwatson, ogra: reboot has to wait until my OOo build finishes; about 1 1/2h
<StevenK> doko: Another openoffice.org upload? Have you no respect for the buildds? :-P
<ogra> doko, fine with me 
<pitti> heno: do you know gnome-accessibility-themes-extras? it wants to go to universe; shall I seed it (if it's any good) or demote?
<fabbione> desrt: you coming to Seville?
<desrt> of course
<pitti> desrt: cool
<desrt> watch me forget the G5 again
<fabbione> desrt: G..... 5....
<fabbione> ahhaha
* desrt grins
<cjwatson> openoffice.org at this point in the release? What universe imploded? :)
<StevenK> Heh
<fabbione> cjwatson: he didn't pay the heating bill.. what's best than a CPU? :)
<cjwatson> mdz_: bug 105861, fyi
<StevenK> fabbione: Bwahaha.
<ubotu> Malone bug 105861 in ubiquity "migration-assistant cleanup handler manages to fork somewhere" [High,Confirmed]  https://launchpad.net/bugs/105861
<cjwatson> investigating
<cjwatson> Mithrandir: ^--
<Hobbsee> Keybuk: were you going to have a separate universe UVF again, at the same time as new package universe freeze?  (aug 30)?
<mdz_> cjwatson: under what circumstances is it triggered (if you know)?
<cjwatson> mdz_: not quite sure; it happened to me with a simple install on a system where m-a didn't offer anything to import
<cjwatson> mdz_: it's quite possible that the forked process (well, actually it's probably a separate thread rather than a true fork, thanks pygtk) goes off and exits harmlessly and the only ill effect is the warning dialog (a relatively recent addition to fix other critical problems)
<cjwatson> I'll let you know when I know more
* cjwatson -> lunch
<cjwatson> critical problems> it used to be that if partman exited non-zero then ubiquity wouldn't notice and could end up trying to "install" into the ramdisk. I fixed that ...
<heno> pitti: it will keep coming from upstream gnome each cycle I guess, so we split it out each time. universe is fine by me though
<pitti> heno: unless its really crackful or has dependencies not in main, we can seed it (for consistently having all binaries in main)
<heno> pitti: right, let's keep it then. It's just themes from upstream that we opted not to install by default, not very crackful
<pitti> heno: alright, I seed it
<pitti> thanks
* ogra grumbles about bug 81227
<ubotu> Malone bug 81227 in hal "Logout screen appears twice [Feisty] " [Medium,In progress]  https://launchpad.net/bugs/81227
<ogra> dear HW vendors, please use unified names goddamned!
<mjg59> Unified names?
<ogra> mjg59, acpi_PWRF and acpi_PWRB .... and who knows what else will show up 
<mjg59> There's no requirement for any sort of consistent naming
<mjg59> Don't attempt to depend on it. You'll just lose.
<ogra> there is ... from me ... but i doubt they will listen to me ;)
<mjg59> HP use ACPI identifiers that are longer than four characters and then collapse them down into C+3 digits of hex
<ogra> gah
<mjg59> so the name will change depending on BIOS upgrade
<ogra> yeah
<mjg59> The spec doesn't require any object names to be meaningful
<ogra> well, but it seems for the HP people on the bug my workaround fixed it
<ogra> might be that they are the lucky ones here ...
<ogra> i simply dont want to bloat that workaround ... 
<mjg59> If you're trying to use ACPI object names, then that's not a workaround. That's a bug.
<ogra> well, how els should i do it ? (the patch is on the bug in my last comment)
<ogra> according to #hal the fix has to happen in hal itself which we cant do atm ... the workaround seems to fix it for a lot of people but not for all ...
* mjg59 waits for Launchpad
<ogra> yeah, its horribly slow atm ...
* desrt gets an IO-APIC-related kernel panic on boot and glances at mjg59
<mjg59> Why not just key off all acpi objects that send the power button?
<ogra> how do i match that ? 
<mjg59> acpi_
<ogra> yeah, thats what i planned now (see my comment)
<ogra> seems i should cut he paternmatching after the underscore to match all acpi_**** devices ... :/
<mjg59> The only ACPI devices that can generate power button events are, well, power buttons
<ogra> mjg59, so you think thats sufficient for now ? 
<mjg59> So yeah
<ogra> ok, i'll change to strncmp then and curt the last four chars ...
<mjg59> You're in a glib application
<ogra> oh, right
<fabbione> heno: are you keeping track of the bugs that have been cleared from 11 iso testing?
<fabbione> heno: they have been wiped from the board too
<fabbione> heno: or do we need to relink them again?
<fabbione> who is our avahi expert?
<fabbione> pitti: is that you?
<pitti> fabbione: Lathiat mainly
<fabbione> Lathiat: you around?
<fabbione> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/105872
<fabbione> (hw-cert bug)
<ubotu> Malone bug 105872 in network-manager "Network not enabled properly by NetworkManager which configures eth1:avah" [Undecided,Unconfirmed]  
<TomaszD> pitti, thanks for fixing that software-properties translations misplacement bug! 
<pitti> TomaszD: you're welcome; I still need to rebuild the langpacks for that
<TomaszD> pitti, that'd be very welcome to have, new langpacks as official update, not just the daily ones
<TomaszD> pitti, can we expect that sometime soon? anyway it's just a few days before the final release...
<pitti> iwj: what is the reason for the mkdir -m 0755 /dev/mapper in libdevmapper1.02.postinst?
<pitti> TomaszD: yes, probably tomorrow we'll see another feisty langpack upload
<TomaszD> pitti, great :] 
<pitti> TomaszD: 'directly after RC release'
<TomaszD> after...? I'm too tired to argue, but I see a flaw in this plan :] 
<pitti> TomaszD: this issue is by no way a showstopper for the RC
<pitti> TomaszD: it should be fixed in the final release, of course, and it will
<TomaszD> no, of course it's not a showstopper, I'm not even trying to argue that. I was just thinking that the last official langpack upload was committed quite some time ago and Ubuntu'd really use a new upload, and RC would be a great testbed for that
<TomaszD> that's why I'm wondering why "after"
<pitti> because we have RC images since yesterday
<pitti> sure, we just got new ones, but still; no time to push in 1000 new packages
<TomaszD> fair enough.
<TomaszD> :] 
<pitti> TomaszD: and you can still dist-upgrade your system after installation, to get the latest pacakges
<TomaszD> yes, sure, I'm no newbie. Using Ubuntu since 5.04 
<TomaszD> bbl
<elmo> seb128: where's 0.16.1 ?
<heno> ogra: I did a complete install in German from the amd64 Edubuntu DVD (20070411). Keyboard and everything else worked fine
<ogra> good
<ogra> on the CD as well, so i guess its doko specific ...
<doko> ogra: rechecking with today's DVD later
<seb128> elmo: that's a good question, "Successfully built" on https://launchpad.net/ubuntu/+source/vte/1:0.16.1-0ubuntu1 
<seb128> elmo: iz launchpad bog
<ogra> doko, thanks ... i think a media check would also make sense
<doko> ogra: the check was sucessful
<ogra> hmm, k
<ogra> still weird 
<Mithrandir> seb128: investigating.
<seb128> Mithrandir: thank you
<iwj> pitti: I'm not sure.  I don't think it was my doing.
<iwj> It seems odd that it doesn't say -p.
<iwj> If you have udev then something has to make /dev/mapper and I have a feeling that the C code in libdevmapper itself won't.
<pitti> iwj: weird; a mere modprobe dm-crypt sorted that out for me so far
<iwj> Is it causing a problem ?  The way you quote it makes it non-idempotent which is clearly wrong.
<iwj> pitti: Ah, probably that causes /dev/mapper/control to be made by udev.
<pitti> iwj: oh, it broke the retracer chroot; which is not really libdevmapper's fault, I just wondered what it was for
<cjwatson> mdz_: migration-assistant panic over; there's something still not right with the control flow, but I've decided it's not release-critical, and the non-zero exit status was due to having an LVM PV on the disk
<iwj> So I bet it's just a fossil.
<cjwatson> so it's a bug, but it can wait until after feisty
<mdz_> cjwatson: ok
<AlinuxOS> pitti, hello
<pitti> iwj: it seems that Keybuk added it 10 days ago, so it's not really a fossil
<iwj> Oh.
<iwj> I bet there's a race then somewhere which means it ought to exist first.
<AlinuxOS> is today LanguagePackTranslationDeadline ?
<Keybuk> hmm?
<iwj> Not clear why the postinst is the right place, though.
<iwj> 14:33 <pitti> iwj: what is the reason for the mkdir -m 0755 /dev/mapper in libdevmapper1.02.postinst?
<mvo_> pitti, Mithrandir: could you please accept the app-install-data-commercial upload to dapper-proposed once it hits (uploaded a couple of minutes ago). bugnumber is #105847
<pitti> mvo_: will do
<Keybuk> because you can install dmsetup into a system with existing devmapper nodes
<mvo_> pitti: great, thanks
<Keybuk> the /dev/.static/dev/mapper is more important, I did the other for completeness
<pitti> Keybuk: hm, but if /dev/mapper/something already exists, why is the mkdir necessary?
<pitti> ah
<Keybuk> pitti: that's what the [ ! -d ]  bit is for :p
<Keybuk> it's to make the directory if you are *not* running udev
<Keybuk> since if you're running udev, the -d /dev/.static/dev bit is true
<Keybuk> it makes sure that /dev/mapper exists as a directory on the root filesystem
<pitti> Keybuk: I see; well, the library doesn't change all that often, I hope, so I can just clean up after it manually
<Keybuk> so that when the udev /dev is mounted, /dev/.static/dev/mapper exists
<Keybuk> pitti: "clean up after it" ?
<pitti> Keybuk: it breaks the retracer chroots (since you cannot mkdir as normal user in /dev)
<Keybuk> oh
<Keybuk> you have /dev in your chroots but not /dev/.static/dev ?
<Keybuk> (that's probably your bug -- some postinsts fail without /dev/.static/dev)
<mdz_> Keybuk: any word on network-manager?
<pitti> Keybuk: I didn't say it's a bug in libdevmapper NB, I was just curious what it was for
<Keybuk> mdz_: yes, lots of words
<Keybuk> most of them four letters long, and not pleasnt
<pitti> Keybuk: the chroot's /dev is just the normal system's /dev
<Keybuk> pitti: libdevmapper assumes that the directory it creates nodes in exists
<Keybuk> pitti: right, but did you recursively mount under that
<mdz_> Keybuk: words which meaningfully relate to the 7.04 release?
<Keybuk> ie. does /dev/.static/dev exist ?
<pitti> Keybuk: there is a /dev/.static/dev on ronne
<Keybuk> *shrug*
<Keybuk> then I don't see why you're touching that postinst at all
<Keybuk> if there's a /dev/.static/dev then you won't be reaching the mkdir you're complaining about ;)
<pitti> Keybuk: it's not really mounted, it's just a symlink to the real /dev, so it includes everything under it
<pitti> Keybuk: reality just proved that wrong :)
<cjwatson> what, a symlink out of the chroot?
<Keybuk> sh -x it
<Keybuk> I reckon your system is bogus'd somehow
<cjwatson> if so then it could be a broken symlink and test -d would return false ..
<fabbione> Keybuk, mdz_, cjwatson: #105872 coming in from hw-cert
<Keybuk> aye, what colin said -- symlinks can't point outside chroots
<pitti> cjwatson: yes, fakechroot supports that to be able to use /proc and /dev
<fabbione> 3 bugs so far from 11 testing.. one is not in LP yet
<cjwatson> pitti: maybe it doesn't support it properly
<pitti> cjwatson: yes, it's pretty hideous
<Keybuk> that postinst looks fine
<cjwatson> specifically stat() of the symlink sounds like it returns the wrong thing
<mjg59> cjwatson: 105234 looks pretty relevant
<Keybuk> if udev is running (/dev/.static/dev exists) then it makes the directory under that if it doesn't already exist
<mjg59> (release-wise rather than to current conversation)
<Keybuk> otherwise it makes the directory on the root filesystem
<Keybuk> (so when you boot with udev, /dev/.static/dev/mapper exists)
<pitti> Keybuk: alright, I track it down the next time it stumbles over that
<pitti> Keybuk: thanks
<Keybuk> right
<Keybuk> so network manager
<fabbione> Keybuk: yeps...
<Keybuk> this thing is so totally bogusly broken that I want to cry
<Keybuk> basically there's a race between ifup and network manager
<Keybuk> so you can end up with two dhclients
<Keybuk> since ifup starts one after network manager kills them all
<mjg59> dhclient is supposed to have pidfile handling
<jtt> is the Ubuntu kernel 2.6.17-10 any different than 2.6.17-10 from kernel.org  i.e. does Ubuntu make any signifcant changes
<mjg59> Why isn't that working in this case?
<Keybuk> mjg59: the pid file has a random number in it
<mjg59> jtt: -10 represents the Ubuntu ABI version, not 2.6.17.10
<mjg59> And yes, very different
<mjg59> Keybuk: Why?
<jtt> mjg59: thanks
<Keybuk> no idea
<mjg59> Fixing that would presumably fix the issue to some extent
<Keybuk> I don't think so
<Keybuk> because I'm seeing other weird behaviour caused by dhcdbd
<Keybuk> it seems to kill dhclient itself if it gets a status message it wasn't expecting
<Keybuk> and I don't understand how network manager kills dhclient
<Keybuk> since it does "killall dhclient", which won't match dhclient3 (which is what ifup starts)
<Keybuk> I also don't understand why NM seems to take over eth0 when there's nothing even logged in yet
<Keybuk> I thought it needed nm-applet to tell it to do that
<mjg59> My understanding was that it claimed interfaces on startup
<mjg59> In the absence of policy, the policy is no network
<Keybuk> so it does appear to "claim" the eth0 interface
<Keybuk> bring it down
<mdz> it seems to bring up interfaces before login for me (which is fortunate because I want that)
<Keybuk> (seperate to it actually killing dhclient, it tells dhcdbd to bring it down)
<Keybuk> and then bring it back up again
<Keybuk> this happens whether or not it was already up or down
<Keybuk> so policy seems to be to always have an interface up
<xtknight> hey
<mjg59> Interesting
<Keybuk> so it seems we have four different things trying to do things to a network interface at the same time
<Keybuk> ifup called by udev
<Keybuk> ifup -a
<Keybuk> dhcdbd
<Keybuk> and network manager
<Keybuk> it's no surprise it's a bit buggered, tbh
<Keybuk> (the ifup -a bit doesn't clash with network-manager, just the ifup-by-udev and we have locking for that)
<azazello> why does acpi-support-0.95 tarball have a top level dir called acpi-support-0.94?
<mjg59> Because we hate freedom
<xtknight> there may be a diff.gz to update it to 0.95?
<Mithrandir> cjwatson: #105861> phew
<azazello> xtknight: the files inside do mention 0.95
<cjwatson> there is another m-a-related bug in that the installation summary doesn't properly display what's to be migrated
<xtknight> azazello, apt-get source gives me onloy a 0.95 dir
<cjwatson> I'll commit the fix but I don't think it's release-critical
<mjg59> azazello: The top level directory name is pretty unimportant
<xtknight> what's the status of the network-manager issue?   
<ogra> heh
<ogra> which of the 1000 ?
<ogra> :P
<xtknight> heh the one with 1000 duplicates ;)
<cjwatson> azazello: the top-level directory name is just whatever the directory happened to be called when the developer built the source package.
<xtknight> bug 105234
<ubotu> Malone bug 105234 in network-manager "Netowrk manager says disconnected but is connected and working" [Medium,Confirmed]  https://launchpad.net/bugs/105234
<cjwatson> read scrollback
<mjg59> xtknight: There's a large number of n-m issues that people are working on
<Keybuk> I also, as an experiment did the following
<Keybuk>  - configured an eth1 and eth2 
<Keybuk>  - both auto/dhcp
<Keybuk>  - ifup brings them both up, both with dhclient3 processes running
<Keybuk>  - started network manager
<Keybuk>  - network manager removes the ip from both
<Keybuk>  - and then "brings up" eth2 again
<Keybuk> dhclient kills the existing eth2 process (correctly, itself) and starts a new one
<Keybuk> you're then left in a state with
<Keybuk> eth1: UP, no IP, dhclient3 running (!!)
<Keybuk> eth2: IP, dhclient, etc.
<Keybuk> (and ifup thinks both are up)
<Keybuk> after a short while (dhcp lease time?) dhclient for eth1 gets an IP again
<bddebian> Heya
<Keybuk> which sends NM into an absolute spawn
<Keybuk> spasm, even
<seb128> Mithrandir: sound-juicer could use a Depends on libgnomevfs2-extra (required to do cddb), that's low importance though, ubuntu-desktop install it, ok to upload the change now or rather next cycle?
<xtknight> what determines whether NetworkManager handles an interface or not?
<hunger> xtknight: As far as I could find out so far: The phase of the moon.
<seb128> xtknight: the interface being list to /etc/network/interfaces or not
<seb128> listed
<mvo_> Mithrandir: could you please do a publisher run for app-install-data-commercial in dapper-proposed ? 
<Mithrandir> mvo_: the publisher is on auto.
<Keybuk> seb128: except that's bogus
<Keybuk> since NM thinks it's fun to kill dhclients
<xtknight> hrmm but /etc/network/interfaces is for ifup() at startup too, right?
<Treenaks> Keybuk: can't it just keep track of its own children, and just kill THOSE, instead of killing anything that looks remotely like a dhclient?
<ogra> Keybuk, well, at least it leaves static interfaces alone atm
<Keybuk> then we end up in the situation where you can't use network manager until you've removed things from /e/n/i
<mvo_> Mithrandir: oh, sorry. I thought it was still in manual mode
<ogra> which was the edgy situation, no ? 
<Keybuk> which was a pain, but at least it worked
<ogra> yeah
<Keybuk> I don't really have any release-useful suggestions at this point
<TheInfinity> when was the update where /usr/share/X11/fonts/... was changed to /usr/share/fonts/X11/... ? because german and english wiki entrys have this old version ...
<Keybuk> with half a dozen tests, I've convinced myself that NM only works if you don't use ifup for anything other than lo
<Keybuk> and even the work to go back to that would be more than 1 week including testing
<Nafallo> TheInfinity: early feisty
<ogra> Nafallo, i thought that came with 7.0 already ? 
<Nafallo> ogra: that change was when we merged back with Debian. I'm fairly certain on that :-).
<xtknight> Keybuk, did the patch ( http://librarian.launchpad.net/7297631/patch_network-manager_0.6.4-6ubuntu6.patch ) produce satisfactory results?  I assume there is another more serious underlying problem?
<TomaszD> there is a problem with network-manager.  "static configuration" option isn't translatable
<tepsipakki> TheInfinity: if you mean the change in new xorg.conf-files, it was made in February when 7.2 was merged
<Mithrandir> TomaszD: already fixed.
<TomaszD> Mithrandir, checked lp this morning, not available
<Mithrandir> TomaszD: that's because LP is lagging.
<TheInfinity> teps ... okay ... then we have to make a switch in wiki ...
<TomaszD> Mithrandir, so should be available, say, tomorrow?
<Nafallo> tepsipakki: are you sure? I still think the change was very early feisty when we merged back with Debian and they had that other path...
<cjwatson> I think it was early *edgy* when we merged back with Debian and they had that other path
<tepsipakki> Nafallo: hah, you are right :)
<cjwatson> oh, hmm, maybe not
<tepsipakki> the ones we merged from in February had both paths
<Nafallo> yay memory! :-)
<cjwatson> I must be thinking of xkb
* Keybuk hates webm
<Keybuk> more than I hate NM
<Nafallo> Keybuk: webm? webmin?
<Keybuk> Nafallo: literate programming
<StevenK> Nafallo: Don't use language like that around me.
<Nafallo> ah ;-)
<Keybuk> noweb thingy
<iwj> Is it just me or is LP being hopeless today ?  I just got an ECONNRESET (according to this here livecd's firefox).
<TomaszD> iwj, it
<TomaszD> it's on its knees
<StevenK> iwj: Agreed, I've gotten four or five
<Mithrandir> iwj: it's slow.
<iwj> For me it's beyond slow.
<cjwatson> #launchpad-code
<Hobbsee> iwj: probably getting as bad as australia's often is - or used to be
<cjwatson> (irc.canonical.com)
<ogra> iwj, seems i'm joining in ... connection reset as well here now 
<fabbione> i just spoke with SteveA about LP
<fabbione> there is going to be somekind of improvement within the day
<ogra> good
<dholbach> amd64 desktop look good
<jsgotangco> yeah
* dholbach rsyncs i386 dvd
<seb128> cjwatson: what component has the ubiquity translations?
<iwj> Hmm, I'm glad I saved a copy of that bug text now.
<cjwatson> seb128: debian-installer
<seb128> cjwatson: ok, thank you
<iwj> Oh, looks like I'm reporting this bug twice since the email from the first attempt has just arrived.
<iwj> Does langpack installation in ubiquity do some kind of LP transaction ?
<iwj> I have an install here which seems to have got stuck at that stage.
<pitti> iwj: downloading the packages at most
<pitti> iwj: but that shouldn't happen for English
<iwj> I'm installing in German just for a change.
<pitti> iwj: do you see a 'cancel' button?
<iwj> Yes.
<iwj> I didn't select it and it has just woken up.
<pitti> iwj: if so, then it's the stage where it downloads language-support-de and dependnecies
<iwj> How big is that data ?
<pitti> iwj: hmm, magnitude of 30 MB
<iwj> Ah, in that case the bug is just poor progress display.
<pitti> iwj: hm, IIRC there was a textual ETA somewhere
<pitti> it usually works quite well for me
<iwj> Not in this case.
<ogra> i usually get a question if i want to download it 
<pitti> ogra: in alternate, yes, but not in ubiquity
<ogra> ah
<pitti> it just does and allows you to cancel
<andre_pl> with the latest feisty kernel my tifm card reader doesn't work at all.  the modules load, but otherwise theres nothing in dmesg.. i had read on launchpad that the latest kernel had included a newer tifm driver that was supposed to solve most of these problems but in my case it is worse.
<reitblatt> andre_pl: you would get better help in #ubuntu-kernel
<andre_pl> reitblatt: thanks. I thought this was the right place. :P
<Hobbsee> andre_pl: likely too late to fix now.  and this may be the right place, too
<andre_pl> ok, well here's another one. since last nights updates when i boot my computer, network manager shows not connected, but it is connected, and it works.
<andre_pl> if i disable/enable it sows the right status
<Nafallo> andre_pl: that's a feature from the last changelog :-)
<Nafallo> andre_pl: people are working on it.
<andre_pl> haha, a "feature"
<andre_pl> i wanted to go bug crazy today but launchpad is dead.
* Hobbsee attempts to perform cpr on launchpad
<Nafallo> there already are a couple of thousands bug reports against network-manager :-P
<Hobbsee> that many?  there were a couple of hundred, last time i looked...
<andre_pl> yeah i've got quite a few issues right now though, not just network manager.
<Hobbsee> andre_pl: are they release-critical?
<andre_pl> well... maybe? lol.  about half of the time I start my laptop it just hangs with a _ in the top left corner after the splash finishes.. then I alt-f1 and it says its failed to read some image file i have to press enter to get it start the boot process.
<Hobbsee> did you get the syslog?
<andre_pl> nope.  i probably can though, it happens often enough.
<Hobbsee> --> #ubuntu+1 anyway
<Hobbsee> seeing as this isnt a supoprt channel
<Hobbsee> yay, it's friday!
* Hobbsee kicks launchpad
<jsgotangco> Hobbsee: yay!
<Hobbsee> jsgotangco: we can now EOL most of https://launchpad.net/ubuntu/+bugs?field.searchtext=breezy&orderby=-importance&search=Search&field.status%3Alist=Unconfirmed&field.status%3Alist=Confirmed&field.status%3Alist=In+Progress&field.status%3Alist=Needs+Info&field.status%3Alist=Fix+Committed&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<Hobbsee> when LP gets better
<Nafallo> that's a small URL ;-)
<Hobbsee> indeed
<TomaszD> andre_pl, don't worry about LP being dead slow, do what I do. Take a magazine, click a link, read an article or two, look if the page loaded. Repeat.
<jsgotangco> my eyes! my eyes!
<Nafallo> TomaszD: haha
<Hobbsee> TomaszD: i used to routinely do it.  every page would take 40-50 seconds to load.
<andre_pl> TomaszD: its not even loading now.
<andre_pl> and i cant get any search results for anything.
<Hobbsee> TomaszD: and i got all of the bugs on the packages i was interested in, emailed to me
* Hobbsee kills the query, and goes to bed
<Hobbsee> night all!
<mvo_> Mithrandir: ok if I do a g-a-i upload so that the desktop data is updated? or should I wait with this
<Hobbsee> TomaszD: bugmail isnt bad, just selecting all the pages you want to load
<Hobbsee> then looking later
<TomaszD> Hobbsee, how about translating in Rosetta? :] 
<TomaszD> getting parts of the .po file in mail lol
<Hobbsee> TomaszD: never tried.  i only speak a bit of german, and english
* Hobbsee really should learn spanish...
<TomaszD> I know Polish, English, German and a bit of Spanish
<Hobbsee> neat :)
* Hobbsee got asked if she spoke greek today
<TomaszD> though it becomes apparent in a few moments that English isn't my native tongue
<TomaszD> :P
<Hobbsee> heh
<TomaszD> 13 years of learning and I still can't get the hang of some things
<TomaszD> and I'm teaching the bloody language too
<TomaszD> :] 
<Hobbsee> yeah well.  5+ years of learning german, and i still cant hold a conversation in it
<Hobbsee> haha
<Hobbsee> mind you, we learnt about things like saltmines, instead of useful conversation
<Hobbsee> TomaszD: your english seems fine so far, anyway :P
<Hobbsee> it's understandable
<TomaszD> well I hope so, I'm an upstream GNOME translator, I should know my thing
<TomaszD> :P
<TomaszD> and about German, it's the same here, four years gone to waste
<Hobbsee> hehe
<TomaszD> Was hasst tu gestern gemacht? Ich habe Computer gespielt und Bucher gelesen
<TomaszD> every single lesson she would ask us that
<Hobbsee> ah crud...i should know that....
<Keybuk> Apr 12 09:56:18 localhost NetworkManager: <information>^ICouldn't send DHCP 'up' message because: name 'com.redhat.dhcp.OperationInProgress', message 'interface eth0 is being released. Please try again later.'.
<Keybuk> hmm
<iwj> Woah!   `Retour   Revenir en arriere #-#-#-#-# fr.po (debian-installer) #-#-#-#-# Retour'
<Hobbsee> TomaszD: i have played on the computer and learned from the book...  dont know what the other one is
<Keybuk> and then ...
<Keybuk> Apr 12 09:56:25 localhost NetworkManager: <information>^IActivation (eth0) Stage 3 of 5 (IP Configure Start) started... 
<Keybuk> Apr 12 09:56:25 localhost avahi-autoipd(eth0)[11501] : Successfully claimed IP address 169.254.7.163
<Keybuk> Apr 12 09:56:25 localhost avahi-autoipd(eth0)[11501] : fopen() failed: Permission denied
<Keybuk> Apr 12 09:56:25 localhost NetworkManager: <information>^IDHCP daemon state is now 11 (unknown) for interface eth0 
<Keybuk> Apr 12 09:56:25 localhost NetworkManager: <information>^IDHCP daemon state is now 14 (normal exit) for interface eth0 
<Keybuk> Apr 12 09:56:27 localhost NetworkManager: <information>^IActivation (eth0) Beginning DHCP transaction. 
<Keybuk> Apr 12 09:56:27 localhost dhclient: There is already a pid file /var/run/dhclient.eth0.pid with pid 134993440#] 
<TomaszD> What have you been doing yesterday, that was the question
<Keybuk> kablooey
* Keybuk begins to blame pitti ;)
<Hobbsee> TomaszD: ahhh...of course.
<TomaszD> pitti is the root of all evil
* TomaszD hides
<cjwatson> iwj: oh damn silly French translators
<Keybuk> Treenaks: ping
<Hobbsee> Keybuk: blame the innocent who arent here, of course!
<iwj> cjwatson: Shall I file a bug ?
* jdong tries to blame blurry openoffice fonts on upstart :D
<cjwatson> iwj: hang on, phone
<iwj> cjwatson: OK.
<iwj> cjwatson: It seems really very ugly and if it's on the common path I might even call it RC (although I suppose it only affects French).
<iwj> cjwatson: I see this in the "confirm resize partitions" dialogue in ubiquity.
<cjwatson> iwj: sigh, I suppose so, though I can only work around it
<cjwatson> Mithrandir,mdz: ^--
<Keybuk> elmo: so yeah, somewhere along the line, you end up with a bogus pid for dhclient
<Keybuk> I have a vague suspicion it's related to that previous avahi-autoipd error, but I could be wrong
<mdz> cjwatson: I'm not sure I can tell the difference between an ugly text bug and standard French punctuation rules :-P
<Keybuk> (though that might be spurious, it's entirely possible it's a dhclient bug)
<iwj> cjwatson: Do you want a screenshot or is what I write in bug 105903 enough ?
<ubotu> Malone bug 105903 in debian-installer "crazy french translation for "retour" and "suivant"" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105903
<mdz> Mithrandir: what's the reason for this:
<mdz>         if (! applet->device_list)
<mdz>                 state = NM_STATE_DISCONNECTED;
<iwj> mdz: This one is obviously really crazy.  It looks like the computer has gone completely haywire.
<cjwatson> mdz: it's a totally fucked multi-line translation due to somebody stupidly unfuzzying a translation
<cjwatson> iwj: no need
<Keybuk> elmo: so, err, that's totally freaky
<Mirv> iwj: what is the English string and how is it translated in French (if re-translated into English)
<Mirv> oh wait, the bug, if it's there I read it from there
<iwj> cjwatson: I haven't seen this crazy string again so I think it must only show up in manual partitioning (or perhaps also auto-resize).
<Mirv> iwj: oh, ok, so someone having had a stupid fuzzy (I've seen those) with all the ## letters etc., and the translators as unfortunately marked is as "reviewed"
<iwj> This flashing /var/lib/os-prober/mount icon is a bit distracting really.
<iwj> Not just during migration-assistant (as I said in bug 105531) but during grub installation too.
<ubotu> Malone bug 105531 in migration-assistant "/var/lib/os-prober/mount briefly appears on desktop" [Undecided,Confirmed]  https://launchpad.net/bugs/105531
<evand> iwj: fix committed, but it's up to cjwatson if he wants it included in the release.
<dholbach> iwj: i'll take a break after this installation - will do test the oem d-i i386 dvd?
<iwj> dholbach: You mean will I test it ?
<dholbach> iwj: sorry, I forgot the "you" :)
<iwj> Sure but are there special instructions for oem installs ?
<iwj> It looks like my rsync got the dvd ok.
<fabbione> i have some spare vmware cycles to spare...
<fabbione> iwj: just select oem at the dvd boot IIRC
<iwj> OK, and nothing in particular else needed ?  NP
<dholbach> iwj: after that it gives you instructions on how to run oem-config-prepare (or whatever it is)
<fabbione> yeah it's pretty straight forward
<heno> fabbione: what arch?
<fabbione> heno: ?
<fabbione> heno: for vmware? i386
<heno> fabbione: i386, amd64, sparc, all of the above?
<heno> ah, ok
<fabbione> there is no sparc vmware :)
<fabbione> and amd64 support is experimental in ws 5.x
<heno> fabbione: can you test kubuntu alternate?
<fabbione> heno: i only have ubuntu images here.. if it's not urgent i can download and test it
<heno> virtualbox is open source (ish) you might get that to run on the sparc
<fabbione> nah... i am waiting for hw virtualization support on Niagara
<heno> fabbione: yep, ubuntu alternate i386 needs testing love too
<fabbione> ok
<fabbione> ubuntu alternate is
<heno> thanks!
<dholbach> iwj: gracias
<Mithrandir> mdz: avoid filling the .xsession-errors with a load of stuff about it not being able to find the proper icon.
<cjwatson> iwj: it'll be presented by a bunch of different dialogs - partitioning, migration-assistant, misc failures
<iwj> cjwatson: Oh dear.
<cjwatson> Mirv: I'm pretty sure I tried to fix this ages ago but Rosetta will only let me present it as a "suggestion" despite me being the maintainer and knowing that it's broken
<cjwatson> and translation syncs are typically too big for me to be able to notice all these problems every time
<Mirv> cjwatson: yeah, the launchpad requires you'd be member of the translation team in question also. anyway, translators should spot those broken suggestions and not mark them as reviewed, but of course it can happen
<cjwatson> there's a similar problem with Turkish
<cjwatson> no others
<Mirv> it depends also on how much "random" people there are in each translation team, as it's generally known that in the early times of Launchpad many translation teams accepted too many members even though Rosetta QA was (and is) lacking
<keescook> doko: can you look at bug 102786?  Someone ran into problems with the python-uno upgrade (it looks like the pycentral call in the prerm is failing?)
<ubotu> Malone bug 102786 in openoffice.org "python-uno fails during upgrade from 2.0.4-0ubuntu4 to 2.0.4-0ubuntu5" [Undecided,Confirmed]  https://launchpad.net/bugs/102786
<keescook> oh, you're already on it.  our comments to the bug crossed paths.  :P
* fabbione puts on the Igor's mask
<fabbione> crossing the fluxes is BAD....
<fabbione> bad is the life the way you know  it will stop instantly and each atom in your body will explode at light speed
* fabbione puts down the pipe
<keescook> okay, that's bad.  important safety tip
<lappy> hey ogra thanks for the acceptance to PyStart
<fabbione> keescook: i guess you have never seen Ghostbuster 1.. did you? :)
<ogra> thanks for doing it :)
<keescook> fabbione: you're being sarcastic, right?  "okay, that's bad.  important safety tip" was the next line.  :)
<fabbione> keescook: oh i didn't remember it in english.. i saw it in italian and doing a rought translation on the fly :)
<keescook> fabbione: hehe. cool.   "If someone asks you if you're a god ...."
<fabbione> ahha yeah i remember that
<keescook> "you say YES!"  :)  one of my favorites.  :)
<fabbione> ehhehe
* fabbione hugs keescook 
<iwj> `Text mode install for manufacturers' is oem, I take it.
<ogra> yeah, that was changed recently iirc
<ogra> iwj, are you currently in a fresh install ? i'm looking for someone who can test something for me with RC i'm not sure its my machine that wrong ...
<ogra> *that's
<lappy> ogra: what do you need tested?
<ogra> screensaver preview ... but be careful it crashes X for me over here if you click the "leave screensaver" button i'm not sure its my crappy ati card or its the screensaver 
<iwj> ogra: Both my test systems are currently installing.
<iwj> Ask me again in a bit :-).
<ogra> iwj, yeah, will do :)
<ogra> if thats happening for others its an RC ... i'm a bit worried ...
<superm1> currently firefox's update-notifier implementation copies over a file to /var/lib/update-notifier/user.d, but how does it signal to the running update-notifier process that it needs to show a popup?
<superm1> i seem to be missing it somewhere in the postinst or something
<superm1> is the update-notifier process perhaps supposed to be holding a inotify on /var/lib/update-notifier/user.d?
<cjwatson> Mithrandir,iwj: bug 105903 fixed in unapproved queue
<ubotu> Malone bug 105903 in ubiquity "crazy french translation for "retour" and "suivant"" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105903
<Mithrandir> cjwatson: yay, great.
<iwj> cjwatson: Great.
<superm1> asac, ping
<iwj> ogra: So what was that test you wanted someone to do ?
<iwj> I have a nice fresh `erase disk' ubiquity-created install here which isn't doing anything else right now.
<ogra> iwj, just start the screensaver preview and survive closing it 
<heno> ogra: I just tested it on a headless box I access via VNC. Just clicking the Preview button kills X there :(
<ogra> argh
<ogra> i was hoping that was only me
<heno> can I get you some logs?
<iwj> ogra: All seems to work just fine for me.
<ogra> i have it here so i can dig through it ...
<ogra> phew
<ogra> ok, two alternate reports ... for now i'll blame vnc ...
<ogra> heno, what kind of graphics card is that ? 
<ogra> i have an ati here ... 
<heno> I'm doing another install so I can test it on real hardware soon
<heno> ogra: nvidia
<ogra> hmm
<Treenaks> Keybuk: pong
<heno> but the vnc stuff is not very stable
<iwj> I have some very boring P4 onboard graphics here.
<ogra> i'll try it with fglrx soon ...
<heno> tested in in virtual box, no problems there
<ogra> strange ... but something isnt completely stable there it seems ...
<Keybuk> Treenaks: s'ok, pretty sure it's not avahi
<iwj> What exactly seems to me most likely to make it crash ?  Any particular screensaver ?  I've been in and out of the screensaver pref and the fullscreen mode, and selected different ones, and it works perfectly for me.
<iwj> s/to me/to make/
<heno> ogra: I can confirm the X crash on two physical machines
<Treenaks> Keybuk: ok :)
<ogra> iwj, i used the 3D-bubbles one (which is a 2d screensaver unlike the name indicates)
<ogra> but i dont think it matters ... 
<ScottK> Keybuk: I tested your new network-manager_0.6.4-6ubuntu7 packages with Kubuntu both wired and wireless with no issues (was not having problems before either).
<fabbione> Keybuk: the upstart ttyS0 transition from edgy to feisty is not fixed yet.. Release Note?
* ogra needs to finish some mail stuff before he can crash his X again :)
<heno> I got it on a Toshiba laptop and and amd64 /w nvidia
<fabbione> Keybuk:  a reboot in that condition can leave users without access to the machine for a while
<Keybuk> fabbione: it's on my list
<fabbione> Keybuk: ok
<iwj> ogra: Bubble3D I take it.  Yes, no problem.
<Keybuk> I don't quite understand why that doesn't work
<fabbione> Keybuk: do you want access on a machine to test?
<fabbione> Keybuk: i can set that up for you by tomorrow
<fabbione> Keybuk: or later this evening
<fabbione> you tell me..
<keescook> Keybuk: I'm still seeing snapshot races; they're just much more rare.  where should I record that? new bug or reopen old?
<Keybuk> new bug
<mdz> any other feedback on the new N-M?
<mdz> it needs regression testing as well as confirmation that it has fixed the main issue
<ogra> mdz, you have an ati card in your laptop, right ? 
<mdz> ogra: yes
<ogra> i fear i found an X crasher bug :(
<mdz> my X hasn't crashed in ages
<ogra> could you try to open the screensaver preview and close it again ? 
<ogra> (colse all important stuff before)
<mdz> it does corrupt the screen occasionally with the current driver
<ogra> it seems for me with an ati card/driver it crashes X ... heno saw it on an nvidia
<mdz> ogra: no problems
<ogra> heno, was that an nv or nvidia driver ? 
<ogra> mdz, phew, ok
<mdz> ogra: I close it by clicking 'leave fullscreen'; is that what you do?
<ogra> yes
<heno> ogra: it was nv
<mdz> ogra: and which screensaver do you run?
<ogra> thats what dropys me out of X
<ogra> mdz, Bubble3D
<mdz> I tried with blank, random and Bubble3D
<heno> a clean ubuntu install on an amd64 desktop
<ogra> or any other i guess, i have stuff open i need to finish before testing more
<mdz> probably specific to certain cards
<ogra> heno, aha
<ogra> i have an amd64 as well here
<mdz> in any case, not a release issue.  possible SRU if further analysis warrants it
<ogra> but i386 install
<ogra> yeah
<ogra> i was just cautious ... since i didnt see it before at all 
<heno> i got in on an amd64 install and an i386 install on an i386 laptop
<ogra> but if its not affecting all setups its ok for now
<heno> I got it on 2 out of 3 :)
<heno> plus the vnc one
<ogra> its surely not the most used functionality
<ogra> i.e. its no NM :)
<heno> true, but it can loose you data, which is bad
<heno> say you have a long OOo doc open and X bails out
<ogra> yeah
<ogra> i know what you mean 
* ogra switches to fglrx to test
<heno> solution might be to remove the preview button ...
<ogra> hmm
* heno -> food
<ogra> that will make me drown in regression bugs :)
* ogra reboots for fglrx
<keescook> Keybuk: done. see bug 105936, with example test scripts.
<ubotu> Malone bug 105936 in lvm2 "snapshot creation failure race "in use: not deactivating"" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105936
<ogra> so its the ati driver for me ... 
<ogra> fglrx works flawless
<tepsipakki> ogra: file a bug and attach the log :)
<iwj> This oem install is freaky.  I've never done this before.  Is there a document saying what I'm expecting ?
<iwj> Hello, anyone ?
<cjwatson> iwj: https://wiki.ubuntu.com/Testing/InstallMethods (fairly briefly)
<cjwatson> typically the manufacturer does everything up to 'sudo oem-config-prepare', and the end user gets the next bit
<iwj> Oh FFS!  I typed  `sudo oem-config prepare'  and it did a very weird thing.
<cjwatson> ha
<cjwatson> been meaning to add a .desktop for that
<harpreet> Colin: Harpreet here from GlassFish. Just wanted to know the status for the packages
<iwj> What does the `prepare' argument mean there ?
<cjwatson> 'sudo oem-config prepare' should crash with AttributeError
<cjwatson> iwj: frontend
<iwj> cjwatson: It didn't.
<iwj> It produced a gui and updated initramfs and then the gui vanished.
<iwj> Halfway through me fiddling with it.
<iwj> I'll report a bug.
<cjwatson> oh, yeah, ok, -f is a frontend - yes, it should reject that, 'prepare' is meaningless
<cjwatson> harpreet: I did some review earlier today and what I saw was fine (and accepted), but it's been a very busy day
<cjwatson> harpreet: I'm looking at sunwderby at the moment
<gnomefreak> there is no support for ppc in feisty right?
<ogra> community support :)
<harpreet> Colin: Ok - thanks. I will just wait up for an email from you then
<gnomefreak> :) but will it run it
<iwj> If I move something to the panel is it supposed to stick after the reboot ?
<gnomefreak> i havent seen ISO;s for ppc 
<cjwatson> harpreet: are you prepared to test the binary packages from our archive?
<ogra> oh, wow, compiz doesnt generate a white screen for me anymore ...
<ogra> not that it would work ... 
<cjwatson> gnomefreak: http://cdimage.ubuntu.com/ports/daily/current/ http://cdimage.ubuntu.com/ports/daily-live/current/
<cjwatson> and generally under /ports/
<gnomefreak> ty hmmm
<harpreet> Colin: That was my followup question. Where do we get the binary from your archive to test.
<cjwatson> harpreet: do you have an Ubuntu Feisty system up and running?
<harpreet> Colin: yes
<xan_> Hi, I asked this question in many ways: #ubuntu, #ubuntu+1, etc and no one answer me. Can you answer this tech question to me?
<xan_> I only want to know how to disable that checkfs.sh checks all the filesystems and achieve that it only checks /
<cjwatson> harpreet: System -> Administration -> Synaptic Package Manager, make sure multiverse is turned on in Settings -> Repositories, search for your package names and install them
<iwj> Anyway, it seems to have worked anyway and that strange rune didn't do any harm.
<iwj> So that's the dvd done apart from winfoss.
* iwj goes to have dinner.
<cjwatson> xan_: set the pass field in /etc/fstab to 0 for the filesystems you don't want to check; see 'man fstab'
<xan_> I have no field
<harpreet> Colin: Ok
<xan_> I can't show you the fstab because I have no internet connection in the other computer
<mjg59> xan_: This isn't a support channel
<xan_> but cjwatson I have no field (nop 0, nop 1, ...) in fstab
<cjwatson> xan_: please read the man page to which I referred you
<cjwatson> it has all the necessary information
<cjwatson> harpreet: the imq binary should be available within an hour
<cjwatson> harpreet: I just accepted the sunwderby source, but the binary will need manual approval later
<harpreet> Colin: Ok. I will need all of them to test this out.
<xan_> cjwatson: collin, please, I believe that all filesystems appeared or not in fstab are checked from /etc/init.d/checfs.sh
<xan_> is it correct?
<harpreet> Colin: What does that mean? I apologize I do not understand the entire process
<cjwatson> xan_: I have already given you your answer.
<cjwatson> xan_: your belief is incorrect (unless there is a serious bug)
<cjwatson> see the fsck man page
<desrt> johanbr; u
<desrt> erp.
<cjwatson> harpreet: progress :-)
<xan_> in feisty beta so?
<cjwatson> harpreet: the binary is what you need to actually install it from the package manager, but the source is the thing we really seriously review
<cjwatson> source gets automatically built into binaries on our build daemons
<cjwatson> the cron jobs that fire that off happen roughly hourly (there's lots of detail there but it isn't relevant)
<harpreet> Colin: Where are you located?
<cjwatson> harpreet: Cambridge, England
<harpreet> Colin: Cool.
<harpreet> Colin: So I wait up an hour for getting all the binary packages and test it out. Once we are okay - I let you know. 
<soho> found a bug, totem wont play mpgets-files in feisty. it opens the add-software dialog and suggests a gstreamer-plugin which i installed.
<cjwatson> harpreet: glassfish Depends: sunwderby (>= ${Source-Version}), imq (>= ${Source-Version}), sun-java5-jre, glassfish-bin (>= ${Source-Version})
<harpreet> Colin: Yes
<cjwatson> harpreet: I won't reject this upload for that, but ${Source-Version} is wrong there
<cjwatson> you may only use that for binaries from the same source package
<cjwatson> sunwderby, imq, and glassfish-bin are all from totally separate source packages and thus their version numbers are (theoretically) independent
<cjwatson> harpreet: as it is, any future upload of glassfish without also uploading the others will break
<cjwatson> I would suggest just writing normal version numbers in place of ${Source-Version} there
<Solarion> are all of you able to reach C3 and/or C4 processor powersaving states?
<Treenaks> I am
<harpreet> Colin: the future uploads of GF will also upload the others as we actually build it lock-step
<Solarion> Treenaks: do you have hci_usb?
<cjwatson> harpreet: likewise in glassfish-bin
<Solarion> something on my box is blocking C3
<cjwatson> harpreet: you mean that you intend to merge all of those into one source package?
<Treenaks> Solarion: what's that?
<Treenaks> Solarion: kernel module? yes.
<Solarion> yes
<harpreet> Colin: No not right away. What happens is we build this from one codebase and we have packaged them separately.
<Solarion> Treenaks: feisty?
<Treenaks> Solarion: yes
<cjwatson> harpreet: ok, in that case the Depends lines are definitely a bug and need to be corrected
* Solarion scratches his head
<cjwatson> if they're separate source packages, you really can't assume that other source packages will be the same versions
<pitti> ugh, back from mega install testing
<pitti> so, this expert install was kind of messy, but the rest went well
<cjwatson> harpreet: an hour> it will take a little longer for all of them to be available, I'm afraid
<cjwatson> harpreet: imq will be available within the hour
<Solarion> Treenaks: may I msg you?
<Treenaks> Solarion: I don't think I can help you fix your bug
<Solarion> I just want to know what things are keeping me from C3
<harpreet> Colin: but we do no need the sunwderby, glassfish-bin, imq for glassfish.
<micahcowan> What can you do with a coredump, if you lack the program that dumped it? (Assuming you're an expert developer/debugger)
<pitti> Keybuk: hm, did you ever try a raid-1 install in expert mode? I just did, and booting the result threw me at an initramfs prompt; I had to manually do 'mount /dev/md0 /root' to continue
<pitti> Keybuk: yesterday I did something similar with a different layout and it worked, so it's a rather special case, I figure (not RC critical)
<pitti> micahcowan: not much, I'm afraid
<micahcowan> pitti, surely there must be a way to get assembly dumps from the core program, at least? I mean, the code is in there, along with stack values, etc. ? What tools would you use to get that?
<pitti> micahcowan: but the code is not contained in the core dump
<pitti> micahcowan: it just has references to the executables and libraries
<harpreet> Colin: are you indicating that this needs to be fixed for this release.
<cjwatson> harpreet: no
<cjwatson> I'm just saying it's a bug
<cjwatson> harpreet: OK, I've accepted all the source packages now
<harpreet> Colin: whew ... I will file it :-)
<cjwatson> harpreet: I'm going out for the evening shortly (it's late here), but I'll accept the binaries when I get back
<harpreet> Great
<cjwatson> (assuming there are no obvious showstoppers there)
<fabbione> pitti: what bootloader did you chose?
<pitti> fabbione: grub, same as yesterday
<fabbione> pitti: what layout did you use?
<fabbione> raid-1 has been working forever...
<harpreet> Colin: So will you send an email that says this to me. Everyone here is on pin and needles and your email will calm things down
<harpreet> Colin: I mean after you accept it ofcourse :-)
<pitti> fabbione: /dev/hda5 and /dev/hda7 -> /dev/md0, with /dev/hda6 as /boot
<micahcowan> pitti, but isn't the executable code loaded into VM at the time the process is running? I had thought that the coredump included everything in that process's VM at the time of dump?
<fabbione> pitti: hmm interesting... did you grab the boot logs without splash/quiet?
<pitti> fabbione: no, I didn't, it wasn't a vmware install; I can do some photos of it, though
<fabbione> can you reproduce it reliably?
<fabbione> if so it would be worth to look at it
<cjwatson> harpreet: done
<fabbione> i am kind of curious if initramfs gets confused by /boot not being on raid1
<cjwatson> harpreet: oh, sure, I'll tell you when it's (about to be) available
<pitti> fabbione: reproduce in the sense of booting the broken installation again, yes
<harpreet> Colin: Thanks. I will check my email in an hour/two and test it out and send you a reply.
<pitti> fabbione: I wasn't sure whether the mdadm d-i module would get along without a separate /boot
<pitti> fabbione: on my production server I don't have a separate /boot, everything is on raid (but I use lilo there)
<cjwatson> harpreet: FWIW, cjwatson@ubuntu.com is a perfectly good e-mail address for me (and actually I prefer it), so I got both your mails ;-)
<pitti> fabbione: I already wondered whether md devices get proper uuids, but since it worked yesterday, I guess that's not it
<fabbione> pitti: mdadm get along with root/boot on raid
<fabbione> also in d-i
<harpreet> Colin: Okay. I have figured you folks at Canonical prefer irc over emails. :-). 
<fabbione> i used that setup for ages on sparc
<harpreet> Colin: Thanks for the email. Have a good evening ahead.
<fabbione> pitti: ok.. if you can get the data out it's worth looking at it.. it might be a corner case that's not so corner as we think
<cjwatson> harpreet: IRC can be faster although e-mail is better if you need reliability
<cjwatson> (IME)
<pitti> fabbione: I prefer it as well (separate /boot is a big ugly imho), but it should still work
<pitti> fabbione: no problem, let me boot again and do some shots
<fabbione> pitti: yeps
<harpreet> Colin: yep. So will test this stuff and let you know before I go.
<keescook> micahcowan: the core file only contains the program memory and various maps, not the executable itself.
<pitti> hi keescook 
<keescook> hiya pitti!
<micahcowan> Okay. Thanks keescook, pitti.
<keescook> pitti: related to core files, shouldn't I be able to generate coredumps of installed binaries that have prior crashes?  (ulimit -c unlimited; sleep 120 &; kill -SEGV %1)  I was only able to do this after copying sleep to the local directory, or after removing /var/crash/*sleep*
<keescook> ack
<Solarion> any recommendations for finding out what's preventing the processor from reaching C3?
<pitti> fabbione: http://people.ubuntu.com/~pitti/tmp/raid1-bootfail-1.jpg http://people.ubuntu.com/~pitti/tmp/raid1-bootfail-2.jpg
<fabbione> pitti: thanks
<pitti> fabbione: pretty messy, no fstab, some modprobe failure, I wasn't sure about the root cause
<imbrandon> Keybuk, got a sec?
<fabbione> pitti: no fstab?
<fabbione> looks like something went foo bar with the installation 
<fabbione> but totally
<pitti> fabbione: nope
<fabbione> probably you will never be able to reproduce that install
<pitti> fabbione: oh, I probably will, wasn't too complicated
<fabbione> ok
<pitti> fabbione: since the actual fstab is on /dev/md0, which wasn't mounted at that time, I assume that the initramfs has a copy?
<pitti> fabbione: I can access the initramfs from here
<fabbione> pitti: initramfs doesn't need fstab
<fabbione> it only needs to find root via root=/dev
<pitti> fabbione: why does it try to access it then?
<fabbione> pitti: it looks to me that initramfs things that root is mounted.. but the raid starts later
<fabbione> can you check what's in /proc/cmdline?
<pitti> fabbione: hmm, it started before IIRC
<fabbione> pitti: note on pic 2
<pitti> fabbione: I can reboot to find out, but should it differ from the options given in grub?
<fabbione> md: md0 stopper
<pitti> right
<pitti> but that's after the failure
<pitti> it was there before
<fabbione> it might differ.. you don't need to reboot
<pitti> fabbione: and on the initramfs prompt I can mount it
<fabbione> yes it's after the failure only on printk
<fabbione> do you have to wait 3 minutes to get there?
<fabbione> or it prompts quickly into the initramfs?
<pitti> fabbione: no, almost immediately
<pitti> fabbione: kernel boots, checks for resume image, and wham, there I am
<fabbione> pitti: then file a bug on initramfs.. it thinks that the raid is there but it's not
<fabbione> pitti: otherwise it would wait for the raid to be formed
<fabbione> i wonder if i can reproduce it in vmware
<pitti> fabbione: hm, indeed it says 'md0 stopped' before the error as well
<fabbione> but not tonight
<fabbione> i am way too tired
<pitti> fabbione: yesterday I did a vmware install and that went fine
<fabbione> pitti: i think you need to talk to iwj too.. i have the feeling that what happens is:
<pitti> fabbione: no worries; thanks for having a look
<fabbione> raid is started with one disk
<fabbione> initramfs finds the raid
<fabbione> at the same time mdadm stops the raid to add the second disk
<pitti> yay race conditions
<fabbione> initramfs tries to mount a device that's there but not working
<pitti> fabbione: I think I can find that out by watching the booting again
<fabbione> and bam
<fabbione> yes.. worth looking
<pitti> fabbione: I'm pretty sure that the raid was up before, but the 'md0 stopped' seems to support your theory
* pitti boots again, brb
<fabbione> once the raid is mounted you can't stop it.. but it might be a race
<pitti> fabbione: you are right
<pitti> fabbione: it boots, md doesn't find anything, so md fails and initramfs says 'waiting for root fs'
* fabbione hugs pitti and sends good night love to everybody
<pitti> fabbione: then it binds sda5, unbinds sda5, binds sda7 and then it's up
<pitti> but at that time I'm already at the prompt
<fabbione> pitti: you really want to talk to iwj about it
<pitti> right, will do; thanks
<pitti> fabbione: that would be a bug against what then?
<fabbione> i think both mdadm and initramfs can be blamed.. but make it RC
<fabbione> this is definetely a blocker
<fabbione> not being able to boot on raid is a problem for servers
<fabbione> pitti: file it against mdadm/initramfs.. affects also.. and make sure both Scott and Ian are aware of it
<pitti> alright
<fabbione> i need to get some rest
<fabbione> 6am -> 10pm is a bit too much
* fabbione -> photo on a pillow
<pitti> fabbione: bug 79204 sounds similar
<pitti> fabbione: good night!
<ubotu> Malone bug 79204 in initramfs-tools "boot on md raid drives fails" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79204
<kofler> What package gives me /lib/modules/`uname -r`/build/ and all the files therein?
<kofler> i.e. Makefile.
<kofler> I can't seem to find any package that does this and I have all these installed: 2.6.17-11-generic
<ogra> ogra@edubuntu:~$ ls -l  /lib/modules/2.6.20-14-generic/build
<ogra> lrwxrwxrwx 1 root root 40 2007-04-12 18:56 /lib/modules/2.6.20-14-generic/build -> /usr/src/linux-headers-2.6.20-14-generic
<kofler> Er, oops, I meant: http://phpfi.com/226155
<ogra> ogra@edubuntu:~$ dpkg -S /usr/src/linux-headers-2.6.20-14-generic
<ogra> linux-headers-2.6.20-14-generic: /usr/src/linux-headers-2.6.20-14-generic
<kofler> Hmm.
<kofler> Thanks ogra.
<pitti> yay, my guess about the hanging desktop was right
<pitti> cjwatson: still awake?
<avoine> there is a expert of gtk that know why the library libgtk-directfb was remove in feisty?
<seb128> pitti: what hanging desktop?
<pitti> seb128: I did an expert install and with that it took a minute for gnome to even begin loading
<seb128> avoine: likely because it was deprecated, we will make gtk+2.0 build it next cycle
<seb128> pitti: lo not correctly configured?
<pitti> seb128: now I tracked it down to a missing loopback iface
<seb128> right
<pitti> seb128: right
<seb128> it's the classic reason
<pitti> ooh, that bugs is already known and ages old, bug 9532
<ubotu> Malone bug 9532 in netcfg "skipping over netcfg means that lo doesn't get configured" [Medium,Confirmed]  https://launchpad.net/bugs/9532
<seb128> yeah, as said, that's the usual reason for gnome-session hanging
<seb128> that and clock set 1907 or something
<seb128> ah
* ogra thought pitti was talking about a nifty new usablitty feature ... desktop on strings
<seb128> known for netcfg as well
<pitti> seb128: right, I often get that clock problem on my laptop when I managed to drain the battery while it was suspended :)
<seb128> I should have a look at making gnome-session display a dialog or something when lo is not configured rather than hanging
<pitti> cjwatson: unping
<seb128> carlos: around?
<pitti> great, so the two breakages on my expert install are filed, and the rest went without a hitch
<avoine> thanks seb128 
<seb128> pitti: when are we going to roll language packs for feisty?
<pitti> seb128: right after RC
<seb128> and no update after that?
<pitti> seb128: today I fixed langpack-o-matic for software-properties, so tomorrow's dailies should be good
<pitti> seb128: well, the usual monthly updates in -proposed/-updates
<seb128> k, just to know until when we can get translation dones
<seb128> k
<seb128> not cool
<seb128> update-manager is still not translatable
<pitti> -able?
<seb128> pitti: no .pot built during build, I fixed it yesterday but rosetta still didn't import it
<seb128> so the "Static configuration" option is not translatable
<pitti> seb128: I think carlos has to manually approve new templates
<seb128> I chassed the missing french translations yesterday
<seb128> he did approve it this morning
<seb128> I'm wondering is rosetta is overloaded also or something
* pitti boots into BenC's new kernel crack, brb
<BenC> BTW, if anyone can test these kernels, I'd appreciate it. Release timeline depends on a good round of testing
<BenC> http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<Solarion> a-HA
<BenC> main thing is that your storage controller isn't regressed
<Solarion> r300 and uhci_hcd are the culprits
<BenC> e.g. you can get to all your static disks on IDE and libata driven controllers
<BenC> as well as CDROM
<Mirv> seb128: is the update-manager translation now in the general language packs instead of the kde packs, or is that a problem too, still?
<seb128> Mirv: update-manager was no to the kde pack
<dholbach> brb with new kernel
<carlos> seb128: the queue is burning
<seb128> carlos: like too many items there?
<seb128> carlos: how come it happens today?
<carlos> seb128: well, the problem we had yesterday delayed things a bit
<carlos> seb128: and it's finishing with evolution .po files
<Mirv> seb128: oh yes, it's the software-properties, and it's still in the kde pack. ok.
<carlos> which are big and we are slow to import them
<seb128> carlos: is there a public location with the queue order?
<carlos> seb128: did you upload a new evolution version? or it's just a small fix done in Ubuntu?
<carlos> seb128: https://translations.launchpad.net/translations/imports/+index?target=all&status=APPROVED&type=all&start=0&batch=75
<seb128> carlos: when? we did upload GNOME 2.18.1 monday and tuesday
<carlos> so that's a new evolution
<carlos> let me check it anyway
<carlos> if this is just a local update I can remove those entries from the queue
<carlos> so we speed it a bit
<seb128> carlos: is the queue going to catch up before tomorrow?
<carlos> once evolution finish, it should be quite fast
<Solarion> bug 105011
<ubotu> Malone bug 105011 in Ubuntu "Unable to reach C3 or C4 powersaving states when uhci_hcd is in kernel, or radeon driver (r300) is in use." [Undecided,Unconfirmed]  https://launchpad.net/bugs/105011
<carlos> but I'm not sure as we only have a couple of hours and each evolution .po file takes a lot of time..
<dholbach> BenC: both my i386s are happy with the new kernel - the amd64 is not - it hangs in busybox and says 'job control stopped' or something - is there anything i can do to debug it?
<seb128> BenC: new kernel works fine on my laptop (i386) do you want details on the config or something?
<carlos> seb128: those .po files were uploaded yesterday
<carlos> so I guess that was a local upload for an already existing version in Ubuntu, right?
<seb128> carlos: you can ignore the po, we need to .pot though because we distro added a string
<carlos> ok
<BenC> dholbach: Can you boot without quiet/splash and see if you get some kernel messages?
<dholbach> BenC: sure, hang on
<Solarion> is emacs 22 going to be in gibbon?
<tepsipakki> Solarion: it's released?
<heno> BenC: works fine on an i386 install here (amd64 hw) with a sata drive
<Solarion> tepsipakki: in the next few weeks
<BenC> heno, seb128: thanks
<tepsipakki> Solarion: sweet
<Solarion> I had thought the betas would be in universe
<carlos> seb128: everything removed except the .pot file
<carlos> that would speed a bit the imports
<seb128> carlos: cool, thank you
<Solarion> http://lwn.net/Articles/229825
<carlos> np
<Solarion> heya seb128 
<seb128> hi Solarion
<Solarion> at least I figured out where my C3 went, I guess.  :/
<dholbach> BenC: http://daniel.holba.ch/temp/PICT1777.JPG
<mjg59> dholbach: Need the page before that
<mjg59> dholbach: shift+pgup should work
<dholbach> mjg59: ok, hang on
<Arby> BenC: new kernel is fine here i386 with SATA drive
<dholbach> BenC: http://daniel.holba.ch/temp/PICT1781.JPG
<dholbach> mjg59: ^ too
<mjg59> dholbach: Hm. Looks like even earlier than that :)
<BenC> yeah, see if you can find some hpa resize stuff
<mjg59> The section where it probes the hard drive
<pitti> dholbach, mjg59: something like that for you as well? http://people.ubuntu.com/~pitti/tmp/14.23-boot-failure.jpg
<BenC> looks like we might have an ABI bump to get the hpa revalidation right :/
<mjg59> pitti: That's consistent with the most likely place for it to fail, yeah
<pitti> interesting 64 bit numbers there
<dholbach> ah yeah - it looks very much like what pitti has there
<mjg59> pitti: Uninitialised memory, at a guess
* dholbach makes another photo
<BenC> yeah, not sure how that huge number came back from the native size read
<pitti> BenC: on my second line there's another failed comparison which isn't that far off
<mjg59> BenC: Urp. Worryingly, take a look at the hpa_sectors line on Pitti's grab.
<BenC> mjg59: yeah, some odd numbers
<dholbach> http://daniel.holba.ch/temp/PICT1783.JPG
<pitti> BenC: do you need the geometries of my HDs?
<BenC> same numbers on dholbach's
<BenC> give me a minute to read this code again, see if anything is glaringly wrong with the logic
<BenC>         /* if no hpa, both should be equal */
<BenC> mjg59: that seems to be an incorrect assumption :)
<mjg59> The alternative is that there's a bug in the reading code
<pitti> 0xFFFFFFFFAFA19EB0
* dholbach is out for a quick walk - prod me if I can do anything to debug or help
<mjg59> pitti: What do you get if you mask off the top ones?
<BenC> mjg59: is the hpa capability check just to see if the drive supports HPA, or to see if the drive has an HP area?
<mjg59> Just checks the capability, I believe
<BenC> 2147483647
<mjg59> You'd need to check the ATA specs to be sure
<pitti> 2946604720
<mjg59> Yeah. Still not right.
<pitti> BenC: your number is for dholbach's?
<BenC> pitti: it's the hex you pasted minus 0xfffffff00000000
<BenC> err, 0xffffffff00000000
<pitti> BenC: hm, I calculated it twice and I get 2946604720, but anyway, it doesn't seem 'more' correct
<pitti> BenC: I raise you to 3000000000!
* BenC is all-in
<Nafallo> haha
<BenC> I think you've got me covered though
<pitti> I originally hope that converting it to hex would reveal a sensible string or so
<pitti> BenC: oh, 14.23 is already uploaded?
<BenC> pitti: Yes, but that's a minor point...Tollef wont get a chance to do d-i/cd stuff till the morning anyway
<BenC> pitti, dholbach: Can you test another kernel in about 30 minutes?
<dholbach> BenC: no problemo - just tell me what you need
<BenC> i386 or amd64?
<dholbach> amd64 is the broken one
<pitti> BenC: yes
<pitti> dholbach: amd64
<seb128> linux upgrade works correctly on my amd64 desktop using i386 distro as well
<BenC> odd that it seems amd64 specific
<heno> BenC: I have a stall on an amd64 as well now
<BenC> mjg59: do you think something is borked in ata_tf_to_lba48() or ata_tf_to_lba()?
<mjg59> Could well be
<mjg59> Symptoms are similar to when that was just returning gash
<BenC> we're using u64 everywhere, but those functions are twiddling bits
<heno> so, erm, guys how do I boot from grub with usplash off
<heno> ?
<mjg59> Remove splash from the command line
<Kmos> heno: sudo apt-get remove usplash
<Kmos> :)
<Nafallo> remove quiet
<Nafallo> from the kernel commandline
<heno> ah
<BenC> heno: 'e' to edit the entry, 'e' to edit the command line, edit it, return and 'b' to boot
* heno slaps head
<mjg59> Nafallo: No...
<Nafallo> no?
<mjg59> Though you'll want to do that as well
<heno> ok
<mjg59> Removing quiet doesn't imply a lack of splash
<Nafallo> ah, right. that changed some time ago :-P
<kylem> BenC, all the testing was done on amd64...
<kylem> by me, that is.
<BenC> I tested it on my amdt64 too
<BenC> but it may be that only lba or lba48 is broken
<BenC> hence, maybe we didn't hit the codepath
<BenC> pitti's is at least showing LBA48
<kylem> unlikely to be hitting the LBA codepath
<BenC> hmm, so am I
<BenC> pitti, dholbach: What's the actual size of your hd's?
<pitti> BenC: hda is 10 GB in total, hdc is 120 GB (imho, let me check again)
<kylem> LBA28 is (1 << 28) sectors * 512 bytes/sector
<kylem> hmm, so conceivable your hda might be lba28.
<pitti> BenC: sorry, hdc (mapped to sdb) is 160 GB
<pitti> BenC: and hda (sda) is 13 GB
<BenC> it's the larger one that shows the 0xffffffff00000000 craziness
<pitti> [   28.005896]  ata1.00: 25408559 sectors, multi 16: LBA 
<pitti> [   28.357830]  ata2.00: 312581808 sectors, multi 16: LBA48 
<pitti> ^ with 14.22 kernel
<pitti> [   28.404219]  SCSI device sda: 25408559 512-byte hdwr sectors (13009 MB)
<pitti> [   28.547102]  SCSI device sdb: 312581808 512-byte hdwr sectors (160042 MB)
<BenC> -14.23 is showing a native size of 25410672 for the 13G drive
<pitti> BenC: right, and 25408559 is on the left-hand side, that's what .22 reports
<kylem> BenC, uh. where's that patch again?
<BenC> kylem: it's in git
<BenC> the hpa on the second one is showing smaller for ata_hpa_resize, for the ata_same_device() it's showing some whacked crap
<pitti> BenC: (left-hand side of the comparison in 14.23, I mean)
<BenC> if it's smaller, that's fine, it gets ignored
<BenC> guess the question is why are we showing some whacked number in ata_same_device() compared to the previous native read in ata_hpa_resize()
<bf> after following instructions in Bug #52685, I know have none of hte duplicate files installed in /etc/Xsession.d, despite that fact that dpkg -L x11-common suggests otherwise.  Anyone have any ideas on why apt/dpkg claims to have installed the files yet they are not on disk?
<ubotu> Malone bug 52685 in xorg "x11-common installs dup files" [Undecided,Fix released]  https://launchpad.net/bugs/52685
<bf> s/know/now
<kylem> BenC, i think the disk isn't set up the same when we call ata_same_device the second time...
<kylem> probably why we were saving the n_sectors_boot...
<BenC> ata_hpa_resize is called, then it does some device checks (LBA, ID's, etc), then it does ata_same_device()
<pitti> "REBUILDING: 20070412 are REJECTED" -> ah, waiting for the new kernel? or any other problems?
<BenC> not sure what could be disabled in between there
<BenC> not sure why it is even recovering devices during this process anyway
<BenC> pitti: new n-m too I think
<pitti> ah, right
* pitti tests this in the meantime
<dholbach> BenC: [   21.666336]  SCSI device sda: 781422768 512-byte hdwr sectors (400088 MB)
<BenC> pitti, dholbach: Give me a little bit to rebuild a new kernel
<dholbach> BenC: np
<pitti> just a little warning, if I drop off the network, n-m screwed me
<Nafallo> pitti: :-)
<mvo> I guess I'm a bit tired already, but why is 20070412 rejected as image?
<pitti> mvo: new kernel + network manager, I assume
<mvo> thanks
<mdz> mvo: see Colin's post to -devel-announce
<pitti> ok, booting again for testing Keybuk's new n-m, brgb
<pitti> brb, even
<mvo> mdz: thanks, my impression was that this mail was about 20070411
* mvo downloads NM instead
<bf> any help with my apt/deb x11-common question? Why might the package skip installed conf files?
<tepsipakki> bf: maybe just because of that.. conffiles are not removed on upgrade
<tepsipakki> it should be done by the package scripts
<tepsipakki> bf: I'll reopen the bug
<bf> tepsipakki: is there a good way to force it to?  Might not help the bug, but I'd like to have a usable X.
<tepsipakki> bf: oh, so you removed all of them :)
<bf> well, that was the suggestion approach...
<bf> err.  suggested
<tepsipakki> no, it was suggested to remove the *xorg-common* files
<tepsipakki> not *x11-common*
<bf> "remove (sudo rm) all duplicate files (from both x11-common and xinit packages)"
<bf> Did i misinterprete that?
<tepsipakki> maybe,
<tepsipakki> or maybe not
<mdz> mvo: well, the issues apply to both unfortunately
<mdz> bf: dpkg --force-confmiss
<tepsipakki> right
* heno makes the word 'REJECTED' link to -devel-announce
<bf> mdz: whee
<bf> mdz:  that seems to have worked.  thanks.  i suppose I should update the bug report?
<tepsipakki> bf: well, I updated it already
<BenC> pitti, dholbach: Ok, built and uploading...should be 5 minutes
<dholbach> rock on
<pitti> yay
<j1mc> i've been away today . . .  will an additional RC candidate image be released tomorrow? 
<dholbach> BenC: same place? finished uploading?
<BenC> almost done
* j1mc needs to know for xubuntu testing ^^  thanks.  :)
<pitti> BenC: can you give me the md5sum, just to be sure? my ISP's transparent proxy is sometimes funny
<BenC> 9008b8fe14597a713fd0b8778b3638a8  linux-image-2.6.20-14-generic_2.6.20-14.23_amd64.deb
<BenC> same location
<pitti> uploaded?
<tepsipakki> BenC: .23 worked for me
<dholbach> pitti: looks like
<dholbach> I have the same md5sum
<tepsipakki> the previous one
* dholbach installs and reboots
<BenC> tepsipakki: thanks
<pitti> yep, md5sum matches
* pitti dpkg -i's and crosses fingers
* BenC does too
<pitti> BenC: is there any way to disable pata at the kernel command line?
<pitti> booting live CD and dpkg -i'ing older kernel in a chroot is a bit painful
<BenC> pitti: you mean pata in general, or disable libata-pata in favor of ide?
<BenC> oh, no, you are just at my mercy for this testing phase :)
<pitti> hm, I don't know; having normal IDE drives back would do it, I guess
<dholbach> BenC: looks GOOD!
<BenC> yay!
<dholbach> you ROCK!
<BenC> no, I just reverted the patch back to kyle's original
<BenC> I such because I broke it :)
<BenC> suck
#ubuntu-devel 2007-04-13
<pitti> rebooting, brb -- hopefully ;)
<bf> thanks all
<mdz> BenC: is there a problem with the candidate kernel?
<mdz> I was just about to test it
<BenC> mdz: There's an issue showing up on some systems where the revalidation of the drive shows bogus native size
<BenC> mdz: caused by my change to keep from bumping the ABI...reverting back to the original patch from kyle fixes it
<BenC> mdz: but it means an ABI bump
<BenC> mdz: I'm assuming we have no choice, so I'll just get this uploaded and punt lrm/linux-meta/backports right behind it
<BenC> pitti: good?
* pitti waves from a working 14.23 kernel
<BenC> sweet
<dholbach> yoohoo
<BenC> pitti, dholbach: thanks for testing
<dholbach> np at all
<dholbach> keybuk's network-manager change works nicely for me too
<pitti> BenC: looks a bit weird in dmesg, but seems to work
<pitti> BenC: 
<pitti> [   35.107711]  ata1.00: ata_hpa_resize 1: sectors = 25408559, hpa_sectors = 25410672
<pitti> ^ small disk, looks reasonable
<pitti> [   35.475432]  ata2.00: ata_hpa_resize 1: sectors = 312581808, hpa_sectors = -1348362576
<BenC> I want to keep the debug messages just in case of issues, but I think we are stable with this now
<pitti> ^ large disk, looks like a signedness issue?
<BenC> ooh, I can fix that printk
<BenC> looks like a lld instead of an llu
<pitti> oh, if it's just a %i vs. %u in the printk, then it's no problem
<mdz> BenC: sigh
<kylem> it's a u64, the bit 63 should not be set.
<mdz> dholbach: what's your network setup?
<kylem> pitti, hda is 12GB?
<pitti> yay, n-m is good for me as well; /me replies to u-devel@
<pitti> kylem: yes
<dholbach> mdz: one network interface using dhcp via cable - it had the "broken network icon" before
<Kmos> n-m works fine here too
<kylem> pitti, ok, output looks slightly suspicious. i suspect the lba28 codepath is less well tested.
* dholbach builds it for the laptop too
<stgraber> n-m is now working for me too (ethernet/wireless)
<kylem> pitti, i'll doublecheck it.
<pitti> kylem: want the full dmesg?
<kylem> pitti, please.
<pitti> kylem: http://people.ubuntu.com/~pitti/tmp/dmesg.txt
<kylem> pitti, thanks. brb. gotta grab food.
* mvo downloads new kernel
* pitti tests CD-ROM
<pitti> kylem, BenC: cd's fine as well
<pitti> ok, that means bedtime, I think
<ajmitch> night pitti 
* mvo reboots to test new packages
<mdz> BenC: do you have a new i386 kernel for testing?
<mvo> nm looks good for me
<heno> BenC: new kernel works on two amd64 systems here, including the one that broke earlier
<BenC> heno: thanks
<BenC> mdz: No, the one there seems to be working for everyone though
<dholbach> n-m works ok on the laptop (wifi and cable) too
<BenC> kylem: why are we using u64 for libata sectors when ide uses unsigned long long?
<dholbach> night guys - see you tomorrow, I'm happy with the new kernel and the new network-manager
<somerville32> :D
<mvo> BenC: new kernel boots/works fine for me so far (amd64)
<BenC> mvo: thanks
<mvo> good night, see you tomorrow. new kernel + NM are good for me as well
<seb128> n-m update works fine on my desktop (using a static config on wired eth) and on my laptop (using the wireless connection)
<BenC> anyone experienced the amd64 problem with my first kernel?
<BenC> infinity2: ping?
<mheily> Greetings.. I was just in #ubuntu-bugs and they told me to come here to discuss escalating the resolution of bug # 104332 for either feisty or feisty-updates.  There is a grave problem with the rdesktop package that causes segfaults when connecting to Windows 2000 servers in 8bpp mode or to some Windows 2003 servers.  I prepared a simple one-line patch that fixes the problem and has been committed into the upstream CVS.  If anyone would b
<jk-> hi
<jk-> anyone here with ps3 mojo ?
<cjwatson> jk-: a bit
<jk-> ah, hi cjwatson.
<jk-> was wondering if I could sort out some integration with the ps3 iso and petitboot.
<cjwatson> oh, petitboot will probably be post-feisty for s
<cjwatson> us
<cjwatson> anything specific/easy you're looking for? :)
<mheily> brb
<jk-> ah, i'm just wondering if we can include some icon directives in the kboot.conf
<jk-> actually, the kboot.conf isn't really suitable for extending in that way
<jk-> but petitboot supports other bootloader configi files.
<jk-> -i
<cjwatson> jk-: are older kboots liable to ignore that?
<jk-> cjwatson: no, so i'd suggest using a different config file format (eg yaboot.conf, or petitboot.conf)
<jk-> I believe kboot will happily ignore those :)
<cjwatson> ok, that we won't be changing for feisty
<jk-> ok, no probs :)
<cjwatson> but you can certainly let me know in a week and I'll change it for gutsy :-)
<jk-> so for post-feisty, you'd look at putting both config files on the one iso?
<cjwatson> sure
<jk-> neat.
<cjwatson> changing to just yaboot.conf would actually be pretty good, save us effort
<cjwatson> Ben had mentioned petitboot to me already, though I haven't checked it out in any detail
<cjwatson> jk-: good idea to have it parse existing configuration files. Out of interest, can it do grub2?
<jk-> yeah, I take it you folks have more important things on your plate at the moment :)
<jk-> not at the moment, but we can add a grub2 parser...
<mheily> The essence of the rdesktop bug is that the program passes an invalid parameter to Xlib when creating an image under certain circumstances.  Previous versions of Xlib would ignore the invalid parameter and just "do the right thing".  The new version of Xlib rejects the entire operation and returns a NULL pointer, which rdesktop fails to check, thus causing a segfault. My patch merely changes the parameter to 0, which means "do the right t
<cjwatson> not critical at the moment, just 'cos switching to grub2 has been one of the things on our theoretical plate for a while
<jk-> the only problem is that the existing formats don't have any facility for specifying icons for boot options
<jk-> (AFAIK)
<cjwatson> pretty sure at least yaboot.conf should ignore unknown keys
<jk-> we can add icon=blah.png directive for yaboot.conf, as they'll be ignored
<jk-> snap
<cjwatson> actually I'd thought that kboot basically shoved keys into the environment
<cjwatson> but I haven't really looked at its config file parsing in any detail
<jk-> yeah, the format is basically label="stuff"
<kylem> BenC, can you name a platform where unsigned long long isn't u63?
<kylem> er, u64
<BenC> kylem: I know it is, but usually on 64-bit platforms that use "unsigned long" for u64...just wondering why one subsystem went one way and the other used the explicit unsigned long long
<kylem> well, it's a 64bit quantity and i'm pedantic, i guess...
<BenC> the rest of libata uses u64, so it makes sense to keep it consistent...I was just being curious :)
<kylem> yeah.
<BenC> I've narrowed down the problem a bit
<_ion> I want a computer where unsigned long long is u63.
<mheily> my PDP/8 has a 63-bit unsigned long long..
<BenC> the first call to ata_exec_internal() to get the native size returns ok, but subsequent calls leave values in tf.hob_lba[lmh]  that match the tf.lba[lmh]  ones
<kylem> sounds like LBA48 is disabled somehow.
<kylem> hmm, no. hrm.
<BenC>         printk("%02x %02x %02x %02x %02x %02x: %016llx \n",
<BenC>                tf->hob_lbah, tf->hob_lbam, tf->hob_lbal,
<BenC>                tf->lbah, tf->lbam, tf->lbal, sectors);
<BenC> that printk in ata_tf_to_lba48() produces this...
<jdong> _ion: I have a 16-bit chip that randomly "forgets" to account the 16th bit in operations.... maybe if you do 4 operations in a row 25% of the times you end up with 63-bit :)
<BenC> [   67.980468]  00 00 00 f9 4b af: 0000000000f94baf 
<_ion> jdong: That sounds like fun. :-)
<BenC> the second call shows this:
<jk-> you guys need a System-i machine, with 65-bit addressing :D
<BenC> [   67.992430]  f9 4b af f9 4b af: ffffffffaff94baf 
<jdong> _ion: oh, it's lovely :)
<BenC> I think the second call happens after revalidation
<jdong> _ion: I swear they developed that controller to mess with our minds :D
<BenC> then it thinks that it has a hpa area to account for, and extends it to some ungodly amount
<kylem> yeah.
<BenC> so things continue to work, but the device appears overly large
<_ion> jdong: Was one of the platform's developers perhaps behind INTERCAL, too? :-)
<jdong> _ion: Microchip Inc... go torch their building :D
<kylem> damn, no _Anarchy_ on irc.
<BenC> not sure why the last 8 bits are getting 0xff aswell, that bothers me too
<kylem> oh.
<ajmitch> BenC: the last set of kernels you're pushing through provides kvm-api-9?
<BenC> ajmitch: yes
<xtknight> Version: 2.6.20-14.23 ?
<ajmitch> great
<xtknight> that one didnt fix kvm for me though i haven't rebooted.  
<BenC> it wont fix kvm, because it doesn't have the kvm-18 drivers
<BenC> that will come a few days after release
* Hobbsee waves
<jk-> hi Hobbsee.
<Hobbsee> hi jk- :)
<Hobbsee> hm.  i'm presuming the kernel that needs testing is the one coming thru the updates now
<fabbione> morning
<Mithrandir> doko: python-defaults is depwait; can you please get that fixed ASAP?
<Mithrandir> (probably just loosen the build-deps a little bit)
<doko> Mithrandir: uploaded
<Mithrandir> cheers
<ajmitch> hi doko
<ajmitch> & Mithrandir 
<Mithrandir> hiya Andrew
<fabbione> Mithrandir: #79204 looks pretty serious to me
<fabbione> pitti was able to hit it yesterday again
<Mithrandir> fabbione: thanks, and ARGH.
<fabbione> Mithrandir: no more bugs reported from hw-cert since yesterday. so we are with those 2 on n-m and 1 on kernel (not RC at all)
<fabbione> Mithrandir: the 2 from NM should be fixed by Keybuk update
<fabbione> but i can't confirm it
<Mithrandir> he has so far failed to actually upload a package to the archive
<ajmitch> there seem to be a few reports of unbootable machines with 14.23 on the users list
<Mithrandir> doko: you uploaded a new version of screem to get it rebuilt a while ago, it seems this version ftfbfs.  Could you take a look at it, please?
<doko> Mithrandir: ugh, that was just a rebuild try
<doko> no-change upload
<Mithrandir> doko: yes, I saw, but it still broke, so I wondered if you have any idea about it and could take a look at it.
<doko> Mithrandir: doing today
<Mithrandir> thanks.
<dholbach> good morning
<_ion> Hi
<mdke_> morning dholbach 
<dholbach> hey _ion, hey mdke_
<dholbach> hum - does anybody know if a new kernel upload is in the works?
<dholbach> I'm sure that whatever BenC fixed in the amd64 version on http://people.ubuntu.com/~bcollins/kernels/feisty-release/ would make things better
<dholbach> at least the kernel boots for me (in contrast to the one in the archive)
<_ion> 2007-04-13 05:45:14 status installed linux-image-2.6.20-14-generic 2.6.20-14.23
<_ion> There was a kernel update this morning.
<dholbach> _ion: that's the broken one
<_ion> Heh, ok
<dholbach> _ion: BenC fixed something in the amd64 variant on people.u.c but didn't bump the version number
<dholbach> and according to the post on ubuntu-devel-discuss@ it seems to screw up some other people's boxes too
<Mithrandir> dholbach: uh, it's supposed to be the same kernel.
<Mithrandir> apart from one built on BenC's machines, one on the buildds.
<fabbione> Mithrandir: time to wake up Ben?
<fabbione> i am sure he will love a phone call at 3 am :)
<dholbach> Mithrandir: what do you mean?
<Mithrandir> dholbach: 14.23 and the one on BenC's page should be the same
<dholbach> not the amd64 one
<dholbach> hang on
<dholbach> Apr 12 23:45:29 BenC    pitti, dholbach: Give me a little bit to rebuild a new kernel
<Mithrandir> where was that?  Here?
<dholbach> Apr 13 00:01:35 BenC    pitti, dholbach: Ok, built and uploading...should be 5 minutes
<dholbach> yes
<dholbach> Apr 13 00:08:16 BenC    9008b8fe14597a713fd0b8778b3638a8  linux-image-2.6.20-14-generic_2.6.20-14.23_amd64.deb
<dholbach> Apr 13 00:08:18 BenC    same location
<Mithrandir> I should stop sleeping so I can watch IRC more closely.
<Treenaks> Argh, what's killing the panel on upgrades?
<dholbach> Apr 13 00:14:34 BenC    mdz: There's an issue showing up on some systems where the revalidation of the drive shows bogus native size
<dholbach> Apr 13 00:14:54 BenC    mdz: caused by my change to keep from bumping the ABI...reverting back to the original patch from kyle fixes it
<dholbach> Apr 13 00:15:00 BenC    mdz: but it means an ABI bump
<dholbach> Apr 13 00:16:12 BenC    mdz: I'm assuming we have no choice, so I'll just get this uploaded and punt lrm/linux-meta/backports right behind it
<dholbach> bug 106110 was just filed and see one of the last posts on ubuntu-devel-discuss@
<ubotu> Malone bug 106110 in linux-meta "Kernel 2.6.20-14-generic faild to boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106110
<Mithrandir> yes
<Mithrandir> it's not in unapproved, however.
<pitti> Hello everyone
<_ion> Bono estente.
<dholbach> heya pitti
* pitti hugs dholbach
<pitti> dholbach: oh, you're already up; bah, sleep is so overrated... :)
<Mithrandir> sleep, schmeep.
<dholbach> pitti: i was already running this morning
<pitti> Mithrandir: so, kernel and nm ==  now?
<Mithrandir> no
<Mithrandir> nm isn't uploaded, kernel is busticated on AMD64, it seems.
<dholbach> pitti: the kernel in the archive does not have BenC's quickfix (it'll mean bumping the ABI)
<pitti> Mithrandir: *sniff*
<Mithrandir> pitti: indeed.
<pitti> Mithrandir: oh, still busticated? BenC's late night version was quite well
<pitti> I see
<Mithrandir> pitti: iz not in ze archive.
<dholbach> Mithrandir: according to the post on ubuntu-devel-discuss@ it screws i386 too (IBM X32) - we were only able to reproduce the problem on amd64 yesterday 
<Mithrandir> nor in any queue
<Mithrandir> and we still have problems on any machines with smart batteries.
* pitti wonders about the flood of Gnome updates on -changes and then realizes that they have been sent 3 days ago. yay ML delay
<mdke_> :)
<desrt> bad news ubuntu dudes
<desrt> -14 broke sata on macbooks again
<Mithrandir> desrt: known.
<mdz_> morning
<Mithrandir> hi mdz.
<desrt> Mithrandir; got a #?
<dholbach> desrt: bug 106110 is one of them - i guess there are dupes
<ubotu> Malone bug 106110 in linux-meta "Kernel 2.6.20-14-generic faild to boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106110
<desrt> buh
<desrt> the fact that the "search" field, when viewing bug reports, searches on "projects" is very interesting
<desrt> dh; https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106063
<ubotu> Malone bug 106063 in linux-source-2.6.20 "Computer will not boot after 2.6.20-14.24 kernel upgrade" [Undecided,Confirmed]  
<pitti> hey mdz_ 
<pygi> hi golks
<siretart> hi pygi 
<pitti> moin pygi
<TheMuso> c
<TheMuso> gah
<_ion> Hi pygi
<pygi> morning _ion, siretart and pitti 
<pygi> s/golks/folks
* pygi blames the sleep (or lack of it?) pattern for that
<_ion> Cool, apparently xfdesktop4 4.4.0-0ubuntu3 didn't FTBFS anymore. :-)
<bluefox> anyone know what facility the LiveCD uses to configure X, and how I can invoke it
<desrt> dholbach; i think there are a few unrelated -14 problems...
<dholbach> desrt: aha?
* bluefox just changed graphics cards.  It DESTROYED his installation i.e. he can't make X work, it's working but no cursor, etc.  dpkg-reconfigure asks a billion questions he doesn't feel like answering.
<desrt> my problem is very much sata related... but this person doesn't even have sata...
<bluefox> as soon as I get X back I'm filing a bug >/
<dholbach> desrt: I hope the kernel team will awake soon and shed more light on this
<desrt> i hope :)
<desrt> this is some pretty serious business for release candidate time :)
<desrt> pitti; i'm looking at a kernel with a whole whack of piix/ata fixes in it... are those the ones you refer to?
<pitti> desrt: http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<pitti> desrt: those are the fixed ones I tested last night, and they unbreak booting for me
<desrt> ya.  that's the one on the mirrors
<pitti> desrt: no, they are not
<pitti> desrt: it's an updated 14.24
<pitti> erm, 14.23
<desrt> so it's like 14.23.1....
<pitti> right
* desrt takes it for a spin
<dholbach> pitti: only the amd64 one does I guess
<pitti> desrt: oh, right, the i386 is the old one
<desrt> buh :p
<desrt> in that case i will simply go to bed and wake up tomorrow when this is all worked out already :)
<desrt> cheerio, gents.
<pitti> desrt: sleep well!
<cjwatson> Mithrandir: Ben was still trying to figure out what the hell was wrong, last I heard
<cjwatson> Mithrandir: it seemed to be spurious 64-bit-specific breakage - 0xffffffff00000000 being or-ed into the HPA max size for no good reason
<cjwatson> or something along those lines
<bluefoxicy> finally fucking fixed.  I think.
<shawarma> Do we have any Python code anywhere that parses /etc/network/interfaces ?
<shawarma> update-manager never touches it, does it?
<dholbach> system-tools-backends parses it
<dholbach> but that's perl
<shawarma> Oh, please don't make me read perl. :-)
<dholbach> kde-guidance is python, but it does not seem to touch etc/network/interfaces
<shawarma> dholbach: Come to think of it... I may not need this at all.
<shawarma> dholbach: No, I can totally work around it.
<shawarma> dholbach: Never mind. Thanks for your suggestions, though.
<dholbach> np
* gnomefreak thanks keybuk for network-manager fix even though hes not here :)
<Tonio_> hi
<bluefoxicy> gnomefreak:  when you see keybuk tell him I need network-manager to actually log into wireless networks during boot ;)
<Mithrandir> iwj: have you had a chance to look at https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/79204 ?
<ubotu> Malone bug 79204 in initramfs-tools "boot on md raid drives fails" [Critical,Confirmed]  
<sladen> joy
<stgraber> bluefoxicy: It's impossible, the wireless networks and password are stored in the user's gconf DB
<torkel> bluefoxicy: should hopefully be fixed in n-m 0.7 (whenever that will be released...)
* gnomefreak doubts ill see keybuk today i have a long day ahead
<tepsipakki> bluefoxicy: to reconfigure X you run "sudo dpkg-reconfigure -phigh xserver-xorg" as suggested in xorg.conf
<pitti> iwj: wrt. #79204, I still have the broken installation here; I'm happy to help debugging
<jsgotangco> hey sabdfl
<highvoltage> morning sabdfl. I'm very excited about the super-free Ubuntu edition :)
* jsgotangco too
<ajmitch> evening
<jsgotangco> heya ajmitch
<Mithrandir> seb128: https://bugs.launchpad.net/ubuntu/+source/gnome-cups-manager/+bug/91218 seems fixed for me now.
<ubotu> Malone bug 91218 in gnome-cups-manager "MASTER: [apport]  gnome-cups-manager crashed with SIGSEGV in g_signal_emit_valist()" [High,Confirmed]  
<Mithrandir> I used to be able to reproduce it, I no longer can.
<seb128> Mithrandir: ok, good, let's drop the milestone then
<seb128> doing the change
<Mithrandir> mark it as fix released?
<seb128> well, we build it with -O0 as a workaround
<seb128> it's not really fixed
<seb128> I'll lower the severity and drop the milestone
<dholbach> seb128: works for me too
<seb128> dholbach: thank you
<dholbach> seb128: hi btw :)
<seb128> hey ;)
<Mithrandir> seb128: fine
<seb128> dholbach: why do you drop milestone of closed bugs?
<dholbach> seb128: because it was a dup of another bug that was fix released
<pitti> seb128: I seldomly had gnome-cups-manager crashes, I'll play around with it a big
<dholbach> seb128: i can milestone the master bug, if you like
<pitti> seb128: s/big/bit/
<seb128> dholbach: no, but I thought we didn't care about dup, they were like closed
<seb128> pitti: thank you
<dholbach> seb128: it was on the milestone list anyway
<seb128> looks like a launchpad bug
<seb128> that's another good reason to reject dups :p
<Mithrandir> seb128: yes, please do reject dups.  Malones handling of duplicates and milestones is less than optimal.
<pitti> I usually un-milestone them
<pitti> rejecting dups looks bad to the submitter
<pitti> as if we reject their bug
<seb128> I do it on purpose
<Spads> pitti++
<seb128> to discourage them to open dups
<seb128> like, look before opening a bug
<Spads> it's not always obvious when a bug is a duplicate, and often two bugs reporting entirely different things will be merged
<cjwatson> pitti: have you seen bug 96244?
<ubotu> Malone bug 96244 in tzdata "Mongolia is not DST anymore" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96244
<pitti> cjwatson: no, didn't see it yet; will take a look later after raid debugging
<cjwatson> thanks
<Riddell> Mithrandir: I've milestoned bug 104794, it's a significant problem with a one line fix
<ubotu> Malone bug 104794 in kde-guidance "guidance-power-manager shows dischanging if battery full" [Undecided,Fix committed]  https://launchpad.net/bugs/104794
<Mithrandir> Riddell: then why is it undecided priority and not at least high, if not critical?
<Riddell> Mithrandir: fixed
<ogra> Keybuk, did i mention yesterday that everything is fine with ltsp and your NM packages ?
<seb128> Mithrandir: did you figure what happened to the vte binaries?
<Mithrandir> seb128: I half-reprocessed them, cjwatson did the other half
<Mithrandir> LP ate them for a moment, then chewed and spat them back out again.
<seb128> hum
<seb128> when did you do that?
<cjwatson> should have gone through in the last publisher run
<seb128> ah, right, I've them now
<seb128> cjwatson, Mithrandir: thanks
<Tonio_> Mithrandir: hi ;)
<Tonio_> Mithrandir: I'm just uploading digikam to edgy-updates, to close my long time pending SRU
<Tonio_> Mithrandir: whatever I do the upload is rejected for SHA1 sum of uploaded file does not match extant file in archive
<Tonio_> Mithrandir: I didn't touch at the tarball at all, and also tried just to upload the dsc and diff (debuild -S, no -sa)
<Tonio_> Mithrandir: rejected whatever I do, so I must say I don't understand
<Mithrandir> Tonio_: can you please talk to another archive admin? I'm a bit busy with other stuff.  Try seb128.
<Tonio_> Mithrandir: sure :)
<Tonio_> seb128: ping ?
<seb128> Tonio_: reading
<Tonio_> thanks
<Mirv> pitti: looks like the software properties is now fixed in the latest langpacks, thanks! I assume I can now close bug 105280.
<ubotu> Malone bug 105280 in software-properties "software-properties translation incorrectly in language-pack-kde packages" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105280
<seb128> Tonio_: is your upload available somewhere?
<pitti> Mirv: great, thanks for checking
<Tonio_> seb128: wanna look at the source package ? gimme a minute
<seb128> Tonio_: no, I want a copy of what you upload somewhere
<Tonio_> seb128: okay
<Tonio_> seb128: http://tonio.homelinux.org/digikam
<Tonio_> seb128: those are the uploaded files
<seb128> Tonio_: https://launchpad.net/ubuntu/+source/digikam/1:0.8.2-2ubuntu1.1
<seb128> Tonio_: that version has already been used
<Tonio_> hum okay
<seb128> Tonio_: it's already used to edgy-proposed
<Tonio_> seb128: sorry that's my first SRU upload so I'm a bit confused.... should I change to 2ubuntu1.2 ?
<seb128> yes
<Tonio_> great, will do thanks ;)
<seb128> you can't have 2 uploads using the same version
<Tonio_> I didn't knew the rule was the same whatever is the section
<seb128> Tonio_: https://wiki.ubuntu.com/StableReleaseUpdates
<seb128> Tonio_: it's documented there
<seb128> "#
<seb128> Include a changelog entry with:
<seb128>     *
<seb128>       A new version number (the same cautions apply regarding the choice of version number)
<seb128>     *
<seb128>       Confirmation of the above testing, including the name of the tester in each case
<seb128> #
<seb128> Make no other changes relative to the version in -proposed.
<seb128> "
<seb128> ups, sorry, wiki copy does work correctly
* Mithrandir gives seb128 a "no"
<Mithrandir> +t
<seb128> Mithrandir: thanks ;)
<pitti> cjwatson: #96244 taken, will do an SRU for that and check with the upstream db
<pitti> cjwatson: thanks for the pointer; I subscribed to the package bugs now
<pitti> seb128: just played around with g-cups-mgr, didn't crash once; OTOH it was reasonably stable for me before, too
<seb128> pitti: ok, thank you
<Tonio_> seb128: yes, I missed the "new version number" line when reading the doc :)
<Tonio_> seb128: will do thanks
<seb128> np
<Keybuk> damn
<Keybuk> err, ww
<pitti> Mithrandir: are feisty doors now generally closed for things like tzdata updates?
<Mithrandir> pitti: yes, -updates would be better for that, I think
<pitti> Mithrandir: alright
<Mithrandir> dholbach: you have a machine with the HPA patch running, don't you?  Can you run fdisk on the disk and see if it gives you a sensible size?
<pitti> Mithrandir: I have as well, checking
<Mithrandir> thanks.
<Mithrandir> with the one where you suddenly had a huge disk, right?
<cjwatson> also parted please
<pitti> Disk /dev/sdb: 160.0 GB, 160041885696 bytes
<pitti> that looks right
<dholbach> Mithrandir: in a bit
<cjwatson> pitti: did you have the sector discrepancy in dmesg that Ben was looking at?
<pitti> [   28.677055]  ata2.00: ata_hpa_resize 1: sectors = 312581808, hpa_sectors = -1348362576
<pitti> that's just a printk bug
<cjwatson> negative? joy
<cjwatson> ah
<pitti> %lld instead of %llu
* pitti converts into positive number
<pitti> 2946604720
<pitti> right, seems so
<cjwatson> pitti: architecture?
<pitti> amd64
<pitti> [   28.317323]  ata1.00: ata_hpa_resize 1: sectors = 25408559, hpa_sectors = 25410672
<pitti> ^ my 13 GB disk
<cjwatson> surely 18446744072361189040 then
<pitti> (sda)
<cjwatson> it's an unsigned long long => 64 bits
<cjwatson> in fact just a u64
<cjwatson> which, yes, is 2946604720 sign-extended
<pitti> cjwatson: I had that in the boot text with the previous broken kernel http://people.ubuntu.com/~pitti/tmp/14.23-boot-failure.jpg
<elmo> you guys saw the thread about this on LKML, right?
<cjwatson> elmo: URL
<cjwatson> or subject line or anything
<elmo> looking, sorry
<elmo> my local archives are pathetically short apparently
<elmo> http://www.ussg.iu.edu/hypermail/linux/kernel/0704.0/2333.html
<elmo> it was a followup to that
<elmo> http://www.ussg.iu.edu/hypermail/linux/kernel/0704.1/0423.html
<cjwatson> ok, trying to track it down ..
<dholbach> Mithrandir: the size looks ok (fdisk and parted)
<Mithrandir> dholbach: ok, thanks.
<Keybuk> isn't that fix the 0002 one?
<cjwatson> it is, I'd just tracked it to that
<cjwatson> http://people.ubuntu.com/~kyle/feisty/0002-2.6.21-fix-lba48-bug-in-libata-fill_result_tf.txt
<cjwatson> which never got applied
<cjwatson> Mithrandir: please interrupt your build and apply ^-- that
<mdz> rebooting, brb
<cjwatson> works for mjg59 apparently
<Mithrandir> cjwatson: in addition to your patch?
<cjwatson> yes
<Mithrandir> building.
<Mithrandir> Riddell: kde-guidance is approved by you, right?
<Hobbsee> Mithrandir: it's working fine here.  i think he approved it earlier
<Riddell> Mithrandir: yes 
<Mithrandir> accepted.
<Riddell> thanks
<ogra> Mithrandir, if i upload to the queue now, will it automatically go to -updates or do i have to keep my upload back until after release day ? 
<ogra> (and file an SRU etc)
<Mithrandir> ogra: updates never automatically go to -updates.
<ogra> will they go manually to -updates if i upload now ? 
<ogra> (i just want to know if i should keep the g-p-m package here or upload it )
<Mithrandir> before you do anything like that, you should read up on the SRU policy, it seems. :-P
<ogra> oh, do we have something for the case where the archive is frozen =
<ogra> ?
* ogra looks
<Mithrandir> if you're uploading to -proposed, assume we have released and follow the regular SRU
<ogra> well, we havent released yet thats why i was asking 
<dholbach> Mithrandir: ok to upload http://codebrowse.launchpad.net/~dholbach/launchpad-integration/bug.103974/changes (rev 87 and 88)? (introducing an icon, that's why a diff does not work so well :-))
<Mithrandir> dholbach: I'm not sure I want to take those kinds of fixes any more, we're too close.
<dholbach> Mithrandir: did you say anything about bug 103974? (i had net problems)
<ubotu> Malone bug 103974 in Ubuntu "dialog-warning is blurry and pixelated" [Undecided,Confirmed]  https://launchpad.net/bugs/103974
<Mithrandir> 13:35 < Mithrandir> dholbach: I'm not sure I want to take those kinds of fixes any more, we're too close.
<dholbach> :-(((
<Mithrandir> it can easily go in an SRU update.
<Mithrandir> s/update//
<mvo> Mithrandir: I have a pending upload for gnome-app-install (dekstop data update + one trivial patch) and a updated release-upgrader. ok to upload those? or do you want to see the debdiff first?
<Mithrandir> mvo: go ahead.
<mvo> thanks
<ogra> Mithrandir, i assume you wont let http://paste.ubuntu-nl.org/15354/ in  (thats why i asked about -updates initially)
<Mithrandir> please wait while I boot my web browser.
<ogra> sure :)
<ogra> the original patch fixed it only for half of the people ... this one fixes bug 81227 for all of them
<ubotu> Malone bug 81227 in hal "Logout screen appears twice [Feisty] " [Medium,In progress]  https://launchpad.net/bugs/81227
<Kmos> feisty final will have gnome v2.18.1 ?
<ogra> feisty has 2.18.1 aready ... 
<seb128> Mithrandir: the lpi change should be no problem, the stock icon use is buggy and overwrite the normal stock icon (try to close gedit with a change and notice how blurry the icon is, happens on random apps)
<pitti> hi Kmos
<Kmos> pitti: hi, you saw my e-mail =)
<pitti> yes, I did
<seb128> Mithrandir: that's a lack of polish and could go to -updates though
<Kmos> ogra: nice
<Kmos> pitti: u've updated firmware?
<pitti> no, no hurry to do so
<Kmos> :))
<pitti> and busy with release stuff :)
<Kmos> yeah, later
<Mithrandir> seb128: hm, ok then, get it in.
<doko> Mithrandir: uploaded screem fixing the ftbfs
<Mithrandir> doko: \o/
<Mithrandir> ogra: get it in now and it's ok.
<ogra> yay
<seb128> Mithrandir: thank you
* ogra dances
<Mithrandir> seb128: does the rescued vte fix bug 85575?
<ubotu> Malone bug 85575 in vte "gnome-terminal reacting very sluggishly" [High,Confirmed]  https://launchpad.net/bugs/85575
<seb128> Mithrandir: I've no idea "sluggishly" is not easy to mesure
<Mithrandir> mvo: where's the new g-a-i ?
<seb128> Mithrandir: drop the milestone anyway, few people have complained, it has got better and we will not change it now anyway
<Mithrandir> seb128: please do so you.
<seb128> Mithrandir: ok
<mvo> Mithrandir: just uploaded, should be there any second
<Mithrandir> mvo: ok, thanks.
<mvo> Mithrandir: update-manager follows in a bit, I just want to run one additional test to make sure its good
<Mithrandir> mvo: sure
<mvo> seb128: vte is generally pretty fast for me these days, it used to be bad, but it is not anymore
<saispo> hi seb128 :)
<seb128> lu saispo
<seb128> mvo: ah, cool
<mvo> seb128: I'm a heavy user of tabs in the terminal and switching between them is fast as well 
<seb128> mvo: do you know around when it started being better again?
<mvo> not sure, sorry.
<Riddell> Mithrandir: new version of knetworkmanager uploaded for bug 105234
<ubotu> Malone bug 105234 in network-manager "Network manager says disconnected but is connected and working" [Critical,Fix released]  https://launchpad.net/bugs/105234
<BenC> pitti, dholbach: Can you guys retest the image I have, same location, basically a rebuild with what I'm about to upload?
<pitti> BenC: can do; it's different from cjwatson's recent build?
<dholbach> BenC: is it different from ...^ :)
<BenC> it's basically the same, but it's with the source that will actually get uploaded, so just being cautious :)
<pitti> right, downloading
<dholbach> downloading
<dholbach> BenC: won't you bump the ABI?
<pitti> BenC: hmm, still 14.23?
<BenC> it's sans ABI bump, but yes there will be one
<pitti> ooooorrllright
<cjwatson> (only amd64 is updated there)
<BenC> right
<dholbach> BenC: looks good
<dholbach> hang on, I booted -15
<pitti> BenC: 866f11ae96887917202a577839347033 <- correct md5sum?
<BenC> yep, that's it
<poningru> I just got pwnt
<poningru> 403 Forbidden [IP: 91.189.89.6 80] 
<dholbach> BenC: your -14 looks good too
<poningru> for downloading the 14.23 from apt
<pitti> poningru: intentionally disabled, it's broken
<poningru> is that intentional?
<poningru> ah ok
<poningru> thanks
<pitti> BenC: booting, brb
<poningru> BenC: anything I can help test?
<BenC> poningru: amd64?
<poningru> :( sorry
<poningru> i386
<BenC> I don't have i386 test images, but colin does
<jdub> seb128: http://svn.gnome.org/viewcvs/pango?view=rev&revision=2225 <-- ZOMG.
<jsgotangco> BenC: you have a kernel for amd64 to test?
<BenC> jsgotangco: http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<BenC> I should delete the i386 one
<jsgotangco> cheers
<seb128> jdub: interesting, no for feisty now though
<pitti> BenC: booted fine
<BenC> pitti: great, can you paste the lines related to hpa in dmesg?
<pitti> BenC: just about to do that :)
<BenC> there should also be a couple with hex dumps
<jdub> seb128: fisty fonts need love too!
<pitti> numbers still don't match perfectly, though
<cjwatson> pitti: if they don't match perfectly it probably means you actually have an HPA
<pitti> what is a HPA, BTW?
<cjwatson> host protected area, used for recovery partitions and such
<pitti> BenC: http://pastebin.ca/438080
<BenC> yeah, I think your 13G drive has a 1Meg HPA :)
<cjwatson> http://en.wikipedia.org/wiki/Host_Protected_Area
<pitti> 3v1l spy
<pitti> cjwatson: thanks
<seb128> jdub: they can still get with -updates if required ;)
<BenC> your second drive matches perfect
<pitti> fdisk shows sane sizes for both drives
<cjwatson> all looks lovely
<BenC> pitti: nice, thanks
<pitti> rock
<cjwatson> Mithrandir: bug 105998 is nasty
<ubotu> Malone bug 105998 in gfxboot-theme-ubuntu "Selecting keyboard layout hangs up the system" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105998
<cjwatson> I bet it's just one keymap name being really long
<Mithrandir> cjwatson: ugh.
<Mithrandir> cjwatson: any fix in sight?
<cjwatson> I bumped it to Confirmed/High
<cjwatson> just looking
<pitti> cjwatson: sure that it's really hanging? it messes up the screen for me, but it continues to work
<pitti> bug 105529
<ubotu> Malone bug 105529 in gfxboot "Keyboard selection (F3) corrupts the screen" [Medium,Confirmed]  https://launchpad.net/bugs/105529
<cjwatson> pitti: yes, it's not a hang for me, but it's not usable either
<cjwatson> oh, I didn't see that one
<cjwatson> I'll dup it to the one that's already in the right state, if you don't mind :)
<cjwatson> actually, no, will dup the other way
<pitti> I don't mind, I didn't file it :) (just confirmed)
<BenC> dholbach: did the kernel work for you?
<BenC> cjwatson: I have an upload ready, but I want to make sure dholbach's reboot went ok :)
<cjwatson> ok
<Tonio_> BenC: hey ;)
<BenC> Tonio_: hello
<Tonio_> BenC: is the new kernel supposed to fix the /dev/disk/by-uuid...... thing ?
<Tonio_> BenC: I was just reopening the bug concerning macbook pro machines...
<Tonio_> BenC: I can test if you want
<BenC> what bug number?
<Tonio_> BenC: bug 91940
<ubotu> Malone bug 91940 in linux-source-2.6.20 "2.6.20-10 regression from 2.6.20-9, Macbook Pro no longer boots" [Undecided,Fix released]  https://launchpad.net/bugs/91940
<Tonio_> BenC: today's update broke this again....
<BenC> today's update probably broke for some other reason
<BenC> Tonio_: using amd64 kernel?
<Tonio_> BenC: no, generic
<BenC> it's all generic, but is it for amd64 and i386?
<BenC> s/and/or/
<Tonio_> i386 (macintel)
<BenC> Tonio_: dpkg -l | grep linux-image-2.6.20-14
<Tonio_> BenC: ii  linux-image-2.6.20-14-generic              2.6.20-14.23                           Linux kernel image for version 2.6.20 on x86
<BenC> you've probably been bitten by some other bug that the next kernel will fix
<Tonio_> BenC: well if you have packages ready, I'll test them :)
<BenC> I have one for amd64, not i386
<Tonio_> okay....
<imbrandon> hrm i am on a 64bit proc ( pent-d 930 ) but i386 kernel and seem to have been bitten by it to ( not a mac )
<Tonio_> BenC: then I'm reopening the bug, I'll close if published upgrade fixes this
<BenC> Tonio_: it's not the same bug
<BenC> please do not reopen it
<Tonio_> BenC: hum, okay ;) hard to figure out since the error message is exactly the same :)
<BenC> is it?
<Tonio_> BenC: yes, exactly the same
<dholbach> BenC: yes yes it was fine
<BenC> odd because nothing changes in the last upload to affect that
<BenC> dholbach: great, was getting worried :)
<BenC> dholbach: thanks
<dholbach> <dholbach> BenC: your -14 looks good too
<Tonio_> BenC: 
<Tonio_> Check root= bootarg cat /proc/cmdline or missing modules, devices: cat /proc/modules ls /dev
<Tonio_>  ALERT! /dev/disk/by-uuid/228d13f9-92fd-4569-836b-9c7f75cb94c6 does not exist. Dropping to a shell.
<Tonio_> same error as in the closed bug
<cjwatson> that error just means "oh my god something went wrong"
<BenC> dholbach: wow, missed that
<BenC> Tonio_: that's not the actual error in that bug report
<BenC> the error it shows is the qc timeout failures, failed to set xfermode
<BenC> Tonio_: your error would match the problem I'm talking about, which will be fixed soon
<Tonio_> okay perfect :)
<BenC> mdz, cjwatson, Mithrandir: upload done
<BenC> cjwatson: do you already have linux-meta, lrm and backports ready, or should I get them?
<Tonio_> cjwatson: ah... didn't knew that was kind of a generic error... thanks for the info
<cjwatson> BenC: lrm's nearly ready here (took a while to download the new orig), go ahead with the others
<BenC> ok
<cjwatson> lrm uploaded
<cjwatson> Mithrandir: http://codebrowse.launchpad.net/~ubuntu-core-dev/gfxboot-theme-ubuntu/mainline/revision/208
<cjwatson> ok to upload that? I'd run into similar problems before, just needed to add a couple more keymaps to the list of special cases
<BenC> linux-meta away
<Mithrandir> cjwatson: looks sensible.
<BenC> is it appropriate that today is Friday 13th?
<cjwatson> YES
<wm_eddie> Heh
<Mithrandir> look at the bright side of it, Breezy is EOL-ed today.
* BenC waves bye to breezy
<pitti> oh, yay
<ogra> yippie
* pitti deletes his breezy chroot
<Hobbsee> BenC: :D
* Hobbsee will email bugsquad telling them to rid malone of breezy-specific bugs soon :)
<Mithrandir> mvo: could you please change meta-release and set Breezy as 'Supported: 0'?
<mvo> Mithrandir: sure!
<mvo> Mithrandir: done
<Mithrandir> cheers.
<ogra> pitti, why do i see php4-sqlite in the archive ? wasnt that dropped ? 
<Hobbsee> hi jono 
<pitti> ogra: I dropped php4 itself and a few packages, probably I didn't drop that one
<BenC> and linux-backports-modules done
<BenC> Mithrandir: the balls in your court now, my friend
<ogra> seems its the only one left with php4 in its name
<Mithrandir> BenC: thank you.
<cjwatson> Mithrandir: I'll upload debian-installer now too - but of course please make sure not to accept it until all the linux-source-2.6.20 binaries are accepted
<Mithrandir> cjwatson: ack.
<cjwatson> and the usual seed change will be needed. Want me to do that now, since you're probably not going to do any CD builds in the meantime?
<geser> ogra: I didn't file a remove request for php4-sqlite as gallimimus still depends on it
<ogra> ah
<ogra> but does it wrok without php4 available even ? 
<Mithrandir> cjwatson: yes, please.
<StevenK> Surely gallimimus is uninstallable since the archive is sans php4
<ogra> right
* StevenK high fives ogra
* ogra ^5es StevenK 
<pitti> I'm fine with killing it
<ogra> it makes it clearer if you apt-cache search php4 :)
<StevenK> pitti: Would you mind killing php5 while you're at it? :-P
<ogra> haha
<pitti> StevenK: 'whooops, typo' :)
<StevenK> pitti: :-D
<StevenK> pitti: Or, "Hrm, who commited the re.sub('4', '5') in remove-package.py? :-P
<geser> ogra: as php4-sqlite isn't installable, gallimimus isn't either but I didn't dare to request the removal of php4-sqlite when other packages still depend on it
<StevenK> geser: And? php4 was killed when it still had plently depending on it.
<heno> BenC: I've tested on two amd64 systems here. Works fine
<pitti> geser: won't make a difference, since php4-sqlite is uninstallable
<ogra> geser, well ...
<geser> StevenK: I'm a simple MOTU and pitti is an archive admin :)
* pitti hugs geser, he does an awesome job
* StevenK looks at forcing gallimimus to work with php5
<StevenK> I wonder if php has a (sh -n/perl -c) run-a-like
<geser> StevenK: if http://www.die.net/doc/linux/man/man1/php.1.html is uptodate try php -l
<StevenK> -l? What the heck?!
<StevenK> Does it expand to --lie-to-me-please ?
<toodles> lol!!
<ogra> who wants to be in bed with phph ?
<ogra> -h
<StevenK> ogra: pph? :-P
<ogra> :P
<StevenK> Ah. -l is lint. I suppose I can accept that.
<pitti> BenC, cjwatson: since one of you certainly uploads linux-meta soon, any chance that you could fix the uninstallability of linux-backports-modules-lowlatency? it depends on linux-backports-modules-2.6.20-14-lowlatency which apparently doesn't exist
<pitti> oh, wait, it's in universe
<ogra> that would at least help the reports :)
<cjwatson> linux-backports-modules-lowlatency should be in universe too
<cjwatson> there should be nothing seeding it
<pitti> right, it's in anastacia
<cjwatson> wow, anastacia looks good, nice work
<ogra> well, i have it in my dvd report for today
<pitti> :)
* ogra checks seeds
<cjwatson> ogra: how old is the dvd?
<pitti> cjwatson: I just fixed everything except the kernel stuff
<ogra> cjwatson, yesterday i think
<ogra> i have it in supported here 
<ogra> oh, wait, thats -debug
<ogra> err
<ogra> ignore me i'm talking rubbish ...
<ogra> what i see is backports-modules 
<pitti> cjwatson: I'm afraid I'm not educated enough to sensibly decide the fate of all those -di things in anastacia
<Mithrandir> pitti: can you top off the CDs for all derivatives with langpack, leaving a megabyte or two to spare?
<cjwatson>  * Kernel-Version: 2.6.19-7-386
<cjwatson> whoa
<pitti> Mithrandir: with pleasure
<cjwatson> that would tend to explain why germinate ignored them
<Mithrandir> cjwatson: where?
<Mithrandir> pitti: thanks a lot
<cjwatson> Mithrandir: supported. fixed.
<cjwatson> pitti: right, I think I've deconfused germinate wrt those -di things
<pitti> cjwatson: yay, thanks
<cjwatson> let me know if not
* pitti reduces feisty_probs.html to one problem and asks doko about it
<cjwatson> linux-backports-modules-2.6.20-14-server
<cjwatson> is that needed?
<cjwatson> zope3-dbg? I thought I'd asked doko about that a while back
<Mithrandir> cjwatson: -15, I'd thought?
<pitti> cjwatson: python-zope3 doesn't exist
<cjwatson> Mithrandir: wouldn't have thought anastacia would have noticed yet
<cjwatson> hmm, there's no linux-backports-modules-server
<Mithrandir> cjwatson: a publisher run just finished, but I didn't think I accepted anything in time for it.
<cjwatson> can I upload linux-meta again to fix that?
<Mithrandir> cjwatson: yes, please.
<Kmos> bug 106214
<ubotu> Malone bug 106214 in gnome-panel "network-manager icon disappears when deactivating wireless network" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106214
* Hobbsee wonders why the buildds arent building the new kernel yet...
<Hobbsee> it appears that they're mostly sitting idle...
<cjwatson> Mithrandir: in unapproved
<cjwatson> Hobbsee: it can take a while for certain cron jobs to notice unfortunately
<Mithrandir> Hobbsee: because the publisher is still running
<Hobbsee> cjwatson: pedal faster :P
<Hobbsee> Mithrandir: ahhh.  point
<Mithrandir> and because I've told them to stay so I can make the kernel build on palmer and not the other buildds
<Kmos> bug 106213
<ubotu> Malone bug 106213 in linux-source-2.6.20 "kernel 2.6.20-14.23 crashed at begining of boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106213
<cjwatson> ah, hadn't noticed that you had the publisher on manual
<Mithrandir> it's not on manual, I'm just sneaking in an extra cycle
<cjwatson> Kmos: almost certainly a dup of a million other bugs - please retry with 2.6.20-15.24 when it's available (some hours)
<cjwatson> Mithrandir: heh
<Hobbsee> Mithrandir: palmer's the fastest machine?
<Kmos> cjwatson: i found it, i'm not the bug reporter
<Mithrandir> Hobbsee: yes
<Hobbsee> neat :)
<Kmos> cjwatson: can I put fix released on it ?
<Mithrandir> it's about doble the speed of the other buildds, something which is significant when we're looking at three-hour build times
<Hobbsee> Mithrandir: indeed.
<ScottK> Kmos --> #ubuntu-bugs
<Hobbsee> Mithrandir: should i ask how much universe stuff is sitting in unapproved, or is all that just going thru?  (it's unmet deps)
<cjwatson> Kmos: not enough info, bug reporter will have to retry
<cjwatson> Hobbsee: http://people.ubuntu.com/~ubuntu-archive/queue/feisty/unapproved/
<Mithrandir> Hobbsee: I shove it through whenever I see it; it was empty five minutes ago
<Hobbsee> cjwatson: wow, we can see that!  when'd that happen?
<Hobbsee> Mithrandir: great, thanks
<cjwatson> Tollef set that up a little while back
<Hobbsee> nice :)
<cjwatson> Hobbsee: that's different from the LP +queue pages which you probably still can't see
<Mithrandir> I need to hook up an RSS feed and IRC bot to it.
<Hobbsee> cjwatson: indeed.  binary new is still hidden, etc.
<Mithrandir> Hobbsee: no, it's not.
<Hobbsee> was last i checked.  info may well be out of date
<Mithrandir> http://people.ubuntu.com/~ubuntu-archive/queue/feisty/new/
* Hobbsee grins
<cjwatson> new was the one you could always see, I thought
<Hobbsee> like i say, out of date info
<Hobbsee> cjwatson: source new - not binary new
<Mithrandir> it's the same queue
<cjwatson> Mithrandir: actually, that isn't mirroring binaries
<cjwatson> Hobbsee: https://launchpad.net/ubuntu/feisty/+queue - should be two binary uploads visible there
<cjwatson> refpolicy and drupal
<Hobbsee> cjwatson: mmm...so it is.  must be new, or i'm blind.  maybe both :P
<Mithrandir> cjwatson: hm, that's a bug, then.
<cjwatson> Mithrandir: shall I fix? I think it's obvious
<Mithrandir> QIDS=$(queue -Q ${QUEUE} -s "${DISTRORELEASE}" info | awk '$3 ~ /^[SB] -$/ { print $1 } ' | tr '\n' ' ' )
<cjwatson> /^[SB] -$/ should be something that matches S- or -B
<cjwatson>  /^[SB] -$/ should be something that matches S- or -B
<Mithrandir> oh, it's -B
<Mithrandir> yes, please fix.
<pitti> ogra: where to put langpacks for edubuntu? server or serveraddon? or do you prefer to handle that yourself?
<ogra> pitti, ? 
<ogra> they are defined in the seeds
<ogra> ship: * Languages: es xh pt de fr ca cs el
<cjwatson> Hobbsee: OK, http://people.ubuntu.com/~ubuntu-archive/queue/feisty/new/ shows binaries now, thanks for that
<pitti> ogra: alright; ok for me to fill them up?
<ogra> ogra@edubuntu:~/seeds/edubuntu.feisty$ grep language ship-addon 
<ogra>  * /^language-pack-[^-] +$/
<ogra>  * /^language-pack-gnome-[^-] +$/
<ogra>  * /^language-pack-kde-[^-] +$/
<Hobbsee> cjwatson: very nice.  thanks!
<pitti> ogra: oh, no need to then, I guess :-P
<ogra> yeah :)
<Mithrandir> dear archive, work faster.  Love, Tollef.
<pitti> ogra: lucky you :)
<ogra> heh
<ogra> having a second CD rules :)
<Hobbsee> Mithrandir: dear Tollef, pedal faster, kthnksbye!
<Mithrandir> it's kthxbye. :-P
<Hobbsee> Mithrandir: you can kill http://people.ubuntu.com/~ubuntu-archive/testing-ports/breezy_probs.html too
<Hobbsee> Mithrandir: :P
* Hobbsee stomps on Mithrandir's toes
<cjwatson> that would be something that still lives in drescher:~cjwatson/
<cjwatson> I'll kill it
<Hobbsee> cjwatson: ahh.  go for it :)
<Mithrandir> cjwatson: can you transition it to be generated by lp_archive or something instead?
<cjwatson> testing/data/dapper/breezy
<cjwatson> testing/data/edgy/breezy
<cjwatson> blink, something went wrong there
<cjwatson> Mithrandir: it's on the to-do somewhere ...
* Mithrandir is scared even just thinking about the size of Colin's todo list
<pitti> Mithrandir: done; {ed,x}ubuntu already have the complete collection, kubuntu is full, ubuntu filled up
<cjwatson> Hobbsee: done
<Hobbsee> cjwatson: great :)
<dholbach> hi danielk
<danielk> hey
<Mithrandir> pitti: thanks a lot
<danielk> http://danielkitta.org/images/ubuntu-kernel-panic.jpg
<dholbach> BenC: ^ that seems to happen with your newest amd64 kernel still
<danielk> linux-image-2.6.20-14-generic_2.6.20-14.22_amd64 works
<danielk> 14.23 doesn't
<danielk> and neither do the packages by cjwatson and bcollins, unfortunately
<pitti> dholbach: Friday 13th
<BenC> "This is not a software problem"
<dholbach> pitti: apparently
<danielk> well it works with the prior kernel
<BenC> danielk: I can't see how -14.22 will work and my package wont
<danielk> BenC: but that's what happens
<BenC> there's nothing there affecting sata_nv directly
<pitti> bad memory?
<danielk> I'm running 2.6.20-14.22 right now
<danielk> don't think so
<BenC> it's not even a sata_nv error
<danielk> perfectly reproducible
<danielk> BenC: it seems related
<pitti> danielk: could you run memtest from grub?
<danielk> if I boot with nomce on the kernel command line, it just hangs without the message
<danielk> I could
<danielk> ok, that will take a while
<danielk> later
<dholbach> BenC: anything else he could to debug?
<dholbach> oh... there he goes
<BenC> scary part is, it looks like at the very point where hpa would be checked
<mjg59_> BenC: No, it's 15 seconds later
<dholbach> if you know of anything he could try, I can phone him
<mjg59_> Sorry, 5 seconds later
<BenC> the SATA link up prints right before hpa check
<mjg59_> BenC: Look at the timestamps
<BenC> and then there's 5 seconds of hang
<BenC> mjg59_: right, what if it is an exception waiting for hpa check to return?
<mjg59_> That's not how MCEs are handled
<BenC> mjg59_: hpa is the only thing changes between -14.22 and -14.23 that would affect him
<mjg59_> Well, assuming that his hardware hasn't died in the meantime
<mjg59_> Has anyone run that through mcelog?
<BenC> if he can reliably go back to -14.22 without problems, then there's a good indication...
<BenC> that's what I want to see
<dholbach> he logged in with -14.22 or -13.x
<BenC> dholbach: can you ask him to run "mcelog --ascii"?
<dholbach> ok
<dholbach> he doesn't know how to access the kernel logs, if the machine does not boot properly
<dholbach> or should he do that with a working kernel?
<Hobbsee> pitti: http://people.ubuntu.com/~pitti/langpacks/daily/breezy-updates/ can go too, (when you're not busy)
<pitti> Hobbsee: done 10 seconds ago :)
<Kmos> pitti: i told him that already
<Kmos> :)
<Hobbsee> pitti: ahh
<dholbach> BenC: ^
<BenC> dholbach: mcelog is not the same, it's stored in hardware, so is good across reboots
<jsgotangco> bye bye Breezy
<BenC> probably even get it from BIOS event log viewer
<fabbione> it's probably time to dist upgrade to dapper then
<bddebian> Heya
<cjwatson> seeds updated to 2.6.20-15 and merged to all derivatives
<danielk> hey
<danielk> so
<pitti> danielk: welcome back
<danielk> BenC: mcelog --ascii </dev/mcelog doesn't output anything
<danielk> pitti: I aborted the memtest after the 4th pass ran without errors
<pitti> danielk: ok, thanks for checking
<danielk> no prob
<BenC> danielk: Maybe your BIOS even viewer has more info?
<danielk> hmm
<BenC> event
<danielk> where would that be? somewhere accessible from the BIOS config?
<BenC> danielk: did you run mcelog as root?
<danielk> yes, with sudo
<BenC> danielk: </dev/mcelog wont work with sudo
<danielk> sudo -s
<BenC> ah ok
<danielk> anyway, just typing "mcelog" (as root) doesn't output anything either
<BenC> danielk: it definitely looks like a hw problem, but it's likely that something is just now triggering it
<danielk> oh well
<BenC> danielk: If you can find some info from the hw, then hopefully we can get something out of it
<BenC> danielk: Try booting the newer kernel with libata.ata_ignore_hpa=0
<BenC> danielk: if you could please
<danielk> cool
<danielk> thanks, will try
<danielk> later
* ogra wonders what this favicon shall be http://codebrowse.launchpad.net/~ogra/ltsp/feisty-ltsp/changes
<Keybuk> a turtle
<Keybuk> knowing robey
<elmo> what's the bug number for 'zomg, this kernel broke the world'?
<elmo> Mithrandir: ^--
<cjwatson> elmo: bug 106063
<ubotu> Malone bug 106063 in linux-source-2.6.20 "MASTER: Computer will not boot after 2.6.20-14.24 kernel upgrade" [Critical,Fix committed]  https://launchpad.net/bugs/106063
<elmo> cheers
<danielk> back again from my N800 now
<kylem> elmo, fixed in -15.
<kylem> elmo, the problem was the patch i committed to fix MBP got reverted unintentionally.
<danielk> BenC: libata.ata_ignore_hpa=0 doesn't help
<elmo> kylem: yeah, I know, just got someone complaining at me about the 000 perms on the mirror of the existing binaries
<jdong> "How exactly do you propose getting dmesg output from a kernel that doesn't boot?"
<kylem> yeah. i'm hitting that now. ;-P
* jdong chuckles
<BenC> danielk: There goes the only known thing that changed between kernels for you
<kylem> danielk, we still attempt to read the HPA, don't we?
<kylem> s/danielk/BenC/
<danielk> well, as I said .22 does work
<BenC> kylem: I didn't check the code path thoroughly...maybe
<danielk> and .23 doesn't
<kylem> yeah, we do. bleh.
* cjwatson 's hand hovers next to the regression klaxon
<BenC> kylem: maybe we shouldn't call ata_hpa_resize() when ata_ignore_all=0
<BenC> either way I still think it's a hw issue, just triggered by this
<danielk> hmm
<kylem> yeah, the taskfile failing to execute wouldn't cause a MCE.
* cjwatson agrees, we just don't know how widespread this broken hardware is
<kylem> unless libata-eh is broken on sata_nv.
<BenC> it's an easy fix
<cjwatson> I don't mind if it breaks by default (at this point) as long as a workaround is possible
<danielk> the mcelog manpage says something about  bogus mce
<kylem> BenC, might as well not touch the existing thing, and add a libata.no_hpa_support=1
<danielk> being not that rare, that is
<BenC> cjwatson: it's not possible with current code
<BenC>                         if (ata_id_hpa_enabled(dev->id))
<BenC>                                 dev->n_sectors = ata_hpa_resize(dev);
<BenC> kylem: we can just change that if to check ata_ignore_hpa
<cjwatson> BenC: I understand
<danielk> this is an Asus A8N-E mainboard btw
<BenC> there's really no reason to call that if we're not ignoring hpa
<BenC> s/change it to check/make it check ata_ignore_hpa as well/
<BenC> Solarion: if (ata_ignore_hpa && ata_id_hpa_enabled(dev->id))
<cjwatson> we should be able to get a kernel for danielk to try fairly quickly?
<BenC> s/Solarion/so/
<mjg59_> Anyone else with sata_nv having the same issue? Or anyone with it working?
<BenC> danielk: Can you test in 30 minutes?
<danielk> ooh that would rock
<desrt> word up guys
<desrt> <- testcase
<BenC> mjg59_: have seen no other reports of it
<kylem> where is the -15 kernel?
<danielk> BenC: yup
<cjwatson> desrt: ?
<kylem> it's not in the archive yet
<BenC> nor reports of it working
<kylem> i have an A8N-e
<kylem> danielk, is this socket 939 athlon64?
<desrt> er... -14 isn't booting for me because of sata problems.  hpa stuff.  is that what you're looking for?
<cjwatson> kylem: danielk's using a non-ABI-bumped version from http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<BenC> kylem: you can test my kernel at http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<kylem> ok
<BenC> desrt: I believe we have that fixes, test my kernel above if you have amd64
<cjwatson> desrt: try http://people.ubuntu.com/~bcollins/kernels/feisty-release/ (warning: will break restricted modules)
<danielk> kylem: yup
<desrt> BenC; 32bit here
<kylem> danielk, ok. i have that board.
<BenC> I'll get a kernel ready in any case
<danielk> kylem: now it gets interesting
<BenC> danielk: Copy the URL above, the kernel will be there shortly...I'll ping when it's ready
<kylem> i'm pretty sure i tested on that board.
<kylem> seeing as it's one of the very few i have.
<danielk> BenC: thanks
<kylem> rebooting now
<kylem> reproduced.
<mjg59_> Oh, fun.
<danielk> rock!
* desrt has never received so much email from a single launchpad bug overnight :)
<kylem> christ.
<danielk> well I'm glad it's not *my* hardware :P
<kylem> ok.
* kylem powers on as many x86 cpus as he can for distcc
<desrt> kylem; you can cross-compiled with distcc :)
<cjwatson> * kylem's house lifts off
<kylem> desrt, while i have like 16 parisc cpus of varying speeds sitting under my desk, they aren't as fast as c2d. :P
<pitti> StevenK: thanks for gallinimus; I'm going to kill php4-sqlite then
<desrt> kylem; fair.
<BenC> kylem: so you get an exception too?
<kylem> BenC, yup. exact same failure. exact same hw.
<BenC> crazy
<BenC> should we dmi blacklist that board?
<kylem> this is new.
<BenC> kylem: Can you narrow down exactly where in the code it occurs?
<kylem> yup.
<BenC> kylem: the only thing I'm worried about is that maybe it's the bit twiddling, which is different in my patch because it got rid of the signed extension bullshit we saw while testing last night
<BenC> but it's exactly the same thing as what's in IDE, so I'm not sure how it could be that
<kylem> it's not that.
<BenC> I have a sata_nv board, but it's running 32-bit kernel
<BenC> I wonder if a 64-bit kernel will boot ok on it
<BenC> build is just about done
<kylem> rookery.ubuntu.com/~kyle/vmlinuz.git is amd64 defconfig i use for quick testing before doing a full rebuild of patches
<kylem> it fails on my sata_nv board, might be worth a try
<kylem> in 10 seconds when it finished uplaoidng
<kylem> BenC, i just kicked off an i386 build, we'll see if it fails too.
<BenC> danielk: Should be about 5 minutes before the package is uploaded
<danielk> BenC: ok
<pitti> Mithrandir, cjwatson: ok to upload http://pastebin.ca/438284 to fix the last feisty_probs.html?
<pitti> (doesn't affect CDs)
<kylem> BenC, yeah, it's ata_exec_internal that's failing.
<BenC> bummer
<BenC> not really fixable
<kylem> i have a n idea.
<BenC> question is, is it ASUS board, or sata_nv
<kylem> libata.hpa_pata_only=1
<kylem> only pata disks should have this issue, ideally.
<cjwatson> pitti: shouldn't it be python-zopeinterface?
<kylem> we can check the cable type pretty easily
<wm_eddie> how do I made a .patch file suitable for going inside the debian/patches directory?
<wm_eddie> (Of a package)
<pitti> cjwatson: I'm not sure; p-zopeinterface is a transitive dependency now, too
<kylem> wm_eddie, dpatch
<pitti> cjwatson: but I didn't reach doko today
<pitti> cjwatson: and other python-foo-dbg depend on python-foo as well
<pitti> cjwatson: that's why I think this isn't terribly wrong at least
<BenC> boot on my sata_nv board..
* danielk downloads BenC's new kernel
<pitti> cjwatson: of course the changelog should talk about 'fix zope3-dbg dependencies'; fixing
<cjwatson> kylem: I'd recommend the simplest possible fix or workaround if necessary ...
<pitti> wm_eddie: https://wiki.ubuntu.com/MOTU/School/PatchingSources
<kylem> cjwatson, ok. i think i have something, giving it a test
<mjr> hmh, the "desktop effects" configuration applet uses a stay-down button which to me is bad. But YMMV.
<danielk> BenC: still hangs
<BenC> danielk: I expected the hang still, just wondering if the ata_ignore_hpa=0 works around it
<danielk> BenC: ok, trying
<BenC> hangs on my sata_nv too
<wm_eddie> thanks pitti.
<wm_eddie> Yay, I fixed the desktop-effects cube checkbox.
<danielk> BenC: still hangs with libata.ata_ignore_hpa=0
<kylem> BenC, fails on i386 here tooo.
<mjg59_> kylem: Checking the cable type isn't a good plan
<kylem> mjg59_, i know.
<kylem> unfortunately, i'm out of better ones.
<kylem> i wonder if it's caused by drivers/ide code loading first.
<mjg59> So *how* is ata_exec_internal causing an MCE?
<mjg59> I've never seen driver code trigger those on x86
<kylem> not a clue in the world
<BenC> maybe it's causing the controller to choke up something
<BenC> it does seem sata_nv specific
<kylem> a PCI access timing out would softfail 0xffffffff, not hardfail and gutter the bus
<BenC> can a PCI device trigger an MCE?
<BenC> danielk: damnit, sorry, it's libata.ignore_hpa=0
<danielk> ok, trying
<mjg59> kylem: Inappropriate DMAing? Though I can't imagine why that would happen
<kylem> mjg59, inappropriate how? :)
<pitti> Mithrandir: zope patch with improved changelog, confirmed by Matthias: http://pastebin.ca/438310
<doko> pitti, cjwatson, Mithrandir: sorry, forgot about that; the fix is correct
<mjg59> What's the outcome of DMAing to an address that's not backed by physical memory?
<kylem> mjg59, kersplat.
<mjg59> What sort of kersplat?
<pitti> seb128, mvo: is the gnome network monitor applet removed on upgrades in favour of n-m?
<seb128> pitti: no, panel config is an user one, there is no real way to do it
<BenC> is it possible that sata_nv doesn't setup the devices well enough before we start probing hpa?
<pitti> seb128: alrighty; 
<seb128> pitti: if you speak about the panel config itself
<seb128> uninstalling it would "work"
<pitti> seb128: bug 85585
<ubotu> Malone bug 85585 in network-manager "i don't think that networkmanager applet is needed" [Undecided,Confirmed]  https://launchpad.net/bugs/85585
<pitti> seb128: 'after upgrade I have both network monitor and nm-applet
<danielk> BenC: libata.ignore_hpa=0 doesn't help either
<pitti> seb128: I'm sure that there are already dups of that
<BenC> danielk: weird, it helps me
<seb128> pitti: the only way to close that would be to deprecated network monitor
<seb128> pitti: like make it a null applet
<desrt> [579347.567063]  NetworkManager[12366]  trap int3 rip:421b7c rsp:7fff9b9c7fc0 error:0
<danielk> strange
<seb128> pitti: but some users might still want to use it
<BenC> danielk: can you boot up a working kernel and do "echo options libata ignore_hpa=0" > /etc/modprobe.d/mylibata
<pitti> seb128: right, bad as well; do you already have a reference bug for that?
<BenC> danielk: then update-initramfs -u, and reboot
<danielk> ok
<kylem> 08:33:02 < kyle> hmm, will a DMA to a non-existant address MCE on i386/x86-64?
<kylem> 08:35:48 < jejb> no ... unfortunately
<mjg59> Ok
<seb128> pitti: not that I remember, we didn't get many bugs about it afaik (or not on GNOME)
<mjg59> So what on earth /can/ MCE an i386?
<pitti> seb128: alright, I just keep it then; thank you
<seb128> np
<seb128> pitti: cleaning network-manager huge stack of bugs?
<mjg59> I was under the impression that the answer was "Basically nothing"
<pitti> seb128: yep
<bluefoxicy> <tepsipakki> bluefoxicy: to reconfigure X you run "sudo dpkg-reconfigure -phigh xserver-xorg" as suggested in xorg.conf
* seb128 hugs pitti
<seb128> pitti: I think that's required, lot of bugs there
<bluefoxicy> tepsipakki:  that should happen automagically.  I put in LiveCD, it installs (has) ati/nvidia drivers and configures Xorg.  If I boot and X goes "OMGWTF" 5 times it should go "DO YOU WANT TO RECONFIGURE X?" instead of "OHCRAP BAIL BAIL BAIL hey btw X died"
<bluefoxicy> and it shouldn't ask me a damned thing besides that
<bluefoxicy> which reminds me
<kylem> i think i found it, Ben.
<bluefoxicy> I should go file a bug on that, now that I've calmed down to the point that I can make a report without 80% of it being abusive language
<pitti> bluefoxicy: no fglrx/nvidia-glx on live system
<pitti> bluefoxicy: and you can use restricted-manager to configure them
<bluefoxicy> pitti:  oh, no?  I thought it pulled those down.
<mjg59> No
<pitti> bluefoxicy: right, r-m will download them
<mjg59> We don't use the non-free X drivers by default
<pitti> but ENOSPACE
<pitti> on the CDs
<bluefoxicy> pitti:  I swapped mobos.  Onboard via -> onboard nvidia.  Result:  2 hours of me trying to get X configured properly to start; half of that was just trying to get it to draw a mouse pointer instead of highlighting things in a ghostly manner as my mouse moved
<seb128> bluefoxicy: there is likely already a bug about it
<BenC> not doing hpa makes things happy, happy on my sata_nv
<seb128> bluefoxicy: there is specs about it
<bluefoxicy> I'm not so worried about X not doing nvidia-glx automagically as I am X freaking dying and expecting me to answer 20 questions to fix it when I swap video chipsets
<seb128> bluefoxicy: it only requires somebody to do the job, everybody is already overworked
<pitti> bluefoxicy: as seb says, it's a known problem and there's a spec
<pitti> no need for more bug reports about ti
<pitti> s/ti/it/
<Hobbsee> bluefoxicy: feel free to volunteer to do it, isntead of waving the magic wand
<bluefoxicy> seb128:  Yeah, everyone is always overworked.  Hell I'm overworked, I have a job and it's made me a less productive member of society :/
<seb128> bluefoxicy: you can always complain that we don't work 24 hours a day, not really going to change anything though
<desrt> bluefoxicy; at the very least, understand that this won't be fixed for feisty and that the most productive thing that you can do right now is to stop talking about it until the next week is over.
<seb128> bluefoxicy: it'll be done at some stage, either contribute or wait, not a lot that ranting will change
<bluefoxicy> anyway at least there's a bug on it
<bluefoxicy> there's not much else I can really do ;/
<seb128> and a specification
<Hobbsee> bluefoxicy: while you're waiting for it to be done, how bout you get rid of all the dupes of the non-booting kernel bug?
<mvo> pitti: release-upgrader is not touch the users config in any way
<pitti> mvo: right, already settled with Seb; thank you!
<danielk> BenC: ok, that helped, thanks
<BenC> danielk: thanks, we'll see if we can get this worked out...appreciate the report
<danielk> np
<doko> ogra, cjwatson: I couldn't confirm the keyboard selection problem with the current edubuntu amd64 dvd (although it's still reproducible with the old one), so either it's fixed or a bad disk
<ogra> bad disk i guess
<ogra> nobody else saw it
<desrt> so guys... you know this bug where laptops using madwifi randomly lock up.... i think i figured out what causes it
<cjwatson> pitti: zope3> ok, that's fine - have you uploaded it?
<desrt> it happens when networkmanager tells the driver to associate with a unencrypted network very rapidly after it is first discovered
<cjwatson> doko: ok, thanks
* desrt can almost always get the crash to happen by waking up from sleep in range of a trusted unencrypted network...
<pitti> cjwatson: no, no approval yet
<pitti> cjwatson: uploaded
<cjwatson> (it's usually best to shove it in the queue at times like this - we can always reject)
<cjwatson> Mithrandir: I'm going to hold off on accepting debian-installer for a while until we decide what's happening with the kernel
<seb128> cjwatson: did you read what I wrote about X-Ubuntu-Desktop-Domain and the ubiquity desktop icon translation the other day?
<cjwatson> bugger. yes, and totally forgot about it.
<cjwatson> is it critical?
<seb128> no, it's just to get the "Install" translated on the desktop CD
<cjwatson> I don't quite understand why it used to be needed and isn't any more
<seb128> well, it's required to use language pack
<cjwatson> but I include the translations directly
<seb128> but it's broken for some reason and doesn't get translated at all
<seb128> and it's late to track the bug now
<seb128> yes
<cjwatson> I intentionally disregard language packs there
<seb128> dropping the domain will make the .desktop translations being used
<seb128> ahhh
<cjwatson> it's a gtk-specific problem?
<seb128> that explains it then
<seb128> dunno about the KDE side
<seb128> we patched glib to use gettext before the .desktop translations
<cjwatson> Mithrandir: ^-- up to you
<seb128> dunno if that has been done for kubuntu
<cjwatson> TBH I'm inclined to leave it at this point - sorry for dropping it on the floor earlier
<pitti> seb128: ISTR that it was done
<seb128> cjwatson: np, most people understand "Install" anyway
<Riddell> seb128: yes, it's just the same
<seb128> it's only cosmetic
<cjwatson> "Install" is also what's written on the pressed CD sleeves
<cjwatson> Riddell: does it actually work for Kubuntu? :-)
<pitti> seb128: just to understand this fully, you want ubiquity to drop the X-Ubuntu-Gettext-Domain: to circumvent the glib bug about not using the langpacks for translation?
<seb128> pitti: no, to workaround the icon label not being translated at the moment
<pitti> seb128: right, that's what I meant
<seb128> pitti: if we drop the gettext domain it uses the .desktop Name[locale]  correctly
<pitti> ok, so we mean the same thing
<seb128> still there is a bug somewhere but it's too late to debug it now
<seb128> next cycle
<seb128> if there is no .mo available the desktop Name[locale]  should be used
<pitti> seb128: I even think that this works
<Riddell> cjwatson: not sure, I don't think I've booted it up in different languages
<seb128> well, something make it not being translated
<pitti> seb128: the problem is AFAIR when the .mo *is* available
<cjwatson> seb128: I've committed the fix for my gutsy tree anyway
<seb128> cjwatson: ok, thank you
<cjwatson> (just commenting it out, since it's a workaround)
<pitti> cjwatson: TBH I'd rather leave it as it is and fix the actual glib bug
<seb128> pitti: well that's a workaround for the time we fix the glib bug
<cjwatson> I agree, hence only commenting it out
<kylem> danielk, around?
<kylem> BenC, around?
<kylem> danielk, try adding sata_nv.adma=0 to your command line.
<pitti> seb128: weird, I thought that was assigned to me some days ago
<cjwatson> pitti: why is ubiquity.mo in language packs at all?
<cjwatson> pitti: in fact, I don't see it in the -de ones (random example)
<pitti> cjwatson: ubiquity doesn't use it?
<seb128> pitti: I closed the bug which was assigned to you as a dup
<seb128> pitti: there was a bug much older on ubiquity
<pitti> seb128: I see
<cjwatson> pitti: ubiquity is designed to ignore language packs because typically we want the installer to have broader language coverage than will fit on the CD in the form of langpacks
<pitti> ./language-pack-de-base/data/de/LC_MESSAGES/ubiquity.po
<seb128> pitti: bug #45741
<ubotu> Malone bug 45741 in ubiquity "Ubiquity desktop icon "Install" is not translated" [High,Confirmed]  https://launchpad.net/bugs/45741
<cjwatson> <cjwatson@riva ~>$ dpkg -c /mirror/ubuntu/pool/main/l/language-pack-de-base/language-pack-de-base_7.04+20070329_all.deb | grep ubiquity
<pitti> cjwatson: I see
<cjwatson> <cjwatson@riva ~>$
<cjwatson> seb128: not convinced that's the same bug
<cjwatson> I suppose it could be
<seb128> "1. Desktop Icon "Install" does not appear translated although is translated and merged in Rosetta;"
<seb128> looks like the same
<cjwatson> I thought I remembered it working in dapper though
<pitti> cjwatson: it's in the daily packages now; it seems my recent fix for software-properties fixed ubiquity as well
<cjwatson> yeah, but it could just have been that I hadn't merged it into the package at that point
<seb128> we didn't have language packs for .desktop in dapper, did we?
<pitti> seb128: I think we did
<cjwatson> and that it wasn't in the language pack
<seb128> pitti: hum, right, they went during the devel cycle though, so maybe cjwatson remember it was working before that
<seb128> s/went/came
<cjwatson> could be
<cjwatson> I'm sure I tested it when I first did ubiquity's .desktop infrastructure
<seb128> pitti: glib bug confirmed BTW with gedit, I dnd the .desktop and moved the .mo somewhere else, the item is not translated then
<pitti> seb128: heh, then this might just fix itself after a langpack update :)
<pitti> seb128: you might actually try a live CD and install the daily langpack deb
<seb128> pitti: I've undupped https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/95883, it's easier to track this way
<ubotu> Malone bug 95883 in nautilus ".desktop files on desktop do not use translations" [Low,Confirmed]  
<desrt> hah.  403 on linux-image-2.6.20-14-generic_2.6.20-14.23_i386.deb.  nice touch!
<mjg59> Ok. Looks like we've got a handle on the problem.
<desrt> mjg59; party.
<BenC> danielk, pitti, dholbach: Be around shortly for another kernel to test?
<dholbach> yes
<pitti> BenC: yup
<pitti> BenC: the one you uploaded a while ago is no good?
<BenC> Seems kyle nailed down the exact problem with sata_nv, we just want to make sure there are no other regressions
<dholbach> rock
<BenC> pitti: it's good for you, but not sata_nv
<dholbach> go kernel team go!
<BenC> Anyone willing to test this kernel when I get it uploaded I would appreciate too
<BenC> be done in about 30 minutes
<BenC> i386 and amd64
<dholbach> super
<zul> just tell me where you stashed it
<pitti> BenC: btw, I made the mistake of already releasing the amd64 binaries, so l-r-m amd64 is already building against 15.24; but I guess that won't need a rebuild, unless the ABI changes again?
<kylem> elegant solution written, damn that was easy.
<pitti> BenC: (I already released them for testing)
<BenC> no ABI bump
<pitti> BenC: great
<pitti> BenC: so I can let l-r-m build away on other arches, too?
<BenC> pitti: The current kernel isn't too bad, the scope of the problem is more limited than the other problems
<BenC> yeah
<pitti> BenC: right, I thought we are pretty safe until we upload a new -meta
<BenC> I uploaded meta :)
<BenC> not sure if it's NEWd or not
<pitti> meta in new?
<pitti> BenC: it's in unapproved
<mdz> BenC: is the patch up anywhere?
<danielk> kylem, BenC: back
<BenC> mdz: http://people.ubuntu.com/~bcollins/libata.diff
<BenC> mdz: That is what's going into -15.25
<BenC>   * sata_nv: Revert patch that enabled ADMA for NODATA transfers.
<BenC>     - GIT-SHA 6429d0744ca5ffe007109ef4d70414bebe15966c
<BenC>   * libata: Completely avoid HPA code paths when ignore_hpa=0
<BenC>     - GIT-SHA 9e3e1aea530dcb2e792f14e365a0d6d95539bfa9
<BenC> that's the changelog
<mdz> BenC: what triggered this sata_nv problem? or is it an old bug?
<BenC> mdz: HPA triggered it
<BenC> it does NODATA transfers, and tripped up the ADMA code in sata_nv
<cjwatson> the HPA ATA commands time out on that controller in that mode
<cjwatson> specifically those commands
<doko> heno: the edubuntu dvd images are not listed on the testing pages; anyway, got the same results as with yesterday's images (plus the keyboard problem was fixed / or a bad disk)
<BenC> it seems to really be a hw issue, but we worked around it
<mdz> BenC: the HPA changes look very reasonable, though sata_nv is opaque to me
<cjwatson> dunno, does the ADMA engine have a spec? the patch being reverted now might be violating it
<BenC> mdz: the patch is just a -R of the one that introduced ADMA for NODATA calls
<BenC>      commit 382a6652e91b34d5480cfc0ed840c196650493d4
<BenC>      Author: Robert Hancock <hancockr@shaw.ca>
<BenC>      Date:   Mon Feb 5 16:26:02 2007 -0800
<BenC>          sata_nv: use ADMA for NODATA commands
<BenC> mdz: that was the problematic one
<BenC> cjwatson: that's possible...kyle has a patch that avoids ADMA for the calls that HPA checks do
<BenC> he sent it upstream for comment
<BenC> builds almost done...
<cjwatson> yeah, saw kyle's patch by mail
<kylem> ack, meant to bcc mdz too, my bad
<BenC> kernels are uploading
<BenC> 5d86d7f2b81fbe886225838a12440fe1  linux-image-2.6.20-15-generic_2.6.20-15.24_amd64.deb
<BenC> 453c471013d6a378d1b41e26278d2ac2  linux-image-2.6.20-15-generic_2.6.20-15.24_i386.deb
<mdz> BenC: hmm?  -15.24 was the previous upload
<BenC> http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<mdz> the one which is still building
<BenC> mdz: no changelog entry, just patch
<mdz> eeek
<BenC> it's just for this build
<BenC> my upload has changelog :)
<kylem> cjwatson, http://linux-ata.org/driver-status.html
<BenC> amd64 kernel is done
<cjwatson> kylem: sorry, what am I looking for there?
<pitti> BenC: downloading
<kylem> cjwatson, you asked if the doc was open
<BenC> cjwatson: #nvidia
<BenC> for that URL
<cjwatson> ah, under NDA it says
<kylem> Robert Hancock has the docs now, i think
<BenC> i386 done now too
<dholbach> rebooting amd64
<dholbach> BenC: amd64 looks good
<BenC> boots on my xeon
<BenC> dholbach: thanks
* pitti reboots as well, brb
<BenC> Sorry, i386 image built without the patch
<BenC> amd64 is good though
<dholbach> ok, then I don't need to restart the i386 :-)
<dholbach> danielk: still around?
<danielk> yup
<pitti> BenC: nothing weird, smooth as silk
<dholbach> yay pitti!
<danielk> installing right now
<dholbach> super
* dholbach hugs danielk
<cjwatson> anyone else here with sata_nv?
* pitti doesn't have sata, sorry
<pitti> oh, I might know someone
<pitti> darn, he's offline
<BenC> pitti: excellent thanks
<fryfrog> sorry, pata_amd here :(
<pitti> who can he dare to walk away from the computer on a friday evening? :-)
<BenC> kylem: can you try the amd64 image?
<kylem> yup.
<kylem> suckin' it down now.
<BenC> Shit, I'm going to need the ABI's for the -15.24 upload
<pitti> BenC: ia64 and i386 are still building, sorry
<cjwatson> let's see how fast we can get them to you
<desrt> the world plots against me.
<cjwatson> i386 is in accepted
<BenC> I don't mind doing an abi ignore for ia64
<desrt> amd64, powerpc, sparc.  all done!  i386 wait wait wait :p
<Treenaks> desrt: i386 is the new m68k
<desrt> m68k was pretty hot, i must say.
<Keybuk> hello
<desrt> hello sir.
<Treenaks> hi#
<desrt> Keybuk; haven't seen you around in a while.  how is life?
<Keybuk> life is bloody busy ;)
<desrt> how will life be next week?
<Keybuk> cjwatson: so, yes, I have sata_nv
<Keybuk> desrt: just as busy
<desrt> (well.. one week from now, i mean)
<Keybuk> but then the week after is nice and fluffy
<desrt> :)
<czr> any hints of the format of d-i mirror/http/proxy? I'm trying to build a pxe booted preseed file (using netboot) but it doesn't want to use proxy at all
<desrt> seems like a good time to take a vacation in the south of spain
<czr> (somewhat OT, sry)
* Keybuk has somewhat lost track of weeks
<Keybuk> at least one week, I'm on a plane for all of it
<dholbach> Keybuk: http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<desrt> Keybuk; only 1 more to go :)
<kylem> BenC, boots here.
<Treenaks> desrt: I've been planning that too, what a coincidence :)
<BenC> Keybuk: running amd64 kernel or i386?
<Keybuk> BenC: amd64
<dholbach> 5d86d7f2b81fbe886225838a12440fe1  linux-image-2.6.20-15-generic_2.6.20-15.24_amd64.deb
<BenC> kylem: http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<BenC> s/kylem/Keybuk/
<Keybuk> desrt: I think I have busy week, quiet week, week on a plane, week in spain
<desrt> BenC; i have an amd64 desktop... should i be testing?
<Keybuk> (ooh, that rimes)
<BenC> Keybuk: Can you test the kernel there please?
<danielk> works!
<BenC> desrt: yes please
<dholbach> danielk: ROCK!
<Keybuk> BenC: downloading; what am I looking for?
<desrt> Keybuk; how poetic.  you could be the next dr. seuss :)
<cjwatson> accelerating the publisher now
<BenC> Keybuk: that it boots :)
<danielk> dholbach: yay!
* dholbach hugs danielk
<Keybuk> BenC: so keep a spare kernel around, eh?
<dholbach> danielk: thanks a lot for testing!
<kylem> now i just need l-r-m... :P
<desrt> Keybuk; just make sure the spare one isn't -14 :)
* dholbach hugs kylem and BenC
<kylem> :)
<BenC> danielk: works for you?
<danielk> BenC: yup
<dholbach> BenC: <danielk> works!
<cjwatson> l-r-m is publishing for amd64 right now
<desrt> ubuntu is rather full of huggers.
<dholbach> :-D
<cjwatson> i386 should be next cycle
<BenC> danielk: excellent, thanks
<mvo> kylem: you need someone with a sata_nv?
<danielk> thanks a lot
<BenC> mvo: the more sata_nv testing the better
<mjg59> Excellent.
<mjg59> We've had the kernel panic almost a week before release
<mjg59> That's far better than usual
<Keybuk> desrt: hugging rocks
<desrt> my laptop still kernel panics on boot about 50% of the time due to that io-apic bug...
<mvo>  http://people.ubuntu.com/~bcollins/kernels/feisty-release/ ? 
<dholbach> mvo: yes
<dholbach> mvo: 5d86d7f2b81fbe886225838a12440fe1  linux-image-2.6.20-15-generic_2.6.20-15.24_amd64.deb
<BenC> mvo: Yes, i386 will be there soon if you need it
<dholbach> ok, so when are new cds ready? :-)
<mvo> BenC: amd64 is what I need
* mvo downloads
<danielk> bye everyone
<dholbach> danielk: have a nice evening!
<kylem> danielk, thanks for your help
<BenC> 630d17875bafda11e8c23edea56bd29f  linux-image-2.6.20-15-generic_2.6.20-15.24_i386.deb
<danielk> dholbach: c'ya tomorrow!
<BenC> uploading now
<dholbach> danielk: yeah, see you
<Keybuk> ok, rebooting now
<danielk> kylem: you're welcome
<Keybuk> if I'm not back within 30s, assume the worst and send jaffa cakes
<danielk> later
<heno> doko: right, I could post it but it would be marked inactive anyway; waiting for new images
<dholbach> jaffa cakes *shudder*
<doko> dholbach: what about pizza tonight?
<dholbach> doko: I had pizza for lunch already :-)
<Treenaks> dholbach: more pizza!
<dholbach> hehe
* kylem ponders pizza
<desrt> BenC; life is good on -15
<BenC> desrt: thanks
<desrt> want a dmesg or anything?
<desrt> (this box has 3 serial ata HDs, btw.. and no CD drive)
<kylem> desrt, could you toss me a dmesg?
<ogra> doko, i'll take a pizza, when do you deliver it ? 
<desrt> http://desrt.mcmaster.ca/random/linux-image-2.6.20-15-generic_2.6.20-15.24_i386-dmesg
<Keybuk> BenC: repeat after me, "next time I give someone a new kernel ABI, I will also give them a restricted modules to go with it" <g>
<ogra> doko, btw what about the frmabuffer prob you had with the edubuntu DVD ? is that still there ? 
<BenC> Keybuk: it's in the archive :P
<pitti> Keybuk: lrm for amd64 is built
<Treenaks> ogra: doko.. on a scooter.. delivering pizza throughout Germany?
<desrt> Keybuk; but a new computer :p
<desrt> *buy
<Keybuk> desrt: I'm extremely happy with this one ... I can set the prettyness in games to 11
<desrt> nvidia, eh?
<ogra> Treenaks, only 350km :)
<doko> ogra: yes, but it may be my graphics card. Radeon 9600 based
<ogra> ok
<ogra> you just didnt mention it anymore so i thought i'd ask again :)
<cjwatson> lrm for amd64 is built but is still publishing
<cjwatson> should be available shortlty
<Keybuk> cjwatson, benc: booted ok with sata_nv other than missing X :)
<BenC> Keybuk: great, thanks
<Keybuk> did you want the dmesg or anything?
* mvo reboots for new kernel love
<BenC> Keybuk: if you could pastebin it, that'd be great
<Keybuk> http://people.ubuntu.com/~scott/dmesg
* desrt has idea for feisty+1 spec
<desrt> 64bit kernel + 32bit user
<BenC> Keybuk: perfect, thanks again
<desrt> we could probably do it practically for free....
<BenC> desrt: We've thought about that, but there's not a lot of testing with 32->64-bit thunking on x86-64
<BenC> we may be missing some functionality because of it
<desrt> ah
<BenC> last I checked usb-printing was borked
<BenC> but it's been a long time since then
<desrt> usbdevfs uses a different interface on 32 and 64?
<desrt> eugh
<mvo> BenC: kernel boots fine for me. you want a dmesg output or something?
<kylem> netfilter is kind of borked for 32->64.
<BenC> desrt: No, same interface, but ioctl's have to be translated when userspace and kernel don't match
* cjwatson adds more hamsters to the publisher
<mvo> usplash looks funny though, but that may as well be my gfx card dying (ancient ati)
<kylem> it's also a royal pain in the god damned arse to debug.
<desrt> BenC; ah.  this is true.
<cjwatson> I know this kernel stuff has been a fun ride, but I can't believe the recent changes would affect usplash
<kylem> mvo, 'funny'?
<Treenaks> kylem: smiley faces, etc.
<mvo> kylem: sort of flickery, in the background, makes my eyes hurt. but once gdm is up, everything is fine again
<kylem> weird.
<cjwatson> the ATI card in my laptop fails to get set up correctly once every so often, and flickers madly until you change video mode
<mvo> I have not seen that before, but I doubt that its releated to the kernel, I rarely watch my system booting
<cjwatson> sometimes even that doesn't sort it out and I need a suspend/resume cycle to do it
<BenC> happens in my powerbook a lot
* Treenaks won't start about _his_ ATI card :)
<Treenaks> kylem: (bug 20283 if you really want to know)
<ubotu> Malone bug 20283 in xserver-xorg-video-ati "[X700]  Really bad sync on HP NW8240" [Medium,Confirmed]  https://launchpad.net/bugs/20283
<cjwatson> used to be about one time in four, I think not so much recently
<kylem> hmm
<BenC> cjwatson: any ETA for the 386 build, so I don't have to run this command every 2 minutes? :)
<cjwatson> BenC: it's in the final stages - maybe five-ten minutes
<cjwatson> ia64 is still missing
<cjwatson> happy with you abi-ignoring that if the other arches are clean
<cjwatson> though the build looks not a million miles from finishing
<dholbach> brb
<cjwatson> publisher> running germinate
<mdz> er, I just noticed that my root filesystem is not in mtab on my laptop
<mdz> I wonder when that happened
<mdz> need to reboot to test the new kernel anyway, will find out if it's persistent
<mdz> brb
<cjwatson> BenC: done, modulo mirroring
<BenC> cjwatson: is there a place I can get to it from rookery?
<dholbach> -15 is happy on both my i386s (was happy there before too)
<cjwatson> BenC: by the time you set anything complicated up, it'll have mirrored to archive.ubuntu.com
<BenC> dholbach: great, thanks
<BenC> cjwatson: ok, thanks
<dholbach> np
<cjwatson> the linux-headers package is up, it's obviously in the middle of it
<BenC> ah, grabbing it now
<cjwatson> there it is
<cjwatson> may depend on which mirror you hit, try again in a bit if it fails
<mdz> BenC: the i386 kernel whose md5sum you posted looks OK here
<mdz> BenC: are you soliciting dmesgs?
<BenC> mdz:  If you don't mind, please
<jwendell> seb128, Hi
<desrt> i386 -15 is up?
<rpereira> Does someone have problems too with Atheros AR5002 and network-manager?
<jwendell> seb128, any reason to not update libnotify and notification-daemon to latest version? They're available since Feb 27
<mdz> BenC: people.ubuntu.com/~mdz/temp/dmesg
<cjwatson> desrt: yes, though not the sata_nv fix yet
<dholbach> jwendell: we're 6 days away from release
<kylem> [    4.152000]  BEN: Called!!
<kylem> [    4.152000]  BEN: Left, 1, 0
<kylem> ;-)
<cjwatson> I was about to comment on that too
<desrt> cjwatson; that's fine.  intel chipset here :)
<BenC> mdz: Ah, that's an outdated kernel...can you grab the current one?
<cjwatson> I assume you're taking those out for upload? :)
<BenC> I don't suspect any problems, so it's not necessary
<mdz> BenC: that's odd, the changelog looks correct
<mdz> linux-source-2.6.20 (2.6.20-15.24) feisty; urgency=low
<mdz>   [Ben Collins] 
<mdz>   * libata: Re-add the tracking of n_sectors_boot
<mdz>     - GIT-SHA 1fa3ab07416406841cc1c7064b55fb084bbb1e3f
<mdz>   * i2c_ec: Do not set parent device. Current ACPI is not setup for this.
<mdz>     - GIT-SHA d80fb3540d170f18639c08f64afd133129bed856
<mdz>     - Bug #96480
<ubotu> Malone bug 96480 in linux-source-2.6.20 "Kernel 2.6.20-13 acpi bug" [Critical,Fix committed]  https://launchpad.net/bugs/96480
<mdz>   [Upstream Kernel Changes] 
<mdz>   * 2.6.21 fix lba48 bug in libata fill_result_tf()
<mdz>  -- Ben Collins <bcollins@ubuntu.com>  Thu, 12 Apr 2007 18:58:24 -0400
<BenC> mdz: that was a mid testing build
<BenC> mdz: the first i386 build I did was bogus, you must have grabbed it first
<cjwatson> Keybuk: heh, if you boot into recovery mode, bootchart sits spinning on sleep 0.2 ...
<mdz> BenC: where's the new one?
<jwendell> dholbach, i know, i asked just because since it was release, we had a lot of time to put it into feisty
<dholbach> jwendell: seems it went unnoticed
<BenC> mdz: same location
<BenC> 630d17875bafda11e8c23edea56bd29f  linux-image-2.6.20-15-generic_2.6.20-15.24_i386.deb
<BenC> there's the right md5sum
<mdz> BenC: I don't have the URL anymore because I rebooted...
* desrt reboots to test that now
<BenC> mdz: people.u.c/~bcollins/kernels/feisty-release/
<mdz> BenC: that's the same one I had before
<mdz> same md5sum
<mdz> 630d17875bafda11e8c23edea56bd29f  linux-image-2.6.20-15-generic_2.6.20-15.24_i386.deb
<BenC> mdz: let me check the bins...
<desrt> BenC; -15-generic-i386 works on 1st gen macbook
<desrt> dmesg?
<BenC> desrt: not with the 386 that you have
<BenC> 5d86d7f2b81fbe886225838a12440fe1  linux-image-2.6.20-15-generic_2.6.20-15.24_amd64.deb
<BenC> there's the right one, uploading
<BenC> sorry about that
<BenC> damn...that's amd64
<desrt> BenC; i have the i386 md5 630d17875bafda11e8c23edea56bd29f
<desrt> from like 30 seconds ago :p
<Treenaks> 
<desrt> arf.  no -headers package -> no madwifi
* desrt plugs in
<BenC> Ah, ok, that build is good
<BenC> it's all goodness
<desrt> awesome.  it works. :)
<desrt> don't suppose you have a matching -headers for it? :)
<BenC> there's no self printk's in the uploaded source though
<BenC> desrt: Not yet :)
<BenC> desrt: the headers in the archive should be good for it
<desrt> cool.
<desrt> today i go down to the coffee shop that always makes my laptop crash
<desrt> and find out why
* desrt snags a copy of networkmanager source...
<fabbione> desrt: your eyes will bleed.. don't :)
<desrt> fabbione; i suspect that it might be the easiest place for a workaround :p
* desrt bets that sleep(5) between networkmanager seeing the network and requesting the association fixes the crash
<BenC> Mithrandir, mdz, cjwatson: uploaded
<mdz> BenC: to the archive?
<BenC> mdz: yes
<Treenaks> <desrt> 'AARGH MY EYES' <coffee shop owner> Why? <desrt> Your AP breaks my Ubuntu and now I have to read networkmanager source <owner> I'll buy another ap if you stop bleeding on my stuff
<mdz> BenC: do you have a debdiff?
<BenC> And if anyone else has a showstopping kernel bug, please give me at least 2 hours :)
<BenC> mdz: I already sent it to you
<Treenaks> BenC: smart batteries? (or are they fixed too? :)
<mdz> hasn't come in yet
<BenC> mdz: Other than the ABI files, and debian/changelog, you have the idff
<mdz> by email?
<mjg59> Treenaks: Fixed
<Treenaks> mjg59, BenC: \o/
<fabbione> BenC: me wants ocfs2 crack :P
<BenC> mdz: http://people.ubuntu.com/~bcollins/libata.diff
<mjg59> Treenaks: Should be, anyway
<Treenaks> mjg59: (yay for acer laptops... *sigh*)
<zul> fabbione: no you just want crack
<mjg59> Treenaks: It's hard to tell, none of us have affected hardware
<fabbione> zul: point..
<Treenaks> mjg59: I do, but it's on edgy atm
<Treenaks> I could upgrade..
<mdz> never mind, I'll generate one
<mdz> it's important to review the exact diff used in the upload, even if we think we know what went into it
<BenC> mdz: I just diff'd the tags from my upload, I've no other way to get a diff quickly
<mdz> BenC: I'll pull one from the upload and put it up
<mdz> http://people.ubuntu.com/~mdz/temp/2.6.20-15.25.diff
<fabbione> 403
<desrt> mdz; 403
<cjwatson> I've read through it independently (mdebdiff from what's in the queue), but it matches what I understood to be in the upload
<mdz> fixed
<mdz> cjwatson: neat, didn't know about mdebdiff
<fabbione> is mdebdiff something running on dresher?
<fabbione> there is no such thing in the archive
<cjwatson> yes
<fabbione> ok
<cjwatson> it's a script that combines debdiff with madison-lite (aliased to m on drescher)
<mdz> diff is OK with me
<cjwatson> palmer's nearly finished with l-r-m/i386
<glick> hmmm pymedia isnt included in ubuntu repos :/
<mdz> cjwatson: so you'll accept l-m along with the new l-s?
<cjwatson> yeah
<glick> hmm maybe ill maintain that package
<glick> package it up
<glick> bring it into ubuntu repos
<cjwatson> publisher running
<fabbione> cjwatson: thanks
<BenC> cjwatson: gracias...lets go grab a beer
<desrt> wow.  that bug on launchpad is getting interesting
<glick> anyone heard of pymedia?
<desrt> people are starting to swear and call each other names
<kylem> BenC, everything look ok?
<BenC> kylem: looks good to me
<BenC> kylem: thanks
<mjg59> desrt: Which one?
<kylem> ok cool
<kylem> pizza time
<glick> whats the channel for ubuntu motu?
<kylem> #ubuntu-motu
<glick> thanks
<kylem> welcome.
<desrt> \
<desrt> mjg59; https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106063
<ubotu> Malone bug 106063 in linux-source-2.6.20 "MASTER: Computer will not boot after 2.6.20-14.23 kernel upgrade" [Critical,Fix committed]  
<desrt> "The" bug
<theCore> BenC: was there a problem with today's kernel?
<desrt> theCore; heh.
<mvo_> lol
<kylem> haha.
<theCore> uh?
<desrt> theCore; yes.  a rather large problem.
<theCore> ah
<desrt> theCore; fixed now, though.. and building.
<theCore> W: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.20/linux-image-2.6.20-14-generic_2.6.20-14.23_i386.deb
<theCore>   403 Forbidden [IP: 91.189.89.6 80] 
<desrt> theCore; that's the broken one
<desrt> theCore; it's forbidden for your own protection :)
<theCore> so that explains this :) 
<doko> seb128, dholbach: python-gst (universe) currently FTBFS, no rdeps and build-deps. ok to remove from feisty?
<theCore> any link to the bug?  
<desrt> theCore; i just pasted it up there ^^
<theCore> ah
<theCore> thanks desrt
<desrt> no prob.
<theCore> ouch, there is some angry complains on this bug report 
<doko_> seb128, dholbach: python-gst (universe) currently FTBFS, no rdeps and build-deps. ok to remove from feisty?
<seb128> doko_: yep
<doko_> seb128: want a bug report?
<seb128> yes
<seb128> or don't bother
<seb128> I'll do it now
<seb128> there is python-gst0.10 now anyway
<doko_> seb128: bug 106304
<ubotu> Malone bug 106304 in gst-python "please remove the gst-python source and binaries from feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106304
<seb128> doko_: ok
<Kmos> BenC: you sent that ata fix to kernel.org people ?
<cjwatson>   * libata: Re-add the tracking of n_sectors_boot
<cjwatson> that was syncing up with patches discussed upstream
<cjwatson>   * 2.6.21 fix lba48 bug in libata fill_result_tf()
<cjwatson> that was an upstream change to start with
<Kmos> :-)
<Kmos> ha
<Kmos> its been uploaded to archive ?
<cjwatson> and Kyle sent a better version of the sata_nv patch in -15.25 upstream; the patch as uploaded just reverted an earlier upstream change for the time beeing
<cjwatson> being
<cjwatson> ok, so the current state is:
<kylem> we're all groovy.
<kylem> :)
<cjwatson> -15.24 is in the archive and built everywhere
<cjwatson> except possibly ia64, and if not that's on its way
<cjwatson> -15.24 should work for everyone except people using sata_nv
<cjwatson> for sata_nv, -15.25 has been uploaded
<Kmos> nice
<Kmos> thx for the info
<cjwatson> but it has not yet built
<cjwatson> (in progress, hamsters running as fast as they can)
<cjwatson> so sata_nv users should stay on -13 until -15.25 is available, and everyone else should use -15.24
<cjwatson> and REPORT REGRESSIONS ASAP
<Kmos> :)
<theCore> I am sure everyone loves this crazy Friday 13th. 
<Seveas> cjwatson, maybe they'd run faster if someone would feed them steroids ;)
<radevil> hello
<radevil> does anybody in here work for canonical???
<Kmos> I think a lot :)
<radevil> yes? :)
<radevil> i found the employment web page in ubuntu site
<radevil> i'm interested in a position for server developer
<cjwatson> the employment page has an address for applications
<cjwatson> we don't really take applications by IRC ;-)
<radevil> i already made a CV and i'm making a cover letter, it's hard for me to make such a formal letter in english
<radevil> so i wanted to konw if  i can speak with somebody in here directly
<radevil> know*
<fdoving> isn't there #canonical ? 
<radevil> i don't know i don't want to mess it up sending a cover letter full of errors :P
<cjwatson> fdoving: not on a public server
<radevil> mmm i don't know i'll try it
<fdoving> cjwatson: ok.
<cjwatson> and when it was it was passworded
<radevil> [#canonical]  CHANNEL HAS MOVED 
<radevil> do you guys work from your houses?????
<cjwatson> radevil: we understand that some people's English is not 100%, and it's OK to note that
<cjwatson> most Canonical-employed Ubuntu developers work from home, though not quite all
<cjwatson> generally that's the expectation for new staff
<radevil> is it a full time job??
<cjwatson> yes
<theCore> radevil: I think they look more at your competences and accomplishment than you English mistakes  
<cjwatson>    Strong English language communication skills, especially in online environments such as mailing lists and IRC
<cjwatson> you do need to be able to get by pretty well
<cjwatson> though that's not the same thing as being able to compose formal letters
<theCore> bah.... I even made two mistakes saying that ...
<cjwatson> being able to communiate effectively on a day-to-day basis is the important bit, really
<cjwatson> disclaimer: I am a hiring manager at Canonical, but I am not the hiring manager for the server positions
<radevil> ohh )
<radevil> :)
<cjwatson> if you want help with your covering letter or CV, I think it would be better to find help locally than to look for somebody from Canonical to do it
<theCore> cjwatson: hire me! :)
<cjwatson> in some ways it's a bit pointless to look for help from employees of the company you're applying to with regard to the impression you're making on that company :-)
<radevil> lol yes
<theCore> (just joking)
<radevil> cjwatson: can i make you a few questions??
<cjwatson> radevil: it's off-topic for this channel, but you can ask me in private
<radevil> ohh ok, i'll pm you
<doko> Mithrandir: I'd like to update gcc-snapshot again to fix the i386 build failure, but I'm worried about build times; would it be ok to upload tomorrow when the kernel packages are built?
<Solarion> how hard would it be to implement a GUI for user ulimits?
<Solarion> [e.g. have gdm, login, ssh, etc. set ulimits when user logs in] 
<ajmitch> morning
<Solarion> that easy, eh?
<Mithrandir> seb128: X-Ubuntu-Desktop-Domain> IMO too late.
<fryfrog> i hate to bug the devs, but i'm having some trouble with the *new* kernel and I think I saw someone talking about a work around earlier.  It was I *think* a kernel arg to disable "hpa" of some sorts, but I don't recall what it was.  Does anyone know, or is there a log of the channel somewhere?
<seb128> Mithrandir: yeah, we decided to not do the change
<Seveas> fryfrog, /join #ubuntu+1 and read the topic
<mc44> Seveas: he meanwithhhhhhh1
<mc44> oops
<fryfrog> i'm talking about the new "fix" kernel -15
<mc44> Seveas: he means with -15
<Seveas> fryfrog, *new* isn't really specific when there's 3 revisions you can refer to as new :)
<fryfrog> ah, sorry :)
<fryfrog> i should have specified :)
<fryfrog> does "n_sectors mismatch" ring a bell?
<Seveas> fryfrog, https://launchpad.net/ubuntu/feisty/+source/linux-source-2.6.20/2.6.20-15.24
<Seveas> fryfrog, which by the way is not the latest kernel
<Seveas> (or is it, me is very confused about kernels today)
<mc44> yeah its not -15.24 yet
<Seveas> .25 is latest
<mc44> the ones in the repos are .14, right
<jdong> repos are still -14....
<jdong> at least as of 25 minutes ago
<fryfrog> so i should just hang in there then?
<mc44> jdong: they are -15.14 for me
<fryfrog> i'm booting to my gentoo livecd so i can chroot into it
<jdong>   Candidate: 2.6.20.15.14
<jdong> ah yes
<jdong> new apt-get update shows that
<jdong> also the fact I'm on the ANL mirror doesn't help with my updatedness :D
<fryfrog> humm, i can't find a boot kernel option to disable hpa
<kylem> libata.ignore_hpa=1
<fryfrog> ahhh!
<fryfrog> thankyou :)
<fryfrog> that is what i was looking for
<jdong> aah the whole internet's slow today :D
<kylem> fryfrog, can you please pastebot your dmesg for me?
<fryfrog> sure, once i'm into a networkable place i can get it :)
<kylem> ok
<fryfrog> is it okay that it will be with the ignore_hpa=1 option
<fryfrog> ?
<fryfrog> crap, that didn't do it, did i typo something?
<kylem> no. i need to see the mismatch messages
<fryfrog> ah, sure i can just do that from teh typing skills
<kylem> you included the libata. part right?
* ajmitch waits for -15.25 to arrive to test for regressions
<fryfrog> ata1.00: n_sectors mismatch 150994954 != 15630488
<ajmitch> though I think I have an identical mb to you, kylem 
<fryfrog> revalidation failed
<fryfrog> disabled
<fryfrog> yeah, i'm checking for typos now
<pkl_>  libata: Completely avoid HPA code paths when ignore_hpa=0 ?
<fryfrog> its okay for it to be "ro libata.ignore_hpa-1 single" right?
<fryfrog> i mean, the order of "ro" and "single" and libata.ignore_hpa=1" doesn't matter
<fryfrog> er, that was a = not -, dang laptop kb
<kylem> fryfrog, there should be a line above that says ata_hpa_resize 1, can you copy that line too?
<fryfrog> sure
<fryfrog> ata_hpa_resize 1: sectors = 156299375, hpa_sectors = 156301488
<fryfrog> want the "current size" and "native size"?
<kylem> yeah
<fryfrog> current size : 156299375 sectors (80025 MB)
<fryfrog> native size : 156301488 sectors (80026 MB)
<fryfrog> then it says native size increased to 150994954 sectors
<fryfrog> blech, i wish i could copy/paste it :/
<fryfrog> wonder if i can mount an nfs share
<kylem> what chipset?
<fryfrog> pata_amd
<fryfrog> er, well that is the driver
<kylem> ok
<fryfrog> i believe it is an nforce4 on it's PATA port
<fryfrog> er, -believe
<fryfrog> i know :)
<fryfrog> the "libata.ignore_hpa=1" doesn't change anything (nor does =0)
<kylem> hrm.
<fryfrog> got my myth backend working, now the fe is busted! :)
<fryfrog> i could provide a booted with gentoo livecd, but i dont think that'd help :(
<fryfrog> i mean, access to it
<kylem> got a digital camera?
<fryfrog> sure, want a pic of the section?
<kylem> yes, very much thank you
<fryfrog> just the part around the ata error?
<kylem> if possible the whole section where you see disks detected, lines beginning with atax.x: especially
<fryfrog> ok
<fryfrog> i forgot to check if my webserver had come back after the feisty update :)
<kylem> are you running i386-generic?
<fryfrog> "-generic" (not amd64)
<kylem> i mistakenly thought 15.25 was in the archive already, but i was wrong. the ignore_hpa thing was added there.
<kylem> http://people.ubuntu.com/~bcollins/kernels/feisty-release/linux-image-2.6.20-15-generic_2.6.20-15.24_i386.deb
<kylem> this should help.
<fryfrog> http://fryfrog.com/wordpress/v/MaryAnn-Donnie/Donnie/Test/
<fryfrog> ahhh
<kylem> thanks, looking
<fryfrog> its a pretty crappy monitor :)
<fryfrog> ah, but not to bad i can read it :)
<Stormx2> Hey. Wouldn't it be possible to have concurrent connections in apt-get update? I'm pretty sure it does the package lists 1-by-1, even if they are on seperate servers
<fryfrog> i think "aptitude update" must do them concurrently
<fryfrog> maybe?
<fryfrog> maybe not
#ubuntu-devel 2007-04-14
<geser> apt-get uses only one connection per server, if you have several servers configured apt-get fetches the lists in parallel
<fryfrog> kylem: those screenshots provide anything useful?
<kylem> sort of :)
<fryfrog> would it be helpful for me to test that -15.24 kernel?
<kylem> yeah
<fryfrog> okay, lemme go down and get onto the live cd again :)
<fryfrog> kylem: should i feed this one the ignore_hpa=1 option?  or try w/o?
<kylem> please try both, but it's ignore_hpa=0 (1 is the default)
<fryfrog> ahhhh
<fryfrog> seems like "ignore_hpa=1" would turn ignore on
<fryfrog> but i'll try both :)
<fryfrog> any preference on which one first?
<kylem> nope.
<fryfrog> that worked, both with the =1 and =0
<fryfrog> would you like the dmesg from both?  i've saved them if you like
<kylem> yes. please.
<fryfrog> !pastebin
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<fryfrog> http://paste.ubuntu-nl.org/15445/ (hpa=0)
<fryfrog> http://paste.ubuntu-nl.org/15446/ (hpa=1)
<fryfrog> currently, it is booted w/o any kernel args, into "nomral" mode
<fryfrog> and working fine :)
<kylem> er. you didn't specify either of them?
<kylem> bizarre.
<fryfrog> yeah, on the 3rd (final) boot
<kylem> but it booted on all 3?
<kylem> interesting, heh.
<kylem> thanks for your time
<fryfrog> yup
<kylem> :)
<fryfrog> np, i prefer to at least provide some guinne pig when i can :)
<fryfrog> guinnea?
<fryfrog> well, you know
* kylem nods.
<fryfrog> I see what looks like some debug msgs left by "BEN" maybe :)
<kylem> yeah those are fixed in the version in the archive :)
<fryfrog> i'm not super hacker, but it seems like hpa was simply disabled for this entirely
<fryfrog> silly question, would using that kernel .deb make the l-r-m modules not work?  i'm quite sure the answer is yes
<kylem> fryfrog, yeah.
<fryfrog> kk
<fryfrog> but the -15.25 is soon-to-join the repos, right?
<kylem> when the version hits the archive, everything shouldbe groovy though.
<fryfrog> (along with all the stuff it goes with)
<fryfrog> kk
<kylem> fryfrog, i already see it for amd64, i386 should be a little while.
<fryfrog> ah, sweet
<fryfrog> i appreciate all your help :)
<kylem> np. s'what i'm hear for. :)
<fryfrog> i think i am seeing the -15.24 in dist-upgrade, i thought it was going to be -15.25?
<kylem> it will be
<fryfrog> at least, dist upgrade is offering to update it
<kylem> must not be in the archive yet
<fryfrog> and aptitude show gives it as -15.24
<cjwatson> -15.25 isn't finished for i386 yet
<cjwatson> https://launchpad.net/+builds/vernadsky
<fryfrog> is there a -15.24 in the repos?
<fryfrog> i don't see it on one box
<cjwatson> yes, for i386
<fryfrog> but on the other, it thinks there is :/
<fryfrog> ah
<cjwatson> for amd64 you should see -15.25
<cjwatson> we're in the middle of the -15.25 build cycle and pedalling as fast as possible
* cjwatson starts another publisher run for -15.25/sparc and a load of language packs
<fryfrog> ah, it must be picking it up because i installed the .deb that kylem showed me
<kylem> ... sparc beat i386? :)
<fryfrog> my other box sees the -15.24, but isn't trying to install it
<cjwatson> kylem: fewer flavours
<cjwatson> i386 tends to be late
<kylem> true
<cjwatson> 386, generic, server, server-bigiron, lowlatency, and any I forgot
<Kmos> why it take so long to build it ?
<Kmos> 3 hours..
<kylem> lowlatency of all the flavours, no?
<cjwatson> Kmos: it's not running on the fastest available box
<cjwatson> kylem: don't think so
<Kmos> cjwatson :-(
<cjwatson> Kmos: which is my fault, I forgot to page a buildd admin to set that up
<cjwatson> faster to just leave it going now
<Kmos> yeah
<cjwatson> but it does always take a while, it's doing five kernel builds from scratch
<Kmos> what machine is it ? very slowly..
<Kmos> it's on the launchpad machine'
<Kmos> ?
<cjwatson> I can't remember if ccache is involved but ISTR it doesn't help much because there are so many different packages going through that the ccache tends not to be live
<cjwatson> it's one of the i386 buildds
<cjwatson> I don't really think it's doing all that disgracefully badly considering that there are five kernel builds to do in that time
<cjwatson> with full module sets for each
<cjwatson> it'll get there, no point worrying about it now
<kylem> probably doesn't have CONCURRENCY_LEVEL set either.
<cjwatson> it should do
<kylem> ah. that's good then.
<cjwatson> that's done automatically by the kernel's debian/rules if /CurrentlyBuilding exists which it should do on the buildds
<Kmos> tomorrow is done =)
<Kmos> lol
<cjwatson> you're not really helping
<Kmos> i would like to..
<Kmos> :)
<fryfrog> 18:29 -!- jdong [n=jdong@ubuntu/member/jdong]  has quit ["FCKGW-RHQQ2-YXRKT-8TG6W-2B7Q8"] 
<fryfrog> i noticed that earlier... that looks like an XP key :p
<Kmos> yeah
<cjwatson> mjg59: bug 106328 is a regression introduced by your most recent upload
<ubotu> Malone bug 106328 in hotkey-setup "dell.hk: line 21: setkeycode: command not found" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106328
<cjwatson> Mithrandir: ^--
<cjwatson> I'm going to fix that since it looks trivial to do so
<cjwatson> -setkeycode     e06d    $KEY_MEDIA      # (Inspiron)    Media (e06d)
<cjwatson> +setkeycodes    e06d    $KEY_MEDIA      # (Inspiron)    Media (e06d)
<fryfrog> wow, +s is simple
<Kmos> cjwatson: that's an easy fix =)
* Kmos downloading trought update-manager kernel .24
<mjg59> cjwatson: Aw, feck :( Sorry!
<mjg59> Thanks for the fix
<conn> hi mjg59, re: bug 103768 with network-manager and softmac drivers, did you identify where the problem is in nm/wpasupplicant? I read on the zd1211rw page of known issues that the interface needs to be brought up "ifconfig eth1 up" before sending commands, perhaps that's a quirk with softmac drivers?
<ubotu> Malone bug 103768 in linux-source-2.6.20 "softmac and network-manager cite unreconcilable differences" [Critical,Unconfirmed]  https://launchpad.net/bugs/103768
<conn> it's certainly an issue on my systems, tested on two separate pcs running feisty and tested with two different zd1211-based cards
<mjg59> I'm still looking into it
<conn> alright, thanks. It'd be nice to get this fix in before the final release, I'll be happy to contribute towards troubleshooting etc. to make it happen
<mjg59> conn: Right now it seems like I'm the only person working on it
<mjg59> My time is a bit limited, but I think I have a vague handle on what the problem is
<mjg59> The issue is finding a way of fixing it without interfering with other drivers
<mjg59> Can't absolutely promise anything, but I'm still working on it
<conn> I'll do some testing on my systems and if I find anything useful, I'll add to the bug. I just couldn't find where NetworkManager sets the ESSID, keys etc via wpasupplicant.
<conn> hmm I don't mean to pressure you at all, of course :). And I appreciate the work all of you are doing, heh ;)
<pochu> mjg59: n-m from p.u.c/~scott/packages works better than ever :-) It now starts connected if I'm connected to the wired network (before upgrading, it didn't start connected). And now I can connect to my wpa wireless network (I'm there atm) but with the previous version I had problems to do it :)
<pochu> mjg59: I'm here because the mail to u-d would get moderated :)
<pochu> btw, does liferea works fine for you? :)
<mjg59> Liferea seems fine for me
<pochu> Cool :) Though there seems to be a little problems with it for other people :-/
<cjwatson> wow, building a full set of all language packs really does take quite a while
<pochu> What about an i386 kernel in a slow machine? :p
<pochu> mjg59: btw, did you forget to set an Ubuntu Maintainer? ;)
<cjwatson> it'll probably still be done before the 300+ other needs-build items for i386
<cjwatson> it's all still churning, just taking a while
<poningru> halp
<poningru> who was it that packaged beryl?
<poningru> do users with ati or intel graphics still have to add stuff to their xorg.conf?
<cjwatson> oho, kernel seems to be into binary stage finally
<cjwatson> amd64 and powerpc have quiesced
<mjg59> pochu: No, I upload stuff under my own address
<mjg59> It's likely to carry on working longer than my @ubuntu one :)
<pochu> +Maintainer: Riccardo Setti <giskard@debian.org>
<pochu> dpkg-buildpackage complained because there wasn't an Ubuntu address there ;)
<mjg59> Which package was that?
<cjwatson> it only complains if your own DEBEMAIL is @ubuntu.com
<pochu> http://people.ubuntu.com/~scott/packages/network-manager_0.6.4-6ubuntu7.diff.gz
<cjwatson> or rather =~ /ubuntu/
<mjg59> pochu: I've never uploaded n-m
<pochu> ups, sorry
<pochu> mjg59: It was Keibuk :S
<mjg59> Scott is keybuk
<pochu> hehe
<cjwatson> sorry, it only fatally complains if DEBEMAIL =~ /ubuntu/. It does warn otherwise but you can ignore ittt
<cjwatson> it
* pochu really needs to sleep :)
<pochu> my DEBEMAIL is pochu@ubuntu.com, so maybe that's why I had to change it
<cjwatson> people with DEBEMAIL =~ /ubuntu/ are responsible for handling it; others are not
<pochu> then I assume the responsability :)
<cjwatson> I'm not convinced it's an ideal heuristic but it's what we have
<pochu> It's better than nothing, isn't it? ;)
<pochu> mjg59: Sorry for bothering you, I'm going to sleep right now :)
<pochu> Have a nice weekend!
<mjg59> Night!
<cjwatson> sparc has quiesced
<cjwatson> as has ia64, so it's just the i386 backlog left
<BenC> cjwatson: any plans to update the i386 buildd?
<cjwatson> BenC: if it had hit palmer, it'd be fine - my fault
<cjwatson> don't know about vernadsky upgrade plans
<kylem> heh
<cjwatson> argh, how many times does the kernel build hit stamp-build-kernel anyway?
<BenC> pretty sure we could acquire a dual quad-core pretty easily
<BenC> cjwatson: blame make-kpkg :/
<BenC> well, blame it now, because it wont be blamed in gutsy
<ajmitch> anything specific that you want tested with latest kernel? just that it boots?
<BenC> ajmitch: make sure you test -15.25
<BenC> -15.24 is known broken on sata_nv
<ajmitch> yeah I've got that
<ajmitch> and I have sata_nv
* ajmitch is also testing lvm on raid
<BenC> basically that it boots and that your drive sizes look sane
<ajmitch> since it's been 2 months since I last rebooted :)
<BenC> hopefully you wont hit any problems, I think we're all out of fire extinguishers
<kylem> i'm wearing my asbestos vest today.
<ajmitch> I'll track down a dapper live cd in case
<cjwatson> dpkg-deb: building package `linux-headers-2.6.20-15-generic' in `../linux-headers-2.6.20-15-generic_2.6.20-15.25_i386.deb'.
<cjwatson> shouldn't be too long now
<BenC> yay
<cjwatson> unfortunately hotkey-setup/i386 is stuck behind all the language packs, so I have to wait for them all
<cjwatson> I'm unwilling to page any buildd admins at this time
<BenC> are the language packs quick?
<wasabi> evms' udev rules only running on dm-* and raid is a bit... annoying.
<wasabi> Any reason these don't run on any block device?
<cjwatson> BenC: individually, yes, but there are a lot of them
* ajmitch hopes he's safe rebooting with evms installed still
<BenC> cjwatson: would be nice if the "all" builds were load balanced :)
<cjwatson> the buildds are doing a couple a minute
<cjwatson> unfortunately historically arch-all binaries haven't necessarily actually *built* on all architectures
<BenC> but they all build on i386, right?
<cjwatson> yes
<cjwatson> because that's historically been the safe working assumption
<BenC> can you guys configure it to build on something else, for testing?
<kylem> can we get some kind of regexp for linux-source-* to only build on the fast one?
<cjwatson> probably, it would be nice to know what failed
<kylem> :P
<cjwatson> apparently tollef normally does it by temporarily turning off the other buildds and then massively scoring up linux-source-* ..
<cjwatson> hadn't realised it was quite that crude :)
<kylem> haha.
<ajmitch> alright, -15.25 working here with / on lvm on md on a sata_nv chipset
<cjwatson> nice
<kylem> thank fuck. :)
<ajmitch> I reckon :)
<mjg59> Once again, the glorious kernel team drag victory from the jaws of defeat
<cjwatson> in Soviet Russia, the kernel boots YOU
<cjwatson> into binary-udebs
<kylem> like a boot stamping on your face, forever.
<BenC> ajmitch: thanks
<poningru> ok submitting that to bash.org right now
<cjwatson> publishing i386 kernel
<kylem> \o/
<BenC> cjwatson: how much longer till you can get some sleep yourself?
<_lemsx1_> Failed to fetch MIRROR_HERE linux-source-2.6.20/linux-image-2.6.20-14-generic_2.6.20-14.23_i386.deb  403 Forbidden
<cjwatson> dunno yet, need to publish d-i and make sure that starts building and ideally start some livefs builds
<cjwatson> _lemsx1_: intentional
<_lemsx1_> any reason for this? i guess this is known
<_lemsx1_> cjwatson: ok. figures
<cjwatson> _lemsx1_: -15.25 kernel is publishing right now; use that when it's available
<cjwatson> should be about half an hour
<cjwatson> -14.23 broke booting for too many people
<ajmitch> far easier to deal with complaints about a forbidden file than unbootable systems
<_lemsx1_> cjwatson: ok. sounds good. perhaps that should be in the subject of this room ;-)
<ajmitch> it's in the topic in #ubuntu+1
<cjwatson> _lemsx1_: this isn't a help channel so I don't feel the need
<_lemsx1_> cjwatson: ok. i understand
<cjwatson> besides, it'll be irrelevant soon
<cjwatson> next publisher run after this, I'll remove the -14 kernels
<_lemsx1_> ajmitch: i didn't know there was #ubuntu+1 ... weird
<ajmitch> it's been around for a few releases
<_lemsx1_> ajmitch: i see... make sense. i never really venture into beta releases ;-) but Feisty is too tempting 
<BenC> cjwatson: it's like what, 3am there?
<BenC> cjwatson: you should get some rest dude
<_lemsx1_> BenC: rest or grab another beer and keep coding... ;-)
<BenC> if he was coding, it'd be different...he's just babysitting automated systems :)
<_lemsx1_> BenC: ahhh... those things take care of themselves ;-) then yeah, he should get some rest
<_lemsx1_> cjwatson: give me root and i'll watch them for you. go to sleep
<_lemsx1_> jeje!
<cjwatson> it's not entirely automated unfortunately - it's the CD builds I need to kick off at the appropriate time
<cjwatson> and I don't have enough info yet to predict a time for it
<_lemsx1_> cjwatson: ouch
<cjwatson> I'm basically dozing in the chair between events
<cjwatson> and keeping an eye out for regression reports
<_lemsx1_> cjwatson: i know exactly what you mean.... no more java there? grab a coke
<cjwatson> I have plenty of coffee, but I don't need to be alert at the moment, so I'd rather be able to sleep easily later
<cjwatson> one of these days, launchpad will be able to manage the whole process start to end for us
<cjwatson> but in the meantime there's enough stuff hooked up by spit and polish that it needs a bit more looking after if you want optimal output times
<_lemsx1_> cjwatson: launchpad is looking better by the minute. that's a very good collaboration site
<Solarion> so, I"m trying to squish a bug with the backlight not turning off when dpms is active.
<Solarion> Does HAL call /usr/share/acpi-support/screenblank on blanking
<mjg59> Many X drivers don't know how to do dpms properly
<Solarion> ?
<mjg59> No
<Solarion> This used to work, I'm pretty sure.
<mjg59> Hal doesn't trigger screen blanking
<Solarion> it's the free radeon.
<Solarion> hey mjg59.  :)
<mjg59> Hm. Ought to work, but entirely possible that something's broken
<Solarion> what could I use to ascertain brokenness?
<Solarion> Pretty sure this is new with feisty.
<Solarion> I'm willing to fix it, but I like to save power (and screen life) :)
<mjg59> How are you triggering dpms?
<_lemsx1_> pardon my interruption, but could DPMS (bugs) crash a system? I always try to turn that off in my PC. when it's on, the PC crashes at random times (when idle for a long time) and I'm not sure if it's DPMS or something else (power, heat, who knows)
<Solarion> xscreensaver and xset dpms force off
<mjg59> And they result in a black screen but the backlight still on?
<Solarion> yes
<mjg59> Almost certainly a radeon bug then, I'm afraid
<Solarion> I'll file it
<cjwatson> -15.25/i386 up and on all archive.ubuntu.com mirrors
<Solarion> mjg59: what could I do to help track it down?
<Solarion> mjg59: would it make a difference if driver is ati or radeon?
<mjg59> No, ati just loads radeon
<_lemsx1_> cjwatson: that's good news
<Solarion> is what I thought, but I wanted to check (there's some weird stuff floating around on the intarwebs around that)
<mjg59> I'm afraid I haven't done a great deal of work on radeon
<mjg59> The PM calls in the driver should be easy enough to find
<mjg59> Then it's a matter of figuring out what's different between them and feisty
<mjg59> Edgy, rather
<Solarion> hmm
<Solarion> so it's not a known problem
<mjg59> Not that I know of, though it's possible it is
<mjg59> I have no ATI machines here, sadly
<jdong> mjg59: honestly how is that sad? ;-)
<_ion> s/sadly/fortunately/
<Solarion> old ati cards are pretty nice.
<jdong> wow ATI jokes come fast :)
<jdong> Solarion: ah, that may be :) but you sure don't see many of those anymore :D
<Solarion> I would either buy a sufficiently old ATI or new Intel
<kylem> mjg59, except your MBP ;P
<mjg59> kylem: Ha. Yeah, but not useful in this case
<_ion> As soon as they release the source code to fglrx with a free license, i'm not going to do ATI jokes anymore. ;-)
<mjg59> Turns out that writing drivers from scratch tells you little about bugs in the old one
<kylem> mjg59, YET
<jdong> _ion: my LUNGS hurt from laughing
<mjg59> kylem: Dude, I'm running it. It's useful in that respect.
<kylem> mjg59, hehe.
<jdong> _ion: and my heart hurts too because I have a x1400...
<mjg59> Need to figure out why the latest changes break LVDS, and then I think we're heading towards being ready for an initial release
<kylem> mjg59, i need to go buy some hw and work on that.
<mjg59> Yeah, schedule should be a bit more empty for the next few weeks, I guess
<_lemsx1_> oh, i see, jokes about ATI are not offtopic... i guess we all just hate the stupid driver situation with them... ;-)
<mjg59> _lemsx1_: The driver situation is being worked on
<mjg59> We'll have something for gutsy
<_lemsx1_> mjg59: you are very optimistic 
<mjg59> _lemsx1_: I'm running an open driver on my r500
<Solarion> mjg59: are you an xorg hacker?
<mjg59> Solarion: I do a small amount of xorg work
<Solarion> bug #106414, if anyone cares
<ubotu> Malone bug 106414 in xserver-xorg-video-ati "[Feisty]  DPMS no longer switches off backlight on radeon" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106414
<jdong> mjg59: ooh very sweet
<mjg59> Right now it runs on a tiny subset of machines
<mjg59> And on everything else it probably melts your TFT
<mjg59> But there should be something useful soon
<mjg59> So, yeah, there's reason to be optimistic :)
<jdong> cool, I'm glad to hear that
<_lemsx1_> mjg59: most people with ATI want 2 things "games" and "aiglx/xgl"... open drivers usually give you some of those 2 things. closed source one gives you 1 at best (hint: not x effects for desktop use)
<kylem> some of us just want a dumb fb.
<jdong> _lemsx1_: heh I've been running fglrx with Xgl for a year now....
* cjwatson suspects mjg59 is familiar with the driver situation ;-)
<mjg59> xcompmgr makes a dumb fb surprisingly usable
<jdong> and it's been compizzing and beryling just fine
<Solarion> some of us want all of that and C3 states.  :(
<_lemsx1_> jdong: went back to the old driver didn't you?
<jdong> old driver?
<jdong> I'm using Feisty fglrx....
<jdong> with feisty Xgl
<jdong> Compiz works as-is in Xgl; Beryl requires the lupine repo 0.2.0
<_lemsx1_> jdong: i wonder how you accomplished that feast 
<jdong> _lemsx1_: on my card it didn't take any effort at all... but YMMV
<jdong> I find the world of fglrx to be really inconsistent from model to model
<_lemsx1_> jdong: what card is that?
<jdong> x1400 mobility
<jdong> I also walked an X800 (X700 maybe?) user through the same steps and it works fine for him too
<_lemsx1_> jdong: ah, i see... very recent stuff
<jdong> basically the beryl wiki procedure...
<jdong> yeah recent stuff
<kylem> eh? x800/700 is r300?
<jdong> I think that's highly relevant to the success rate
<kylem> why would you need to use fglrx...
<mjg59> Well, r400
<mjg59> But close enough
<jdong> kylem: IIRC he said it was glitchy with OSS drivers?
<kylem> mjg59, right
<jdong> wasn't my card :-/
<_lemsx1_> jdong: on every new release of drivers there is always a post on rage3d.com forums about missing xgl/aiglx ... nobody ever says it works for them
<jdong> heh
<_lemsx1_> jdong: i'm so fed up with it, that i don't care anymore ... 2D is fine for most things. 3D for what matters (some games)
<jdong> well Xgl is not exactly cake to set up for most people
<_lemsx1_> jdong: but you bet that i'm never buying an ATI (or recommending it)
<jdong> yeah on the forums I've definitely seeen people put up a fight with fglrx
* Solarion goes to bed
<jdong> _lemsx1_: likewise.... I only settled for the card because this laptop model comes with a bunch of other perks....
<_lemsx1_> jdong: i thought that AMD buying the company was going to actually improve the customer relationship... but i guess "costumer" really means "vendors" and "oem" for them... screw it
<jdong> _lemsx1_: it looks downhill to me
<jdong> _lemsx1_: AMD is planning to use its GPU integration to lock the framebuffer for DRM purposes
<jdong> _lemsx1_: it looks like ATI is contagious
<_lemsx1_> jdong: looks to me that AMD is in the path of becoming synonymous with ATI and DRM, both acronyms with bad connotations ... oh well
<Solarion> where do src debs go?
<_lemsx1_> jdong: for me is Intel all the way from now on
<Solarion> _lemsx1_: me too
<jdong> _lemsx1_: +1
<Solarion> or a very old ati
<cjwatson> Solarion: I suspect you don't mean source debs. you mean source packages?
<jdong> LOL
<Solarion> cjwatson: yes
<cjwatson> Solarion: in the regular archive right next to the binary packages
<cjwatson> apt-get source <sourcepackagename>
<Solarion> cjwatson: "regular archive" is what/where?
<Solarion> yes, that's how I installed it
<cjwatson> http://archive.ubuntu.com/ubuntu/
<cjwatson> do you mean where do they go on your system?
<Solarion> yes
<_lemsx1_> Solarion: do you have a deb-src line in your sources.list file ?
<cjwatson> 'apt-get source' puts them in the current directory
<Solarion> yes
<cjwatson> so wherever you ran that
<Solarion> ah, there they are
<_lemsx1_> Solarion: man apt-get ;-)
<Solarion> any radeon driver hackers aroudn?
<_lemsx1_> Solarion: did you just use the H word?
<_lemsx1_> Solarion: just kidding ;-)
<_ion> I didn't get it.
<_lemsx1_> _ion: "hacker" has such a bad meaning for some people. programmer is much nicer: any radeon driver programmers around...
<jdong> oh come on.... you gotta try harder to make _ion melt into a puddle
<jdong> _ion: fglrx
<jdong> _ion: automatix easyubuntu libdvdcss2 java opera flash shockwave ......
<_lemsx1_> jdong: jeje!
<jdong> :)
<_ion> From that lise, libdvdcss is a good thing, and it sucks that software patents prevent it from being distributed freely. :-)
<_ion> list
<_ion> CSS itself sucks, of course.
<jdong> _ion: but Automatix Installs It (tm)
<jdong> out of the box!
<jdong> swiftfox!
<_lemsx1_> anybody knows of a screensaver that's actually useful? something that connects to an RSS feed and displays the text in a Slide-Show way that's fun to read and "flashy" ?
<jdong> _lemsx1_: I've put up fortune -o as a screensaver before
<jdong> that... actually didn't end well.....
<jdong> who knew those jokes would offend?
<_lemsx1_> jdong: ROFL
<_lemsx1_> jdong: if you install the wrong fortune cookies they will... i love those offensive thingies.. they are fun
<_ion> If i say "from now on, 'hacker' means a terrorist", would you stop (and encourage others to stop) using the word because me and perhaps some other people have a stupid idea about the word's meaning? :-)
<_lemsx1_> _ion: if you convince the society that surrounds me, i will... but that's assuming that "terrorist" is "bad" for me ;-)
<_lemsx1_> _ion: what if i grew up in a society where what we know as "terrorist" are consider "martyrs" ?
<jdong> then there are other issues to deal with than the connotation of 'hacker' :)
<_ion> :-)
<_lemsx1_> jdong: couldn't agree more
<_lemsx1_> jdong: jeje!... like "lack of food for proper nutrition" for instance... boy i'm getting hungry... jeje!
<cjwatson> langpacks and hotkey-setup done, publishing; d-i building
<cjwatson> forgot to remove -14 kernels, looking at that now
<_lemsx1_> jdong: i got the idea of a good screensaver from the slide show on the Nintendo Wii... but that's offtopic anyway ... i'll keep looking (or venture into writing one)
<guiment> is it true that feisty will include compiz in the main ubuntu repository (that is, not universe or multiverse)?
<jdong> it's already there and instaled by default
<guiment> jdong: but not enabled by default, right?
<jdong> correct
<jdong> it can be enabled thru System->Prefs->Desktop Effects
<guiment> jdong: and beryl will stay universe?
<jdong> yes
<guiment> jdong: thank you
<jdong> no problem :)
<guiment> jdong: probably more beryl plugins should be added, though
<guiment> useable in compiz
<jdong> well what you see at this stage is what will ship
<jdong> compiz by default will be pretty conservative
<guiment> right..
<jdong> additional compiz plugins are in universe, compiz-extra
<jdong> beryl and beryl-plugins-unsupported are both in universe too
<guiment> jdong: of course it will be, it has to, we don't want to discourage newbyes because of some eye candy
<jdong> :)
<guiment> jdong: i mean i strongly agree
<guiment> :)
<guiment> jdong: one last question: as you know, the initial plans were to abandon the inclusion of compiz and some drivers by default: how did this change? or when?
<jdong> guiment: To the best of my knowledge Compiz went in by default because of Mark/TB influences....
<jdong> guiment: proprietary drivers can be easily installed via the Restricted Manager
<ajmitch> they're not installed by default, but it's easy to turn them on (desktop effect, restricted drivers manager)
<jdong> and for nvidia and nvidia-new, they will be set up to work with 3D effects
<ajmitch> or compiz may be installed by default, but not enabled
<jdong> ajmitch: installed by default; not activated
<guiment> jdong, ajmitch: i know how much mark wanted that, i was just curious when this changed
<jdong> it was.... like a month ago?
<guiment> jdong: aha, i thought so
<guiment> jdong, ajmitch: any official announcement? i would like to read that
<jdong> don't recall any official announcement...
<guiment> jdong: oh, ok
<guiment> jdong: thanks again :)
<guiment> ajmitch: thanks too
<jdong> anytime
<jdong> infinity2: aww infinity+1 would sound so much cooler :)
<cjwatson> livefses building, braindump of state sent to Mithrandir, and bedtime at last
<jdong> night cjwatson
<jdong> don't work too hard :)
<_ion> Yay, dovecot 1.0.0
<YokoZar> So, I just became an ubuntu member
<YokoZar> will I automatically have my launchpadnick@ubuntu.com as an email address?  I'd like to use it for the package maintainer field.
<ajmitch> yep
<ajmitch> not sure exactly how automatic it is, but it should work, and forward to your preferred address in launchpad
<YokoZar> ajmitch: hooray it works perfectly
<ajmitch> great
<sladen> hd*->sd* migrations issues in bug #93655 should that be raised in importance
<ubotu> Malone bug 93655 in udev "hda -> sda transition not handled during upgrade" [Medium,Confirmed]  https://launchpad.net/bugs/93655
<Mithrandir> should probably just be releasenoted.
<sladen> cjwatson: thanks for uploading the hotkey-setup typo fix
<Treenaks> sladen: Unique UUID Identifier? sounds like Personal Pin Number :)
<sladen> uniquely universally unique personal identifier identifier number
<Treenaks> sladen: (tm)
<sladen> Treenaks: I think there's some money to be made it in
<Treenaks> sladen: especially if you can sell it to governments
<pitti> cjwatson: ubiquity install release notes button leads to http://www.ubuntu.com/testing/feistybeta ; that is certainly going to change?
<pitti> Mithrandir: ^ do you know about this as well?
<pitti> cjwatson: FYI, "Install" icon is translated now on live CD, due to new langpacks
<Mithrandir> pitti: ugh, no, nobody has filed a targeted bug with critical importance about it.
<pitti> Mithrandir: ok, will file one once Im back on my normal system with real kezboard layout
<pitti> argh
<Mithrandir> kezboard ftw.
<Nafallo> :-)
<pitti> hi mvo
<mvo> alter!
<mvo> hey pitti
<ajmitch> hi mvo, pitti 
<Nafallo> hi mvo, pitti, ajmitch
<mvo> hey ajmitch, Nafallo
<heno> pitti: I expect cjwatson won't be around for a few hours; he was up all night feeding the hamsters
<Mithrandir> heno: new day, new candidates.  Care to update the testing grid?
<heno> we should all give him a hug when he returns :)
<heno> Mithrandir: yep, will you pm me md5sums?
<Mithrandir> sure
<Mithrandir> see msg
<heno> Mithrandir: done. I didn't see ubuntu-server amongst those. still building that?
<fabbione> heno: could you please wipe results for netboot too? thanks
<fabbione> (and upgrade)
<heno> fabbione: yeah, I wasn't sure about that. will do
<fabbione> heno: cheers mate
<heno> *** 20070414 CD and DVD images are ready. Check md5sums and post test results here: https://www.stgraber.org/ubuntu/isotesting/ ***
<bdgraue> i updated to 2.6.20-14 and now to 2.6.20-15 and have still this problem  http://www.ubuntuusers.de/paste/9217/
<afflux> I installed the kernelupdated to 2.6.20-14.23 yesterday, which broke my system (something with ata)... but I removed the older kernels that were still installed for cleaning up. 
<afflux> now i'm in a livecd, chrooted into feisty and updated to -15.25 --- and I still have the same ata error (revalidation failed, n_sectors mismatch)
<heno> mvo: welcome!
<heno> ready for some fresh upgrade testing? :)
<bdgraue> i someone need more specific to help, please ask..
<mvo> heno: maybe, but I will have to stop when my wife comes back and catches me in front of the computer at a weekend ;)
<heno> heh
* mvo just got dcc-spamed 
<cjwatson> Mithrandir: the release notes thing pitti mentioned is fine, it goes through a redirect
<heno> cjwatson: great job on the all-night CD building! hope you slept well
<cjwatson> like a baby
<cjwatson> wow, people are still reporting bugs from Herd 1
<cjwatson> (bug 106346)
<ubotu> Malone bug 106346 in ubiquity "Installer crashed in a Compaq Evo 510 Celeron  (dup-of: 61912)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106346
<ubotu> Malone bug 61912 in ubiquity "assert cache._depcache.BrokenCount == 0" [High,Confirmed]  https://launchpad.net/bugs/61912
<fabbione> ehehe
<cjwatson> (61912 is closed actually, it just has a high/confirmed edgy task in case I ever get round to a point release)
<cjwatson> Mithrandir: I've committed a seed change to trim off 67MB or so of kdepim stuff from the Edubuntu DVD, which should bring it back within size limits
<cjwatson> that's the last of the CD-health-check-reported problems
<Enola_Gay> hi all
<Enola_Gay> Is this bug https://bugs.launchpad.net/ubuntu/+source/hal/+bug/99498 planned to be fixed until Feisty release?
<ubotu> Malone bug 99498 in hal "Nautilus and hal can't umount usb hd disk" [High,Confirmed]  
<fabbione> heno: ping?
<heno> fabbione: hi
<fabbione> heno: hey dude.. i finished all the sparc test installs.. i only need to re-test upgrade with the new kernel even if i doubt it will fail.
<fabbione> heno: i will try to do it either this evening or tomorrow, otherwise it's thumb up here
<heno> fabbione: ROCK!
<fabbione> Mithrandir: ^^ for you too
<fabbione> (thumbs up of course includes reading the Release Notes.. otherwise there are known bugs)
<pitti> cjwatson, Mithrandir: here's the promised bug: bug 106517
<ubotu> Malone bug 106517 in ubiquity "Release notes button points to beta page" [Critical,Unconfirmed]  https://launchpad.net/bugs/106517
<cjwatson> pitti: 11:27 <cjwatson> Mithrandir: the release notes thing pitti mentioned is fine, it goes through a redirect
<pitti> hey cjwatson! big hug for the night shift!
<poningru> indeed
<pitti> cjwatson: oh, sorry, I didn't see this, was offline for testing
<pitti> cjwatson: so I close this again, sorry for the panic
<poningru> address for case of beer shipment?
<cjwatson> pitti: (done already)
<ajmitch> hey daniel
<desrt> mjg59; well... there you have it.  http://digg.com/linux_unix/Newly_leaked_Antitrust_Memo_Bill_Gates_on_Making_ACPI_Not_Work_with_Linux
<Mithrandir> cjwatson: coolie, thanks.
<dthacker> link to daily builds?
<asac_the_2nd> dthacker: iso?
<dthacker> yes, please
<Nafallo> cdimage.ubuntu.com
<Nafallo> :-)
<dthacker> tnx
<Nafallo> np
<Nafallo> iwj: I still get that error with disks already added on one array with up-to-date feisty. maybe it's because the array is degraded?
<fabbione> Nafallo: was the raid downgraded before rebooting?
<fabbione> or degraded
<Nafallo> fabbione: yes
<Nafallo> fabbione: planning on fixing that soon though. I took the server down to add another harddrive :-).
<fabbione> Nafallo: ok.. then boot normally, put the raid back to full state and reboot
<Nafallo> moving data around now
<fabbione> ok
<fabbione> i think it's normal you see error when a raid is degrade
<fabbione> +d
<Nafallo> yea. but the system should still boot.
<fabbione> i would test it here but it takes over 10 hours to resync afterwards
<fabbione> there is an ENVVAR to make it booting
<Nafallo> I think we should work on it in gutsy rather than feisty though
<fabbione> the problem is very simple
<Nafallo> if the fix is easy enough we can put it in -updates anyway.
<fabbione> there is no way to tell when all devices for a certain raid set will appear
<fabbione> so the only thing we can do is to make sure all of them are there before starting the raid
<Nafallo> yea. that sounds like what I was about to write :-)
<fabbione> to be on the safe side you can set an envvar to override that
<fabbione> there is no other way to fix it
<Nafallo> hmm, oki.
<fabbione> check mdadm changelog to see how to do it
<fabbione> i don't recall it right now
<Nafallo> I'll make the array happy instead :-)
<Nafallo> still running pvmove from the disk I will add to the new disk. have been running for hours now and is at 23.9% ;-)
<fabbione> pvmove is slow
<Nafallo> sure is :-)
<fabbione> sometimes it's faster to backup/reformat/restore
<Nafallo> but it's wonderful weather, and it can work without me sitting and watch it :-)
<fabbione> assuming you have enough space to do that
<fabbione> ehhee
* heno takes a break. back in an hour
<Nafallo> do we know if feisty will be delayed yet?
<fabbione> Nafallo: nope.. RC clearly is.. release is unknown
<Nafallo> thought so.
<Nafallo> but I didn't know if RC and final had to have that week... ;-)
<Nafallo> in that case it would have been known :-)
<fabbione> well it's best if there sometime in the middle just collect pieces around
<Nafallo> agreed. and atleast I think it should be a week ;-)
<imbrandon> moins Nafallo / fabbione 
<Nafallo> morning imbrandon :-)
<fabbione> hi imbrandon 
<ajmitch> hi imbrandon 
<imbrandon> heya ajmitch 
<ajmitch> good timing, I'm just off to sleep now :)
<imbrandon> snow everywhere out side, it supose to be SPRING !?! /me hushes
<imbrandon> heh
<fabbione> it's deadly warm here
<imbrandon> sleep well ajmitch 
<fabbione> night ajmitch 
<ajmitch> night
<imbrandon> fabbione, it was 80 F a few days ago, now snow, next week they are calling for 80 F again
<imbrandon> crazy
<fabbione> 80 F.. how much is that in C =
<fabbione> ?
<imbrandon> ummm /me looks
<imbrandon> 80 degrees Fahrenheit = 26.6666667 degrees Celsius
<fabbione> i would be dead at that temp...
<fabbione> anything > 10C is deadly for me :)
<imbrandon> thats normal summer temp here :)
<Nafallo> 20+ C here :-)
<imbrandon> the DataCenter is always nice and cool here though
<imbrandon> makes hot days nice
<Lathiat> hehe
<Lathiat> our data center wasn't so cool last week :/
<Lathiat> secondary aircon failure, got a widdle bit warm
<Lathiat> not dangerously warm but warmer than i would have liked :P
<imbrandon> if ours goes above 72F ( 22C ) alarms start calling everyone in the company, normaly we stay arround 50F on the DC floor, plenty of CRAC's to keep it cool
<fabbione> hey Lathiat 
<fabbione> Lathiat: finally i see you around
<Lathiat> fabbione: hehe, what can i do for you :)
<fabbione> Lathiat: nothing really.. i just had to talk to you
<Lathiat> Anyone here using cacti on dapper that wants to test some security updates?
<Fjodor> Hi fabbione. IIRC, you are situated in Copenhagen. Any chance that you might come to Aarhus at any point in time?
<fabbione> Fjodor: i actually might next weekend
<fabbione> why?
<Fjodor> Just saw your nick and recalled that I offered you a beer for doing the locale work back when dapper was in beta :-)
<Fjodor> I think
<fabbione> oh
<fabbione> ehhe
<Nafallo> hehe
<fabbione> i will know more during the week.. it depends a lot on how release goes
<Fjodor> Yearh. it's scheduled for the 19th, isn't it?
<fabbione> basically i need to go to Vejle for one of this confirmation parties on sunday and planned to visit friends in rhus from friday
<fabbione> but if we are delayed i might jump on the train on sunday morning and be back sunday evening
<Fjodor> Ah. My gf goes to Crete Saturday morning, so I'm basically free from then, so do let me know if you are coming to town
<fabbione> Fjodor: sure.. how can i contact you in case?
<Nafallo> Fjodor: gf doesn't like beer? or to young? ;-)
<Fjodor> sune@molgaard.org
<fabbione> Nafallo: there is no such thing as too young in DK
<Fjodor> Nafallo: More likely too old. She has prematurely grown over beer...
<Nafallo> fabbione: kewl! :-)
<Nafallo> Fjodor: :-)
<Fjodor> fabbione: Or mobile: +45 20 16 32 95
<fabbione> Fjodor: writing down thank
<Fjodor> fabbione: And finally_ ICQ is 20952483, MSN Messenger is msn@molgaard.org and jabber is fjodor@jabber.dk
<fabbione> it's enough your phone num
<fabbione> i won't have inet from where i will be
<fabbione> neither my laptop
<Fjodor> Fair enough
<Fjodor> Oh, if you call instead of texting, do identify yourself as Fabbione from #ubuntu-devel. I have a lousy short-time memory, so I might get confused :-)
<fabbione> Fjodor: sure.. ok :)
<Fjodor> :-)
<fabbione> bbl
<saelynh_X-chat> hi there 
<saelynh_X-chat> I just want to know if festy will be out next thurday or if will need to be a little be more pacient ?
<Mithrandir> saelynh_X-chat: any deviations to the schedule will be announced when they're made.
<Mithrandir> or rather, when they're decided.
<saelynh_X-chat> oki :)
<saelynh_X-chat> thanks Mithrandir
<Mithrandir> np
<poningru> linux-server: Depends: linux-image-server (= 2.6.20.14.12) but 2.6.20.15.14 is to be installed
<poningru> is that intentional?
* ScottK thinks it means your local mirror is not fully updated.
<vandenoever> on edgy, the following command reports an error:
<vandenoever> echo hi |valgrind iconv -f ISO-8859-15
<vandenoever> but this is ok:
<vandenoever> echo hi |valgrind iconv -f ISO-8859-1
<Seveas> !bugs | vandenoever 
<ubotu> vandenoever: If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.ubuntu.com/ IRC is not a good medium to report bugs and this channel is for development coordination.
<vandenoever> Seveas: but can you confirm it?
<Seveas> vandenoever, I'm no longer running edgy, so I cannot confirm
<vandenoever> Seveas: is the problem still there on feisty?
<Seveas> ==24311== ERROR SUMMARY: 6 errors from 5 contexts (suppressed: 13 from 1)
<vandenoever> Seveas: thanks
<vandenoever> i'll note that in the report too
<Seveas> vandenoever, http://paste.ubuntu-nl.org/15639/
<vandenoever> Seveas: it's identical to mine
<BenC> CALL FOR TESTING: We have a new kernel that is supposed to fix regressions in 2.6.20-15.25
<BenC> if you could test http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<BenC> I'd appreciate knowing if it still works as opposed to -15.25
<BenC> also, if -15.25 doesn't work for you because of sata_nv or HPA issues, please let me know if it does work for you
<BenC> please report success/failure to #ubuntu-kernel, and make sure to note whether -15.25 worked for you prior to this
<pitti> famous last words of petunia bowl: Oh no, not again!
<BenC> pitti: you have a magical lba28 HPA drive, can you test please? :)
<pitti> BenC: sure, will do
<BenC> pitti: thanks
<pitti> BenC: in about 30 minutes or so, my postgresql testsuite is running ATM
<BenC> pitti: No problem, it'll be that long before I can get the upload ready and feel comfortable about uploading it
<pitti> BenC: darn, I just completed my very last test case of the 20070414 CDs :)
<kylem> BenC, i don't suppose you want to pull in the intel crestline patch + the gatt patch from mainline ubuntu-feisty? ;-P
<kylem> otherwise i'll fix it in -security post-release
<kylem> doesn't really matter, since it needs userspace bits tho.
<Mithrandir> if it doesn't matter, I think it should go in post-release.
<BenC> kylem: I would love to, but I think mdz/cjwatson/Mithrandir will shoot me
<kylem> k.
<kylem> can't blame a guy for trying. ;-)
<kylem> bbiab. playoffs.
<BenC> collectively I think they have a decent chance of getting one bullet on me, even from the EU :)
<Mithrandir> BenC: I would never be so kind as to shoot a coworker if I was angry with them.  I'm much more cruel than that.
<BenC> lol
<Mithrandir> oh, and .no isn't part of the EU.  It just feels that way.
<BenC> .no would do the EU some justice...very nice country
<pitti> too bad that we saw so little of it during the sprint
* kylem pines for fjords
<BenC> we did get to see an underground bowling alley, what more do you want? :)
<Mithrandir> pitti: if we ever end up having a smaller sprint here we can have it in our cabin up in the mountains.
<kylem> Mithrandir, that would be awesome
<Kmos> bug 106622
<ubotu> Malone bug 106622 in linux-source-2.6.20 "linux-image-2.6.20-15 fails to properly detect and configure EMS USB-II" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106622
<Kmos> it gives a patch =)
<BenC> mdz, Mithrandir, cjwatson_: I feel comfortable with the current patch fixing things
<Mithrandir> BenC: is there anything it doesn't cover?
<BenC> I'm going to upload with this patch people.u.c/~bcollins/libata.diff
<BenC> Mithrandir: it covers everyone that reported problems related to sata_nv and HPA, so far
<Mithrandir> BenC: and do we have a solution to the problem of module parameters not being propagated?
<BenC> trejack has a different issue, that seems unrelated to anything we are doing right now, and which I cannot reproduce
<pitti> BenC: alright, back from dinner and testsuite finished; you still need me to test that kernel?
<BenC> Mithrandir: kyle is working on something for initramfs-tools and modprobe
<BenC> pitti: yes, please
<pitti> alrighty
<BenC> Mithrandir: I'll hold off on an upload for about an hour, just to make sure testing goes well
<BenC> but so far so good
<Mithrandir> BenC: please just upload it, we can easily reject it if it's broken.
<BenC> Mithrandir: ok
<BenC> Now, as much as I like spending my b-day with you guys, my wife has a party going on here for me :)
<pitti> BenC: ooh, happy birthday!
<pitti> BenC: funny that we two have bday on the same day
<pitti> probably not in the same year, though :)
<BenC> pitti: today is your b-day too?
<pitti> yes :)
<BenC> sweet, happy b-day :)
<BenC> I'm '72
<Mithrandir> BenC: enjoy it.
<pitti> thanks *smile*
<Mithrandir> pitti: congrats.
<pitti> BenC: '80
<BenC> well, 1972, not 72 years :)
<pitti> Mithrandir: thanks
<Mithrandir> pitti is a mad youngster, just like me, it seems.
<BenC> Mithrandir, mdz, cjwatson_: Uploaded, and afk
<pitti> unfortunately neither my gf nor some of my friends are in the city; fortunate for working on the weekend, though :-P
* pitti ^5s Mithrandir
* pitti boots new kernel
<maswan> Mithrandir: speaking of smaller sprints, I'm sure you guys would enjoy Kronlunds too, during winter or summer. :)
<Mithrandir> maswan: that's an excellent suggestion.  Does it have some kind of URL with prices and booking info and so on?
<Mithrandir> also, do you know about how it is, bandwidth-wise?
<maswan> Mithrandir: I will know in one month. :) It was good before the university sold it off anyway.
<maswan> Mithrandir: http://www.kronlundkursgard.se/
<Kmos> BenC: '72 ? lol..
<maswan> Mithrandir: let me dig for prices
* kylem liked the weather in scandinavia a lot
<kylem> reminded me of home :P
<Mithrandir> it's slightly hard to get to ume, that's a downside.
<Mithrandir> kylem: I liked .ca a lot, it reminded me of home too. :-)
<maswan> Yeah, there are good flights from arlanda, but it is one more hop from the closest international airport
<pitti> Mithrandir, BenC, kylem: new kernel 15.26 is happy on my (quoting Ben) 'mad lba28' drive
<pitti> [   29.770878]  ata1.00: ata_hpa_resize 1: sectors = 25408559, hpa_sectors = 25410672
<pitti> [   29.770885]  ata1.00: Host Protected Area detected.
<pitti> [   29.770886]       current size : 25408559 sectors (13009 MB)
<pitti> [   29.770888]       native  size : 25410672 sectors (13010 MB)
<Mithrandir> pitti: coolie.
<Kmos> BenC: it's the year =) lol
<Kmos> 35 years old.. happy b'day
<Kmos> :)
<Mithrandir> maswan: now you made me miss being a student and doing all the crazy stuff we did, including NUCCCs.
<maswan> Mithrandir: I got a quote at ~1300 SEK/person from lunch-lunch, including single rooms, hottubs, etc.
<Mithrandir> including food too?
<maswan> Mithrandir: so about 1k SEK/day including food if you can stand sleeping 4 people in a room.
<maswan> yes, that's two lunches, one dinner, one breakfast and two fika
<Mithrandir> doesn't sound bad at all then.
<maswan> plus a few hundred SEK/day for conference room
<kylem> pitti, good to hear.
<maswan> Mithrandir: anyway, if you guys are interested, I'm heading there in may, so I can get back to you wrt bandwidth etc. 
<maswan> Mithrandir: heh, I haven't quite let go of that world yet, I'm heading to NUCCC in Lund next month. :)
<Mithrandir> maswan: I'm not the one doing plannings for sprints, but I could ask about it, sure.
<Mithrandir> maswan: lucky you. :-)
<maswan> Mithrandir: it's good for up to about 80 people, 100 can probably squeeze in (like we did att NUCCC here)
<Mithrandir> yeah, I'd be thinking distro-team sprint or something like that.
<Mithrandir> where we're around 20-ish.
<maswan> that's about the size of this group too, the swedish academic hpc sysadmins gettogether
<tormod> ok, just found https://www.stgraber.org/ubuntu/isotesting/
<bluefoxicy> hrm what the hell
<bluefoxicy> someone try installing seti (you'll get boinc something), then remove it and boinc-client
<bluefoxicy> while that's removing (like as soon as you hit apply in synaptic), open System->Administration->Services
<bluefoxicy> see if Services and Apt both freeze.
<bluefoxicy> services might just break on its own too
<bluefoxicy> but it's not as much fun if you don't break Apt too ;)
<bluefoxicy> alternately, the boinc-client uninstallation script might just be broken too and I hit both bugs at once :(
<phaidros> hi, just read this: http://www.washingtonpost.com/wp-dyn/content/article/2007/04/13/AR2007041301610.html
<phaidros> is ubuntu kernel already patched for madwifi?
<phaidros> seems to be a major bug in madwifi :/
<jdong> that sounds like that AP scanning bug from a month ago
<phaidros> jdong: it is. 
<phaidros> so its done already. 
<phaidros> I just found it today :)
<jdong> yeah
<phaidros> wasn't for a while in #madwifi :)
<phaidros> ok, kewl.
<phaidros> thanks 
<jdong> phaidros: http://www.ubuntu.com/usn/usn-404-1
<jdong> phaidros: Jan 01
<jdong> 09*
<phaidros> wow, january .. thats some time ago 
<phaidros> hehe, news are late then :)
<bluefoxicy> oh man, how do I approach this
<bluefoxicy> my hard disk light flashes once a second just about
<bluefoxicy> nothing should be causing that
#ubuntu-devel 2007-04-15
<jdong> beagle :)
<bluefoxicy> I don't have it installed.
<bluefoxicy> jdong:  any profiling tools that can tell me what's touching disk?
<jdong> yeah there are... can't think of the one off the top of my head
<jdong> laptop-mode's profiler
<jdong> whatever it's called
<jdong> lm-profiler
<jdong> :)
<bluefoxicy> ah
<bluefoxicy> uh oh
* bluefoxicy just turned his hard drive off  :)
<jdong> LOL
<bluefoxicy> /dev/sda:
<bluefoxicy>  issuing sleep command
<jdong> bluefoxicy: I've accidently unplugged a USB external holding some swap...
<jdong> oops.
<bluefoxicy> I heard a distinct "CLICK"
* bluefoxicy should hdparm -y, not -Y
<bluefoxicy> how ironic, it spins right back up :/
<bluefoxicy> jdong:  I'm quite interested in actually getting the hard drive to spin down after a few minutes.  This would, in theory, allow the motor to not constantly run and thus not burn out x.x
* popey wonders what package the mouse pointer icons are in
<jdong> bluefoxicy: spindowns are worse for it
<jdong> bluefoxicy: they have much more limited spindown cycles than continuous-operation hours
<jdong> and spindown is pretty useless without something like laptop-mode nicely tuned
<pitti> good night everyone
<bluefoxicy> jdong:  oh.  I have a server behind me that usually doesn't get touched
<jdong> bluefoxicy: still cron would wake it up at least once per day
<jdong> and syslog writes sync too
<bluefoxicy> nods
<jdong> you still will lose in the end :(
<jdong> the only exception I'd make is for an external that is torqued around a lot during operation
<jdong> spinning it down while not in use can be a major lifesaver
<popey> \o/ xcursor-themes
<jdong> (like an ipod sized HD)
<bluefoxicy> jdong:  sounds like hybrid flash/hard drives will be a boon for drive lifetime
<jdong> if done right, yeah
<bluefoxicy> if they let you keep like a 4 gigabyte journal on there ;)
<jdong> LOL
<jdong> haha
<bluefoxicy> and then flush it to disk in one run
<jdong> yes
<jdong> and if they can use fuzzy logic to figure out what to prefetch...
<jdong> and also telepathic anticipation
<jdong> :)
<bluefoxicy> (a 4 gig flash drive costs like $50 on Newegg... in a year that'll equate to maybe $10 more cost added to making a hard drive with 4G flash on it
<bluefoxicy> yeah, split it between repeatedly read sectors and a mirror of sectors that have been written
<bluefoxicy> and when you spin the drive up, flush the sector-write cache to disk and adjust the sector-read cache as needed; then after several minutes (20-30?) of not actually needed the disk (just the flash area), spin the drive back down
<bluefoxicy> If it works out right, normal usage, syslog, cronjobs that don't run shit like updatedb (which I've now killed off), xchat/gaim logs, etc, should reside mainly on flash
<bluefoxicy> along with boot time libraries and libc and stuff (woot, no spin-up during boot)
<bluefoxicy> so playing movies and music and games would kick the drive up and nothing else should in theory :)
* bluefoxicy likes  to juggle theoretical rhetoric, things that will never really happen...
<bluefoxicy> hybrid drives will probably die out
<dthacker> are there daily images being created for edubuntu and kubuntu at this stage of the release process?
<Riddell> dthacker: no, it's manually controlled now
<dthacker> Riddell: tnx, watching and learning for next cycle
<bo1> hello
<lucidsmog> I haven't been able to find this information, but are the actual source packages that you apply to your official builds available somewhere?
<lucidsmog> source patches, rather
<poningru> lucidsmog: just do apt-get source packagename
<poningru> and the orig.tar.gz is the original
<poningru> and there is another that is the patch
<lucidsmog> poningru: Oh, that's good to know!  To tell you the truth I'm not really an Ubuntu user, but googling around for some things that were annoying me about Firefox lead me to a "launchpad" website about Ubuntu talking about some patches against Firefox for tighter GNOME integration, I just couldn't find the patches.
<poningru> lucidsmog: per mofo agreement there isnt anything that isnt changed without mofo approval
<crimsun> lucidsmog: download the source package for firefox (orig.tar.gz+diff.gz+dsc), extract it, and see what's packaged in firefox-gnome-support
<lucidsmog> crimsun: firefox-gnome-support (at least at packages.ubuntu.com, which I just found) links back to the firefox sources, which look to be the stock ones to begin with, as far as I can tell.
<crimsun> lucidsmog: that's correct; firefox source generates that binary.
<crimsun> lucidsmog: if you'll inspect what is distributed in the diff.gz, you'll see what becomes firefox-gnome-support.
<sudo> http://www.codigolibre.org/modules.php?name=Downloads&d_op=viewdownload&cid=1
<orangey> Hey all!
<orangey> I'm having a problem here.. When I am trying to compile a kernel package which is older (-10), I get "Compatibility levels before 4 are deprecated"
<Hobbsee> orangey: please read the /topic
<orangey> Hobbsee: I'm thoroughly confused where I belong, then.
<orangey> #ubuntu?
<orangey> #ubuntu-kernel?
<Hobbsee> orangey: #ubuntu+1 for feisty, #ubuntu for dapper/edgy support
<Hobbsee> orangey: and i doubt many people are around, as it's a sunday here
<orangey> gotcha.
<orangey> thanks.
<tuxmaniac> Has rc been released? I saw a delay announce meant on the devel announce list. Will this affect the final release of Fawn? 
<cjwatson> No, and the final schedule hasn't been decided; there'll be a further announcement if it's determined to be delayed.
<cjwatson> we're deciding based on the outcome of testing with what we've got at the moment (rough summary: mostly seems ok except for problems with nvidia ata chipsets)
<tuxmaniac> cjwatson, Dankeschon
<tuxmaniac> cjwatson, nvidia.. grrr :-)
<czr> is there a channel for d-i-related questions?
<Hobbsee> czr: probably here, you're after cjwatson - but not on a sunday, i'd expect
<czr> I just have a silly irritating thing. I want to disable usplash via preseed but can't seem to find any way to do it.
<evand> czr: #ubuntu-installer, but keep in mind it's Sunday
<czr> thanks evand & hobbsee
<Mithrandir> morning evand, Hobbsee
<evand> good morning Mithrandir 
<Hobbsee> heya Mithrandir!
<Mithrandir> new day, new kernel.
<Hobbsee> Mithrandir: thought that read "another day, another kernel"
<Mithrandir> same difference, really
<Hobbsee> true
* Hobbsee really should get all the pictures from last night and publish them somewhere
<Hobbsee> damned procrastination
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/anastacia.txt <-- woo, emptiness
<ivoks> cjwatson: here?
<dutchfish> hi is there some way to cross-compile to native PE win32 exe without the need for mingw, for instance with the help of dpkg-cross?
<Nafallo> dutchfish: hi! this channel is for the development of Ubuntu. for support, see #ubuntu. thanks.
<dutchfish> Nafallo, i thought this was a development question, i am very sorry
<stgraber> dutchfish: Development of Ubuntu not development on Ubuntu
<dutchfish> stgraber, so if there is no package and i wanted to make one for the ubuntu commmunity, it is not ubuntu development?
<Nafallo> dutchfish: that's universe, so #ubuntu-motu :-)
<dutchfish> stgraber, ok, thx anyway
<cjwatson> ivoks: on and off
<ivoks> cjwatson: i just wanted to ask you would another upload of console-tools be possible if i fix problems with keymaps for 4-5 countries :)
<ivoks> sorry, console-setup, not -tools
<cjwatson> ivoks: it's not very likely at this point; sounds like the sort of problem that could be fixed in an update, if it's a regression from edgy
<cjwatson> ivoks: but is there a bug number for this?
<ivoks> cjwatson: it didn't work in edgy too
<ivoks> cjwatson: bug 93077
<ubotu> Malone bug 93077 in console-setup "Non-exsisting layouts" [Medium,Confirmed]  https://launchpad.net/bugs/93077
<cjwatson> Mithrandir: re-accepted debian-installer, since hw-detect is in
<cjwatson> ivoks: ok, sorry, it sounds really too hairy to get tested properly at this point
<ivoks> ;..( ok
<cjwatson> it shouldn't affect the installed system
<cjwatson> (that doesn't use the keymap reduction stuff)
<ivoks> problem is only in installer, right
<cjwatson> so we should release-note that users of those keymaps need to install using a US layout and then switch afterwards
<cjwatson> Mithrandir: could you remind me to give you some text for that?
<cjwatson> ivoks: we should fix this as early as possible in gutsy; I can certainly have a look at it and see whether the right fix is to change the xkb data or to change console-setup
<cjwatson> anyway, got to go again now
<ivoks> cjwatson: ok, bye, thanks
<Mithrandir> cjwatson: thanks, and yes, will do.
<mdzlu> cjwatson: around?
<cjwatson> mdzlu: on and off
<tsmithe> cjwatson, how feasible is something like http://ubuntuforums.org/showpost.php?p=2456306&postcount=1 ?
<andreasw> hi I have a bug which is already reportet but for edgy rc (in the final version this bug was not there) and I have it in feisty beta now is it better to rereport it for feisty beta?
<pochu> andreasw: no, the same bug should be enough. Which one?
<andreasw> pochu: #68031
<pochu> bug 68031
<ubotu> Malone bug 68031 in kdegraphics "[edgy rc]  - ksnapshot draws ugly gray lines (trail marks)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/68031
<pochu> andreasw: I'm afraid I can't help you, but I've confirmed the report, since another user has the same issue
<andreasw> ok thanks
<andreasw> but it's strange that this bug seems to only exist in dev versions of ubuntu ^^
<pochu> andreasw: doesn't it happen in Edgy stable?
<andreasw> pochu: no it doesn't
<pochu> :)
<pochu> Let's hope it doesn't happen in Feisty final too ;)
<andreasw> yep but I will now look at kde.org maybe I'll find a similar bug there
<pochu> andreasw: If you find it, then link it in the LP report :)
<andreasw> pochu: ok just found an entry but the user also uses feisty ^^
<andreasw> and it is not solved yet
<pochu> andreasw: link?
<andreasw> http://bugs.kde.org/show_bug.cgi?id=143723
<ubotu> KDE bug 143723 in general "ksnapshot draws artifacts on screen while selecting region" [Normal,Unconfirmed]  
<pochu> andreasw: linked :)
<Nafallo> I still have the bug that /dev/md2 already has disks in initramfs :-)
<Nafallo> so still have to break=premount and pkill mdadm :-)
<Nafallo> but I will ask tomorrow when Keybuk and iwj are working again ;-)
<fryfrog> is there a kernel update -15.25 expected?  i was under the impression there was, but have only seen the -15.24 that breakifies one of my poor systems :(
<Nafallo> linux-image-2.6.20-15-generic | 2.6.20-15.25 | http://se.archive.ubuntu.com feisty/main Packages
<Nafallo> yes :-)
<fryfrog> humm, so it is in repos?
<fryfrog> i guess i'm not so good with my apt fu yet :/
<fryfrog> Setting up linux-image-2.6.20-15-generic (2.6.20-15.27)
<fryfrog> okay, weird
<fryfrog> one of my systems is happily installing a ".27" and the other only sees .24 :/
* Nafallo updates :-)
<fryfrog> sudo aptitude show linux-image-2.6.20-15-generic
<fryfrog> is that showing what is *available* or what I have installed?
<fryfrog> sorry, i should not ask in dev chan
<Nafallo> apt-cache policy linux-image-2.6.20-15-generic should help you
<fryfrog> thanks, sorry to ask newb questions here i won't do it until i forget again :)
<Nafallo> hehe
<zyga> what is the current status of RC?
<cjwatson> tsmithe: it's been discussed before, needs some work though
<tsmithe> cjwatson, thanks - what kind of work?
<BenC> Mithrandir, cjwatson: How's everything looking?
<Mithrandir> BenC: looks good; rolling ISOs now.
<BenC> Mithrandir: excellent
<Hobbsee> how would one go about debugging https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/97499 ?
<Hobbsee> Mithrandir: would you know, seeing as you were one of the last to touch NM?
<ubotu> Malone bug 97499 in network-manager "[Feisty]  System crash when NetworkManager tries to activate Wifi" [Undecided,Unconfirmed]  
<heno> woo! I see new ISOs :)
<Arby> hi heno
<Arby> let the games continue :)
<heno> Arby: indeed
* heno posts new images on the tracker
<Arby> we were just wondering about that in #ubuntu-iso
<heno> I've flushed yesterday's and added 20070415 ISOs
<heno> an overview of the testing from the past few days can be seen here https://www.stgraber.org/ubuntu/isotesting/archive
<mrsno> arr /me downloads again
<mrsno> :D
<spike> hi there
<spike> I need to look at coreutils sources and noticed that gnu.org ships 6.9 while all the distros I've checked, including ubuntu, ship 5.9X
<spike> what's the reason behind it?
<spike> it's a major revision number behind, so it must be something obvious that I'm not aware of
<beuno> anyone around that can confirm that apport won't be activated by default in Feisty?
<beuno>  UWN will be out in a while, and I don't want to get that wrong  :D
<pokoko> g'day everyone. In Ubuntu, and I suppose in Linux kernel version 2.6.17-11, i think there's a bug where a mounted usb device doesn't get recognised after a suspend/resume. Has this been worked out yet or some solution which I am unaware of ?
<pokoko> ve googled and asked people for answer but so far no one seem to know the answer. One solution was turning acpi=off which doesn't suit my need. How can this be addressed? thanks.
<pokoko> dmesg'ing tells me that kernel is using wrong IRQ
<pochu> pokoko: you can test a recent image of Feisty, ans see whether it's fixed, and if it isn't, then file a bug :)
<pokoko> pochu, well.. this is not viable
<Chipzz> pokoko: also, it's sunday, most people are away for the weekend
<pokoko> pochu, for me
<pokoko> Chipzz, yeah it's already Mon here in Auz
<pokoko> ;)
<Chipzz> pokoko: and you'll probably have more luck asking in #ubuntu-kernel
<Chipzz> ;)
<pokoko> Chipzz, cheers
<Chipzz> pokoko: yw :)
<Nafallo> file a bug? :-)
<pokoko> Nafallo, heh.
<pokoko> Nafallo, will do.
<pokoko> but what's the point in having #ubuntu-kernel if it can't be used suitably in realtime ? ;)
<Chipzz> pokoko: also, like pochu said, test a recent image of feisty; latest kernel is 2.6.20-14.22 AFAIK
<Chipzz> pokoko: you're probably running edgy or dapper?
<pokoko> Chipzz, yes. edgy
<pochu> Chipzz: -15.27 ;)
<Chipzz> pochu: oh, you're right :)
<Chipzz> I was doing apt-cache show linux-image-2.6.20-14-generic (instead of 15)
<Nafallo> Chipzz: .17 is edgy :-)
<Chipzz> typo probably :)
<Nafallo> dapper is .15
<Chipzz> pokoko: the chances that there will be new kernels for edgy fixing your particular issue are probably quite slim (but not non-existant)
<Chipzz> given that the feisty release is around the corner
<pokoko> Chipzz, so what are the options ?
<Chipzz> upgrading to feisty (either now or when it's released) ;)
<pokoko> Chipzz, I do not why only I get this error. surprising.
<pochu> Chipzz: if that's fixed in Feisty :)
<pokoko> Chipzz, surely will do that later.
<pokoko> Chipzz, *if* only. heh
<Chipzz> pokoko: nothing is perfect :) not even the linux kernel :)
<pokoko> true
<Chipzz> so, bugs exist, and it's possible that bugs exist that do affect you. ;)
<pokoko> Chipzz, i actually tried unloading uhci and usbcore modules before and after suspend/resume but that didn't work either. :(
<pokoko> heh
<pokoko> Chipzz, thanks for the *enlightment*. ;)
<pokoko> enlightenment actually.
<pokoko> heh
<anti_pop> i reported this, but no replys. did i something wrong or isnt this a "bug" ?? https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106205
<ubotu> Malone bug 106205 in linux-source-2.6.20 "system freeze" [Undecided,Unconfirmed]  
#ubuntu-devel 2008-04-07
<YokoZar> Sweet, Hardy is sufficiently faster than Gutsy that I can now watch some HD videos in realtime without massive frame dropping.
<bluefoxicy> shouldn't autoclean interval be 1 instead of 0?
<bluefoxicy> apt seems to be piling up old versions of packages (like 30 versions of the same nvidia driver etc) until it fills up my hard disk :|
<jdong> YokoZar: that's probably because of recent improvements in ffmpeg's decoding performance
<YokoZar> jdong: Cool.  Either way end users will be happy to know that they can now watch higher resolution...movies...
<jdong> indeed
<lamont> dear firefox3.  why do you render my nagios map as white on white?
 * lamont upgrades to see if firefox changes
<vlowther> Bug #212660, suspect mjg59's three headed monkey spotted in wild in 2.6.24-1[45].  System goes through all the motions of suspending/resuming, but the kernel spews debugging information into dmesg instead of actually suspending.  If anyoune could point me to a handy guide on how to interpret this outputm that would be much appreciated.
<ubotu> Launchpad bug 212660 in linux "kernel 2.6.24-15 fails suspending" [Undecided,New] https://launchpad.net/bugs/212660
<vlowther> Interestingly enough (and the log shows this), suspend/resume works normally once.
<vlowther> -12 kernel functions as expected.
<PurpleBlu> Is there a convert pdf text documunt to odf or something?
<jdong> PurpleBlu: this isn't the right channel to ask support questions
<PurpleBlu> jdong, I thought I was in my local ubuntu-chicago channel.  sorry
<stuporglue> Does anyone else use the "USA International (with dead keys)" layout? The dead keys aren't working for me in Hardy, though they worked in Gutsy
<stuporglue> The new key layout does't show any way to get an a or o with a tilde on it...which makes it difficult to type Portuguese correctly
<slytherin> pitti: Can you please take a look at bug 212801. f-spot has depwait on powerpc due to this.
<ubotu> Launchpad bug 212801 in gnome-desktop-sharp2 "Please promote to main on powerpc" [Medium,Triaged] https://launchpad.net/bugs/212801
<slytherin> TheMuso: Hobbsee told me to contact you. I am trying to solve OOo FTBFS on powerpc, but unable do test my solution since I don't have much disk space on my machine. She said you have access to some powerpc machine.
<Hobbsee> TheMuso: i know you used the ubuntuwire ppc for a while - any idea if that's still up?
<TheMuso> Hobbsee: No idea.
<TheMuso> slytherin: I am actuallyw orking with calc on this one as we speak. Got a test build going on my PPC.
<slytherin> TheMuso: ok. What changes did you do?
<TheMuso> slytherin: I've been instructed to disable ppc java support building at this time, build likely won't be done for several hours yet.
<TheMuso> slytherin: calc also told me that I should b elooking at approx 10GB used for the build.
<slytherin> TheMuso: But it is already disabled right? I say some code in rules file that disables java support if arch is powerpc. I was in fact going to suggest to remove the code i.e. re-enable java support. I will also take a look at Debian's diff.gz to see how it differs in this respect.
<TheMuso> slytherin: Sorry thats what I meant.
<slytherin> TheMuso: thanks for looking into it. :-) See you later.
<fabbione> cr3: !
<cr3> fabbione: dude! how's it going?
<cr3> fabbione: since you happen to be in #ubuntu-devel, will I have the pleasure of your spankings at uds?
<fabbione> cr3: pretty good thanks...
<fabbione> cr3: nope.. i haven't been invited
<cr3> fabbione: that sucks. I'm sure you could double my productivity just by the fear of your presence :)
<fabbione> cr3: ahahha
<fabbione> cr3: just think that i am always behind you
<fabbione> cr3: if not me, my spirit will be there :)
<cr3> fabbione: would it be too much to ask for a poster or a cardboard cutout of you?
<ion_> I can sell one of mine.
<fabbione> cr3: perhaps me frozen in graffite like Ian Solo?
<ion_> I have a livingroom full of cardboard cutouts of fabbione.
 * cr3 fabbione if I had a cardboard cutout of you, I'd really keep it next to my desk, no matter what canonical might think :)
<cr3> hm, that didn't come out quite right :(
<fabbione> ahahah
<cr3> fabbione: nah, Ian Solo had a kinda desperate look. I'd go for the "angry and will make my cry like a little girl" look.
<cr3> getting late for me, cheerio folks
<fabbione> night cr3
<fabbione> take care dude
<fabbione> and don't dream too much about me
<fabbione> it's not healty
<fabbione> oh gone...
<fabbione> well
<warp10> Good morning
<xtknight> how does "add/remove programs" populate its list?
<LaserJock> from a package
<LaserJock> app-install-data I believe
<xtknight> i see it now.  is there any reason why vinagre would have two entries in menu-data?  I'm not even sure what vinagre.desktop vs vinagre-file.desktop are for
<xtknight> bug 213207
<ubotu> Launchpad bug 213207 in vinagre "Vinagre appears in Add/remove applications twice as "remote desktop viewer"" [Undecided,Confirmed] https://launchpad.net/bugs/213207
<LaserJock> oh, interesting
<xtknight> but it's also twice in app-install-data-ubuntu
<LaserJock> yeah
<xtknight> automatically generated or something
<LaserJock> that data comes from flags in the .desktop files
<xtknight> so i guess i can just remove the -file one from menu-data
<LaserJock> well, I think you fix the .desktop in vinagre
<LaserJock> the app-install-data packages are autogenerated
<xtknight> ah
<xtknight> vinagre-file is the base of some sort of shell extension i assume, like right clicking or open with?
<LaserJock> xtknight: pastebin the 2 .desktops
<xtknight>  /usr/share/applications/vinagre.desktop: http://rafb.net/p/eGJVPW93.html  ; /usr/share/applications/vinagre-file.desktop: http://rafb.net/p/YC1fCl94.html
<xtknight> some nasty unicode there
<xtknight> (the file's fine locally)
<xtknight> NoDisplay=true on the second one.  maybe Add/Remove should not populate when NoDisplay=true
<xtknight> or the autogenerator
<LaserJock> xtknight: I'd maybe add a task on app-install-data-ubuntu to that bug report
<xtknight> ok
<xtknight> LaserJock, for example, xfprint4 has the same problem.  only, the two entries are named differently and refer to the same binary package.
<xtknight> and removing them works fine, they just treat each other like dependencies, X each other out
<LaserJock> yeah
<LaserJock> I suspect there may be a few of those
<xtknight> http://rafb.net/p/WPAfvU75.html
<xtknight> a whole list of possibilities.  pavumeter also happens
<LaserJock> where is that from?
<LaserJock> which directory?
<xtknight> i just did "grep -i NoDisplay=True *" in menu-data under the app-install package
<LaserJock> k
<LaserJock> well NoDisplay=True isn't a great criteria
<LaserJock> what you're looking for is packages that produce more than 1 .desktop file
<superm1> xtknight, i ran into this some time back on the myth packages too
<superm1> xtknight, you want to put X-AppInstall-Package=PACKAGE in the desktop files
<superm1> er well wait that's a different problem i ran into as well
<xtknight> ok i made a silly little script to determine which pkgs have >1 .desktop file.  here are the results for my system, the pkgs i have installed, for what it's worth:
<xtknight> http://rafb.net/p/alPgv347.html
<superm1> xtknight, i think i actually had mvo add it a list to restrict it
<xtknight> hmm
<superm1> and then added that X-AppInstall-Package key to the remaining desktop file to make sure the right one got installed
<kagou> Good morning
<xtknight> superm1, ok so looks like i should just remove X-AppInstall from the auxiliary vinagre-file desktop file?
<xtknight> that won't cause any regressions or side effects?
<kagou> pitti, told me that language packs are generated twice in a week, but now they are 15 days old. Is there a special place to take them ?
<superm1> xtknight, please check with mvo
<superm1> xtknight, he'll know for sure
<xtknight> mvo? ah ok
<xtknight> is that his nickname on here
<superm1> yeah
<xtknight> thx
<dholbach> good morning
<LaserJock> dholbach!
<dholbach> hey LaserJock
<mdke> morning dholbach
<dholbach> hey mdke
<seb128> hey dholbach mdke
<mdke> morning Seb
<Ng> is gnome-volume-manager necessary for things like autoplaying a DVD? Those options have moved to nautilus and I see this morning's upload of g-v-m disables the scanner command
<seb128> hey Ng
<Ng> that's the only one currently enabled in mine anyway, so I'm wondering if I can get away with removing it from my session
<StevenK> I thought hal just told gvfs that a DVD has appeared
<Ng> hey seb128 :)
<seb128> Ng: can you do printing tests today?
<seb128> Ng: upstream fixes the glyph positionning issue on the pdf example attached to the bug, I would like to know if that makes the printer work correctly too
<Ng> seb128: sure. we've had xerox confirm that the PS crashes their lab machines, so they're going to work on a fix for some future firmware.
<xtknight> pdf bug 150187?
<ubotu> Launchpad bug 150187 in poppler "[gutsy] [regression] Evince has very bad quality when printing pdf files." [Unknown,Confirmed] https://launchpad.net/bugs/150187
<seb128> xtknight: no
<Silicium> hi there
<Silicium> so, i cant get help in the public channel so i try it here, iam sorry, i know is a developer channel. so
<xtknight> Silicium, what's your question?
<seb128> Silicium: try #ubuntu
<Ng> but obviously it would be nice not to be generating invalid ps :)
<Silicium> how i can add more than one repositorys into a preseed file?
<Silicium> seb128: no chance, this guys does not know what preseed is oO
<seb128> Ng: the ps generated is valid as far as I can say and upstream had no validity issue with it neither, it's displayed correctly on screen out of the glyph positionning bug
<Ng> ah
<Ng> ok
<Silicium> can i add this regulary or must create a script to do this after base install?
<xtknight> Silicium, #debian might have a better idea but make sure it's not ubuntu-specific
<xtknight> sounds like debian-installer stuff to me so..
<Silicium> yea thanks
<seb128> Silicium: you can try #ubuntu-installer too if that's an installer question
<Silicium> ok tx
<kagou> lu seb128
<seb128> lut kagou
<crevette> salut
<seb128> lut crevette
<crevette> salut seb128
<\sh> hmm...should /etc/init.d/ssh restart fail when a user is still logined via sshd or should it restart with kicking out the sshd sessions?
<\sh> right now, it just failes because port 22 is still available
<\sh> I mean, it could restart the main sshd process..without interfering with the sshd which is started for the user
<slytherin> Hobbsee: looks like pitti is too busy to take notice of bug 212801. Do you know anyone else who has the power to do it?
<ubotu> Launchpad bug 212801 in gnome-desktop-sharp2 "Please promote to main on powerpc" [Medium,Triaged] https://launchpad.net/bugs/212801
<Fujitsu> \sh: It does neither. It restarts the listening process only.
<Fujitsu> \sh: That's what it does.
<Fujitsu> slytherin: ubuntu-archive \ {Hobbsee}
<\sh> Fujitsu, hmm...
<\sh> Apr  7 10:15:09 home-emt64 sshd[13757]: Received signal 15; terminating.
<\sh> Apr  7 10:15:09 home-emt64 sshd[13775]: Server listening on :: port 22.
<\sh> Apr  7 10:15:09 home-emt64 sshd[13775]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
<\sh> so what is the error message then?
<Fujitsu> \sh: Hum. That would happen if the socket was closed improperly, or if another process is actually listening on it.
<crevette> \sh, netstat -taupen |grep 22 helps
<slytherin> Fujitsu: I didn't understand.
<Fujitsu> slytherin: Bah, that was normalish set notation.
<sjoerd> \sh: That error is perfectly normal and can be ignored
<Fujitsu> Any member of ubuntu-archive, except Hobbsee.
<slytherin> Fujitsu: are you the member?
<sjoerd> \sh: under linux if you listen on :: then you listen on the same ipv4 port too by default, causing the error meesage
<Fujitsu> slytherin: I don't appear to be a Canonical employee, so not as far as I know.
<slytherin> Fujitsu: or do you know anyone else who is online right now?
<\sh> sjoerd, evil...
<sjoerd> \sh: not really
<\sh> sjoerd, well...when I read the error message, it can give me the view, that the restart didn't work properly somehow..but that's just me
<sjoerd> right, the error message is indeed a bit misleading
<\sh> another thing, why I actually restarted sshd, is vi /etc/login.defs and change hushlogin file from .hushlogin to /etc/hushlogins...and the described behaviour doesn't work somehow..while touch ~/.hushlogin  works as expected
<raphink> and it doesn't work in etch either actually
<raphink> it seems to have been broken for quite some time
<seb128> sjoerd: hey, your gnome-keyring dbus restart patch is crashing, I sent the bug to the bts
<sjoerd> #?
<raphink> there's hardly any info on hushlogin on google, apart from what's written in /etc/login.defs
<seb128> sjoerd: ok, you  don't read the pkg-gnome bugs, I was not sure ;-)
<seb128> sjoerd: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474418
<ubotu> Debian bug 474418 in gnome-keyring "gnome-keyring-daemon crashed with SIGSEGV in dbus_connection_remove_filter()" [Normal,Open]
<sjoerd> seb128: ah, you send it to the dbts :)
<sjoerd> seb128: i though you meant the upstream one :)
<seb128> sjoerd: no, I didn't know it had been sent upstream, that was still a debian change before today ;-)
<sjoerd> i do read the pkg-gnome bugs, but i tend to lag
<\sh> raphink, check apt-get source shadow , where /bin/login is created...
<\sh> raphink, looks like a bug inside the source
<raphink> yes, looks like login actually doesn't consider the HUSHLOGIN_FILE parameter
<raphink> but uses .hushlogin directly
<seb128> sjoerd: I would say bugzilla for the upstream bug tracker ;-)
<sjoerd> :)
<\sh> raphink, well, it does somehow but not as described
<raphink>                 addenv ("HUSHLOGIN=FALSE", NULL);
<raphink>                 /*
<raphink>                  * pam_unix, pam_mail and pam_lastlog should take care of
<raphink>                  * this
<raphink>                  */
<raphink> hi allee
<slytherin> seb128: Can you please look at bug 212801? It causes depwait for f-spot on powerpc
<ubotu> Launchpad bug 212801 in gnome-desktop-sharp2 "Please promote to main on powerpc" [Medium,Triaged] https://launchpad.net/bugs/212801
<slytherin> raphink: please use pastebin
<raphink> sure
<raphink> sorry
<allee> morning raphink, long time no see
<raphink> \sh: the definition of this variable seems to be controlled by the hushed function
<\sh> yepp...
 * \sh stops now and goes home
<raphink> which is returned by pam_open_session
<seb128> slytherin: could do that, the bug has been opened on a sunday and is open for less than a day though, no need to ping people on IRC
<slytherin> seb128: Ok. Will keep that in mind now onwards.
<raphink> ah no
 * Nafallo ponders
<Nafallo> anyone know of a bug with backlight? my vaio seems to have it turned off in hardy.
<seb128> Nafallo: gnome-power-manager issue? You want to speak to ted when he'll be around, it's sunday night still for him right now
<raphink> hmmm
<raphink> hushlogins actually works with the login command, but not with ssh
<raphink> \sh: openssh deals with hushlogin itself without using login
<raphink> session.c:      snprintf(buf, sizeof(buf), "%.200s/.hushlogin", pw->pw_dir);
<Nafallo> seb128: dunno where it comes from. will speak to him, thanks :-)
<james_w> I want to force a debconf question on some upgrades to help fix a problem that existed in some previous versions of a package.
<james_w> This works fine when the package is installed with dpkg, but not with apt, as that calls config twice for the upgrade, and so I end up forcing it to be shown twice.
<james_w> What would be the best way to ensure that the question is only shown once on the upgrade?
<james_w> as far as I know config is called with the same arguments both times isn't it?
<cjwatson> james_w: I take it this is a debconf question that already existed beforehand?
<james_w> cjwatson: yes, this is ca-certificates again.
<cjwatson> james_w: I've done this kind of thing before; bear with me while I find an example
<james_w> I'm overriding the seen flag in certain cases to give a prompt to the user when we are reasonably sure that they were hit by the bug.
<james_w> unfortunately I didn't test with apt as I didn't realise there would be this difference.
<cjwatson> (I did it by setting a different flag, seen_in_<whatever version>_upgrade, IIRC; flag names are actually quite free-form even though "seen" is special)
<james_w> ah, so you can set arbitrary things with db_fset?
<cjwatson> james_w: right; look at /var/lib/dpkg/info/man-db.config
<james_w> thanks.
<cjwatson> james_w: and the cleanup code near the end of the postinst
<cjwatson> james_w: at the time, joeyh said he'd never heard of anyone else taking advantage of the fact that you can have arbitrary flags, so I got to feel special ;-)
<james_w> :-)
<james_w> this is an SRU as well, so should I use one flag value and not clean up until hardy, so that the user will only be prompted once?
<cjwatson> hmm
<cjwatson> that would work
<cjwatson> I'm not sure whether I prefer that, or special-casing the SRU versions in hardy
<cjwatson> yours is probably neater given that dealing with non-trivial trees of versions is a pain
<james_w> yeah, pitti wasn't happy with my initial version that special cased the versions, so the current code will prompt once per distribution upgrade.
<cjwatson> not cleaning up the flag in the SRU is fine as long as it gets cleaned up eventually. I do have an objection to leaving cruft in the debconf db that never gets cleaned up, but "eventually" is fine.
<beasty_> morning
<beasty_> is it hard to setup your own apt-repository
<beasty_> ?
<Daviey> no
<beasty_> ok i found a mini howto
<beasty_> now next step
<beasty_> is it hard to create a .deb file ?
<beasty_> and if not ... is there a howto avail ?
<crevette> create a deb, for me means nothing; you want to create a new package from scratch ?
<crevette> or just rebuild existing package
<beasty_> crevette: build somthing from scratch
<crevette> I would start to read docs on internet on debian.org
<crevette> and look in package sources for example
<crevette> apt-get sources <packagename>
<beasty_> ok
<seb128> https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/index.html
<seb128> you can read that
<seb128> https://help.ubuntu.com/ubuntu/packagingguide/C/index.html rather
<crevette> ah yeah this one is neat
<beasty_> just some files that need to be placed somewhere i'll figure it out
<beasty_> thanks for your help seb128
<beasty_> and crevette
<crevette> you're welcome
<beasty_> crevette: the fact is
<beasty_> the pages you gave me were from c/c++ projects
<cjwatson> beasty_: it doesn't make much difference; the only thing that really changes is what you put in the debian/rules build target
<beasty_> all i need is that some files are distribuated to certain directories
<cjwatson> since compiling source is strictly more complicated than just putting files in place, you can just simplify what you have
<cjwatson> also read debhelper(1) and its various child manual pages, specifically dh_install(1)
<seb128> TheMuso: around to discuss launchpad integration changes?
<TheMuso> seb128: Yes I am.
<seb128> TheMuso: what would you think about changing the launchpad_integration_add_ui to add the separators automatically?
<seb128> TheMuso: that's what is used in most cases, it would mean we can use the short version and update quickly the packages using it
<TheMuso> seb128: I don't know why that wasn't suggested in the first place, so no argument from me.
<seb128> since the semantic change we can bump the soname
<seb128> so we know what we need to rebuild
<seb128> and the changes are just dropped the separators in the xml descriptions
<seb128> s/dropped/dropping/
<TheMuso> Yeah I gathered.
<seb128> cjwatson: any opinion on doing that or not?
<TheMuso> Do you want to keep the additional function, i.e the _with_separators function?
<cjwatson> entirely your call as far as I'm concerned
<cjwatson> does it deal with handling the case where the LPI bits are at the start or end of the menu?
<seb128> TheMuso: yes, it can be useful in case we don't want add a separator before and after which can happen
<seb128> cjwatson: we still keep the new function for those cases
<TheMuso> seb128: ah of course.
<seb128> but right we could try to get the standard function clever and detect menu start and end
<seb128> but not something for hardy
<cjwatson> as long as the old library is kept around until everything's rebuilt, the disruption should be minimal
<seb128> ok
<seb128> TheMuso: can you do that now? ;-)
<seb128> GNOME 2.22.1 tarballs are due today
<seb128> so if we can land the lib change before the uploads we will have most of rebuilds done easily
<TheMuso> seb128: Yes I can... You said to bump the soname? I still don't quite understand why, if the API is staying the same...
<seb128> TheMuso: the sementic change, we needed to add the separators to the ui description and we don't now
<seb128> TheMuso: and that makes easier to know what needs to be rebuilt or not
<seb128> TheMuso: I don't have a strong opinion about it though
<tjaalton> could an archive admin please sync tightvnc, since the current version is uninstallable
<TheMuso> seb128: Ok. We are only bumping the soname for liblaunchpad-integration, adn not lpint-bonobo?
<seb128> TheMuso: right
<TheMuso> seb128: Ok, I'm on it.
<seb128> TheMuso: if that's possible, if they are coded to have the soname changing both is no issue
<TheMuso> Ok.
<seb128> tjaalton: ups, forgot the other day, I just synced it now
<tjaalton> seb128: heh, thanks :)
<Riddell> infinity: I managed to run BuildLiveCD locally and it does indeed stop at 72% for kubuntu-kde4
<Riddell> now I wonder where to start in reproducing it
<TheMuso> sebOk code changes are done, give me a bit to test.
<TheMuso> gah
<TheMuso> seb128: One question. What part of the soname needs to be bumped? I'm guessing one of the minor fields?
<seb128> TheMuso: wait, I've got yet another idea
<TheMuso> seb128: Ok.
<seb128> TheMuso: can we look to the previous and next element and know what they are?
<TheMuso> seb128: I don't know enough gtk to comment.
<seb128> TheMuso: in which case we can add the separators only those are not separators already
<seb128> TheMuso: hum, not trivial to do and not required I would say, let's do the soname change rather
<seb128> TheMuso: the soname is the number directly after .so, the major number
<TheMuso> seb128: Right, I thought the soname referred to all three numbers as a whole.
<seb128> TheMuso: anyway it's late for you now no? Maybe let's continue tomorrow rather than rush if you want
<TheMuso> seb128: I'm at the point where I'm ready to test my changes, its fine I can do this now.
<seb128> TheMuso: ok, thanks
<TheMuso> seb128: A quick question about seahorse. Is there any way we can get seahorse agent to load in a way that it sees the GTK_MODULES environment variable for at-spi? Currently the pop-up dialogs for SSH/GPG keys are not accessible, because seahorse-agent loads too early.
<seb128> slomo: ^ do you know about that?
<seb128> TheMuso: what do you call seahorse agent? gnome-keyring does ssh and gpg in hardy now
<TheMuso> seb128: seb128 in /etc/X11/Xsession.d there is 60seahorse, which queues seahorse-agent to be loaded...
<TheMuso> Unless that is a remnant left on my system...
<siretart> seb128: does gnome-keyring happen to support keys from a gnupg smartcard?
<lamont> The following packages will be REMOVED
<lamont>   linux-686 linux-generic
<lamont> le huh?
<Ng> TheMuso: the seahorse package claims that file here, and I too have seahorse-agent parenting my session
<seb128> siretart: no idea
<seb128> TheMuso: hum right, I guess gnome-session should start it rather or something
<TheMuso> seb128: Right, maybe something for hardy+1. I'm just thinking of others. I can work with the dialogs fine myself.
<seb128> ok
<siretart> seb128: is there some announcement or something about the gpg support in gnome-keyring? I fail to find it in the changelog?
<seb128> siretart: http://live.gnome.org/GnomeKeyring
<siretart> that page doesn't loose any word about 'gpg' nor 'gnupg'.
<siretart> it does talk about ssh, though
<slytherin> AFAIK, seahorse agent officially replaced gnome-keyring-manager
<seb128> siretart: are you sure it does gpg?
<siretart> seb128: you claimed that before. that's why I'm asking
<siretart> 14:37:00 < seb128> TheMuso: what do you call seahorse agent? gnome-keyring does ssh and gpg in hardy now
<seb128> siretart: typo then
<seb128> siretart: it does ssh
<siretart> seahorse does both (but without smartcard support)
<siretart> is it the intention to make gnome-keyring replace seahorse?
<seb128> siretart: I think so, at least the agent part, maybe not the user interface
<siretart> hm
<siretart> on what (gnome?) mailing list do such discussion happen?
<lamont> does update-notifier leave a file somewhere when there are updates available>?
<james_w> lamont: I presume it just asks apt.
<pitti> Good morning
<lamont> james_w: and the question is 'does it leave that info in a file somewhere, or is it completely in-core?'
<ffm_> Hi, I have a bug that is _really_ a blocker for FF3 in hardy, can someone take a look at it?
<ffm_> (It affects certin pages seemingly for no reason)
<Riddell> ffm_: ask asac politely
<ffm_> Can someone please look at Bug #212315
<ubotu> Launchpad bug 212315 in firefox-3.0 "Page does not render, old tab appears in place" [Undecided,New] https://launchpad.net/bugs/212315
<ffm_> Riddell: How's that?
<pitti> soren: I'll have a look at 197968
<pitti> YokoZar: ia32-libs> no, of course not
<ffm_> Hm.. it works... odd...
<slytherin> lamont: there is a file /var/lib/dpkg/status which has status of all the applications. I guess apt uses this file and compares list of packages to determine if upgrades are available
<Ng> ffm_: the page you link to works fine for me
<lamont> slytherin: I know how to do the task over, I'm just wondering if update-notifier has made it trivial
<pitti> slytherin: promoted
<slytherin> pitti: thanks. Can I also ask you for a give back for f-spot?
<pitti> slytherin: nothing to give back, it's depwaiting
<slytherin> pitti: so will it automatically start building? It was depwaiting due to libgtkhtml3.16-cil being in universe
<james_w> lamont: it seems to ask /usr/lib/update-notifier/apt-check
<pitti> slytherin: yes, it will
<slytherin> pitti: Ok. Thanks a ton
<james_w> lamont: which does "sys.stderr.write("%s;%s" % (upgrades,security_updates))"
<asac> ffm_: for me that page works
<lamont> james_w: kewl
 * Hobbsee just gave it back
<Hobbsee> hmmm
<dholbach> cjwatson: do we build xubuntu from universe nowadays?
<megabyte405> hello dholbach
<dholbach> hi megabyte405
<TheMuso> dholbach: yes we do.
<dholbach> megabyte405: as i understand it: abiword is currently in main because xubuntu made use of it, as TheMuso just said we build xubuntu from universe nowadays
<dholbach> megabyte405: which means: if we move abiword to universe we wouldn't have to bother filing main inclusion requests for build-dependencies
<megabyte405> hmm
<Fujitsu> abiword is also about the only wordprocessor that doesn't suck... demoting it sounds bad.
<megabyte405> yeah, I'm not immediately in favor of moving abi to universe
<seb128> Fujitsu: having it outdated doesn't sound good either though
<slytherin> Hobbsee: looks like you did the give-back too early. Let it be handled automatically now. :-)
<Fujitsu> seb128: This is true.
<dholbach> seb128: bug 202174 is all about getting it updated
<megabyte405> I'd rather make a subpackage abiword-collaboration
<ubotu> Launchpad bug 202174 in abiword "Please update to version 2.6" [Undecided,Confirmed] https://launchpad.net/bugs/202174
<seb128> dholbach: well, you start speaking about promoting new things
<dholbach> megabyte405: still it'd build from the same source package (which is in main, so all of it's build-depends would need to be in main too)
<dholbach> seb128: no, I pondered demoting it
<megabyte405> dholbach: oh, I see
<seb128> I think it makes sense to demote it
<megabyte405> hmm, so that's not a good situation in eitiher way.  What would be the estimated effort to get asio in main?
<dholbach> getting changes into abiword in ubuntu would be quicker too, if it lived in universe
<megabyte405> is there a downside?
<cjwatson> dholbach: I don't believe that's the only reason abiword is in main
<dholbach> megabyte405: https://wiki.ubuntu.com/MainInclusionProcess
<dholbach> cjwatson: oh, ok
<cjwatson> dholbach: it's in the Ubuntu DVD seed
<dholbach> cjwatson: I didn't bother grepping though the seed commit logs, just checked the rdepends
<dholbach> alright
<megabyte405> I would rather remove collab for the time being, I think
<dholbach> megabyte405: that'd mean setting a build option?
<megabyte405> yes
<dholbach> right
<megabyte405> or simply not having the dependency, configure will turn it off automatically if we don't satisfy the dependencies
<dholbach> I see
<megabyte405> I'm gonna say for now, let's keep it in main, I'll turn off collab, and consider submitting an abiword-plugins-universe package
<seb128> new source?
<dholbach> 2.6.2 afaik (bug 202174)
<ubotu> Launchpad bug 202174 in abiword "Please update to version 2.6" [Undecided,Confirmed] https://launchpad.net/bugs/202174
<seb128> dholbach: just pointing that a new binary will not remove the need for the Build-Depends to be in main still
<seb128> dholbach: if that's what is suggested there
<Riddell> infinity: seems to be caused by kde-l10n-de
<megabyte405> seb128: yes, I would package abiword-plugins again and only enable the universe-required ones
<megabyte405> a very simple package, I think.
<megabyte405> brb - temporarly laptop sleep
<dholbach> seb128: I'm not sure I understand
<seb128> dholbach: well, those tools are built from abiword itself, so would the new abiword-plugins-universe suggested there be a new source in universe?
<dholbach> I don't know
<TheMuso> seb128: Ok things look ok with an evince test. I'll update the patch in launchpad-integration as well, and will upload...
<seb128> TheMuso: thanks!
<megabyte405> the trouble package is just a bunch of headers
<megabyte405> since it doesn't have to be compiled, I could just patch it in to the source
<TheMuso> seb128: Ok so I've bumped the soname from 0 to 1, renamed the liblaunchpad-integration package... Just checking this is correct before I go ahead?
<seb128> TheMuso: sure, do you have your source package somewhere?
<TheMuso> seb128: Not yet, I can push to a bzr branch if that helps.
<seb128> TheMuso: well, as you want, I can have a look if you have the updated version somewhere
<dholbach> megabyte405: not sure if that's a good solution - we try to avoid duplication of code wherever we can
<TheMuso> seb128: ok just a sec.
<megabyte405> dholbach: I agree it is not a good solution - it would be while I go through the MIR process for asio-dev
<megabyte405> a "stop gap measure" if you will
<TheMuso> seb128: http://bazaar.launchpad.net/~themuso/launchpad-integration/new-api
<seb128> TheMuso: seems fine to me, if that works correctly just upload ;-)
<TheMuso> seb128: Ok thanks for the review, will do so now.
<seb128> thanks for the work on that
<TheMuso> No problem.
<ffm_> asac: Must be an issue on my end then.
<emgent> heya
<TheMuso> seb128: Ok uploaded. The new binary packages will have to be newed, otherwise the other bits of launchpad-integration, and apps that depend on them will be uninstallable.
<asac> ffm_: try to disable extensions
<cjwatson> TheMuso: note that binary uploads don't get accepted until all their binary packages have been NEW-processed, if necessary
<cjwatson> so the only way you can get into that situation is with Architecture: all binaries
<cjwatson> (in the event that the i386 build is processed out of sync with the others)
<TheMuso> cjwatson: Oh ok.
<TheMuso> Makes sense.
<TheMuso> cjwatson: Managed to reproduce that libssl bug, which I've partially tested a fix for, but the rest is for tomorrow, so goodnight all.
<cjwatson> night!
<seb128> TheMuso: ok, thanks and have a good night!
<adrian15> Does anyone apart from tuxcantfly, who seems not to be online, how to do I build a unetbootin image from source code? Thank you.
<cjwatson> adrian15: what does "unetbootin" mean? (Obviously I can make a good guess but there are a few slightly different things you might mean and it would be better if you expanded your abbreviation.)
<leon_pegg> wasabi hello are you still pursuing your https://help.ubuntu.com/community/ThirdPartyApt blueprint?
<wasabi> Eh. It's something I'd like to work on, given infinite time.
<wasabi> Actually, there are a few people workign on similar things now...
<wasabi> But I still like mine better. :0
<leon_pegg> gapti is an implementaion of thrid party apt but its broken :(
<wasabi> Yeah. I know. I wrote that.
<wasabi> It was pretty crappy. Callouts to bin/gpg and apt and stuff.
<wasabi> If I was redoing it today, I'd probably integrate it somehow into the Add/Remove or update-manager bases.
<wasabi> Which seem to provide a lot of the mechanics already.
<wasabi> It's actually probably a 24 hour task for somebody familiar with that code.
<leon_pegg> I was wondering what the current state of development was as I was planning to give a go at implementing it myself
<wasabi> Oh yeah?
<wasabi> gapti to me was more just a proof of concept. I just wanted to see if I could write a program that could do the basics, show the right dialogs, etc.
<leon_pegg> I run a repository at http://the.orangearchive.net/ (http://deb.orangearchive.net/)
<adrian15> cjwatson: I am talking about this: http://lubi.sourceforge.net/unetbootin.html
<adrian15> cjwatson: I want to make a custom super grub disk build for windows.
<wasabi> leon_pegg: I highly recommend you investigate harmonizing with the add/remove or update-manager bases. And if not that, then integrate directly into synaptic.
<leon_pegg> ok, do you have any other segestions for me before I start
<wasabi> Not really. Maybe think harder about my file format before continuing.
<wasabi> I'm not too happy with the way I sign the file.
<wasabi> I'm not even sure it needs to be signed.
<leon_pegg> the one thing I noticed was that the apt file had to have an install line
<wasabi> Yeah?
<leon_pegg> the file format seemed ok to me
<leon_pegg> well thats how the gapti worked (think i have a really old source copy)
<wasabi> Yeah.
<wasabi> The first line of the file is very non-conventional.
<wasabi> The mime type thing.
<leon_pegg> is it actually needed?
<wasabi> It originated because I was getting annoyed at text-based files without any good type of type indicator. ;)
<wasabi> Doing mime type detection on an extension sucks.
<wasabi> And with out, it looks like a plain ol' gpg signed file.
<wasabi> I dunno. I'd entertain other suggestions.
<wasabi> You know, one of the things I wanted to do was restrict the Install line to allow packages to be installed which are signed with the same key.
<leon_pegg> I was planning an almost exact implementation by your blueprint but if you have segestions on the fileformat I would love to know
<wasabi> But some people, who have a different aim for ThirdPartyApt than I did, thought that was a bad idea.
<wasabi> That is, ONLY allow packages with the same key.
<leon_pegg> that make perfect sense
<cjwatson> adrian15: oh, goodness, no idea then. I thought it was an abbreviation for something standard from Ubuntu.
<wasabi> For instance, if the file is signed with the Ubuntu key, then it can only install packages from Ubuntu's archives.
<wasabi> If it's signed with Your key, then only repositories signed with your key would be installable.
<cjwatson> adrian15: I'm not sure this is the best place to ask, since it doesn't come from us
<wasabi> But this introduces a problem for some people, who want to be able to easily link to Ubuntu packages.
<wasabi> Me, I don't care about this people. I don't think that is very useful.
<leon_pegg> wasabi, I think that maybe we could completely kill the install line
<wasabi> How so?
<wasabi> If vmware hands you a file, I'd only want vmware to initiate install of vmware.
<leon_pegg> because we have apturl
<wasabi> (that could depend on other files)
<leon_pegg> as the person clicks the link for the apt file (which installs the repository) then the user clicks the apturl link that then installs the program
<wasabi> What's apturl?
<leon_pegg> apt://php5-cli
<wasabi> Oh. Eh. I never really liked that.
<soren> pitti: "13:04:45 < pitti> soren: I'll have a look at 197968"   Ok, cool! I'm not sure why you're telling me, though :)
<wasabi> Dunno.
<leon_pegg> clicking that from firefox in gutsy will ask the user to install php5-cli package
<wasabi> For a web page to be able to randomlly initiate an install from any repositiory, to me seems dangerous.
<wasabi> It's not really non-secure. The user still has to accept it... but it's confusing.
<wasabi> Which may make the user make a wrong choice.
<pitti> soren| 15:34:39 < xhaker> ahh weekends... pitti care to look into bug #197968
<ubotu> Launchpad bug 197968 in libmtp "Link in udev rules.d" [Wishlist,Confirmed] https://launchpad.net/bugs/197968
<pitti> soren: ^ because of that
<adrian15> cjwatson: :) I supposed that 8.04 included lubi... when you open cd in windows it asks you to install ubuntu into windows as an image... isn't it ? ;)
<leon_pegg> saying that we have to put some trust in users to make informed choices
<wasabi> Sure, but we have to be able to not present those users with confusing choices.
<cjwatson> adrian15: 8.04 includes wubi, but not unetbootin
<wasabi> Or misleading.
<cjwatson> adrian15: lubi is a different frontend, AFAIK
<leon_pegg> very true.
<wasabi> I sort of just do not really like the idea of some random webpage on the internet installing Ubuntu packages.
<leon_pegg> its posible now apturl is installed by default in gutsy
<wasabi> Oh. Great.
<wasabi> See, to me it's not that big of a deal... what it is is misleading.
<leon_pegg> wasabi, the way I see it is your spec is designed to allow users an easy way to add third party repos making the spec have the ability to install packages to seems odd to be
<soren> pitti: Oh! Hehe :) That was just me pasting a few lines of scrollback for cody.
<wasabi> If I install an Ubuntu package, I expect to do so from an official looking ubuntu.com page.
<wasabi> leon_pegg: The spec's purpose is to assist ISVs.
<wasabi> leon_pegg: That is all. I want people like VMware to be able to offer a great user experience, so they choose to use Ubuntu.
<wasabi> leon_pegg: Click here to Install VMware Workstation 6.5!     Or some big nice looking button. And it asks the proper questions, sets up the proper stuff, and Just Works.
<wasabi> The spec's purpose is not to install Ubuntu packages. We already have tools for that.
<leon_pegg> maybe having the spec so it does not have to install packages but can also just add the repository and key
<wasabi> See, I don't really think user's give a damned about repostories and keys. They just want software.
<wasabi> The repositories are just an implementation detail.
<wasabi> They want to a) install something b) make sure updates are tracked.
<leon_pegg> yes but a key concept of your blueprint is the adding of the repository and key
<wasabi> Which is not something I wanted to describe to the user using that language.
<wasabi> I wanted to describe it more like:   "Do you approve of the installation of VMware distributed by VMware, Inc?"   "yes"   "no"             "Do you want to trust VMware to deliver future updates to installed components?"
<leon_pegg> ah that sounds much better
<wasabi> This is about making the Ubuntu user experience attractive for ISVs, so they are motivated to consider Ubuntu a main platform.
<wasabi> And deploy .debs, and track updates.
<wasabi> And I really do mean third party ISVs.
<wasabi> And that does mean, usually, commercial.
<wasabi> But not always.
<leon_pegg> like the repository I maintain at orangeArchive its main task is to distribute php-gtk to debian and ubuntu users and keep it uptodate
<wasabi> Isn't that already in Ubuntu/Debian?
<leon_pegg> no
<wasabi> See, with open source software, it actually is easier to put it in the main archive.
<wasabi> s/open source/free/
<leon_pegg> I have only started packaging php-gtk it has also only just had an offical release before it was alpha/beta
<wasabi> So package it, get it in Debian main.
<leon_pegg> its packaged, and I am also working on getting it accepted
<wasabi> If getting it accepted is a big problem, then that process needs to be improved.
<wasabi> Which is a seperate issue from ThirdPartyApt.
<leon_pegg> I think its more to do with the guy from php-gtk
<wasabi> Now, I don't want to poo poo all over your motivation to work on ThirdPartyApt. :0
<wasabi> I just want to convey what my goal of it was.
<wasabi> To be honest, if you work on it, for whatever purpose you have, and it also fulfills mine, I'd be ecstatic. :0
<wasabi> Back when I wrote it apt:// did not exist.
<leon_pegg> I also run other repos that distribute software I have developed to client (the main reason I like Third Part Apt)
<wasabi> Also, I think I still disapprove of that idea. But there's apparently little I can do about that.
<wasabi> It's open for abuse.
<wasabi> Much like ActiveX and friends.
<wasabi> Though, I guess mine is too.
<wasabi> I guess my main concern is... we know we have packages in universe with security vulns. We know this.
<wasabi> I don't really want to make it super easy for random web pages to prompt users to install software, which says it's official Ubuntu software.
<wasabi> I don't mind ubuntu.com prompting users for that.    I don't mind random web pages prompting users for things and it NOT saying it's approved by Ubuntu, but by some other party.
<leon_pegg> thats were signing the files in your spec helps
<wasabi> But the cross over gets me.
<ScottK2> I look at PPAs and pretty well consider the third party repository question is resolved in Canonical's perspective.
<wasabi> scottK, review ThirdPartyApt spec before proceeding. :0
<wasabi> I just want to avoid, as much as possible, any random web page popping up a dialog to install FooBar and having it say it's signed by Ubuntu which is trusted.
<ScottK2> It doesn't mean I favor it, but that it's pretty well to late to worry overmuch.
<wasabi> To me that's misleading, and gives users a false sense of security.
<leon_pegg> I aggree
<wasabi> Hence the install line.
<leon_pegg> I would want to avoid that at all costs
<wasabi> packages on the install line must be signed by the same key that signed the original file.
<wasabi> leon_pegg: Another thing, if users say they don't want to track updates, I want the key to be untrusted.
<leon_pegg> that I agree with but as I see it installing packages at the same time does not prevent someone creating a copycat gpg key and doing it that way
<wasabi> And the repository to be removed.
<cjwatson> it should say "ubuntu.com" rather than Ubuntu, and make any internationalised domain name handling obvious
<leon_pegg> that makes sense
<cjwatson> (if the description is free-form and provided by the site, what's to stop evil.example.com saying that it should be described as Ubuntu?)
<wasabi> cjwatson: You are absolutely right.
<wasabi> And I agree that means the url comes into play somehow.
<wasabi> Anyways, obviously more thinking has to be done.
<leon_pegg> so we check the url against the repo url ?
<wasabi> Which is one of the main reasons I just never finished it.
<wasabi> leon_pegg: Or some sort of way to tie the file itself to it's origin.
<wasabi> Perhaps the file gets the domain name in it, and it must be launched from that domain (which will require some communication with browser in some way)
<leon_pegg> wasabi, communication with the browser is not to hard
<leon_pegg> instead of downloading the .apt file clicking a link to a .apt file will trigger the Thrid Party Apt program directly which downloads the file which then allows checking domain against the domain in the apt file
<seb128> slangasek: any news about the pixman update?
<leon_pegg> wasabi, I know how to go about this in firefox but not sure about other browsers
<_MMA_> seb128: We talked about the clock-panel applet and the space it has on the left when no home location is set for the user. Has/will this be fixed before release?
<seb128> _MMA_: will you send a patch? ;-)
<seb128> _MMA_: it has not been fixed yet, not sure if it'll, depends of upstream or if somebody works on the required change
<_MMA_> seb128: You mentioned it was a known upstream bug and was in the works. If it wont be fixed, Ill simple switch off the gconf keys for Ubuntu Studio users.
<seb128> _MMA_: your call
<seb128> I've no idea yet if that will be fixed or not before hardy
<_MMA_> Ok. I just didnt want to do it if a propper fix was gonna land for Hardy.
<seb128> _MMA_: ok, btw we still didn't get user complains about that
<wasabi> leon_pegg: All seems reasonable.
<leon_pegg> ok Well I am going to have a look over gapti and then browser the updatemanager add remove and the likes I'll let you know my progress
<keescook> tedg: your screen res stuff is very interesting -- I'm surprised 16:9 is less than 1 percent (I took your data and extracted 16:9)
<Ng> 16:10 shirley?
<Ng> err, I mean, surely that's what widescreen monitors are?
<broonie> They're traditionally 16:9...
<Pici> More recently 16:10...
<tedg> No, TVs are 16:9, most screens are 16:10
<tedg> 1920x1080 vs. 1920x1200
<Pici> Why? I dont know, thats just the way they are.
<keescook> yeah, that's why I was surprised.
<tedg> I thought more people would be using TVs also.  But then I found a lot of the TVs actually use 1920x1200 with the computer input.
 * broonie suspects that the resolution of the screen may differ from the physical aspect ratio.
<tedg> Yes, square pixels are unlikely on TVs, though most monitors have them.
<tedg> NTSC basically specified that they shouldn't be square so that most manufactures are used to that.
<slangasek> seb128: ack on pixman, but LP wouldn't let me submit that comment to thebug right now...
<keescook> my TV computer is 1920x1080 (but I don't browse the web with it...)
<tedg> keescook: See, you're skewing the stats.  Go get websurfing!
<keescook> heh
<tedg> I was pretty stoked that newz2000 posted those stats publicly so I could blog on them :)
<seb128> slangasek: ok, thanks
<seb128> slangasek: btw upstream fixed the clock applet timezone picking
<pitti> mvo: ah, installing your latest compiz crack now
<slangasek> seb128: which way did they fix it? :-)
<mario_limonciell> mvo, xtknight needed to talk to you sometime last night about too many vinagre desktop files showing in add/remove applications.  I thought it was some sort of list that needed to be modified for what "doesn't" show up in that list by default, but i forgot, so I referred him your way
<seb128> slangasek: added codes for countries and states in the xml database and changing the libgweather api to use those
<seb128> slangasek: which means a soname change but only gnome-applets and gnome-panel are using the lib so that's ok
<slangasek> seb128: mm, so the config dialog itself is still going to be upside down?
<xtknight> mvo, yup i am available whenever you are ready to talk about the vinagre stuff
<seb128> slangasek: yes, but I don't think that's an issue if the timezone selection is right, it means only 1 action = pick a city to get everything working
<slangasek> seb128: if all you want is time, the current picker is still nasty
<seb128> slangasek: switching those would mean you have to pick a timezone for nothing if you are going to select a location anyway
<seb128> slangasek: well nothing suggests to the user that the location is for weathering
<slangasek> seb128: and limiting the TZ selections by country code is not going to solve the problem for all locations in the US
<seb128> slangasek: so from an user point of view it's just picking the nearest town
<seb128> slangasek: they added coded by countries and by states I think
<slangasek> seb128: which is a pain in the ass - I shouldn't be presented with a cluttered UI for "picking the nearest town" if all I'm doing is configuring a clock
<seb128> slangasek: picking a town or a timezone is that really different?
<seb128> it's just pointing where you are on a map basically
<ScottK2> Depends on if the nearest major town is in the same time zone or not.
<slangasek> seb128: yes, picking a timezone is two levels (America -> Los_Angeles) and picking a city is five levels (North America -> United States -> Oregon -> Portland -> augh why wouldn't it let me pick Portland, oh goddamn it it's another submenu, ok I'll pick Hillsboro Airport)
<seb128> you can still change the timezone manually
<slangasek> changing the timezone manually is not a feature!
<slangasek> for > 90% of users, the timezone is the whole point of the exercise!
<seb128> slangasek: I disagree with that, 90% of the user will pick a location and be done with the dialog
<slangasek> huh?
<slangasek> for > 90% of the users, the *point* of picking a location is to get the time set right
<seb128> which is the case now if you pick a city in your timezone
<slangasek> a clock that can't get that right (which has been the case up until now) has been worse than worthless
<seb128> right, I agree with that
<seb128> but they fixed it to have the mapping working correctly now
<slangasek> it's still way more work than users should have to go through in order to pick a timezone
<slangasek> it's information overload
<seb128> it's not
<seb128> I just type my town name in the search entry
<slangasek> a) how is the naive user supposed to know that the only cities listed are ones with airport codes?
<slangasek> b) there are two Portlands in the US, and if I type in the search entry the wrong one comes up first
<seb128> click on "next"
<seb128> it'll go to the next one
<slangasek> yes
<seb128> anyway that's not to pick your system clock
<seb128> but only to add extra locations
<slangasek> but you have to be able to figure out from context whether you've got the right one in the first place
<seb128> I think that picking the right timezone is good enough and will have to do for hardy
<seb128> we have other issues to fix rather than this UI detail
<slangasek> if it really picks the right timezone now
<slangasek> I'm concerned that it's going to do the wrong thing for places like Indiana still, and we're not going to have any way to test for this
<seb128> why would it?
<slangasek> because Indiana is a single state with multiple timezones
<slangasek> whose borders are not determined by a line equidistant between the cities the zones are named after
<seb128> this whole thing is a mess ok
<seb128> but I think it'll have to do for hardy, it's only an extra feature to add locations in an applet
<seb128> it's not to configure your system clock nor anything
<slangasek> well, somehow when I went to fix my clock after the applet had screwed it up, the first thing I found that would do it was the 'locations' panel...
 * kirkland wishes he could click on a city (any city) in Texas on that map...  Finding Chicago is an exercise in patience and dexterity with a mouse :-)
<seb128> slangasek: we changed the dialog to use time-admin since
<seb128> kirkland: just type chicago in the search entry?
<kirkland> seb128: in the graphical installer?  you can do that?
<cjwatson> kirkland: you're talking about something completely different, then
<seb128> kirkland: we are not speaking about the installer
<kirkland> cjwatson: seb128: oh, sorry, then
<cjwatson> there's a bug open about the difficulty with that map, and it's on evand's list
<xtknight> what are you guys speaking aobut?
 * kirkland goes back to the meeting where his attention should be at the moment
<pitti> mvo: FWIW, compiz still works here; session management got a bit worse, though
<slangasek> seb128: right, so time-admin may indeed address that for most users.  I'm still concerned that we'll still get bitten by cases where the timezone boundaries don't follow the geopolitical borders
<pitti> mvo: before, terminals at least remembered their position and virtual desktop
<slangasek> off the top of my head, states in the US which have split timezones are: Indiana, Tennessee, Oregon, and Alaska
<seb128> slangasek: the xml is structured by zone, countries, states, etc so it should have no error between countries for example
<seb128> slangasek: now those 1 state = several timezones might require adding extra code to some locations which are in this case
<pitti> hm, I just tried adding Austin; it's off by one hour when using the time applet, hmm
<seb128> pitti: it likely picked the wrong timezone
<slangasek> pitti: the changes seb128 is talking about haven't been uploaded yet
<seb128> pitti: fixed code landing today when GNOME 2.22.1 is uploaded
<pitti> right, it chose America/Monterey instead of America/Chuhuahua
<pitti> s/Chu/Chi/
<pitti> seb128: ah, I'll try that; maybe that'll fix the search function,too
 * pitti hugs seb128
 * seb128 hugs pitti
<slangasek> pitti: America/Chihuahua is also wrong ;)
<slangasek> (it should be America/Chicago)
<pitti> *shrug*, maybe; the map doesn't show anything in the vicinity of Austin :/
<slangasek> true
<pitti> hm, removing places makes it crash/hang
<seb128> pitti: you really want to wait the update to test, vuntz has been fixing load of crashers and issues this week
<pitti> slangasek: hm, when I select America/Chicago, it would be 1 am; but it's 12 am here
<pitti> (^ in time-admin, not the panel)
<slangasek> hmm?
<slangasek> both of those times are wrong for Austin, even if you mean pm instead of am
<pitti> slangasek: I mean that Chicago is apparently not the right TZ for Texas, Austin
<pitti> erm, pm, sorry
<slangasek> it's currently 2pm in Chicago and in Austi
<slangasek> n
<slangasek> ... unless I've done something to screw up my own clock while we were talking :)
<slangasek> haha, it's 10am and my clock thinks it's 12
<slangasek> grr
<pitti> hm, the clock in the hotel says 12, and so does my mobile
<slangasek> oh, because I clicked on Chicago in time-admin, pff
<slangasek> ok, it's currently 12pm in both Chicago and Austin
<slangasek> so if you have a different time for Chicago, your system clock must be off..?
<pitti> Mo 7. Apr 18:12:53 UTC 2008
<pitti> Mo 7. Apr 12:12:50 MDT 2008
<slangasek> $ date --utc
<slangasek> Mon Apr  7 17:14:18 UTC 2008
<slangasek> so :)
<pitti> hm; TZs are soo confusing :)
<stgraber> pitti: yours is wrong :)
<pitti> I wonder what broke it
<pitti> it was still fine at home, hmm
<pitti> I might have broken it when I tried to set the timezone for here in the plane
<slangasek> :)
<mvo> pitti: thanks for the testing!
<dpm> could anyone tell me how are the LiveCd strings handled? what determines which packages will get a translation for the LiveCD? I'm asking because in the case of our language, it is very odd that the top level menus (Applications, Places, System) are not translated, but all the menus under those are. I've been told at #ubuntu-translators that I should contact the developers directly regarding that.
<Riddell> evand: any plans for a ubiquity upload? having installable Kubuntu CDs would be handy
<pitti> hah
<pitti> slangasek: thanks
<evand> Riddell: yes, blocked on a in progress fix by cjwatson for usplash issues.
<slangasek> pitti: for? :)
<pitti> slangasek:  helping me fix my TZ :)
<slangasek> ok, you're welcome. :)
<munckfish> cjwatson: Hi you there?
<jdong> mvo: just wanted to drop you a quick note that compiz 0.7.4 from your PPA works great on my Hardy macbook
<jdong> mvo: and that I think some of the new features in this compiz release such as the live previews in the Spaces switcher would be awesome to have in Hardy
<andre2> Could someone please try to get a Freeze Exception for bug 181909?
<ubotu> Launchpad bug 181909 in gnome-phone-manager "SonyEricsson phones can't send SMS" [Undecided,New] https://launchpad.net/bugs/181909
<mvo> jdong: cool, thanks for the testing! I'm applying for a freeze exception, whish me luck :)
<jdong> mvo: good luck! :D
<mvo> :P
<jdong> mvo: btw have you had a chance to look into that firefox-compiz bug? might be a good time to sneak in that fix
<mvo> jdong: which one in particular? that it switches workspaces when a new tab is opened? that is supposed to be fixed I think
<jdong>  bug 212542
<ubotu> Launchpad bug 212542 in compiz-fusion-plugins-main "Drop type=Utility from 01-animation-defaults.patch" [Undecided,Triaged] https://launchpad.net/bugs/212542
<jdong> that one
 * mvo looks
<jdong> firefox 3.0 beta 5 causes compiz to use ridiculously in-your-face animations on all drop-down boxes
<mvo> jdong: yeah, thanks! good point
<jdong> mvo: fantastic!
<poningru> hey sorry to be a bother but I was wondering where to take an sshfs bug
<poningru> I think this is mostly an upstream bug
<poningru> when I run rhythmbox over an sshfs mounted music lib
<poningru> it kills that sshfs mount
<poningru> I have the strace if anyone wants to take a look at it
<poningru> the server is running gutsy
<poningru> music library*
<james_w> poningru: the best idea is to report a bug.
<poningru> in launchpad?
<james_w> yes
<poningru> but... ok
<mdke> superm1: thanks for looking into bug 202301. I'm just wondering: do you think the modification of description you've done could be a separate bug, or do you think it is the same bug?
<ubotu> Launchpad bug 202301 in mozilla-firefox-locale-all "Firefox not translated/localized" [High,Confirmed] https://launchpad.net/bugs/202301
<mario_limonciell> mdke, (i'm superm1 @ work), I think it fits as the exact same underlying bug
<mario_limonciell> mdke, because those strings are put in the jar's
<mario_limonciell> mdke, so once the jar's are used, the original (visible) bug will be resolved
<mdke> mario_limonciell: right, ok! Thanks again for looking into it
<mario_limonciell> mdke, no prob.  Hopefully that info can get it solved now :)
<mdke> mario_limonciell: hope so
<cjwatson> munckfish: here now
<munckfish> oh hi
<munckfish> :)
<munckfish> howz it going?
<munckfish> I'm working on the ps3-kboot stuff
<munckfish> I had some questions earlier
<cjwatson> just finished assembling a bunk bed for my stepson, and now all my joints hurt
<cjwatson> but anyway
<munckfish> aha, flat pack or ... ?
<cjwatson> originally flat-pack, moved from mother-in-law's house by disassembling and reassembling
<munckfish> Ok just a couple of quick questions
<munckfish> First is
<munckfish> I know the big freeze is approaching
<munckfish> what's the score with getting other PS3 related packages in in the next few days? E.g. updating spu libs, docs, ps3 utils etc
<munckfish> all things I'd like to see done
<munckfish> but juggling work and wife I'm not sure how quick I could get through it
<munckfish> ?
<cjwatson> munckfish: doable if you hurry
<munckfish> right
<munckfish> deadline is 10th right?
<munckfish> if we miss it would we be stuck with old package versions for hardy's lifetime?
<munckfish> or I suppose they'd have to be backports right?
<cjwatson> there is some space for exceptions from the 10th to about the 13th or 14th
<cjwatson> but it'll be a beg-release-manager kind of thing
<munckfish> ok, tomorrow I'll list out what's needed
<cjwatson> backports are no use for stuff that has to go on the CD
<munckfish> I guessed as much
<munckfish> yep
<cjwatson> ps3-kboot desperately needs to be prioritised, since it doesn't work at all
<cjwatson> and no testing can be done
<munckfish> ok I've finished the scripts for it
<munckfish> just need to run with pbuilder
 * Mez sighs
<munckfish> Mez: was the sigh for us?
<Mez> no, for opera in feisty
<Mez> s/is/si/ :P
<munckfish> bit naff is it?
<Mez> munckfish, have a look at my post to ubuntu-devel :D
<jdong> any hardy 64-bitters who have some free time and boredom on their hands?
<jdong> the firefox 3.0~beta5 update brought on a slew of complaints of flash crashing significantly more often
<jdong> and the root cause for this still needs some triaging
<munckfish> cjwatson: thx for the info, I should get the kboot sources uploaded somewhere for review tomorrow
<munckfish> help - I'm getting "WARNING: The following packages cannot be authenticated" from pbuilder's satisfy depends. How do I get the sig key for hardy into my pbuilder env?
<crimsun> jdong: first isolate the sound backend in question.
<crimsun> jdong: (i.e., if necessary, get PA out of the picture, then continue debugging)
<tedg> megabyte405: Hey, are you making the Abiword packages?
<megabyte405> tedg: yes I am
<megabyte405> megabyte405=Ryan Pavlik=abiryan
<tedg> megabyte405: Cool.  They download and install for me now from your PPA.
<megabyte405> They did?  Great
<megabyte405> which version do you have installed?
<megabyte405> (presuming the ppa9 since I seem to have broken the ppa8 with over-eager dependencies)
<megabyte405> They've all worked for me, so go figure :)
<tedg> megabyte405: I found a couple little things that I want to mention (ppa9), there doesn't seem to be a menu entry in the Applications menu.
<megabyte405> really?  OK, will look into that
<tedg> megabyte405: And when I go to Collab, it doesn't have any protocols listed.
<megabyte405> Ah, yes, that would be because of a dependency error - we can build abicollab but no backends.  If I can't resolve this the way I'd like, I will just disable abicollab
<tedg> megabyte405: Heh, we'll I'd hate to loose abicollab, but I understand :)
<megabyte405> tedg: OK, I think I fixed the menu bits - I was under the impression that we had the desktop files in the upstream source, but it seems we don't.
<megabyte405> tedg: I would too - the trouble is the best back-end has a compile time dependency on libasio-dev, which is just a bunch of header files, but it's in universe
<megabyte405> and as I don't want to move abi into universe, I have to work around the issue.  Right now, my approach is patch those headers right into abi
<cjwatson> munckfish: ok, cool
<tedg> megabyte405: Could there be a "abiword-plugin-collab" package in universe?
<cjwatson> munckfish: should be there already; make sure something's done 'apt-get update' in the chroot
<munckfish> yeah
<munckfish> I think key is ok
<cjwatson> munckfish: (ubuntu-keyring is part of ubuntu-minimal, so you can't really be without it)
<munckfish> I think the problem is
<munckfish> when I update
<megabyte405> tedg: well, if the current approach doesn't work and I don't find someone important enough to push libasio-dev into main, in theory :D
<munckfish> it bails with
<munckfish> elmo: Internal Error, Could not perform immediate configuration (2) on tzdata
<munckfish> "E: Internal Error, Could not perform immediate configuration (2) on tzdata"
<munckfish> cjwatson: Is tzdata broken maybe, surely not at this stage?
<munckfish> that is what I get running the command "sudo pbuilder update --distribution hardy --override-config"
<munckfish> :(
<keescook> megabyte405: please don't embed duplicated code into a package (especially not one in main, and really especially not for code that has a universe counter-part).
<keescook> megabyte405: as part of the FFe for abiword, you'll have to get MIR's approved for the new build-deps that are in universe.
<megabyte405> ok
<megabyte405> there is only one - please see the bug https://bugs.launchpad.net/ubuntu/+source/abiword/+bug/202174
<ubotu> Launchpad bug 202174 in abiword "Please update to version 2.6" [Undecided,New]
<cjwatson> munckfish: try pbuilder login and upgrading by hand
<munckfish> ok
<munckfish> would that be same as
<cjwatson> although changes made in login won't be preserved
<munckfish> upgrading from gutsy to hardy using just apt?
<cjwatson> but it might let you see what's going on
<cjwatson> if you're upgrading from gutsy, I would suggest recreating the pbuilder environment from scratch
<munckfish> e.g. update sources list to point to hardy, then apt-get dist-upgrade right?
<munckfish> well I just
<munckfish> created it now
<munckfish> especially for hardy
<munckfish> but I am running on gutsy
<cjwatson> (but, worst case, you can do 'pbuilder --login --save-after-login', I think
<cjwatson> )
<cjwatson> I don't use pbuilder, so am just going on docs
<munckfish> ok I'll see what I can do
<munckfish> oh you don't?
<munckfish> is there any other way I can side step this
<munckfish> ?
<munckfish> e.g. if I test it builds on gutsy
<cjwatson> not necessarily to be emulated; I keep quite close track of the state of my system and just build in the base environment
<munckfish> is that safe enough?
<cjwatson> no, that's definitely not a good idea for this
<munckfish> so I should persevere
<cjwatson> you could install debootstrap from gutsy-backports, 'sudo debootstrap gutsy /path/to/new/chroot', chroot into that and install what you need by hand
<tedg> megabyte405: Did you file a MIR for libaiso already?
<cjwatson> pbuilder will likely be easier if you can get it to work though
<megabyte405> tedg: no, I haven't had a chance.
<munckfish> yeah
<megabyte405> (this has all transpired within the last 2 days)
<munckfish> cjwatson: thx
<cjwatson> (really, the reason I don't use pbuilder is that (a) I'm kind of old-school and have never got used to it (b) I used to be quite badly disk-limited on my laptop so tried to minimise extra chroots)
<tedg> megabyte405: I realize.  I'll submit one.
<megabyte405> tedg: great, that is much appreciated
<megabyte405> tedg: I've outlined my basic reasonings on my last (or second to last) comment on that bug - basically, if it's gone through the boost review, and it's good enough for them, that's pretty good, and as the windows maintainer of AbiWord too I'm used to staying current with the upstream anyway, and I know it's well maintained
<cjwatson> munckfish: bug 211120?
<ubotu> Launchpad bug 211120 in update-manager "hardy upgrade breaks on tzdata" [Medium,Confirmed] https://launchpad.net/bugs/211120
<munckfish> looking ...
<munckfish> hmm I think I'm stuffed then :(
<cjwatson> munckfish: don't see why that should affect fresh creation though. How long ago did you create this chroot?
<munckfish> 2 hrs ago
<munckfish> just recreating it now
<cjwatson> oh
<munckfish> to see if that helps
<cjwatson> well, that blows my first theory out of the water :)
<munckfish> first time around I did
<munckfish> sudo pbuilder create --debootstrapopts --variant=buildd
<munckfish> this time I just did sudo pbuilder create
<munckfish> according to
<munckfish> https://wiki.ubuntu.com/PbuilderHowto
<munckfish> first thing makes my chroot more like a buildd that's why I did that
<munckfish> I'm hoping (blindly)
<LaserJock> pbuilder uses the buildd variant I believe
<munckfish> that doing normal create will make this go away
<cjwatson> --variant=buildd should be fairly harmless; tzdata is Priority: required and thus in the buildd variant
<munckfish> :(
<tedg> megabyte405: So, it seems the asio version in universe is about 6 mo. old.  Have you asked the boost folks to upgrade to 1.35?
<cjwatson> also, tzdata hasn't been changed in a while ...
<LaserJock> munckfish: you're not able to create a chroot?
<munckfish> now running sudo pbuilder update --distribution hardy --override-config again with optimism
<megabyte405> tedg: we don't use the one in the new boost yet
<LaserJock> rather pbuilder
<munckfish> LaserJock: nope
<tedg> megabyte405: Are they different?
<munckfish> when I run the above command to
<cjwatson> LaserJock: his symptoms on update are similar to those in bug 211120
<ubotu> Launchpad bug 211120 in update-manager "hardy upgrade breaks on tzdata" [Medium,Confirmed] https://launchpad.net/bugs/211120
<cjwatson> which suggests a slightly more general problem somewhere
<megabyte405> tedg: only superficially - boost::whatever instead of asio::whatever
<munckfish> update my pbuilder to hardy
<munckfish> it fails
<megabyte405> tedg: right now we use the standalone one (can't use the boost-integrated one yet), which had its 1.0.0 "final" release a bit ago
<LaserJock> odd
<megabyte405> Our devs have brought asio 1.0.0 into fedora and suse already
<tedg> megabyte405: Yes, but hardy-universe seems to only have 0.38
<megabyte405> although all we technically need is 0.38 rc1 or newer - the hardy-universe one does work
<megabyte405> (I know, I have tested it, and I think that's what we're using on Windows too)
<munckfish> hmmm now it's stuck on
<munckfish> rmdir: /var/cache/pbuilder/build//15790/spu: Device or resource busy
<tedg> megabyte405: Yes, but that means there's a published list of problems with it ;)
<megabyte405> tedg: true - is that a good thing or a bad thing?
<munckfish> hmmm may have solved that by umounting it
<tedg> megabyte405: Not sure.
<munckfish> good news - it's worked fine now! thx for the help. I rebuilding the pbuilder env from scratch seems to have solved it some how. dunno how.
<cjwatson> ok, that's a (partial) relief
<megabyte405> ok, a new abiword source package is up on my ppa, should build soon
<emgent> geser: ping
<munckfish> cjwatson: two other things I should really double check with you to save time
<munckfish> 1. is version number - I decided to go with same scheme you and ben did
<munckfish> took overall version of upstream release
<munckfish> 1.6
<munckfish> set as 1.6-1 in our change log
<munckfish> I'm still not 100% on the versioning scheme I thought it would have to be 1.6-0ubuntu1
<munckfish> is it ok as 1.6-1?
<cjwatson> note that the current version doesn't have 'ubuntu' in its version
<ScottK> Is it in Debian as 1.6-1?
<cjwatson> ScottK: it's not in Debian at all
<munckfish> 2. I set the maintainer field to Ubuntu PS3 Port dev list addrss
<cjwatson> munckfish: both of those are fine
<tedg> keescook: Can you tell me about scunia?  It seems like a bunch of things come up in the search, but they don't mention if it was a library problem or custom code.  Is there some data in the back that they're using that they know it was a library issue?
<munckfish> cjwatson: pheweee
<ScottK> cjwatson: I thought we normally used -0ubuntu1 even for those.  We certainly do when reviewing new packages for Universe.
<cjwatson> ScottK: it's fine to do so, but not strictly required
<cjwatson> ScottK: and in any case it's clearly OK to follow the existing scheme
<ScottK> Fair enough.
<keescook> tedg: secunia?  they're a security advisory clearing house, basically.
<cjwatson> ScottK: there are cases where universe's policies are a bit overkill IMO; the diffstat requirement is an example I was wittering about elsewhere earlier today
<tedg> But, when I do a search, are they showing me all the data?  Or is some hidden?
<keescook> tedg: searching advisories can be a bit opaque.  Generally, it's all there.
<megabyte405> tedg: ok, in about 15 minutes there should be an updated binary package ready in my ppa, please update and let me know if it fixes your issue
<ScottK> cjwatson: For FFe's a lot of it depends on who's asking.  If you look in the approved ones, a lot of them don't actually have all the bits filled out.
<tedg> keescook: Okay, I'm searching for "asio" which is fairly generic, and I'm getting a bunch of "this devices is broken."  Which, in theory could be because of the library, but doesn't say so.  I'm guessing that they're just picking up the generic text.
<tedg> megabyte405: Great!
<ScottK> The documented requirements are meant for some of our less experienced contributors IMO.
<megabyte405> tedg: if you need my input for the MIR, just email me abiryan ryand net.  I have some work to finish here now, so I'll be paying less attention then going to bed, but I'll be back on it tomorrow when I have free time, just like today
<keescook> tedg: right, I tend to search using upstream names, and common packaging names (libasio, asio-devel, etc)
<cjwatson> ScottK: the problem is that diffstat is totally useless for any serious review.
<keescook> tedg: also, I find cve.mitre.org tends to have fewer false positives.
<cjwatson> ScottK: the only purpose I see in it is to present an appearance of a serious review. There's no way it can actually be used for a meaningful assessment.
<cjwatson> and telling less experienced contributors that it's required (and therefore, implicitly, that it's useful) is mis-educating them
<ScottK> I can see that.
<ScottK> Perhaps we ought to review how we do this at UDS and come up with more sensible requirements for Intrepid.
<cjwatson> certainly I understand the "depends who's asking" thing
<cjwatson> I think basically I'd like the process to contain no elements that I'm embarrassed to describe to others ;-)
<tedg> keescook: Cool, I explained all that in the MIR :)
<munckfish> cjwatson: huh this kboot takes so long to build, I can see why you and ben gave up on it :D
<ScottK> cjwatson: That sounds like a good criteria.
<Caesar> cjwatson: I just became aware that the alternate installer (in /usr/lib/finish-install.d/55netcfg) cleans out /etc/network/interfaces to pave the way for NetworkManager after the installation. Is there no way to opt out of this?
#ubuntu-devel 2008-04-08
<cjwatson> Caesar: it only does it if network-manager is going to be installed
<cjwatson> so the way to opt out is to arrange for network-manager not to be installed
<megabyte405> tedg: thanks for your help - I'm out for the night.  email if you need something, mention abiword in the subject
<megabyte405> (just in case my spam filter gets eager)
<Caesar> cjwatson: installing ubuntu-desktop makes that kinda hard
<tedg> megabyte405: Cool, NP.  Have a good night.
 * tedg types too slow.
<ScottK> cjwatson: Do you have a moment for a quick backports discussion.  jdong pointed me at you.
<jdong> haha keep the blame trail alive :D
<ScottK> Of course
<cjwatson> Caesar: ok, netcfg 1.40ubuntu5 allows you to preseed netcfg/network-manager to false
<cjwatson> ScottK: sure
<Caesar> cjwatson: You rock
<ScottK> cjwatson: clamav is releasing 0.93 with a soname bump a week before we release.  There's no way to reasonably stuff that into Hardy, so what I was hoping to do was to get hardy-backports ready early and have it (with rebuild rdepends) in hardy-backports at or nearly at release.
<ScottK> cjwatson: This would require us to loosen the must be in the development release before backport rule for a few weeks until Intrepid's tool chain is up.
<ScottK> Any problem with that?
<cjwatson> ScottK: any core-dev can upload to -backports directly, so technically it's feasible
<cjwatson> ScottK: I suggest uploading it to a PPA first so that at least it's been tested somewhere else
<ScottK> That's what I'd start with (PPA).
<cjwatson> but otherwise I'm OK with it
<ScottK> OK.
<cjwatson> hardy-backports should work already
<ScottK> Cool.
<ScottK> jdong: ^^^ we're in business.
<ScottK> cjwatson: Thanks.
<Dossy> Do Ubuntu's kernels include the ext2online patch?
<jdong> ScottK, cjwatson thanks!
 * lamont has a stupid nautilus et al question... any good victims around?
<lamont> specifically, when the user nfs mounts /mnt/foo-media, one machine populates that into the desktop and the places view of "the gnome explorer" (nautilus, I expect).
<lamont> on the other machine, on gutsy and on flatline-installed hardy, it doesn't.
<lamont> how comez is that?
<seb128> lamont: are you sure the machine which displays it use mnt?
<seb128> lamont: nautilus shows media mounts and not mnt ones
<lamont> I expect so.  it's an old unix geek
<lamont> although it could be that simple, I suppse
<Caesar> How do the Contents-${ARCH} files get generated? I feel like I'm reinventing the wheel here...
<lamont> apt-ftparchive contents is what you're looking for
<tedg> Ahh, I didn't realize that the subpackages of boost were in universe... bummer.
<tedg> I guess no Abicollab :(
<Caesar> lamont: thanks
<up_the_irons> guys, is there a channel for package building support? (trying to backport a package, which I've done a lot, but this particular package is bothersome)
<jdong> up_the_irons: #ubuntu-motu please
<up_the_irons> jdong: thanks
<LaserJock> tedg: boost is a new dep?
<LaserJock> dang it, I forgot the password to the printer
<tedg> LaserJock: Well, asio is needed for Abicollab.
<tedg> And asio has boost as a dep.
<LaserJock> ah
<LaserJock> that'd be kind of a big MIR
<slangasek> tedg: which part of boost?  boost source is already in main
<LaserJock> oh, right, I thought it said Universe
<tedg> https://wiki.ubuntu.com/MainInclusionReportAsio
<tedg> Is there instructions on how I make the bug in LP?  (like who to subscribe, etc.)
<slangasek> ubuntu-mir (there are instructions somewhere, but I don't have the url to hand)
<slangasek> ah, libboost-regex, my favorite
<tedg> Okay, I can't seem to find it after 10-15 minutes of searching...
<tedg> But is on Hardy?
<tedg> bug.
<tedg> Or on asio?
<slangasek> on asio
<tedg> I'm not optimistic on this one going through, but here it is: https://bugs.launchpad.net/ubuntu/+source/asio/+bug/213688
<ubotu> Launchpad bug 213688 in asio "Main Inclusion Report for asio" [Undecided,New]
<emgent> heya cjwatson
<mophead> Is there a usability development project?
<calc> new OOo in about 1hr
<calc> openoffice.org_2.4.0-3ubuntu2_amd64.build
<lamont> heh.  update-manager gets really pissy if you have an apt/preferences that pins a=hardy at pri 50. :-(
 * lamont mutters something about how it'd be nice to get the current git-core into hardy, while realizing that there isn't a checkbox on the feature freeze exception paperwork labeled "nice"
<jdong> lamont: haha you could use the old "it's got a test suite" argument
<lamont> jdong: well, it confused me for a minute when it bombed out on my laptop....
<jdong> lamont: but I'm sorry to say I used that one with bzr 1.3 and it did introduce a minor regression so ~release could be gun-shy :D
<lamont> then I figured out _why_ lzma was not scheduled for install...
<lamont> oh, git-core.
<lamont> yeah
<lamont> OTOH, 1.5.4.5-1~CAT.6.06 will land on zinc sometime this week, I expect.
<slangasek> Amaranth: do you have any comments on james_w's patch for bug #118936?
<ubotu> Launchpad bug 118936 in alacarte "Alacarte does not recover deleted menu items" [High,Triaged] https://launchpad.net/bugs/118936
<RAOF> Something seems to be sending pulseaudio SIGXCPU, which then makes pulse spin madly, consuming a CPU core for a couple of seconds before being killed.  (1) What's sending pulse SIGXCPU, and (2) How can I debug the spin/kill that happens once it's sent - I can't reproduce the behaviour under gdm.
<TheMuso> RAOF: Have you checked messages/syslog, and what pulse clients are you using?
<RAOF> TheMuso: I've got a single pulse client; banshee (trunk) -> gstreamer-pulse.  Neither syslog nor messages contain anything apropos.
<RAOF> Oh, and load averages are <= 0.5 for the last 15 min.
<TheMuso> Hrm.
<TheMuso> RAOF: Tried other clients?
<RAOF> No; that'll be the next step (after lunch).
<TheMuso> RAOF: Ok.
<RAOF> The step after _that_ will be trying on !rt kernel.
<StevenK> What's SIGXCPU?
<StevenK> I don't even recognise that signal
<lifeless>        XCPU           core      core dump may fail
<lifeless> and more usefully
<lifeless>        SIGXCPU     24,24,30    Core    CPU time limit exceeded (4.2BSD)
<lifeless> man 7 signal is your friend
<lifeless> RAOF: ^
<lifeless> RAOF: the CPU time being used is probably in the aport core handler
<lifeless> RAOF: which will be why you can't reproduce under gdm
<StevenK> Whoa. "CPU time limit exceeded"
<TheMuso> That sounds a little like something the rt kernel could cause.
<slangasek> could it?  traditionally that means you're using ulimit
<TheMuso> I'm guessing here.
<lamont> StevenK: as long as that wasn't irssi or such... :-)
<lamont> slangasek: maybe we should put a 6 hour ulimit on buildds?
<lamont> er, builds, even
<slangasek> lamont: <yuck>
<ion_> The volume 'CDROM' uses the iso9660 file system which is not supported by your system.
<ion_> Ooookay. :-)
<lamont> heh
 * lamont is sad that he has no consolekit sessions when he logsin
<RAOF> lifeless: Oh, thanks.  It remains odd.
<lifeless> indeed :P
<RAOF> Let's see if rhythmbox triggers SIGXCPU.
<RAOF> It seems particularly odd since pulse consistently takes up <= 1% of my fully-scaled-down CPU cores.
<lifeless> smells odd yes
<RAOF> OK.  For those playing at home, it seems that Rhythmbox does _not_ trigger SIGXCPU.
<jdong> any core-devs want to sponsor an extremely trivial debdiff?
<jdong> wait, where did it go....
<LaserJock> a Heisendiff? :-)
<slangasek> it was so trivial it dissolved back into the quantum foam
<jdong> actually I might just hold off
<ion_> Haha
<jdong> I was gonnna just add an empty dpatch patchsys to Transmission
<jdong> but I might as well wait for the patches to come in over this week
<jdong> unless there's some evil freeze that's coming up soon that I'm unaware of that won't let me put in a patchsys
<LaserJock> the 10th is a freeze
<LaserJock> but I doubt it's gonna make a difference
<jdong> LaserJock: does it make a difference between bugfix patches and adding a patchsys?
<StevenK> I thought the 10th was the freeze. As in, Hardy freezes and doesn't thaw
<Chipzz> jdong: won't you be unnecesarily diverting fmor debian then?
<LaserJock> StevenK: as in every upload has to be approved by a RM
<RAOF> It starts of a bit mushy first :)
<jdong> Chipzz: I'm not sure if it's necessarily unnecessarily
<StevenK> Ah, snow and then ice? :-P
<jdong> Chipzz: I need to backport 8 or so important bugfixes from transmission SVN with cooperation with upstream devs
<LaserJock> jdong: there's no patch system already in place?
<jdong> LaserJock: surprisingly not
<jdong> Chipzz: I'd rather not introduce a brand new release cycle of transmission this close to release
<Chipzz> jdong: well, you aren't changing the build system, only adding to it I guess
<LaserJock> jdong: if you want to stick close to upstream you can just not use a patch system
<jdong> Chipzz: particularly one that quirked on me, refusing to close when it's a tray icon and similar misbehavior
<jdong> LaserJock: that kinda sounds messy
<LaserJock> but with 8 patches it might be less hassle in the long run to just add dpatch
<Chipzz> jdong: I'm not arguing about the use of the patches btw :)
<jdong> LaserJock: yeah I figure it might become a nightmare to manage in case one of those patches turns out to be incorrect , etc
<Chipzz> but I think it's a guideline to try not to diverge from debian as much as possible?
<LaserJock> jdong: it can be sure
<jdong> Chipzz: agreed, but this divergence couldn't hurt
<jdong> Chipzz: Debian's already past us on transmission and they couldn't care much about what we're doing to Hardy's transmission
<Chipzz> jdong: wouldn't the appropriate course of action be asking the debian maintainer what he thinks about it? (not sure if you done that)
<jdong> Chipzz: well at this point I don't see how even if Debian adds a patchsys it'd help us
<jdong> Chipzz: Debian's on 1.11-1, we're on 1.06-0ubuntu4
<Chipzz> easier to merge back later?
<jdong> though of course in the long run a patchsys is going to be helpful
<Chipzz> well
<jdong> right now I'm more concerned about getting these changes into Hardy before freeze
<Chipzz> I'm not arguing against the patch system per se ;)
<jdong> transmission's in between a rock and a hard spot right now
<LaserJock> jdong: if you think you're gonna ever have to do an SRU or security update it can be nice
 * StevenK tries to figure what is dragging in pidgin-data
<jdong> a torrent client, probably feasible we'll find something wrong in 3 years
<StevenK> apt-cache rdepends doesn't help
<Chipzz> jdong: well, if the debian maintainer applies the same patch system as you do, it will be easier to merge back later
<Chipzz> as there will be only entirely new files instead of changes to files
<jdong> Chipzz: agreed
<jdong> Chipzz: I will talk to the Debian folks at the same time
<LaserJock> Chipzz: that's why he said that Debian has already passed us. It's unlikely they will go back and patch a previous version
<jdong> http://launchpadlibrarian.net/13197466/transmission.debdiff in case anyone feels particularly bored
<LaserJock> so if it's specifically for the Hardy version then Debian's not gonna care
<jdong> I believe this is the 2nd time I've added dpatch so a bit of reviewing where I hooked it in would be appreciated too :D
<jdong> grumble debdiffs don't represent empty files, do they?
<Chipzz> LaserJock: well yes. but what I meant is, if debian adapts the same patchsys, it will be easier to merge back post-hardy
 * jdong mutters a bit under his breath
<LaserJock> Chipzz: oh right, yeah
<RAOF> jdong: From memory you want to have a patch-stamp target, right?
<jdong> RAOF: the dpatch.make include handles that
<Chipzz> LaserJock: or if a sec bug is found, and debian has a patch, it would be easier to do a security update
<jdong> (I think :D)
<jdong> RAOF: from what I understand I just need to get the patch and unpatch rules in the right place with dpatch.make
<RAOF> jdong: Eh, probably.  Anyway, it's being called from a -stamp target itself, so should get called exactly once anyway.
<RAOF> This line brings back memories of great frustration: # touch config.status to prevent execution of autoconf
<jdong> :)
<dholbach> good morning
<LaserJock> morning dholbach
<jdong> oh it's that late already?
<StevenK> Heh
<LaserJock> jdong: that's exactly what I was thinking
<dholbach> hey LaserJock
<dholbach> hehe
<dholbach> 7:34 here :)
<dholbach> if that helps you making a decision :)
<StevenK> There's a 7:30 in the morning?
<LaserJock> I think that's what he's claiming
<StevenK> I don't believe it.
<StevenK> If mornings really exist, why are there only 12 hours on a clock.
<LaserJock> so true
<jdong> StevenK: I've heard, in some places, there are 24 hours.
<jdong> StevenK: but I've also heard that some places use unified base-10 measurement systems
<RAOF> jdong: Those crazy Europeans.  All sorts of decadent leftist improprietary.
<ion_> But at least OOXML is a standard everywhere.
<LaserJock> jdong: that's just cheating
<jdong> LaserJock: I know. For them they don't get cool math questions like how many ounces are in a ton...
<RAOF> LaserJock: How does that even work for you.  I mean, you're a scientist, and so presumably use the _sane_ measurement system in your work.  Does it cause cognitive dissonance?
<LaserJock> RAOF: no, it's even worse
<LaserJock> I use a mix of metric and imperial
<RAOF> LaserJock: What.  You _don't_ use the sane measurement system?!
<LaserJock> for instance my laser table is tapped on a 1" distance
<LaserJock> my optics are usually 1"
<StevenK> LaserJock: Your whole country uses a mix of metric and imperial
<RAOF> >.<
<LaserJock> but I also use mm,cm, and m
<RAOF> Man.  Imagine how much of a technological powerhouse the US could be if it _
<LaserJock> I have a table for converting between approximately 6-8 different units of energy
<RAOF> didn't_ use a broken measurement system.e
<LaserJock> well, we got it from the English, what can I say
<StevenK> I'm waiting for the US to realise their money system is metric, and switch it to imperial.
<RAOF> LaserJock: Except that you use a different measurement system to the English, right?
<LaserJock> RAOF: no, we have a lot that's the same
<RAOF> I mean, a US imperial gallon isn't the same as an English imperial gallon, or some such stupidity?
<LaserJock> some things are different some are the same
<StevenK> RAOF: See: "ton" and "tonne"
<slangasek> StevenK: that would, of course, be inconsistent with the rationale for not having switched to metric in the first place
<LaserJock> our ton is different than a tonne
<slangasek> RAOF: actually, a US "imperial gallon" is the same as an English imperial gallon; but a US gallon is not
<LaserJock> I don't think American's care so much what system they use as they are afraid of changing it
<TheMuso> RAOF: So it sounds like something banshee is doing.
<StevenK> slangasek: Why did the US not switch over?
<LaserJock> I still can't get used to C
<RAOF> TheMuso: Except that banshee isn't doing it now, either >.<
<slangasek> StevenK: inertia
<TheMuso> RAOF: even more weird. Still the RT kernel?
<RAOF> TheMuso: Yup.
<StevenK> The British resisted metric currency for years as being "too complicated"
<RAOF> TheMuso: I haven't rebooted.  I just came back from lunch, and everything works.
<LaserJock> StevenK: we'd just say "too expensive"
<RAOF> slangasek: Aah.  That makes it so clear!
<StevenK> No, I think your country has 100 million people who can't tell that miles and kilometres are both units of meaursement
<slangasek> RAOF: the gallon used in the US is .8 of an imperial gallon
<LaserJock> well, in 30 years we'll all speak spanish and then we'll convert ;-)
<slangasek> LaserJock: por quÃ© esperar?
<RAOF> slangasek: Is that _exactly_ .8 of a gallon, or something more traditional, like .79341 of an imperial gallon? :P
<slangasek> RAOF: well, entertainingly, units tells me it's 0.83267418
<slangasek> I had been led to believe it was exact
<StevenK> slangasek: You need to start doing freeze annoucements in 3 languages
<LaserJock> slangasek: because
<slangasek> StevenK: I thought about a Spanish poem for the opening announcement for hardy heron, but all the good poems are about swans, not herons
<LaserJock> well, I'm not moving to all metric until time is metric :-)
<StevenK> Haha
<TheMuso> lol
<LaserJock> you can't be all "metric is so wonderful" if you still have base-60 time units
<LaserJock> I'm sorry
<StevenK> I note milliseconds aren't base-60
<StevenK> slangasek: I doubt you'll find any Spanish poems about ibexes, either.
<RAOF> I don't know about where you are, but here in .au we've had decimal time since the 60's :)
<StevenK> And decimal currency since what, '66?
<LaserJock> StevenK: yeah, it's funny. Once you are to seconds it becomes metric.
<RAOF> Something like that.
<StevenK> I do recall the offical changeover date was Valentine's Day
<slangasek> StevenK: '66 what? petaseconds?
<StevenK> slangasek: '66 being 1966
<LaserJock> anyway, as a scientist I end up learning a variety of unit systems and converting to whatever the "norm" is
<LaserJock> it even varies between specialties within a field of chemistry
<StevenK> Or inventing your own
<LaserJock> I try to avoid taht
<LaserJock> reviewers aren't as impressed
<StevenK> What, especially if you name them all Mantha?
<LaserJock> "The rotational energy give to the molecule was 10^6 Manthas"
<slangasek> not "manthae"?
<LaserJock> ewwww
<LaserJock> you can't do that
<LaserJock> I'll have to also define the plural form
<slangasek> I can't?
<LaserJock> no, my unit my gramatical rules
<StevenK> Heh
<slangasek> heh
<StevenK> "
<StevenK> Doh
<YokoZar> Can I ask someone to download and dput a package for me?  For some reason dput is failing on the server I have it on, and I can't upload from home.  It's 400 megs, however.
<LaserJock> I think I should be an energy unit
<StevenK> "The plural form shall be Manthas, except on days defined below, in which case it's Manthae."
 * RAOF needs to play Mao with a sufficiently large group.
<LaserJock> "On the internationally recognized Mantha day the unit shall be called 'Jordans'"
<LaserJock> yeah, this is sounding good
<LaserJock> I need to contact IUPAC about this
<StevenK> And then LaserJock woke up.
<LaserJock> crap, still using kilojoules
<LaserJock> how come Joule get's his own unit? what'd he ever do that was so special?
<StevenK> "Intel would like to announce the general public availability of the Linux Connection Manager project (codename: ConnMan)."
<slangasek> dunno, better ask wikipedia
 * StevenK sobs.
<LaserJock> oh, well, I don't know what so special about the 1st Law of Thermodynamics that they guy needs a unit named after him
<LaserJock> pfft
<slangasek> to accompany their PCI abstraction layer, "CardShark"?
<warp10> Good morning
<StevenK> slangasek: Oh crap, I hadn't heard that one.
<slangasek> StevenK: that's ok, I'm making it up as I go!
<StevenK> I'm waiting for their new OOM algorithm, SerialKiller
<LaserJock> nice
<TheMuso> lol
<StevenK> And their back up utility, IvanMilat
<StevenK> (Sorry, that will only make sense to Australians)
 * TheMuso chuckles.
<LaserJock> I was gonna go with something called "Grifter" but I like SerialKiller better
<RAOF> And a select group af backpackers :P
<StevenK> RAOF: Well, yes.
 * RAOF is the _king_ of poor-taste.
<StevenK> Er, yes. That was worse than my joke. :-)
<StevenK> Nooooo, it requires resolvconf
 * StevenK spits
<seria-mau> i noticed that network mounts in fstab which become available are automatically mounted. how is unmounting in case a network link becomes unavailable supposed to work? nfs has some difficulties with that, afaik.
<slangasek> seria-mau: as a "lazy" unmount; processes that still reference the filesystem that's gone away will have issues, but there's really no graceful way to handle that
<ion_>      opera | 9.27-20080331.6fesity1 | http://archive.canonical.com feisty-commercial/main Packages
<ion_> Utunbu has Orepa in fesity. :-)
<lool> slangasek: w00t; we have a component mismatch issue with lrm-2.6.24-15 on lpia; it's in multiverse while linux-lpia and linux-restricted-modules-lpia pull it
<lool> slangasek: Could you please promote it to restricted?
<slangasek> lool: hrm, I just saw that myself and demoted those packages to multiverse; all of the lpia kernel packages have been in universe/multiverse up until now, is that intended to change?
<slangasek> (I assumed that the linux-meta packages being in restricted/main was a mistake, but ICBW)
<StevenK> Personally, I think -lpia should be in main/restricted, and -lpiacompat in universe/multiverse.
<StevenK> But that's me
<lool> slangasek: Ok; we (at least I) usually don't include multiverse in many of our configs such as pbuilder, virtual machines, moblin-image-creator runs, so I personally see that it will cause me some work to fix this, but I understand why it should go to multiverse
<lool> StevenK: What would be the rationale?
<slangasek> lool: well, it would be inconsistent to have the lrm packages in restricted but the other packages all in universe, which is where they've been up until now
<StevenK> lool: "Gut feeling" :-)
<lool> slangasek: However, all of this is in lpia which is a non-official arch, so I wonder whether it makes sense to repeat the fact that it's not supported by moving things to multiverse while we could keep them in restricted and decide to promote the arch to supported with less efforts
<lool> slangasek: Not sure we should judge on history, it might well be a long time error
<slangasek> lool: hey, I just put the packages in the component pitti tells me to :)
<slangasek> (or doko)
<StevenK> Ahhh, so pitti is the man behind the curtain!
<lool> I personally lived without multiverse most of the time until now, and I'm happy that it's not "reachable" from my apt-get installs
<StevenK> ln -s lool rms
<slangasek> dude harsh
<StevenK> Haha
<lool> Not until I wear a beard
 * dholbach hugs lool
<lool> slangasek: Ok, next question; are the *.txt files on people.ubuntu.com/~ubuntu-archive including lpia mismatches and there is no mismatch ATM or are they not including this unofficial arch?
<jamesh> dholbach: it's good to see that the AbiWord situation is resolving itself
<slangasek> lool: you're referring to http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt, or another report?
<lool> slangasek: This is the one which would have saved me some time today, yes
<lool> slangasek: But it's more of a general question, there are other reports which would be interesting for lpia too
<dholbach> jamesh: yeah, I'm very happy too to see it being worked on
<slangasek> I don't know, I'm not familiar with how that particular report is generated; but I suspect it's only for i386/amd64 at present
<lool> Hmm where's the installability report
<slangasek> lool: http://people.ubuntu.com/~ubuntu-archive/testing-ports/hardy_probs.html ?
<slangasek> but then, that gives you ports but not universe :)
<lool> slangasek: See how evil it is to need *verse!  ;)
<lool> slangasek: Ok; so you say you fixed the linux-meta tree in this report for lpia?
<lool> I guess I'll only see this in a couple of hours
<slangasek> I hadn't seen/done lbm yet
<lool> slangasek: Thanks for your time; I'd be happy if you could file a TODO whereever that is about including lpia installability and component mismatches reports
<slangasek> but linux-image* and lrm should now be consistently in the same component
<lool> slangasek: But what about linux-lpia?
<slangasek> lool: if you can open a bug and subscribe ubuntu-archive to it, that's probably best, given that I don't know where that report happens today
<slangasek> yes, linux-lpia as well
<lool> Ok, thanks
<lool> slangasek: I believe there is a wiki page or a text file /somewhere/, but I'll file a bug
<slangasek> heh, I can't fix linux-backports-modules-hardy without demoting it on all archs... I think we should plan to promote the lpia linux packages to main/restricted at some point...
<lool> slangasek: Who should we discuss that with?
<amitk> so naive question - this means the Section line in the control file is just a _request_, not a commandment, right?
<lool> amitk: Yes
<lool> amitk: Archive has the final override
<lool> amitk: Especially in the case of Ubuntu where we inherit Section from Debian for many packages, but need to change it
<slangasek> lool: pitti or doko, I think
<lool> slangasek: Email or bug report?
<slangasek> lool: I don't know, and it's too late here for me to have an opinion
<lool> slangasek: Ok; sorry for keeping you on the computer so late; sleep well
<StevenK> amitk: Same with the Priority, but they should match.
<slangasek> lool: not your fault :)  'night :)
<lool> #213808 for the *.txt reports for lpia
<amitk> cool
<Mirv> pitti: the (i18n) bug 199255 has a small fix waiting for sponsoring. so does bug 204155, but the first one is also assigned to you.
<ubotu> Launchpad bug 199255 in policykit-gnome ""Authorizations" shows untranslated, but it's translated in Launchpad" [Undecided,In progress] https://launchpad.net/bugs/199255
<ubotu> Launchpad bug 204155 in network-manager-applet "Nm-editor translations not loaded" [Undecided,Confirmed] https://launchpad.net/bugs/204155
<doko_> lool: http://people.ubuntu.com/~ubuntu-archive/component-mismatches-mobile.txt ?
<lool> doko: That's for lpia?
<doko> lool, yes, and the other one is http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt
<lool> Ok; I thought component-mismatches-mobile.txt was an old manually generated report as it didn't bear "lpia"
<lool> doko: Would it make sense to name it lpia? :-)
<lool> If it's just running the same script over lpia, that might be clearer; but then I can live with -mobile
<doko> lool: ask ubuntu-archive :-)
<lool> doko: Ok, I did
<lool> Uh, one can't subscribe multiple people at once in Malone?!
 * lool tried comma and space separated lists
<Fujitsu> lool: The best way to do that is to email.
<amitk> bleh... flash on amd64 with the 32-bit libraries is crash-prone
<laga> amitk: yup. used to be better..
<Fujitsu> Does it take Firefox with it these days?
<laga> not all the time :)
<lool> Fujitsu: The best way to contact ubuntu-archive?
<lool> Fujitsu: I filed a bug and subscribed pitti and doko to it (as well as slangasek and myself)
<Fujitsu> lool: Just subscribe ubuntu-archive...
<lool> I did that too
<lool> Sorry, failed to mention it, but I naturally subed u-a to both bugs first thing
<Fujitsu> doko is the only member of the above set that shouldn't have already been subscribed (either by filing it, or membership in ubuntu-archive).
<amitk> laga: npviewer crashes 10 times a day for me. Either _I_ watch too much flash-based stuff or the whole web is becoming flash-based... :-/
<lool> Fujitsu: I think direct membership can help focus a particular person on a bug (to make it clear this particular person is needed)
<laga> amitk: i use flashblog, but i like youtube a lot.
<lool> But I'm not into the magical ubuntu-archive stuff, so when I'm told this and that person should be in the conversion, I sub them  :-P
<laga> amitk: flashblock* :)
<Fujitsu> lool: Anyway, the emailing method I referred to is a bug to <bugnumber>@bugs.launchpad.net with some line of the body matching `^  subscribe someone someone-else some-other-person'
<Fujitsu> Er, s/a bug/an email/
<lool> Fujitsu: Ohhh ok
<Riddell> TheMuso, seb128: library transition on liblaunchpad-integration?
<seb128> Riddell: yes, I'm going to do that this afternoon, let it in NEW for now
<Riddell> seems a bit late in the cycle, but ok
<gustavonarea> Hello. I have an Atheros network card, which is not recognized in Gutsy. It's not even recognized the network card, nor the wireless one. `ifconfig' doesn't recognize it either. What can I do?
<seb128> Riddell: so are trivial changes and we have been asked to make possible to uninstall launchpad-integration in hardy if possible I understood correctly
<seb128> Riddell: the soname change was not really required, it just make easier to keep track of what needs to be updated
<gustavonarea> Well, I could find it with "lshw -C network", but it's listed as "*-network UNCLAIMED". It doesn't have an iterface name. What can I do?
<asac> TheMuso: some users report crashes with flashplugin-nonfree and youtube when pulseaudio is used (with libflashsupport). any idea if latest bug fix release might help?
<megabyte405_> new abiword build uploaded to ppa and building now
<kelemengabor> hi all
<kelemengabor> cjwatson: there is a problem with the debian-installer translation
<kelemengabor> the new template was just uploaded today
<kelemengabor> and has lots of new strings to translate
<kelemengabor> but the deadline is two days from now, and I don't think the imports will be finished to that date
<cjwatson> kelemengabor: I know, but I can't do anything about it now
<cjwatson> kelemengabor: I might arrange for a deadline extension if possible
<kelemengabor> well, how about delaying it a week?
<cjwatson> I can't
<cjwatson> that would require delaying the Ubuntu release
<cjwatson> (I'm entirely serious)
<kelemengabor> but extending the deadline only for d-i could work?
<cjwatson> kelemengabor: I'm asking elsewhere
<cjwatson> kelemengabor: and no, the installer translations cannot possibly wait until next Thursday (that's release candidate day!), but we may be able to allow the extra weekend or something
<cjwatson> kelemengabor: I will mail ubuntu-translators@ with details
<kelemengabor> okay, thanks
<Mirv> kelemengabor: I think the import queue is quite fast these days, though there are the OOo stuff now there which takes some time
<cjwatson> Mirv: hmm, I'm confused, I still don't see the "Network proxy" string in https://translations.launchpad.net/ubuntu/hardy/+source/debian-installer/+pots/debian-installer/fi/+translate
<cjwatson> Mirv: is it really there and I'm just blind?
<kelemengabor> Mirv: not really...
<Mirv> cjwatson: the templates are in the import queue, not imported
<cjwatson> ah
<Mirv> kelemengabor: actually carlos asked for a priorization of the debian-installer templates, so hopefully they'd go in today or so
<kelemengabor> these days it's very slow, partially due to the OO.o templates
<cjwatson> ok, I can't really mail ubuntu-translators@ until they're actually in place
<kelemengabor> some weeks ago my uploads were imported in a few hours, but my latest d-i translation is there since friday...
<kelemengabor> lets hope priorization works
<carlos> cjwatson: I hope it happens in next 2 hours at most...
<carlos> cjwatson: will ping you once it's done
<cjwatson> carlos: thanks!
<Riddell> mvo, bdmurray: still no update-manager 0.81.2 for gutsy-updates?
<megabyte405> new abiword build (ppa12) uploaded to ppa and building now
<kagou> Hi
<seb128> lut kagou
<kagou> lut seb128
<lool> doko: Hmm there's no mozilla plugin for openjdk?  Or not yet?
<doko> lool: icedtea-gcjwebplugin
<doko> but it doesn't support LiveConnect yet
<lool> So icedtea itself mostly goes away except for random peripheral bits which will be using openjdk, correct?
<lool> I have no idea what LiveConnect is
<doko> lool: yes, LiveConnect is the interaction of JavaScript and Java
<doko> unfortunately every second applet seems to require that
<lool> Ah that sucks indeed
<munckfish> cjwatson: wahaay! ps3-kboot build completed successfully ... finally!
<munckfish> thx for your assistance last night btw
<cjwatson> great
<james_w> Hi, I'm preparing an SRU, and the version in -proposed is not satisfactory, so I am preparing a fixed version.
<james_w> do I need to explain the whole fix in the changelog of the new version, or will the user be shown both changelog entries when updating from -updates?
<slytherin> TheMuso: calc: Thanks for working on OOo. :-)
<MacSlow> I'm trying to remove/purge non-needed kernel-images/modules and to free space on my hd, but I get errors form update-initramfs for trying to generate new initrd.img for kernel-versions I'm trying to remove? Since my /boot partition is full it fails.
<MacSlow> Can someone enlighten me why a "dpkg --purge" tries to fill space on /boot instead of freeing space on the partition?
<cjwatson> it's because when you remove linux-ubuntu-modules it doesn't know that linux-image is also being removed and so it needs to regenerate the initramfs
<cjwatson> not really easy to fix without breaking other things :(
<ion_> cjwatson: Kernel version specific dpkg hooks?
<MacSlow> cjwatson, but I have to remove the kernel-modules too because of dependencies dpkg complains about otherwise
<cjwatson> let me rephrase, not really easy to fix in a practical manner for hardy
<cjwatson> MacSlow: I understand
<MacSlow> arx... hm... so now I'm left with a broken update on my work-machine due to a too small /boot-partition (100 MBytes)
<cjwatson> MacSlow: the quickest way to deal with this is probably to edit /var/lib/dpkg/info/linux-ubuntu-modules-*.postrm (for the versions you're trying to remove) as root, and comment out the update-initramfs lines
<MacSlow> hm... fresh install and saving /home is the only solution I can think of atm
<slytherin> MacSlow: How about you remove both in same command. I mean does it work?
<cjwatson> MacSlow: MASSIVE OVERKILL!
<cjwatson> slytherin: no, it won't
<slytherin> cjwatson: Oh. I think then yours is the easiest solution
<cjwatson> (P.S. there's no need to explicitly save /home with the hardy installer; it will take care of that for you. But it's overkill to reinstall for this.)
<MacSlow> cjwatson, ok I try that /var/lib/dpkg/info/linux-ubuntu-modules-*.postrm-thing
<cjwatson> MacSlow: I agree that it's unfortunate, and you should file a bug on linux-ubuntu-modules-2.6.24 if there isn't one already. I don't see an obvious correct solution but it would be worth a bug report anyway.
<ion_> Wouldnât dpkg hooks with the kernel version in their name be a correct solution?
<cjwatson> ion_: you can say "dpkg hooks" with no further details and solve any problem ... What exact hook semantics would help here?
<cjwatson> Do you mean dpkg triggers?
<TheMuso> asac: No I'm not sure. Users can at least try it I guess.
<ion_> cjwatson: Sorry, triggers, yeah. Brainfart. Something wants to do update-initramfs for 2.6.24-15-generic, thereâs a trigger with â2.6.24-15-genericâ in its name activated. When purging 2.6.24-15-generic, the trigger would either just have disappeared, or it would notice that 2.6.24-15-generic doesnât exist anymore and do nothing.
<cjwatson> ion_: that sounds like it would work, but it's far too late to make such a change for hardy
<ion_> cjwatson: Yeah
<cjwatson> if MacSlow files a bug, that could be tried in 8.10 and possibly be a candidate for 8.04.1
<doko> seb128, ScottK: is there no replacement for galculator, which couldn't be used for -mobile?
<seb128> doko: no idea, I'm not a mobile team guy
<seb128> dunno what are their requirements
<MacSlow> cjwatson, not very verbose but here it is https://bugs.edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/213873
<ubotu> Launchpad bug 213873 in linux-ubuntu-modules-2.6.24 "purge of package causes generation of new initrd.img" [Undecided,New]
<cjwatson> ok, thanks
<MacSlow> pitti, what's the name of the actual restricted-manager binary?
<MacSlow> dpkg -L restricted-manager/-core does not yield much
<seb128> MacSlow: jockey-gtk jockey-common
<MacSlow> seb128, ah ok... why the name-change? Or was it named that from the beginning?
<seb128> MacSlow: because it can manages all drivers now and not only the restricted ones
<MacSlow> seb128, thanks
<seb128> MacSlow: you are welcome
<MacSlow> next reboot
<cjwatson> mvo: could you hop into #ubuntu-installer for a minute? ubuntu-keyring issue
<seb128> TheMuso: around?
<TheMuso> seb128: Yes I am.
<seb128> TheMuso: bug #213874
<ubotu> Launchpad bug 213874 in launchpad-integration "package liblaunchpad-integration1 None [modified: /var/lib/dpkg/info/liblaunchpad-integration1.list] failed to install/upgrade: trying to overwrite `/usr/share/icons/hicolor/16x16/apps/lpi-bug.png', which is also in package liblaunchpad-integration0" [Undecided,Confirmed] https://launchpad.net/bugs/213874
<seb128> TheMuso: the new version needs a replaces on the previous one
<TheMuso> seb128: Ah right, thanks for the heads up.
<seb128> TheMuso: can you fix it now?
<TheMuso> seb128: I'm on it.
<seb128> TheMuso: thank you
<seb128> brb
<Silicium> heyho
<Silicium> there are any documentations about debootstrap scripting?
<Silicium> the debootstrap scripts
<cjwatson> Silicium: not to my knowledge; they're not really supposed to be edited by non-developers
<cjwatson> Silicium: what are you trying to achieve? there are usually better ways than changing debootstrap
<Silicium> i need to install one additional package after base install over debootstrap
<cjwatson> are you using the ordinary installer?
<cjwatson> Silicium: if you're using the ordinary installer, you can just preseed pkgsel/include to a list of the extra packages you want to install
<cjwatson> much easier than messing around with debootstrap scripts
<laga> cjwatson: i've tried to make a new task for mythbuntu. does this look sane? http://www.pastebin.ca/976701
<Silicium> cjwatson: i dont want preseed :)
<Silicium> i need that for develop
<Silicium> and installing on  CF cards and so
<cjwatson> Silicium: I don't understand your objection; but alternatively you could set the packages you want to be Priority: important in the Packages file, if you're already customising that
<cjwatson> laga: the packages in Task-Key need to be actually listed in the seed as well
<Silicium> i have one dummy package that install a kind of software
<Silicium> and i need to install that one
<Silicium> but not with a installer
<Silicium> i need to do that over debootstrap
<cjwatson> Silicium: well, debootstrap just installs everything with Priority: required and important by default, so just set that appropriately
<laga> cjwatson: so it's not sufficient that mythtv-backend-master depends on them? they're still pulled in, right?
<cjwatson> laga: also, there's no seed called 'common'. Did you mean 'desktop-common' rather than 'desktop common'?
<cjwatson> laga: it's sufficient that it depends on them; why not use Task-Key: mythtv-backend-master, then?
<Silicium> cjwatson: so i can change this in the script
<Silicium> thats not the problem
<laga> cjwatson: i created a new seed called 'common'. i'm afraid the seed layout has changed a bit in our tree (don't ask me why please :))
<cjwatson> laga: oh, err, ok
<Silicium> but i prefeer to writ a new script
<Silicium> cause is clean
<cjwatson> Silicium: your problem, then, if you refuse my advice :)
<laga> cjwatson: i'll try to get some sanity back into our seeds for +1 and also write some documentation about seeds, but that'll have to wait a bit.
<cjwatson> laga: you should put backend-master before supported in STRUCTURE, and add backend-master to the seeds named in the supported: line there
<cjwatson> the last seed in STRUCTURE is used for build-depends generation, so order matters
<laga> cjwatson: thanks for your suggestion, i'll modify tas-key
<cjwatson> Silicium: writing a new script is generally not the clean option, in my experience as a debootstrap maintainer
<Silicium> ok
<Silicium> can i get the debootstrap packages from two repositorys?
<cjwatson> but if you really want to do that, you can, you're just on your own :)
<cjwatson> no, it can only operate on one
<Silicium> so on my repository is only my package
<Silicium> and the default script want to install a stage one
<cjwatson> I sort of said this before, but I'll try once more. debootstrap's job is only supposed to be to get a minimal base system up and running. It's not supposed to do absolutely everything, and the intent of the authors is that you should layer things on top of it - so if you need more packages than the minimal base system, you should simply install them after running debootstrap.
<Silicium> hmm okay
<Silicium> then is better i create a own script and do that with aptitude and chroot/fakeroot
<Silicium> allright :)
<cjwatson> We have run into issues before due to the fact that packages installed within debootstrap have to obey a couple of extra rules, due to the way that debootstrap unpacks things
<cjwatson> (unfortunately I forget the details right now)
<cjwatson> easy to fix once you encounter it, but a hassle if it's not necessary
<cjwatson> laga: you should also have 'Task-Per-Derivative: 1', which means that the task name will be mythbuntu-backend-master rather than just backend-master
<cjwatson> laga: also, what deals with installing the contents of the common seed?
<laga> cjwatson: i thought/hoped it would be pulled in if i say "live: desktop common" in STRUCTURE
<TheMuso> seb128: Tested that it works now, and uploaded.
<seb128> TheMuso: thanks
<TheMuso> seb128: np, sorry I missed it. :)
<seb128> that's alright, happen to everybody
<seb128> I was going to try before accepting the binary
<seb128> but somebody else did get it you of new before that
<seb128> s/you/out
<cjwatson> laga: where can I see the whole seeds? mythbuntu.hardy in what I thought was the obvious place doesn't have a common seed
<laga> cjwatson: sorry, i havent pushed yet. didn't want to push possibly broken stuff. wait a sec
<laga> cjwatson: pushed
<cjwatson> laga: I'd recommend applying http://paste.ubuntu.com/6615/ so that the common seed is used when installing the live or backend-master tasks
<cjwatson> you don't need it for the others since ship and ship-live aren't installed directly
<laga> cjwatson: does STRUCTURE need to be changed?
<cjwatson> no
<cjwatson> oh, err, one other glitch
<cjwatson> tasksel doesn't really have a way for tasks to depend on each other
<cjwatson> so you have to fake this in seeds
<cjwatson> in order for backend-master to rely on desktop, you need to actually put mythbuntu-desktop in the backend-master seed
<laga> where mythbuntu-desktop is a (meta) package?
<cjwatson> it's not necessary for the live seed since the live CD filesystem builder usually sorts this out for you
<cjwatson> yes, I assume you already have that
<cjwatson> you do
<laga> yes
<laga> ok, thanks. quite complicated :)
<cjwatson> yes :)
<\sh> seb128, nautilus uses nowadays the registered binfmt stuff we provide within a package, right?
<seb128> \sh: no idea about how binfmt works but nautilus nothing special to use that so I would say no
<\sh> seb128, so it honours mime-types which are provided by .desktop files (e.g. application/exe or whatever mime-type name) ...
<seb128> yes
<seb128> it uses shared-mime-info to determine the mimetype and look to desktop files claiming this mimetype to know what to use
<seb128> doko: could you build the launchpad-integration build priority on i386?
<doko> seb128: done, btw, do you know why the translations are never merged back from rosetta?
<seb128> doko: thanks, merged back where?
<doko> seb128: into the package
<seb128> doko: what package? launchpad-integration? because we use the language packs I think
<doko> seb128: yes, but the translation status in rosetta never gets updated. so at least I never know if there are really new or changed translations when I export the data for the OOo menu strings
<seb128> doko: ah
<seb128> doko: I'll update translations when doing the next upload
<doko> seb128: thanks!
<laga> cjwatson: it's magic. i've now got a mythbuntu-backend-master task! i have no clue if it works as intended, but it's there :)
<laga> ogra_cmpc: still planning a new ltsp upload? or did i miss that opportunity?
<cjwatson> laga: great
<laga> cjwatson: everything in the 'common' seed will also be installed when i select backend-master in tasksel?
<cjwatson> right, that's the idea
<cjwatson> though, hmm, that relies on Launchpad Task headers
<cjwatson> argh, please give me a minute, I'm doing four things at once and something has to give
<laga> sure, take your time.
<laga> cjwatson: my reasoning for having 'common' was that live and ship have the same packages. i guess these only list what is included on the disks. ultimately, i want the live disk and the alternate disk to have the same set of packages available (minus ubiquity) and then use tasks on the alternate to install a subset of these.
<ogra_cmpc> laga, i was planning one for today/night, even though the main changes will be rather ldm
<laga> cjwatson: i figured explaining what i actually want to do is a bit better than letting you guess, although it might seem like i want you to do my work :)
<laga> ogra_cmpc: okay. i reated a ticket with a patch the other day and assigned it to you, but i guess you have seen that
<ogra_cmpc> laga, did you file that as ltsp bug ? i dont seem to see it
<laga> let's see
<stgraber> ogra_cmpc: I'll have a fix to include in like 5min
<stgraber> ogra_cmpc: http proxy and ltsp-build-client (one-liner)
<ogra_cmpc> ah, thanks
<ogra_cmpc> i wonder where that comes from so suddenly though
<laga> ogra_cmpc: https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/212550
<ubotu> Launchpad bug 212550 in ltsp "mythbuntu: plugin enhancements" [Undecided,New]
<ogra_cmpc> laga, gracias :)
<laga> ogra_cmpc: de nada :)
<stgraber> ogra_cmpc: bug 213927
<stgraber> ogra_cmpc: seems to be working here, rebuilding a new chroot just to make sure
 * ogra_cmpc pokes the bot
<ogra_cmpc> stgraber, urgh, thanks
<stgraber> ogra_cmpc: that's weird because the previous line had stricly no chance to be working :) (missing ; and using '' instead of "")
<ogra_cmpc> yeah
<stgraber> ogra_cmpc: confirmed to work correctly, my chroot is now building correctly
<seb128> doko: do you know if the i386 buildds have issues today?
<ogra_cmpc> stgraber, thanks for that
<amitk_> ogra_cmpc: how can I go about creating larger fs for classmate images? Current one has no possibility of installing more than  kernels
<ogra_cmpc> amitk_, switch to tty 2 in the installer, you can edit the partition values in the script (/sbin/cmpcinstaller) then save and reboot the installer image to make it take effect, /boot only has 50M spare atm
<doko> seb128: building OOo, the other two have timeouts
<seb128> doko: right, I noticed now
<stgraber> ogra_cmpc: oh, something else I noticed, installing ltsp-server doesn't install any inetd server ...
<stgraber> ogra_cmpc: and tftp-hpa doesn't seem to work correctly with inetutils-inetd at least with the default settings (trying from a clean Ubuntu not through the Ubuntu Alternate and LTSP install option)
<MacSlow> Would a reasonalbe fix to #213926 be a Replaces: liblaunchpad-integration0 in debian/control?
<pwnguin> jwz tried ubuntu ltsp with 7.10 and eventually decided that he'd remain in 2003 instead of debug it =(
<stgraber> Apr  8 17:06:34 ltsp-server inetd[4310]: /usr/sbin/in.tftpd: exit status 0x4c00
<stgraber> Apr  8 17:06:38 ltsp-server in.tftpd[4534]: received address was not AF_INET, please check your inetd config
<stgraber> ogra_cmpc: ^
<cjwatson> MacSlow: that is the correct fix
<cjwatson> MacSlow: TheMuso said earlier that he was working on it, IIRC
<TheMuso> Yes and a fix was uploaded.
<MacSlow> TheMuso, cjwatson ah ok
<ogra_cmpc> stgraber, i will try that tonight, thats weird
<MacSlow> TheMuso, for the time being (until it reaches the repo) I'll use a local fix then
<stgraber> ogra_cmpc: ltsp-server and ltsp-server-standalone don't depend on an inetd server :(
<ogra_cmpc> stgraber, ogra@laptop:~$ apt-cache show ltsp-server|grep Depends|grep -c1 tftp
<ogra_cmpc> 1
<ogra_cmpc> oh, wait
<ogra_cmpc> err
<ogra_cmpc> openbsd-inetd
<ogra_cmpc> or inet-superserver
<ogra_cmpc> do you have xinetd installed or so ?
<ogra_cmpc> else ltsp-server should pull openbsd-inetd in
<MacSlow> argl... the build-dependencies for liblauchpad-integration1 are killing me (not enough space on disk left)
<ogra_cmpc> stgraber, i dont get why you dont see the dep ...
<cjwatson> MacSlow: sudo dpkg --force-overwrite -i /var/cache/apt/archives/liblaunchpad-integration1_*.deb; sudo apt-get -f install
<ogra_cmpc> `it should be pulled in properly ... just tried in avm
<ogra_cmpc> *a vm
<laga> ogra_cmpc: i thought you committed https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/198356 too? not sure if it can be closed
<ubotu> Launchpad bug 198356 in ltsp "make it easier to specify alternate DHCP ports" [Undecided,New]
<MacSlow> cjwatson, oh cool... thanks!
<james_w> is patches.u.c not updating currently?
<james_w> an upload from a couple of days ago that I want to point someone to has not shown up yet.
<slytherin> calc: ping
<pitti> Mirv: please feel free to assign the other one to me, too
<cody-somerville> Does gconf still use CORBA or does it use dbus now?
<seb128> it uses orbit
<seb128> hey pitti
<pitti> seb128: greetings from uni texas
<slytherin> Is a build being terminated by inactivity on buildd right or wrong?
<seb128> pitti: having fun there ? ;-)
<pitti> seb128: presentation just started; so far, yes :)
<sistpoty|work> slytherin: that depends... means that a build didn't produce output on stdout for $timeout. could indicate that it's stalled, could also mean that it's just taking a very long time w.o. producing output ;)
<seb128> pitti: good ;-)
<slytherin> sistpoty|work: hmm. let's assume that it is long time w.o. producing output. Then how can we fix the build?
<sistpoty|work> slytherin: if it does indeed work, you can beg a buildd admin (maybe infinity) very nice ;)
<slytherin> sistpoty|work: ahh, I think I will leave that to calc. He uploaded OOo to fix FTBFS on powerpc and it failed again but for different reason this time, inactivity. :-(
<Mirv> pitti: I can't assign, but I did subscribe you there. Daniel asked Alexander to check it but I'm not sure if Alexander has time.
<Mirv> seb128: do you think you could put the small new patch in bug 213134 in to have potfiles as it should be for the randr-1.2 applet? the debdiff has the patch itself, version number is now out-dated as such as new uploads have come.
<ubotu> Launchpad bug 213134 in gnome-control-center "Untranslated strings in Monitor Resolution Settings window" [Undecided,Confirmed] https://launchpad.net/bugs/213134
<seb128> Mirv: sure, will do that in a bit
<Mirv> cjwatson: I guess I can ping you on behalf of carlos: the new debian-installer template has now hit Rosetta, bringing 90 new strings to translate.
<carlos> Mirv: you were faster than me ;-)
<carlos> Mirv: thanks
<carlos> I saw it going to the top of the list, but got distracted while I was waiting it to be imported...
<carlos> Mirv: however, translations are still being imported
<carlos> so is better to wait a bit before we announce it
<carlos> cjwatson: ^^^
<cjwatson> ok
<carlos> cjwatson: if you want to check when the import is done: https://translations.edge.launchpad.net/ubuntu/hardy/+source/debian-installer/+imports?field.filter_status=APPROVED&field.filter_extension=all
<carlos> cjwatson: that list should be empty
<carlos> seems like each entry takes around 10 minutes to complete
<cjwatson> carlos: got it, thanks
<cjwatson> carlos: I hate to ask, but why does it take so long?
<carlos> cjwatson: well, that's something I'm wondering too. We did some optimisations that, for some reason are not working in this case
<carlos> cjwatson: I need to talk with jtv and danilo about this to see whether we had a performance regression...
<carlos> cjwatson: the files are big, so it's normal that this take some time, but given that is not the first time we import them, it should be faster
<carlos> just to clarify it...
 * ogra_cmpc wonders what gnome does with the hotkey windows to manage to broadcast it to all available displays like in bug #212802
<ubotu> Launchpad bug 212802 in ltsp "Server brightness popup window shown in clients" [Undecided,New] https://launchpad.net/bugs/212802
<mjg59> hal broadcasts a brightnessup or brightnessdown event over dbus
<mjg59> g-p-m picks that up
<mjg59> (solution: don't run gpm in the client session)
<ogra_cmpc> hmm, i thought CK would prevent that nowadays anyway
<ogra_cmpc> but indeed
<ogra_cmpc> if g-p-m runs thats clear
<carlos> cjwatson: ok, the problem was in some other place. it's now importing files in around a minute or so
<cjwatson> carlos: aha, good stuff
<\sh> guys, why is it not possible to get libgif-dev (depends on: libgif4 4.1.4-2) for gutsy? even if it's available on our archive servers
<\sh> wine backport ftbfs because of this...(http://launchpadlibrarian.net/13223894/buildlog_ubuntu-gutsy-amd64.wine_0.9.58-0ubuntu3%7Egutsy1_FAILEDTOBUILD.txt.gz) and sbuild denies to take the second build-dep (libungif) which is still valid for gutsy ;)
<mjg59> \sh: It won't take libungif because libgif-dev is available
<\sh> mjg59, well, according to archive, yes
<cjwatson> what else would it be according to? :-)
<cjwatson> it looks like the build-dependencies are inconsistent somehow
<mjg59> It's not obviously clear why the install is failing - packages.u.c says that 4.1.4-2 is in the archive for gutsy
<\sh> cjwatson, http://archive.ubuntu.com/ubuntu/pool/universe/g/giflib/ <- all debs are there :)
<cjwatson> yes I know
<cjwatson> I suggest you debootstrap --variant=buildd a chroot and try installing all the stuff that sbuild says it wants to install
<cjwatson> simultaneously
<\sh> could it be a confusion in the packages file? (giflib now in main, but for gutsy in universe) ?
<cjwatson> then drill down by eliminating bits of it
<\sh> cjwatson, sbuild on my machine for gutsy fails too
<\sh> cjwatson, and I'm using the packages files from a.u.c
<cjwatson> archive-level inconsistencies are massively less likely than a package-level screwup. Don't start your investigation with the least likely possibility
<mjg59> \sh: Ah, yes - it doesn't say it can't find libgif4, it says it's not going to be installed
<cjwatson> right, i.e. build-deps inconsistent somehow
<cjwatson> as I said above
<\sh> cjwatson, debian/control: ->  libgif-dev | libungif4-dev <- so it takes libgif-dev and tries to install libgif4 (which is correct)
<cjwatson> and something else in the build-dependencies makes that impossible
<cjwatson> like if you try to install libgif-dev and something that conflicts with libgif4 simultaneously, you'll get that
<\sh> damn...we have this libgif libungif problem again
<cjwatson> (for example; of course there are other possibilities)
<\sh> cjwatson, no...we had this before...I remember now...
<\sh> and for gutsy we strictly used libungif instead of libgif
<cjwatson> so change wine's build-deps to match?
<\sh> cjwatson, for hardy it's correct...backports are the problem
<cjwatson> then you'll have to have a non-trivial source-change backport
<cjwatson> which core developers can do by regular uploads
<\sh> ok...
<\sh> ScottK, please remove libgif-dev from wine backport build-dep so only libungif is getting in..then it works
 * \sh thinks it was fontforge which clashed these days with libgif 
<\sh> cjwatson, thx :)
 * \sh should write down those cornercases somewhere
<emgent> heya
<_MMA_> If a particular file isn't being thumbnailed (.cbr) and it should be, what should I file a bug against? Nautilus?
<seb128> why should it?
<_MMA_> Because it has up until now? :) I actually think it has something to do with the "comix" package. I think it has the thumbnailer info in it.
<seb128> use gconf-editor
<seb128> go to desktop, gnome, thumbnailers
<seb128> and look for the mimetype you are interested in and what is thumbnailer
<seb128> the cbr one is evince apparently
<_MMA_> Hmm... I get "comicthumb" here. :-/
<pedro_> _MMA_: they work fine for me, I've just test them with the examples on bug 191634
<ubotu> Launchpad bug 191634 in evince "Broken Evince support for cbr and cbz files" [Low,Fix committed] https://launchpad.net/bugs/191634
<seb128> _MMA_: so you have your buggy software
<_MMA_> seb128: Maybe a logout/in would help.
<seb128> _MMA_: to what?
<_MMA_> seb128: That worked. Maybe I just needed to restart something.
<seb128> maybe you had evince configure before
<seb128> try to run the command written in gconf manually
<_MMA_> seb128: Thing is the thumbnailer isnt set to "evince". Its set to "comicthumb".
<seb128> right, that's what I mean, is that command working?
<_MMA_> I can only guess as I now have the thumbnails.
<_MMA_> seb128: Hmm... I do get an error when I run the command from CLI actually. I'll look into the usage arguments and file a bug if need be.
<BalaamsMiracle> mdke: I've asked carlos the following, but he told me to ask you: I was wondering if there is some schedule that's being used to determine when translations of documentation is being rolled out, because ubuntu-docs is for te most part translated to Dutch now, but at least in Hardy there haven't been any updates of ubuntu-docs since quite some time.
<slangasek> seb128: should the new libcairo take care of the printing problems (bug #151145)?  or is that not yet known?
<ubotu> Launchpad bug 151145 in gtk+2.0 "Evince print fails with Postscript driver" [High,Incomplete] https://launchpad.net/bugs/151145
<carlos> cjwatson: hi, you can send that announcement now
<slangasek> cody-somerville: hrm, something's regressed on the xubuntu daily CDs - the xubuntu-desktop metapackage is now uninstallable (?)
<cjwatson> carlos: great, thanks
<seb128> slangasek: the gutsy issues described on this bug had been fixed in hardy, I confirmed that with upstream some days ago
<seb128> slangasek: I think the bug should be closed and people having issue in hardy should open new bugs
<seb128> slangasek: because this one starts being hard to read and has likely several issues listed now
<seb128> slangasek: the glyph positioning issues reported on some other bugs have been fixed now
<seb128> slangasek: what remains is that printing some documents crash the xerox office printer, but the document seems valid, it's displays correctly and gs doesn't complain about it so we are waiting on details from xerox to know what in the ps makes the printer crash
<seb128> slangasek: that's my understanding of the current situation on those printing bugs
<slangasek> aha, ok
<slangasek> thanks :)
<seb128> np
<Pantaleon> ola
<jdong> Hobbsee: can you give-back bzr-builddeb on gutsy-backports? It raced the bzrtools backport and should work now.
<seanh> Where would I go to request that gnome-themes-extras 2.22 be packaged for hardy? Currently the beta has 2.20, but a new theme was added in 2.22
<jdong> launchpad
<jdong> we are in FFe though
<ogra_cmpc> e ?
<seanh> How do I make the request? As a bug report?
<jdong> ogra_cmpc: same thing
<ScottK> seanh: Yes
<seanh> ok done
<seanh> https://bugs.launchpad.net/ubuntu/+bug/214052
<ubotu> Launchpad bug 214052 in ubuntu "Please update gnome-themes-extras to 2.22 in hardy" [Undecided,New]
<xtknight> mvo, whenever you have time i need to talk to you about a couple bugs that i've been tracking
<emgent> heya fabbione :)
<ion_> cjwatson: While we're waiting for apt+zsync, couldn't we begin using pdiffs for apt-get update in the meantime, since it's already implemented and tested in Debian?
<cjwatson> ion_: would need implementation in Launchpad
<cjwatson> the Soyuz team is not exactly lacking in urgent things to do, so I'm not sure this would be quicker ... but you're welcome to propose it to the Launchpad team
<laga> cjwatson: it'd be very cool if you could take a look at my question/the seeds some time soon. no hurry though, gotta run now :)
<cjwatson> laga: ok, but dinnertime now (sorry)
<ion_> cjwatson: Ok, i'll talk to them about it. #launchpad?
<cjwatson> yes
<emgent> asac: I need a little help for complete python-launchpad-bug cookies support in anteater tool
<emgent> http://bazaar.launchpad.net/~ubuntu-whitehat/ubuntu-whitehat-project/uwht.dev/annotate/emgent%40emanuele-gentili.com-20080407235635-9c0rlcwmk0eu90ia?file_id=anteater.py-20080328174815-qukxnpiclv9834qw-3
<emgent> https://code.edge.launchpad.net/~ubuntu-whitehat/ubuntu-whitehat-project/uwht.dev
<emgent> have you a little bit time for help to complete it ? :)
<emgent> i should add Bug.authentication
<asac> emgent: whats the problem?
<emgent> documentation is very small and i dont understand how to complete this
<emgent> https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/Bug
<emgent> heya thekorn :)
<asac> emgent: what doesn't work?
<azeem> slangasek: well, I finally filed a FFE for opensync (#214083), FYI, after testing kitchensync in a hardy chroot last night
<emgent> asac: i should add autentication support
<asac> emgent: thekorn probably knows better ;)
<emgent> ok :P
<asac> emgent: actually i think it would help if you could rephrase what your problem is ;) ... i didn't quite get where you are stuck
<emgent> asac: np, thekorn helping me now :)
<slangasek> azeem: pushing the limits there, are we? :)  I'll see what I can do about reviewing the FFe request, but I don't think I'll get to it until tomorrow.
<azeem> slangasek: I know it's unlikely, but I was very busy at the uni/on vacation over the last days/weeks
<ogra_cmpc> that answer sounds like a multiple choice form ...
<ogra_cmpc> make your check where appropriate :)
<mvo> xtknight: sure, I'm around (but might be a bit slow in responding)
<xtknight> bug 213207
<ubotu> Launchpad bug 213207 in vinagre "Vinagre appears in Add/remove applications twice as "remote desktop viewer"" [Undecided,Confirmed] https://launchpad.net/bugs/213207
<slangasek> azeem: that's ok, for comparison I'm trying to make a last-minute change to the PAM stack :-P
<jdong> ogra_cmpc: You are proposing a ( ) Low Regression risk  ( ) Test Suite   ( ) Can't possibly get any worse      argument as a FFe. This won't work because of .....
<xtknight> mvo, well mario referred me to you on this one.  i can't remember why exactly , i think he thought you'd have some input on it?
<jdong> ogra_cmpc: I think we need to get such a form for rejecting FFes :D
<xtknight> mvo, basically there's two desktop files in vinagre, and each of them is appearing in add/remove programs.  we should exclude one from the app-install-data database, probably
<mvo> xtknight: yeah, that must have slipped thourgh, we have a blacklist for this, I will keep it in mind for the next update (due today or tomorrow)
<xtknight> mvo, oh ok. so you're the package maintainer?
<ogra_cmpc> jdong, heh
<mvo> xtknight: yes
<xtknight> mvo, i made a little tool to show packages with more than one desktop file, where the error is possible.  but not necessarily all of them have this problem, in fact very few do.  there are some packages that have two different desktop files for each component of themselves (Like xfprint4)  but the entries work fine in add/remove progs: they just cancel each other out and they're not duplicates because they're differently named.
<xtknight>   http://paste.ubuntu-nl.org/62543/
<xtknight> i am not sure what we want to do about those, for example "Xfce 4 print dialog" and "Xfce 4 print manager" are the same package, both are listed in add/remove.  i guess this is fine?
<mvo> xtknight: have you run it against the ddata in /usr/share/app-install/desktop ?
<xtknight> mvo, this just goes through debian packages and determines which ones have more than one .desktop file by listing all their files.  but i don't see any results from app-install/desktop specifically
<xtknight> well i'd probably need a different script to determine if there were duplicates in that folder because they all come from app-install-data
 * mvo nods
<xtknight> maybe with the same X-AppInstall-Package=?
<jdong> ogra_cmpc: https://wiki.ubuntu.com/JohnDong/FFeRejectionForm
<mvo> yeah, I think a test with this would be cool. sometimes this is intentional as a package ships functionatliy where it is appropriate to have multiple ones (e.g. gnome-games), but generally its not
<rwh> hi there. I just upgraded to hardy, and my gnome-settings-daemon coredumps somehow. Known issue or should I file a bug somewhere?
<slangasek> rwh: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/, pick your poison, it's probably /one/ of those...
<rwh> slangasek: tnx, I'll have a look
<xtknight> mvo, here we go :) http://paste.ubuntu-nl.org/62550/
<xtknight> well seems not perfect, not sure why there's dupes of filenames in there (maybe error in grep) but i identified a couple other packages like BMP (it has BMP and BMP offline mode)
<xtknight> ethreape, etherape as root
<kagou> slangasek, it will be great to have a package on ppa for Bug #208419 !
<ubotu> Launchpad bug 208419 in pam "Integrate samba password in PAM" [Wishlist,In progress] https://launchpad.net/bugs/208419
<slangasek> kagou: damn, ok :)
<slangasek> kagou: that will have to come a bit later
<kagou> sladen, as soon as it will be available, i will test it ;)
<kagou> oups slangasek
<mvo> xtknight: cool, thhanks
<xtknight> mvo, yeah hold on i fixed that little bug
<rwh> slangasek: seems to be #210226. gsd is not that hard to confuse apparently :)
<xtknight> mvo, fixed http://paste.ubuntu-nl.org/62556/   but anyway since some of them don't appear twice in Add/Remove yet appear on that list, i'm trying to find out why
<mvo> xtknight: sometimes its the dekstop files, e.g. a missing or incorrect Categories= in the desktop file
<YokoZar> Hmm, my emails to ubuntu-devel are still being put in the moderation queue but I'm an ubuntu developer now...
<xtknight> mvo, yup.  anyway i also was referred to you about Bug 212542
<ubotu> Launchpad bug 212542 in compiz-fusion-plugins-main "Drop type=Utility from 01-animation-defaults.patch" [Undecided,Triaged] https://launchpad.net/bugs/212542
<xtknight> i was told it might be integrated in the next revision of the package
<xtknight> and if i were to make a debdiff i didn't know whether i should actually edit the 01-animation-defaults.patch, or create a NEW patch in debian/patches to revert 01's changes that we don't want.
<LaserJock> YokoZar: using the right address to send from?
<YokoZar> LaserJock: what is the "right" address?  Is it my ubuntu.com one or any that I have confirmed in launchpad?
<LaserJock> YokoZar: honestly I don't know
<lamont> WTF does system->preferences steal focus?
<kagou> slangasek, can you explain me how your patch work (i'm completely ignorant of pam)
<lamont> and short of nuking compiz totally, how do I configure it's pretty little stupidities away?
<slangasek> kagou: um... that's a lot to explain
<slangasek> kagou: can you narrow the focus of your question? :)
<xtknight> kagou, slangasek i can make a package on my ppa for that patch if you want
<kagou> slangasek, of course. with your patch, samba password is it the same as samba password ?
<lamont> slangasek: I remember when I finally _got_ pam.  that was a very painful few hours at the end of a long time of head-beating
<kagou> as user password ?
<lamont> (of course, now I'm in that state of thinking I get it, while wondering if/when I'll discover that, no, I didn't....)
<slangasek> kagou: yes, that's the point
<slangasek> xtknight: thanks, feel free, that would save me a bit of time later
<kagou> sladen, it seems that user password and samba password are sync with your patch. This is done on user creation ?
<kagou> sorry sladen , i mean slangasek
<slangasek> kagou: it's done any time the password for a user is changed, as long as libpam-smbpass is installed, yes
<slangasek> (installing libpam-smbpass by default is the easy part)
<kagou> slangasek, samba have to be patched too ?
<slangasek> no
<kagou> oh nice
<slangasek> what do you believe would need patched in samba?
<xtknight> ok will do
<slangasek> lamont: heh, how would getting pam compare with getting leprosy
<lamont> I used to know Pam... she was cute.
<lamont> slangasek: it's one of those "it's so &^)*^& simple that it's complex" kind of things
 * slangasek grins
<kagou> slangasek, ok i understand. Thank you :)
<lamont> dear vmware.  please quit stealing focus. kthx
<lamont> why is it that more and more apps believe that they are important enough to warrant hijacking focus?
<slangasek> is it stealing the focus, or stealing the mouse?
<ion_> lamont: The window manager should really tell such applications "you there, behave" and ignore their crap. :-)
<lamont> ion_: I'd love a metacity patch that does that.
<Robot101> wg burger
<Robot101> FAIL
<lamont> 02:0b.0 VGA compatible controller: nVidia Corporation NV34GL [Quadro NVS 280 PCI] (rev a1)
<lamont> does that mean no compiz love for that machine?
<mjg59> lamont: Only if you use the closed driver
<lamont> how do I know if I'm doing that?
<lamont>         Driver          "nv" ??
<mjg59> THat's not the clsoed one
<lamont> and what should it be to be "not closed"?
<lamont> kewl
<lamont> in that case, brb
<mvo> xtknight: yeah, I plan to integrate this patch in the next upload
<xtknight> ok
<mvo> xtknight: (sorry for the lack in my replies, its rather late here already)
<xtknight> that's ok im' tired as well
<lamont> hrm.. so killing X and loging back in after installing compiz doesn't seem to have given me any love... mjg59 what did I forget?
<lamont> eep.  and must run away
 * lamont back online much later
<lamont> (although restarting X did hijack ctl-shift-page-down)
<mjg59> lamont: Did you install the closed driver?
<dandaman32> hey, found a grammatical typo on the website:
<dandaman32> "Everything you need on one CD, which provides a complete working environment."
<dandaman32> probably should be changed to something like, "Everything that you need for a complete working environment comes on one CD."
<dandaman32> or at a minimum, add an "is" in there maybe
<slangasek> dandaman32: there are many websites, can you be a bit more specific?
<dandaman32> slangasek, it's on http://www.ubuntu.com/products/whatisubuntu
<slangasek> ah
<slangasek> dandaman32: perhaps you could submit a bug report about it? https://bugs.launchpad.net/ubuntu-website/+filebug
<dandaman32> will do
<slangasek> (the developers don't, in general, have access to edit the website)
<dandaman32> yep, makes sense
<YokoZar> doko: ahh, you beat me to uploading that.  I did the same changes a couple days ago, but dput was crashing on me since ia32-libs was too big for my upload
<leon_pegg> hello all could someone point me in the direction of creating a debain source package from cvs code (I know how to create a source package from tar.gz, from what I understand it is diffrent from cvs)
<ScottK> Take the cvs snapshot, remove the .CVS stuff, roll your own tarball, and do as you would otherwise.
<leon_pegg> ok thanks
<leon_pegg> what about version numbering?
<dandaman32> leon_pegg: i'd suggest adding a "-cvs20080408" to the version number.
<leon_pegg> thanks, I have been creating packages from php-gtk and some people have been asking for a cvs package (lazy peps)
<dandaman32> and as a full time PHP developer, i can't understand why the hell anyone would want to write graphical applications in PHP... lol
<dandaman32> frankly, i love the language and hate the bindings.
<leon_pegg> dandaman32, I am a full time PHP Developer, but I have found php-gtk very helpful
<leon_pegg> it allows me to create client apps that can code share with there web counterparts and will run on windows/mac/liunx systems without recompiling
<leon_pegg> I see writing php-gtk ass as no differant to writing an app in  pygtk
<crimsun> hmm.  the cupsys [Ubuntu] changelog refers to reverting "usr/share/doc symlink/directory breakage".  Does that imply that we won't be shipping an Ubuntu changelog, etc., in /usr/share/doc/cupsysfoo?
<YokoZar> hmm, apt-get update is now downloading a 4 meg package list for universe
<Nafallo> have been doing for a while now :-)
<YokoZar> It's compressed right?
<Nafallo> yea
<YokoZar> Hmm, it's compressed with gzip though.  Maybe for Intrepid we should do lzma :)
<Nafallo> YokoZar: ==> mvo ;-)
<larson9999> i bring this up everyone once in a while in #ubuntu and never get a response.  so i figure i'd see if maybe this is the right place for this question.
<ScottK> It's probably not, but that won't stop you.
<larson9999> one of the things that's bugged me for a while with ubuntu is the fact that the first time you click on the main menu icon(i use the smaller main menu vs that 'huge' main menu that's the default) there is quite a long lag before it opens.  but with the default there is no lag.  is there a way to make the smaller main menu have no lag like the default?
<_MMA_> larson9999: I believe it's because it's caching more images at one time. I see this on other GNOME systems as well.
<larson9999> _MMA_, yeah, i do see it on other gnome systems too.  but my menu isn't so big.  my guess is that the smaller main menu does cach anything on start up but the default does.  so i figured if that was the case maybe dev my be the place to correct it.
<larson9999> s/does/does not/
<_MMA_> larson9999: If anything, it's an upstream issue.
<larson9999> _MMA_, ok, i'll try there.
<tjaalton> slangasek: I'd appreciate if you could shove vdr through NEW when it has built. it only added a package for debugging (vdr-dbg)
<tjaalton> slangasek: no rush.. the plugins will wait for it
<munckfish> BenC: got a sec?
#ubuntu-devel 2008-04-09
<xtknight> for Bug 62230 ... how is the video driver autodetected?  i'd like to force certain problematic cards to go to vesa.  this bug has been here for at laest the past three releases
<ubotu> Launchpad bug 62230 in xserver-xorg-video-nv "Corrupt graphics on boot with 7800GT/nv" [Medium,Triaged] https://launchpad.net/bugs/62230
<xtknight> safe graphics mode works sure but when you alternate install you get a frozen system
<xtknight> actually even when you regular install you do
<slangasek> tjaalton: well, I do see /two/ new binaries added by vdr... :)
<ScottK> He must want you to leave the other one ;-)
<Caesar> Hmm
<Caesar> It seems that when gnome-keyring acts as the SSH agent, it can't cope with loading an RSA1 key
<Hobbsee> jdong: already back, it looks like
<jdong> Hobbsee: magical
<jdong> Hobbsee: err, on gutsy-backports?
<Hobbsee> jdong: oh, meh.
<emgent> heya Hobbsee :)
<Hobbsee> heya
<Hobbsee> jdong: i'll actually have to use the LP UI for that :(
<jdong> Hobbsee: aww so it'll take 10 minutes of your time waiting for LP to load?
<Hobbsee> jdong: given back
<jdong> whee
<jdong> and if it FTBFSes again, can I get an Ubuntu brown paper bag?
<ScottK> Flaming?  On a doorstep?
<emgent> anteater 1.0 beta is out! :)
<bddebian> ScottK: :)
<ScottK> I knew someone would get it.  I should've figured you'd be the someone.
<bddebian> heh
<Hobbsee> jdong: why does it die?
<jdong> Hobbsee: it should build-dep on bzrtools >= 1.3
<jdong> Hobbsee: but Debian didn't do it, I didn't want to diverge to do it, a rebuild would fix it at worst..
<jdong> Hobbsee: this particular FTBFS results when the archive has new bzr, old bzrtools, and tries to build new bzr-builddeb
<Hobbsee> hmm
<jdong> that leaves new bzr + old bzrtools in uninstallable state
<Hobbsee> so you'll need to rebuild bzrtools too, then.
<jdong> no, bzrtools built fine
<jdong> it just built a matter of MINUTES after bzr-builddeb tried to build
<Hobbsee> hang on, i thought you said it all died again.
<jdong> Hobbsee: no I said if!
<jdong> hypothetical :)
<Hobbsee> oh, right.
<Hobbsee> i'm confused, apparently
 * Hobbsee has been dealing with far too much other shit, apparently.
 * jdong gives Hobbsee a hug
 * Hobbsee hugs jdong back.  And you're unfortunate enough to know what a great section of it is about, too.
<jdong> :( yeah
<RAOF> Hm.  SIGXCPU strikes again.  And it's not banshee-trunk-specific, I've just had rhythmbox do it.
<RAOF> Maybe it only occurs on battery - I couldn't reproduce yesterday afternoon, and I think the difference was I plugged the lappy in.
<jdong> RAOF: isn't SIGXCPU used by mono, specifically, the Boehm GC, to signal collection?
<jdong> could there be some bug at that level?
<RAOF> jdong: Except that neither pulse nor rhythmbox are mono apps?
<jdong> RAOF: oh sorry. you mentioned banshee
<jdong> -ECONTEXT
<RAOF> Hm.  Rhythmbox _really_ doesn't like pulse dying on it.  1.1GB of memory is not a nice mem usage ;)
<RAOF> jdong: I think you're right about mono's usage of XCPU.  At least, debugging banshee suggests that you make gdb pass XCPU through.
<pleaseandthankyo> is there a good diet softwares? like for a diabetes guy or a healthy living diet software for person who has heart d eases?
<jdong> not the right place to ask.... Please use #ubuntu
<lifeless> he just asked in at least channels
<tedg> pleaseandthankyo: While this isn't the place to ask, the only diet software I know for Linux is "Shrinkingman" -- but I don't believe it is maintained anymore.
<tedg> pleaseandthankyo: http://debain.org/software/shrinkingman/
<RAOF> For those playing at home, pulse being killed with SIGXCPU?  Not a on-battery problem.
<lamont> meh.  dapper-backports upload of git-core is blocked on cvsps being in universe in dapper.
<LaserJock> doh
<jdong> LaserJock: lovely
<jdong> err lamont
<jdong> lamont: do you have closer connections with the soyuz folks than us?
<jdong> please I beg of you or someone, do something about it
<jdong> I've simply fallen upon deaf ears to fix this several-month-old regression
<lamont> does it have a bug?
<lamont> number that is
<lamont> jdong: because a bug number would be a major step towards escalating the fix.. esp if said bug was several months old...
<jdong> lamont: yes it does
<jdong> https://bugs.edge.launchpad.net/soyuz/+bug/198936
<ubotu> Launchpad bug 198936 in soyuz "Regression: Backports should ignore main-universe split" [Undecided,New]
<jdong> note the lovely lack of any activity or acknowledgement it exists
<lamont> jdong: I have a couple of things ahead of it (not just pleading for the sync of bind9.4.2-10 (after I upload it...)).  I'll poke someone or 3 about it this week
<jdong> lamont: thank you so much
<lamont> jdong: I mean, nfc if it'll have any more effect that your efforts...
<lamont> hrm... so do I mark a bug 'fix released' when I upload to debian, or when it's synced into hardy?
<RAOF> When it's sync'd, surely.  You could mark it as 'fix committed' when you upload to Debian, probably :)
<lamont> nah, it get's "fix committed" when the fix is, uh, committed.  (to the vcs)
<LaserJock> lamont: well, I suppose the LP ideal would be that it would be Fix Released on a Debian task and probably Fix Committed on an Ubuntu task
<slangasek> lamont: you put the LP: line in the Debian changelog, and let the sync close the bug ;)
<lamont> slangasek: did that. :)
<slangasek> then let LP take care of the rest?
<lamont> slangasek: yeah - that was my plan.. the only thing it doesn't take care of is figuring out how to trigger the sync. :-)
<lamont> but I'll worry about that after dinstall tomorrow
<slangasek> ah, heh
<lamont> the upload is 2 ubuntu bugs, zar0 debian bugs. \o/
<LaserJock> slangasek: do you think you could push flashplugin-nonfree from the gutsy unapproved queue?
<slangasek> LaserJock: can you tag the archive admin on duty, please? :)
<LaserJock> I guess
<LaserJock> I was just trying to be as quick as possible
<LaserJock> but I can sub ubuntu-archive
<LaserJock> actually I won't, that'd be mean
<LaserJock> I'll poke in the morning if it's not done
<LaserJock> night all
 * lamont -> sleep
<Hobbsee> sleep is banned
<tjaalton> slangasek: oh right, vdr-plugin-pictures.. totally harmless, it seems :)
<dholbach> good morning
<warp10> Good morning
<laga> morning
<kagou> Good morning
<xtknight> is there supposed to be a konqueror-kde4-dbgsym package?  i don't see one.  ditto for konqueror-nsplugins-kde4-dbgsym
<TheMuso> 5~/c
<TheMuso> ugh
<RAOF> :)
<slangasek> kagou: bug #208419> did you ever install libpam-smbpass?
<ubotu> Launchpad bug 208419 in pam "Integrate samba password in PAM" [Wishlist,In progress] https://launchpad.net/bugs/208419
<slangasek> ah, apparently not
<kagou> slangasek, i finally installed libpam-smbpass
<kagou> :)
<xtknight> did it ever work?
<slangasek> kagou: right - the pam change makes it optional, so that PAM itself continues to work with or without libpam-smbpass installed
<kagou> but now i'm having problems with samba share...
<kagou> so i'm investigating
<slangasek> kagou: and making libpam-smbpass be installed by default is an additional change to make in support of this, but I want to be darned sure the PAM changes are right first
<kagou> indeed
<kagou> mmm apparently, since i'v installed libpam-smbpasswd i can not enter in my PC from a windows client. An authentification is needed
<slangasek> what do you mean by "enter"?
<mdke> BalaamsMiracle: I'm planning to import translations for ubuntu-docs in the next 2 days, time permitting
<kagou> from windows, i browse PC, and when I enter (double-click)  in my PC name (to see shared folders), now an athentification is required
<kagou> i purge my system and recheck all
<mdke> slangasek: is it going to be ok if the final ubuntu-docs upload with imported translations is ready by this weekend (i.e. a couple of days later than the freeze)?
<slangasek> mdke: yes
<mdke> slangasek: thanks
<kagou> slangasek, i suspect patched pam packages to interfer with samba server
<kagou> i'm installing a fresh daily image (to ensure that all is clean).
<kagou> brb
<slangasek> kagou: with or without libpam-smbpass installed?
<kagou> without
<slangasek> I'd want to see the share config
<kagou> slangasek, it's the default, installed by samba package
<slangasek> the samba package doesn't ship with any shares enabled by default...
<kagou> indeed, i making share using usershare system (nautilus-share). This way smb.conf is not modified
<slangasek> ok, and is it set to allow anonymous access?
<kagou> what ? smb.conf or usershare folders ?
<slangasek> the usershare folder
<kagou> no, set to authentification
<slangasek> so where's the bug?
<kagou> slangasek, i can not enter in my PC (from windows samba browser) to see shares (printer/filders)
<kagou> sorry i must go for 10min
<kagou> brb
<slangasek> ok, I don't see why you expect this to work currently.  You've said that libpam-smbpass wasn't installed, so no Samba password entry was set up... so why would you expect it to work yet?
<kagou> seb128, lut. do you have problem on launching gdmsetup. Here it tkae long time to launch, an harddrive have a lot of activity
<seb128> kagou: hi, no, but we have several report about it being slow on the first run after installation, the harddrive activity is interesting, could you strace it?
<kagou> slangasek, to resume. On a fresh/clean install/with samba/a folder shared for guest with nautilus-share (usershare). Browsing samba from a windows XP client is done like this : Enter workgroup/see PC/enter PC/see shares/ enter shares. Now that i'v played with pam pached/libpam-smbpass, ica n do browse/entre workgroup/see PC/CAN NOT entre PC
<kagou> seb128, sure, i'm finishing a fresh install
<kagou> seb128, a "strace gdmsetup > info" is enough for you ?
<Hobbsee> kagou: erm.  if the folder(s) that you're sharing require authentication, and you're getting a prompt to authenticate....what, exactly, is the problem?
<Hobbsee> kagou: you appear to think that you should not have to authenticate, even though you've set it up so it requires authentication.
<kagou> Hobbsee, i'm getting a prompt to enter in the PC, not in the share
<kagou> this is the problem, as i can't see pdf/folder shares
<kagou> this is the problem, as i can't see printers/folder shares
<Hobbsee> you're trying to connect to a windows box, i assume?
<slangasek> from a windows box, to a Samba server
<kagou> from a windows XP client
<Hobbsee> oh right
<Hobbsee> kagou: why would you expect to have to have to put in your password at the physical samba share, then?
<slangasek> kagou: that sounds perfectly normal to me that you would be asked to authenticate when connecting to the server
<Hobbsee> having to bash down the server room door, so you can type in a password, so you can pull files from the server room back to your windows machine seems...backwards.
<slangasek> ...?
<Hobbsee> which appears to be what kagou is saying?
 * Hobbsee gives up
<xtknight> he just wants to see what shares are broadcast
<xtknight> instead of actually getting into a share
<xtknight> not sure if you need to auth to do that
<slangasek> I believe he's saying that he gets a password prompt trying to browse the host from windows
<slangasek> which is normal
<Hobbsee> well, yes...
<kagou> slangasek, no it's not normal
<Hobbsee> ah, right.  so that's what he's saying.
<slangasek> er, but it is...
<kagou> :p
 * mvo waves to xtknight
<kagou> sorry but my english is poor and sometimes i'v difficulty to explain well
<xtknight> mvo, oh yeah i had another bug to talk to you about
<xtknight> Bug 212542
<ubotu> Launchpad bug 212542 in compiz-fusion-plugins-main "Drop type=Utility from 01-animation-defaults.patch" [Low,Triaged] https://launchpad.net/bugs/212542
<xtknight> get my earlier messages?
<slangasek> kagou: when you try to connect to an SMB server, the server will request credentials from the client even if all you're doing is browsing it - and different shares may be visible depending on the credentials used
<slangasek> so yes, you will get a password prompt when browsing the host, unless your Windows client already knows credentials to use
<kagou> slangasek, since today, connecting SMB server do not requier password prompt, and so i can see shares (printers/shared folders)
<Hobbsee> head-->desk.
<Hobbsee> (mine)
<mvo> xtknight: yeah, that one is scheduled for today
<xtknight> mvo, oh ok i didn't even bother to check the page.  looks like you've got that taken care of, then
<xtknight> i'm off to get sleep, laer
<xtknight> later
<slangasek> kagou: by "since today", do you mean "before today"?
<mvo> thanks xtknight
<xtknight> mvo, thanks for dealing w/ the bugs, your job seems heftier than mine
<kagou> slangasek, indeed
<slangasek> kagou: what's the value of 'map to guest' in /etc/samba/smb.conf?
<kagou> slangasek, i can't say this now. Let me finish install :)
<ogra_cmpc> asac, if i dont use dhcp, can it be that NM doesnt show the network at all ?
<ogra_cmpc> (the wlan i mean)
<slytherin> ogra_cmpc: yes, when you use static ip, NM will pretend as if it doe snot know what the status is. :-)
<asac> ogra_cmpc: if you have a config in interfaces, NM will not manage that device
<ogra_cmpc> asac, no, thats different
<asac> ogra_cmpc: it will instead assume that you are online (so apps don't come up in offline mode)
<ogra_cmpc> asac, RichEd doesnt have a dhcp server in his network ... seems he doesnt see his wlan on the cdlassmate
<asac> ogra_cmpc: if the interface is managed, network manager cannot know about dhcp or not dhcp before it actually associates. so its unrelated for sure
<asac> ogra_cmpc: maybe he has a hidden SSID
<ogra_cmpc> no, he said he doesnt
<asac> sudo iwlist scan
<ogra_cmpc> (was my first question as well :) )
<kagou> slangasek, i'v a meeting. I'll be back in 1 hour
<asac> ogra_cmpc: if manually scanning doesn't show the network its a driver or AP issue
<asac> but since the cmpc works in general, i'd guess that its an AP issue for him
<ogra_cmpc> asac, i would guess APv since i havent seen the cmpc break on wlan at all with hardy yet
<asac> ogra_cmpc: maybe he uses a standard not supported by the cmpc driver?
<asac> like abg
<ogra_cmpc> and had no reports from others either
<ogra_cmpc> asac, <RichEd> abg ? wtf ?
<ogra_cmpc> if he does, he doesnt know i guess :)
<asac> ogra_cmpc: my router provides options to select modus "g or b"
<asac> ogra_cmpc: maybe some chipsets do not yet support one of abg
<asac> thats the only idea i currently have
<ogra_cmpc> i dumped all of that on him ... lets see what comes out
<kagou> slangasek, still here ?
<slangasek> kagou: only barely
<kagou> slangasek, with a fresh clean install+samba, browsing from a windows client let me see shares on my ubuntu samba server without password
<kagou> i see "PDF" + "Printers..."
<slangasek> kagou: this is with 'map to guest = bad user' in /etc/samba/smb.conf?
<kagou> yes, this is the default in smb.conf
<kagou> now i will install patched pam + libpam and try if this is changing something
<slangasek> so the username you've used to log in to the Windows client is one that doesn't exist on the server, right?
<kagou> indeed
<slangasek> ok; in that case, this is the expected behavior.  Yes, please let me know if something changes just by installing the new pam package
<kagou> slangasek, is there files to save before installing patched pam and libpam-smbpass ?
<slangasek> the only files that will be changed are /etc/pam.d/common-auth and /etc/pam.d/common-password
<slangasek> please install *just* the patched pam first
<slangasek> and test
<kagou> thanks
<kagou> ok
<slangasek> and then install libpam-smbpass, and test again
<kagou> 3 packages to upgrade...
<kagou> ->reboot
<slangasek> I have a more complicated PAM configuration on my own machine rather than the proposed default, but I believe that the tests I've done with the local samba are consistent and correct
<kagou> slangasek, works the same
<slytherin> calc: pitti: Does anyone of you mind if I reopen the bug 205923?
<ubotu> Launchpad bug 205923 in openoffice.org "openoffice in hardy doesn't build on powerpc" [Critical,Fix released] https://launchpad.net/bugs/205923
<kagou> i install libpam-smbpass
<kagou> reboot
<slangasek> slytherin: how does that differ from bug #214042?
<ubotu> Launchpad bug 214042 in openoffice.org "[Ubuntu] [hardy] OOo FTBFS on powerpc due to timeout" [Critical,In progress] https://launchpad.net/bugs/214042
<slytherin> slangasek: I didn't log any of those two. The timeout ones seems to be logged yesterday only.
<kagou> slangasek, seems ok too.
<slytherin> slangasek: and timeout is the reason I was going to reopen first one. But anyway since calc himself logged another bug and looking into it, I will not intervene. :-)
<kagou> i add a usershare for guest now
<BalaamsMiracle> mdke: Thanks for the info. But is there an official schedule after which the translations for all documentation are imported? Like once a month, one every 3 months, once a release?
<kagou> slangasek, damn seems to work now
<kagou> slangasek, i wil add new user, use it to share a folder with password
<cjwatson> anyone here in the Ubuntu German translators team? I need somebody to approve the typo correction (Standardspache -> Standardsprache) in https://translations.launchpad.net/ubuntu/hardy/+source/debian-installer/+pots/debian-installer/de/61/+translate for bug 195075
<ubotu> Launchpad bug 195075 in ubiquity "Typo in german translation of installer" [Low,Fix committed] https://launchpad.net/bugs/195075
<kagou> argll, windows have password+user in cache i must find how to empty this
<laga> i think i've applied twice for the german translators team but i havent been approved yet.. i guess i need to bug them in their irc channel
<cjwatson> the Launchpad translations team tell me that the translator teams are really supposed to be translation moderator teams, and that casual translators should just use suggestions
<cjwatson> the UI isn't clear at the moment
<kagou> slangasek, i found my bug !
<laga> ah. ok.
<laga> cjwatson: how are "suggestions" then merged? by the moderator teams?
<cjwatson> I'm told that that's the idea
<kagou> slangasek, all seems to work great, before i change my password for the first user. After that i can not more see shares
<ogra_cmpc> just out of curiosity, does anyone know why installing xfonts-* packages wants to have /lib/modules/$kvers/modules.dep in place ?
<cjwatson> I suspect that a number of translator teams don't actually work this way in practice at the moment, though
<ogra_cmpc> FATAL: Could not load /lib/modules/2.6.24-8-generic/modules.dep: No such file or directory
<laga> cjwatson: well, i was going to translate a few of "my" apps in rosetta to my native language.. i guess i'll resort to vim then and let rosetta handle other languages
<Hobbsee> TheMuso: looks like the launchpad-integration stuff is broken - conflicting file bewteen liblaunchpad-integration0 and liblaunchpad-integration1.  Please fix.
<cjwatson> laga: don't let me discourage you
<cjwatson> if you're doing serious chunks of translation, it's probably more effective to be in the moderator team anyway
<Hobbsee> TheMuso: wait, never mind.  mirror is out of date.
<laga> cjwatson: no worries, it's just a different choice of UI for me, the translation will end up in the repos anyways.
<cjwatson> true
<ogra_cmpc> ARGH
<ogra_cmpc> LAGA !
<ogra_cmpc> laga,        # do not start ltsp-client-core
<ogra_cmpc>         chroot $ROOT update-rc.d -f ltsp-client-core remove || true
<laga> i guess i broke something.
<ogra_cmpc> laga, could you move that and the following update-rc.d commands inside the if statement ?
<laga> ogra_cmpc: yes. sorry :/
<ogra_cmpc> so it doesnt get executed on normal ltsp ... its somewhat fatal to not have ltsp-client-core starting :)
<kagou> slangasek, bring back the "old" password, and all is ok
<slangasek> kagou: what "first user"?  At this point, I don't think this has anything at all to do with the pam changes; either your expectations for Samba are at odds with the intended behavior, or there's a bug in Samba, either way it doesn't correlate with the PAM change
<ogra_cmpc> sorry, i should have spotted that the fi sits to far up
<kagou> first user ->user created on hardy installation
<stgraber> ogra_cmpc: is that bug 214481 ?
<ubotu> Launchpad bug 214481 in ltsp "[hardy] ltsp-build-client builds incomplete filesystem" [Undecided,New] https://launchpad.net/bugs/214481
<laga> ogra_cmpc: just a debdiff this time? easier for you :)
<ogra_cmpc> laga, sure
<ogra_cmpc> stgraber, right, looks like it
<ogra_cmpc> laga, ^^^
<slangasek> laga, ogra_cmpc: could you not use update-rc.d -f, which will be completely undone by any upgrades to the ltsp-client-core package? :)
<kagou> slangasek, should I  report this bug to samba
<slangasek> kagou: if you think there's a bug, yes.
<laga> slangasek: what do you suggest?
<slangasek> kagou: in the meantime, I'm off to bed
<laga> slangasek: deleting the init script?
<ogra_cmpc> slangasek, well, thst the mythbuntu plugin doing that, i.d actually appreciate to have ltsp-client-core starting on ltsp :) but i'm sure laga will take it into account
<slangasek> laga: I don't think there's really a proper way to do that to another package's init script
<laga> slangasek: echo "exit 0" >> /etc/init.d/ltsp-client-core ;)
<kagou> slangasek, thank you for your time, i will remove pam patched and libpam-smb to test if this bug i sstill here. cya
<ogra_cmpc> laga, move it to K
<cjwatson> laga: the system is designed so that you must get the other package to cooperate, rather than non-consensually fiddling with its bits
<laga> cjwatson: that's planned for +1
<ogra_cmpc> upcdate-rc.d of the package will do nothing if a K link exists, just dont remove it
<laga> ogra_cmpc: so i just remove the S links. i guess for +1, i should write a blacklist function similar to the whitelist one
<ogra_cmpc> If  any  files  /etc/rcrunlevel.d/[SK]??name already exist then update-
<ogra_cmpc>        rc.d does nothing.  The program was written this way so  that  it  will
<ogra_cmpc>        never  change an existing configuration, which may have been customized
<ogra_cmpc>        by the system administrator.  The program will only  install  links  if
<ogra_cmpc>        none  are  present, i.e., if it appears that the service has never been
<ogra_cmpc>        installed before.
<ogra_cmpc> from man ...
<ogra_cmpc> laga, oh, btw,why did you disable nbd-client ? it wont do any harm (will just fail silently if there is no configuration)
<laga> ogra_cmpc: i'm not worried about starting it, i'm worried about it getting killed when the box is shut down
<asac> ogra_cmpc: whatfor would libflashsupport require SSL?
<ogra_cmpc> ah, right, you should move it
<laga> hum, is it "for i in $@; do" or "for i in "$@"; do" - i wonder if i these quotation marks will affect semantics
<ogra_cmpc> asac, hmm, i knew that once ... its so long ago that i had to do with actual code there, let me look
<Mithrandir> laga: use "$@" or just for i; do ... ; done
<asac> communication with sound server? over ssl?
<laga> Mithrandir: thanks
<asac> ogra_cmpc: please fix it ;)
<ogra_cmpc> asac, whats wrong with it ?
<asac> ogra_cmpc: from the strace it looks like it invalidates file descriptors and finally crashes firefox/youtube
<asac> ogra_cmpc: go to youtube ... select a video with sound ... and push backwards and forwards ... wait till sounds start. repeat
<asac> crash!
<ogra_cmpc> asac, aha
<ion_> laga: sh -c 'set -- "foo bar" "baz x"; printf "%s\n" "$@"' and sh -c 'set -- "foo bar" "baz x"; printf "%s\n" $@'
<ogra_cmpc> asac,
<ogra_cmpc>   * built with tls support patch from Daniel T. Chen <crimsun@fungus.sh.nu>
<ogra_cmpc>     https://code.edge.launchpad.net/~crimsun/libflashsupport-pulse/devel
<asac> ogra_cmpc: yeah i disabled that already
<asac> by default it uses OPENSSL
<ion_> laga: And yeah, as Mithrandir said, plain âfor iâ is sufficient.
<ogra_cmpc> asac, originally it used libssl
<asac> that patch switches to gnutls
<asac> yeah ... but that didn'thelp
<ogra_cmpc> well, then its not ssl related i'd say
<asac> i even switched from PULSEAUDIO to ALSA ... in that way the crashes are even more frequent
<ogra_cmpc> yeah, flashsupport shouldnt be hooked between flash and alsa
<laga> ion_: thanks
<asac> ogra_cmpc: well. it was just to evaluate
<ogra_cmpc> its really only to work around pulse not closing its handles
<ogra_cmpc> err flash
<ogra_cmpc> not pulse
<asac> ogra_cmpc: and see where the problem might be. so given that neither SSL nor the sound output is responsible i guess that its really in the core of flashsupport
<asac> they have a worker thread for instance.
<asac> maybe that tries to access filedescriptors after firefox already closed the page or something
<ogra_cmpc> did you check the urls listed in the package description ?
<asac> ogra_cmpc: i don't see that purpose in the code
<asac> ogra_cmpc: for updates? Luke did. there is no new code
<ogra_cmpc> but probably info we dont know yet :)
 * ogra_cmpc looks
<asac> ogra_cmpc: #225  Deadlock/crash in flashsupport closing stream
<asac> maybe that ticket
<ogra_cmpc> hmm, the only git checkin is a version change to support pulse 0.9.5
<cjwatson> laga: as a general rule, double-quote all parameter expansions in shell unless you know that you have an explicit reason not to do so
<asac> ogra_cmpc: yeah. thats what luke told me
<asac> damn. now gdb crashes if you run firefox from within
<asac> doko: ^^
<ogra_cmpc> so that looks like there a partial fix already
<ogra_cmpc> 6 lines is not that much, but seems there is more to fix ...
<asac> ogra_cmpc: where?
<asac> in the ticket?
<ogra_cmpc> yeah
<asac> oh in the mids of the long pastes there is indeed something
 * asac reading
<asac> let me try that
<ogra_cmpc> http://paste.ubuntu.com/6658/
<ogra_cmpc> but apparently that doesnt fix it completely yet
<asac> hmm
<ogra_cmpc> works ?
<asac> ogra_cmpc: no, but i had a hacked version trying a clean one now
<cjwatson> laga: (cases where you would generally not want to double-quote parameter expansions are when they're the operand to 'case', or when you want to deliberately word-split something)
<asac> ogra_cmpc: how is that supposed to fix a dead lock?
<laga> cjwatson: i once read a good explanation of all that, but i forgot half of it, hence my question :) thanks for the explanation
<cjwatson> laga: http://www.greenend.org.uk/rjk/2001/04/shell.html is a good article by a friend of mine on the subject
<asac> ogra_cmpc: now it crashes firefox when playing the video for first time
<laga> cjwatson: thanks, bookmarked
<ogra_cmpc> asac, as i understand it he tries to kill the thread before it can lock up
<doko> asac: architecture specific?
<ogra_cmpc> asac, http://www.pulseaudio.org/ticket/225#comment:4 is the relevant info here i think
<asac> doko: i don't think so.
<asac> doko: can you try to start gdb /usr/lib/firefox-3.0b5/firefox
<asac> run
<asac> with dbgsym for xulrunner-1.9 and firefox-3.0 installed?
<asac> maybe flashplugin-nonfree and libflashsupport-dbgsym as well
<asac> ogra_cmpc: hmm. we could use a timed mutex then in shutdown
<ogra_cmpc> i wonder if there is simply siomething missing in FPX_SoundOutput_Close
<ogra_cmpc> where the heck is p DEFINED
<ogra_cmpc> oops
<asac> ogra_cmpc: pulse doesn't provide such a timeout lock
<asac> ogra_cmpc: unlikely that p is not allocated :)
<ogra_cmpc> no, i mean not freed correctly
<asac> ogra_cmpc: zeroing is done in line 943
<ogra_cmpc> FPX_SoundOutput_Close frees p->mainloop, ->context and ->stream
<asac> and alloc in the line before
<asac> ogra_cmpc: i think its created in init and then only kept as user_data in the callback
<asac> ogra_cmpc: pa_context_set_state_callback(p->context, context_state_cb, p);
<ogra_cmpc> hmm, what about p->first ?
<asac> welll and a few more callbacks get that
<asac> so maybe we really get a call with that as data after free
<asac> for instance _write_callback might be  a candidate
<asac> maybe we can cancel those explicitly on free?
<ogra_cmpc> write_data breaks oif p->first is 1 and then sets it to 0 ... but it doesnt get freed
<ogra_cmpc> at least not explicitly anywhere
<asac> so what is first?
<asac> just a bool thing?
<cjwatson> tjaalton: do you know if there's been any progress on bug 184651, or if it needs help? It's assigned to you
<ogra_cmpc> it indicates that there is a connection to flash as i understand it
<ubotu> Launchpad bug 184651 in xorg-server "Crash when starting gnome-settings-daemon, in SrvXkbFreeGeomRows()" [High,In progress] https://launchpad.net/bugs/184651
<cjwatson> tjaalton: setxkbmap (to Brazilian and back) might be an easier way to test it than messing with gnome-settings-daemon
<asac> ogra_cmpc: also maybe interesting that we goto fail; instead of goto unlock_and_fail in line 693 even though we have a lock
<tjaalton> cjwatson: I'm about to upload it :)
<asac> ogra_cmpc: first == no connection to flash?
<asac> i cannot map that ;)
<cjwatson> tjaalton: hooray :-)
<ogra_cmpc> asac, if (!p->first && !pa_stream_get_timing_info(p->stream))
<asac> ogra_cmpc: maybe it indicates if its the first write_data ?
 * cjwatson blats yet another dup of it
<asac> call after _Open?
<ogra_cmpc> hmm
<ogra_cmpc> line 890: p->first = 0; /* So, we write the first block noch, remember that */
<asac> ogra_cmpc: let me try to null out the callbacks before freeing the context
<ogra_cmpc> so p->first seems to indicate the first data blck
<asac> yeah
<cjwatson> does anyone happen to know if there's an appropriate GTK style for warning text that would render it as red? I don't really feel good about hardcoding the colour. Bug 204053
<asac> i think first isok
<ubotu> Launchpad bug 204053 in ubiquity "Make warning text in Ubiquity red" [Wishlist,Confirmed] https://launchpad.net/bugs/204053
<Riddell> evand: erk, ubiquity has stopped being able to change the mount point
<cjwatson> Riddell: in bzr?
<Riddell> cjwatson: today's daily CD
<cjwatson> I expect that's my fault
<cjwatson> you said my changes worked ;-)
<Riddell> kubuntu
<Riddell> cjwatson: yeah, I can't remember if I tested setting the mountpoint
<Riddell> I'd have thought I would, but maybe not
<cjwatson> I'm syncing the Kubuntu daily now and will check once I've got it
<cjwatson> or I can help you fix it if that would be quicker
<cjwatson> Riddell: is this while creating a partition, or while editing a partition?
<cjwatson> Riddell: and is it by selecting from the dropdown, or by typing it in?
<Riddell> cjwatson: selecting the dropdown
<Riddell> while editing a partitio
<cjwatson> Riddell: and presumably the symptoms are that it accepts it in the dialog, but then doesn't actually change it when you press OK?
<Riddell> cjwatson: yes
<cjwatson> damn, it's working in gtk and that bit's basically the same
<cjwatson> can I have syslog just in case it's a stupid crash or something?
<cjwatson> (and /var/log/installer/debug)
<Riddell> hang on, jockey seems to have frozen the entire machine while installing broadcom firmware
<Riddell> cjwatson: http://kubuntu.org/~jriddell/tmp/syslog
<Riddell> running on my installed machine
<Riddell> exception near the bottom
<Riddell> http://kubuntu.org/~jriddell/tmp/debug
<cjwatson> Riddell: whoopsie
<Riddell> cjwatson: http://kubuntu.org/~jriddell/tmp/kde_ui.diff
<Riddell> seems to sort it
<Riddell> cjwatson: committed
<ion_> mvo: Has there been any progress with the apt+zsync thing, btw?
<cjwatson> Riddell: thanks, I was on the phone so you beat me to it
<seb128> $ dpkg --compare-versions 2.22.1 gt 2.22.01; echo $?
<seb128> 1
<seb128> bah
<Riddell> pitti: after using jockey to install broadcom firmware on a live CD session, any process using the network freezes
<Riddell> oh, pitti's away
<Riddell> cody-somerville: possibly this was intended to go to you https://bugs.edge.launchpad.net/ubuntu/+source/abiword/+bug/202174/comments/30
<ubotu> Launchpad bug 202174 in abiword "Please update to version 2.6" [Undecided,New]
<cody-somerville> Riddell, thanks. It was.
<cjwatson> lamont: in case you don't read bug mail, could you have a look at bug 206113, please?
<ubotu> Launchpad bug 206113 in util-linux "Wubi install cannot create swap space (8.04 Beta) [Regression from alpha 6]" [Undecided,New] https://launchpad.net/bugs/206113
<lamont> cjwatson: I don't read bug mail generally, thanks
<lamont> hrm... although that does leave me wondering where I auto-filed the mail...
<lamont> cjwatson: it'll be this afternoon latish sometime, and I'll work on that.  (after 2200UTC)
<cjwatson> thanks
<lamont> go ahead and assign it to me if you want - either way, it's top of the list when I get my core-dev hat back on.
<seb128> asac, pochu: what was this firefox font issue happening when using the xrandr capplet?
<pochu> seb128: bug 178558
<ubotu> Launchpad bug 178558 in xulrunner-1.9 "Firefox 3.0 makes everything annoyingly huge" [High,Fix released] https://launchpad.net/bugs/178558
<seb128> xrandr1.2 seems quite broken
<seb128> xorg detects the dpi correctly
<seb128> but as soon as you use the new capplet on an intel965 card you get broken dpi values
<seb128> ie, xpdyinfo lists 1x1 for example
<ogra_cmpc> thats tiny :)
<ScottK> mvo: I see you updated my pyspf package for Dapper -> Hardy upgrades.  I'm pretty sure python-dns will also need doing.  I'll take care of that one so you can mark it off your list.
<cjwatson> lamont: ok, done
<lamont> dear firefox.  please stop stealing focus and let the window manager do its job.  kthx
<mvo> ScottK: great, thanks
<ScottK> mvo: Actually looking at it now.  The python-dns we have in Dapper was so unmaintained it didn't actually provide python version specific binaries
<ScottK> So it looks like due to poor maintenance two years ago we get off easy now.
<jdong> asac: what's the least messy way for me to make firefox "open with" a single app for everything?
<rrittenhouse> I went to upgrade hardy this morning to grab the latest packages and I'm just wanting to see if this was a problem on my end or your end. When updating it tries to install ia32-libs (im running 64bit hardy) I get an error msg stating that the ia32-libs package is trying to overwrite /usr/lib32/gtk-2.0/2.10.0/loaders/svg_loader.so which is also in package vmware-server
<cjwatson> that's a vmware-server bug
<rrittenhouse> ah ok
<cjwatson> it shouldn't be shipping files in that directory
<mvo> ScottK: heh :) good, python-dns dosen't show up in my scanner for the missing conflicts/replaces so that is good news
<cjwatson> if it needs to ship them itself for whatever reason (but really, it shouldn't), then it should use a private directory
<lamont> dear firefox. when picking a window to use for a "open in browser" thang, please prefer the ONE IN THE CURRENT WORKSPACE
<Hobbsee> lamont: it picks the last used one instead?
<lamont> yep
<lamont> and drags it across several workspaces to get here.
<Hobbsee> yeah.  i don't think firefox groks workspaces - or focus.
<lamont> not a regression though
<lamont> for either
<lamont> simply pain
<mvo> lamont: are you running the latest metacity? or compiz?
<Hobbsee> with kde you could fix that.
<Hobbsee> but i don't remember it being a problem (it changing work spaces) with compiz for a long while either.
<lamont> mvo: on this machine, I have yet to have compiz come up....  what do I need to tweak where (restarted gdm and X after (re)installing compiz, still no compiz love)
<mvo> lamont: click on system/preferences/apperance/desktop effects
<lamont> Hobbsee: it doesn't change workspaces, it drags a ffox window from another workspace to here.
<Hobbsee> lamont: sorry, that's what i meant.
<Hobbsee> (was unclear that it == firefox, in my statement)
<rrittenhouse> I'm also getting "no space left on device errors" is that something with hardy?
<lamont> meh.  "please reboot so we canz have the closed nv driver, kthx"
<lamont> mvo: thanks - I'll reboot later today then
<mvo> lamont: yeah, the joy of binary-only drivers
<cjwatson> ogra_cmpc: could you reassign bug 207634 to the proper place? I doubt it belongs on ubiquity
<ubotu> Launchpad bug 207634 in ubiquity "LTSP amd64 installs 64bit clients software" [Undecided,New] https://launchpad.net/bugs/207634
<ogra_cmpc> heh, i wonder how it ended up there first place :)
<stgraber> hmm, LTSP assigned to ubiquity ? :)
<\sh> cjwatson, TB devices are working
<cjwatson> \sh: excellent
<cjwatson> \sh: though I hope that's >2TB?
<cody-somerville> slangasek, As I suspected, those errors yesterday were just intermittent.
<\sh> cjwatson, you can bet on it :)
<asac> jdong: hmm
<cjwatson> Riddell: bug 203626 looks very ugly; does it show up that way by default?
<ubotu> Launchpad bug 203626 in ubiquity "Kubuntu installer: Edit partition dialog rendering error" [Undecided,New] https://launchpad.net/bugs/203626
<cjwatson> Riddell: can we just remove all the sizeHints from the .ui files? :-P qt4-designer seems to like to add them from time to time
<TheMuso> If anybody happens to be running hardy on a PowerPC, if you could please try this new yaboot package, to fix G5 SATA issues. http://www.themuso.id.au/ubuntu/yaboot_1.3.13a-1ubuntu5_powerpc.deb Works for me on my G4, and the author tested on a few machines, but the more it is known to work on other machines the better. If all is favourable, please ping/message me, and I can then get it uplaoded. Thanks in advance.
<Riddell> cjwatson: yes, that would probably work
<ogra_cmpc> asac, do we have a bug open for the libflashsupport issue ? i'm just talking to warren in #ltsp (libflashsupport maintainer in fedora)
<asac> ogra_cmpc: no, because we cannot get a good backtrace
<asac> i have a upstream crash report though
<asac> (so its not only us)
<ogra_cmpc> yeah
<ogra_cmpc> do you know when it broke ?
<asac> ogra_cmpc: http://crash-stats.mozilla.com/report/index/49e43885-e464-11dc-8f26-001a4bd43e5c
<ogra_cmpc> (or do you mind coming over to #ltsp so i dont need to proxy warren :) )
<asac> ogra_cmpc: i think it either was always broken (e.g. we didn't use pulseaudio + flashsupport combo)
<ogra_cmpc> i think flash changed
<asac> ogra_cmpc: yes. probably wasn't the problem when flash didn't use xembed
<ogra_cmpc> ltsp users used that setup in gutsy
<asac> which was about 2 flash releases away
<ogra_cmpc> (we didnt have it buy default though)
<asac> ogra_cmpc: but you said that you cannot reproduce it in ltsp ... so maybe you just didn't see it
<ogra_cmpc> asac, well, i had plenty other firefox issues in gutsys ltsp it probably just was hidden behind the ram problems
<asac> ;)
<asac> ogra_cmpc: question is: can you reproduce it now?
<asac> anyone still has a rotting old flash on his disk? (something older than 6 month?)
<asac> i'd really like to see if this is a flash regression
<\sh> slangasek, any reasons why we didn't sync/merge php 5.2.5 for hardy?
<ogra_cmpc> asac, not atm, i'm testing flash on the classmate a lot and the browser runs stable .... i havent tested on ltsp
<asac> ogra_cmpc: classmate uses flashsupport + pulse?
<asac> that would really go together with the caused-by deadlock thing
<asac> most likely classmate has a different thread scheduling due to its constraints :)
<lamont> cjwatson: I want an escape in ControlPath for 'source IP' address or some other easy-to-control thing
<asac> ogra_cmpc: http://crash-stats.mozilla.com/report/index/49e43885-e464-11dc-8f26-001a4bd43e5c
<asac> ogra_cmpc: oh sorry. alrady posted that above
<ogra_cmpc> asac, indeed it uses whatever we have by default
<cjwatson> lamont: %l for local host name not good enough?
<ogra_cmpc> asac, warren asks if you could come over for a sec (#ltsp)
<lamont> cjwatson: I have a big-fat-routing hack where there's an additional IP on the host, and packets from that IP get routed/SNATed out a diff ISP...
<cjwatson> lamont: bugzilla.mindrot.org would be the best place to ask, then
<cjwatson> if I add it locally they'll just do it with a different option letter later ;)
<Riddell> cjwatson: today's kubuntu desktop CD has universe disabled in sources.list
<lamont> cjwatson: very true
<lamont> thanks
<cjwatson> Riddell: the live CD itself always has, AFAIK; shouldn't affect what's in place after installation
<cjwatson> if you want to change that, livecd-rootfs is the place, but you should probably take care to do that only after installing everything
<cjwatson> Riddell: is there time to fix bug 203660 by creating a QMessageBox by hand as described in http://doc.trolltech.com/4.3/qmessagebox.html? I agree with Celeste that the current display is confusing
<ubotu> Launchpad bug 203660 in ubiquity "Partition formatting message unclear" [Medium,Triaged] https://launchpad.net/bugs/203660
<ogra_cmpc> cjwatson, hmm, is the d-i question for the installer language asked on purpose ?
<ogra_cmpc> (i dont mean the gfxboot one)
<cjwatson> ogra_cmpc: only if you select English in gfxboot; and yes, that's on purpose in case people just take the default
<ogra_cmpc> i selected german
<cjwatson> ah, I know, this is because I haven't uploaded debian-installer recently
<cjwatson> so it's still using the localechooser without that feature
<ogra_cmpc> ah
<cjwatson> (I changed how this stuff works in response to bug 85162
<cjwatson> )
<ubotu> Launchpad bug 85162 in localechooser "installer doesn't permit to set little countries" [High,Fix released] https://launchpad.net/bugs/85162
<ogra_cmpc> nice description :)
<Riddell> cjwatson: yes that dialogue should be fairly easy to fix, I think it just wasn't possible or I couldn't see how when I first ported it to qt4
 * Riddell adds to TODO
<cjwatson> thanks
<cjwatson> ogra_cmpc: uploading
<ogra_cmpc> i'll test with the next build if its gone ...
<TheMuso> Keybuk: Do you have a minute to discuss some initramfs/mdadm stuff?
<Keybuk> TheMuso: sure, what's up?
<TheMuso> Keybuk: Re the initramfs error handling spec at https://wiki.ubuntu.com/HardyInitramfsErrorHandling, I'm trying to get a mount root failure hook to execute for mdadm if a RAID array cannot be brought up. The hook gets executed from the panic function, however this does not happen because the md device node exists even if the array cannot be brought up.
<TheMuso> Keybuk: What I'm thinking of doing is making the panic while loop get executed if either the root device node doesn't exist, or vol_id can't identify the device/volume. However I am wondering if there is a better solution, or whether this might break something else.
<kagou> pitti, around ?
<Keybuk> I'm not entirely sure I follow
<Keybuk> the mountroot() function in the initramfs runs alongside udev
<Keybuk> which itself runs alongside the kernel which is busy poking and probing for things
<Keybuk> so device nodes may show up at any time inside mountroot(), not when you're expecting them
<Keybuk> this is why mountroot() has a while loop that waits for the device node to exist
<Keybuk> since that's a good indication that the block device has been detected
<Keybuk> for mdadm devices, the device node is created when the array is detected
<Keybuk> this does not mean that the array is functional
<Keybuk> since the array can be detected if metadata is found on another drive about it
<Keybuk> or if just one drive of the set has turned up
<TheMuso> Keybuk: I gathered as much.
<TheMuso> re mdadm
<Keybuk> so mountroot() also tests the root device with vol_id
<ogra_cmpc> dont you have a uuid you can wait for ?
<ogra_cmpc> ah
<Keybuk> which actually examines the filesystem on the root device
<TheMuso> Waiting for a device is not the issue.
<Keybuk> as ogra says, if you have UUID= this is largely irrelevant since you won't have the target filesystem UUID until the array is functioning *anyway*
<Keybuk> this is for ROOT=/dev/md1
<TheMuso> I'm talking about the point where the script gives up, and panics.
<Keybuk> ok
<Keybuk> so after a while, the script gives up and panics
<Keybuk> if they're using ROOT=UUID=... you're pretty buggered, since you don't know it's on a RAID device
<Keybuk> if the UUID has shown up, you wouldn't be panicking
<TheMuso> Yep, that I also know. The issue here, is the above spec outlined details of some information being given to the user in the form of a mountroot failure hook, that gets executed before the script drops you to a shell.
<Keybuk> ok
<ogra_cmpc> long term the panic function should be enhanced imho
<Keybuk> in which case, you have several cases
<Keybuk> 1) the $ROOT device doesn't exist
<Keybuk> 2) the $ROOT device exists, but vol_id fails
<Keybuk> for (2), if $ROOT looks like an md device, you can assume the array is broken in some way
<TheMuso> Right. At the moment, these hooks are executed in the panic function, if panic is passed an extra argument. However since the md device node exists, the panic doesn't occur, and the script crashes out later anyway.
<Keybuk> actually that's only really two cases, not several ;)
<Keybuk> the panic should occur?
<Keybuk> mountroot() will panic if the array exists, but hasn't been activated
<Keybuk> so [ -e $ROOT ] is true
<Keybuk> but /lib/udev/vol_id $ROOT will be false
<Keybuk> ie. array node exists, but filesystem on it cannot be found
<TheMuso> Yes thats right.
<Keybuk> at that point, if $ROOT is /dev/md*, you can just use mdadm to probe it and provide useful feedback
<Keybuk> oh
<Keybuk> I see
<Keybuk> there's a bug in the initramfs script ;)
<Keybuk> it loops while the device doesn't exist, or vol_id fails
<Keybuk> but only panics if the device doesn't exist
<Keybuk> thus your problem
<Keybuk> :p
<TheMuso> Yes.
<Keybuk> I honestly think that's just a bug in the initramfs script
<Keybuk> vol_id was added later, so was obviously missed on the third point it was needed
<TheMuso> Right, I was thinking of adding it to that lop anyway, so panic gets triggered and still gives the user meaningful info.
<Keybuk> that second while should match the first while, and the if
<Keybuk> yes
<Keybuk> that is what I would do
<TheMuso> Ok. Was just wonderng if that would be likely to break anything else.
<Keybuk> shouldn't think so
<TheMuso> I've already tested these changes locally, and they work 100%.
<TheMuso> Keybuk: Ok thanks for your time.
<Keybuk> could you do me a favour while you're in there?
<TheMuso> Keybuk: Sure.
<Keybuk> the init script in initramfs
<Keybuk> the very last line is exec run-init
<Keybuk> it could do with a 2>&1 on the end ;)
<TheMuso> Of the whole line?
<Keybuk> yeah
<Keybuk> should be
<Keybuk> exec run-init ${rootmnt} ${init} "$@" <${rootmnt}/dev/console >${rootmnt}/dev/console 2>&1
<TheMuso> Yep I can do that. What is this supposed to be fixing?
<Keybuk> fixes the long-standing bug that init has no stderr :-)
<TheMuso> haha right.
<pwnguin> the more i look at initramfs scripts, the more i understand why they're not fixed =(
<TheMuso> pwnguin: The whole initramfs infrastructure is not too bad actually, once you get your head around it.
<laga> hah
<TheMuso> Keybuk: Ok, will do that. Thanks again.
<pwnguin> TheMuso: then feel free to have a look at bug #203429
<ubotu> Launchpad bug 203429 in initramfs-tools "resume script missing functions" [Undecided,Confirmed] https://launchpad.net/bugs/203429
<TheMuso> pwnguin: Ok...
<Keybuk> TheMuso: patch looks good to me
<TheMuso> Keybuk: Ok, will throw it in as well.
<ogra_cmpc> initramfs ... <3
<pwnguin> so is initramfs really the kernel team's purvue?
<pheld> are there any hardy locale-packages for FF3 somewhere?  or updated locale for FF2?
<Keybuk> pwnguin: not really, it's one of those things that doesn't really belong to the kernel or to userspace
<Keybuk> one of my long-term goals is to make it just an extension of userspace
<pwnguin> oh, btw Keybuk. i haven't been able to reproduce it lately, but thinkfinger in hardy is occasionally triggering an infinite look in hal-input-addon or something. if i can ever get it again, i'll make sure to document it well
<Keybuk> interesting
<pwnguin> i tried having a look at the package for interesting changes, but the diff.gz includes most/all of upstream svn
<Keybuk> I'm not entirely happy with thinkfinger in general
<Keybuk> I managed to find all sorts of little threading issues with it
<pwnguin> i dont think anyone is
<Keybuk> fprint is much better, but nowhere near complete enough
<Riddell> ArneGoetje, freeflying: kubuntu-kde4 CDs have started being built again, scim-bridge-client-qt4 seems pretty broken for people who don't use scim.  if you don't have scim installed it delays startup by several seconds and if you do it insists on starting scim-gtk (not skim) and won't let you kill it
<freeflying> Riddell: do u have any extra space for scim in cd?
<Riddell> freeflying: not really, but it shouldn't force people to run an app they don't need
<freeflying> Riddell: if not, I prefer to drop skim scim-bridge out, cause without scim and corresponding IMe, they really useless
<Riddell> scim-bridge-client-qt (qt3) has no such problems, if you don't have scim installed it doesn't complain or delay apps starting
<ScottK> doko: For python-central I think we are done with fixing everything.  For python-xml, it looks like zsi and pyslide need some additional work.  I'm out of bandwidth to deal with it.
<doko> ScottK: thanks, these are still on my list
<doko> ScottK: hmm, I did upload zsi ...
<ScottK> doko: Yes, but there was some additional feedback on zsi.  I think either the feedback was invalid or additional change was needed.  I haven't have time to investigate.
<ScottK> doko: For zsi see https://bugs.launchpad.net/ubuntu/+source/elisa/+bug/199014/comments/94
<ubotu> Launchpad bug 199014 in pyslide "python-xml removal: please drop/replace (build) dependencies" [Undecided,In progress]
<doko> ScottK: uploaded
<ArneGoetje> Riddell: I told you before that you will need 4 packages installed: scim, scim-bridge-agent, scim-bridge-client-qt4, scim-bridge-client-qt.
<ArneGoetje> Riddell: otherwise it doesn't work!
<TheMuso> Ok, new initramfs-tools uploaded, and I'm off to bed.
<Riddell> ArneGoetje: right, but even with scim installed (and we don't like gtk apps in kubuntu of course) it causes problems for non-scim users
<Riddell> since it insists on starting scim and won't let you quit
<ArneGoetje> Riddell: well, now you cannot use CJK.
<Riddell> yes :(
<ArneGoetje> Riddell: start skim and select it to be the gui for scim.
<ArneGoetje> Riddell: you will need scim running in the background anyways. Skim is the KDE frontend to connect to the scim backend daemon.
<Riddell> ArneGoetje: do you know why scim-bridge-client-qt4 insists on starting scim while qt/gtk clients do not?
<ArneGoetje> Riddell: scim will always be running and is normally started with the X session. im-switch takes care of that.
<ScottK> doko: Cool.  I guess we can mark that off as done then.
<geser> keescook, jdstrand: as bug #214194 is marked security, I wanted to ask you if it's ok to set the bug to invalid based on my comment
<ubotu> Launchpad bug 214194 in gnupg "GnuPG allows remote attackers to cause a denial of service" [Undecided,Confirmed] https://launchpad.net/bugs/214194
<jdstrand> geser: yes-- this was also confirmed (as noted in ubuntu-cve-tracker)
<emgent> hi jdstrand
<jdstrand> hi emgent
<keescook> geser: yeah, please do.
<freeflying> ArneGoetje: Riddell also need scim-modules-socket
<ScottK> freeflying: Riddell is going to upload the qt3 asian languages patch you pointed me at yesterday.
<freeflying> ScottK: have u tested it already?
<ScottK> No.  He was looking into it.
<Riddell> freeflying: makes chinese characters in konqueror nicely
<ScottK> My Kubuntu bandwidth is consumed by kde-guidance at the moment.
<freeflying> Riddell: but can not handle it under en_US locale
<freeflying> Riddell: oh, u mean ur patch?
<Riddell> freeflying: yes, adding the patch fixes chinese characters in konqueror for me
<emgent> keescook: have you saw anteater beta?
<emgent> hi, btw :)
<freeflying> Riddell: cool
<doko> Riddell: what is a standard image viewer installed by default on Kubuntu?
<Riddell> doko: gwenview
<doko> Riddell: thanks
<keescook> emgent: hi, took a brief look, seems nice.  :)
<emgent> cool :)
<doko> Riddell: hmm, but there's nothing like an alternative for a generic image viewer?
<Riddell> doko: I don't understand
<Riddell> doko: konqueror too of course (using gwenview's kpart)
<crevette> who is Soren Hansen ?
<crevette> hey I found :)
<crevette> soren: around ?
<cjwatson> Riddell: I think he means an alternative as in update-alternatives
<cjwatson> isn't there an XDG way to spawn an image viewer given a file?
<cjwatson> like xdg-open <filename>
<ogra_cmpc> cjwatson, do you still se the hang in kvm when the X focus is gone ? apparently my virtualbox decided to behave similar
<LaserJock> cjwatson: yep
<cjwatson> ogra_cmpc: it was only when switching using Ctrl-Alt-<cursor>, so now I just press/release Ctrl-Alt and use the workspace switcher widget
<ogra_cmpc> ah, k
<ogra_cmpc> i have it with alt-tab my installs all failed at different points today
<ogra_cmpc> its a bit tricky to put windows side by side on the classmate ... so i cant really avoid dropping the focus ...
<cjwatson> my kvms are usually maximised
<ogra_cmpc> ah
<emgent> heya tseliot :)
<tseliot> ï»¿emgent: hi
<LaserJock> who's archive day is it today?
<cjwatson> LaserJock: http://wiki.ubuntu.com/ArchiveAdministration
<LaserJock> seb128: can you accept flashplugin-nonfree into gutsy-proposed for me, thanks?
<seb128> LaserJock: I technically can but it has to be approved by ubuntu-sru first no?
<LaserJock> seb128: I approved it
<seb128> bug number?
<LaserJock> seb128: I just didn't want to sub you guys from a massive bug
<seb128> sorry I've to go in a minute and I don't know enough about this update to feel comfortable to push it to stable
<seb128> try to grab slangasek or pitti otherwise I'll have a look when I'm back
<LaserJock> it's bug #173890
<ubotu> Launchpad bug 173890 in flashplugin-nonfree "flashplugin-nonfree fails to install due to md5sum mismatch" [High,In progress] https://launchpad.net/bugs/173890
<LaserJock> it's just a md5sum update going to -proposed
<LaserJock> not -updates yet
<cody-somerville> Which subdirectory of ~ubuntu-archive on p.u.c shows the diffs between what was pulled in yesterday and today to build the cd?
<cjwatson> cody-somerville: that's buried in the appropriate CD build log under http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/
<jdong> can an archive admin open flood gates on backports binary NEW?
<jdong> in particular nexuiz is uninstallable in gutsy-backports because -data passed and the binaries are in NEW
<Sveinung> What is the correct procedure to report that I have modified a source package that currently won't build (according to its page in Launchpad) so it builds (at least on my system)? I have filed a bug against it, but if that is the wrong way to do it pleace tell me.
<Sveinung> the bug: https://bugs.launchpad.net/ubuntu/+source/dbus-java/+bug/204704
<ubotu> Launchpad bug 204704 in dbus-java "dbus-java should work with IcedTea" [Undecided,New]
<ScottK> That's the right way.
<Sveinung> ok
<Sveinung> thanks :)
<ScottK> Sveinung: Even better, if you haven't, make a debdiff and attach it to the bug.
<cjwatson> (or just an ordinary diff is usually fine.)
<Sveinung> how is that different from a normal diff?
<ScottK> Which is actually in there already.
<infinity> Sveinung: After you "dpkg-buildpackage -S", you can "debdiff old_ver.dsc new_ver.dsc" and get a diff of the source packages.
<ScottK> Sveinung: Since it's a multiverse package, #ubuntu-motu is a better channel.
<Sveinung> The diff removes the dependency on unfree packages too
<LaserJock> pitti: if you have a sec can you allow flashplugin-nonfree into gutsy-proposed?
<ScottK> Which means it could be promoted to Universe (and #ubuntu-motu is still the right channel).
<cjwatson> For some reason there is an idea floating around that debdiffs are much easier for sponsors to deal with. In practice it makes almost no difference and sometimes introduces extra work since you might well have to rewrite the changelog anyway.
<Sveinung> ok. Thank you. I am new to Ubuntu
<ScottK> No problem.  Glad to have you.
<infinity> cjwatson: I'm 50-50 on changelog diffs, but debdiffing tends to provide more clean diffs than "diff tree-1 tree-2", since one of the trees might accidentally be uncleaned, etc.
<ogra_cmpc> LaserJock, dunno if you noticed, i dropped the math, teaching and light desktop categories from edubuntu addon
<Caesar> Doh
<Caesar> I submitted a bug with the wrong title
<toresbe> submit a bug
<cjwatson> Caesar: "Edit description/tags"
<Caesar> cjwatson: yeah, just saw it
<infinity> Sveinung: A minor nitpick, if you're changing it to build-dep on openjdk-6-jdk, you might want to put the openjdk-6-jre dependency first in the ORed list, not last.
<toresbe> "Bug #34235 has the wrong description"
<ubotu> Launchpad bug 34235 in malone "+editstatus oopses if you clear out the source package name" [Medium,Fix released] https://launchpad.net/bugs/34235
<toresbe> and then file a bug against the erroneous description bug when the bug is fixed
<cjwatson> infinity: It annoys me when somebody attaches a diff to a bug that's perfectly good, and then some jobsworth comes along and asks them to attach a debdiff instead. That's an excellent way to give contributors the impression that we care more about form than substance.
<infinity> Sveinung: (Which also makes it more obviously correct to say "it no longer depends on multiverse packages")
<infinity> cjwatson: Oh, yes, I'm not going to insist on "ur diff is teh wrong formatz!!" or anything, I just recommend debdiff to those who aren't supplying useful patches at all.
<Sveinung> infinity: thank you
<\sh> guys, do we have an up2date software package for controlling powernow or speedstep cpus like athcool or powersaved in main? I wonder if we can get rid of old crap in universe
<cjwatson> infinity: sure
<cjwatson> I've just been railing against bits of our process that seem to be excessive, lately
<infinity> cjwatson: Heh.
<LaserJock> ogra_cmpc: yeah,saw something about it, didn't know about math and teaching though
<LaserJock> ogra_cmpc: what'd we lose?
<johanbr> \sh: That's mostly controlled with kernel governors now, I believe. That control happens in the powernowd package.
<\sh> infinity, any update on wine for lpia and p-a-s?
<ogra_cmpc> LaserJock, empty categories
<ogra_cmpc> we didnt lose any packages
<\sh> johanbr, so actually tools like athcool and friends are obsolete? (me doesn't use normally such things ;))
<LaserJock> ogra_cmpc: we don't have any math apps?
<infinity> \sh: Err, could the update be in the form of "doh, forgot, I'll do it right now"?
<ScottK> cjwatson: For me, if I get a debdiff, it's their name in the changelog/their upload that I'm sponsoring.  If I have to write debian/changelog, then it's my name with thanks to.  I'd rather give them credit for the upload if they've done all the work.  That's why I prefer the debdiff.
<ogra_cmpc> LaserJock, none in the cd menu at least
<ogra_cmpc> what should be there ?
<LaserJock> the KDE Edu math apps apps should be in there
<LaserJock> tuxmath?
<ogra_cmpc> games
<cjwatson> ScottK: Nonsense. You can perfectly well edit the changelog trailer to include their name, or put their name in a "[ Happy Contributor ]"-type prefix.
<ScottK> I could.
<infinity> ScottK: That works for an upload that fixes one thing, but if their patch is being integrated into an upload with many fixes (as is more common for Debian packages, or stuff in main), it's more effort.
<cjwatson> ScottK: This takes approximately two extra seconds.
<\sh> infinity, i think you need to come to berlin @ linuxtag after UDS to relax a bit :) I know that feeling about forgetting some things, too :) then I need to reset my brain :)
<cjwatson> and also what infinity said.
<infinity> ScottK: I can see both sides, and I also care approximately 0% about it all, as long as there's SOME sort of usable patch. :)
<\sh> infinity, but thx a lot :)
<cjwatson> I care deeply about the fact that friends of mine have been put off contributing to Ubuntu because the first patch they send is ignored for months and then they get a request to resubmit it as a debdiff from somebody who clearly doesn't know anything about the software involved.
<cjwatson> It doesn't give us a good impression at all.
<ScottK> I definitely agree that getting the usable patch is 99% of it.  I guess we can argue about the 1%.
<ScottK> Agreed on that.
<LaserJock> cjwatson: well, we did have contributors getting upset that their name wasn't in the changelog
<johanbr> \sh: I haven't heard of people using athcool nowadays. I'm not even sure it runs on modern AMD processors.
<LaserJock> I think that was some of the motivation of trying to get them to do a debdiff we can sponsor straight off
<ScottK> So maybe we need a clearer set of sponsoring guidelines.
<cjwatson> LaserJock: I have no sympathy for sponsors who fail to credit contributors appropriately. It's not the contributor's fault for using the "wrong format".
<infinity> The only other time I kinda like to see a "debdiff" (or, rather, changelog entries in the diff) is if the patch is so mind-numbingly complex and intrusive that I want some verbosity explaining WTF it does, but that can just as easily be done in a bug comment too.
<cjwatson> The work should be the sponsor's, not fobbed off onto contributors.
<\sh> johanbr, well yeah...debian just updated it for a single line of source change...since feisty imho
<LaserJock> cjwatson: it's not failing to credit
<LaserJock> cjwatson: it's that they don't show up in -changes or on their Launchpad pages if you don't
<cjwatson> LaserJock: That's just dubious expectations, and we should probably reset those. As infinity said, if it had been rolled into a bigger upload they wouldn't have got that either.
<LaserJock> and so if they eventually want to apply for MOTU they end up with an underestimate of their work
<LaserJock> cjwatson: sure, we just don't have a lot of those in Universe/Multiverse
<cjwatson> I think it's a much bigger issue that we're putting off people who might apply for MOTU later on.
<LaserJock> cjwatson: most uploads are by a single person
<cjwatson> or even who might be useful sources of patches even if they never choose to become developers
<infinity> The point here is that unnecessary process is off-putting.
<LaserJock> cjwatson: well, I agree but we do have a damned if we do, damned if we don't situation at times
<infinity> I can't count the number of times I've reported a very clear bug, with obvious testcases, and had someone respond with "can we see lspci -vvv and dmesg output, please?"
<cjwatson> Unnecessary process also slows us down, and in this business agility is pretty critical
<infinity> And the same for patches, people insist on debdiffs, diffstats, etc.
<cjwatson> diffstats! That was the other thing I was complaining about
<LaserJock> I agree guys
<cjwatson> What a totally useless metric for anything
<LaserJock> but that's policy
<\sh> LaserJock, depends....when you are working on a package with several fixes...I think I tend more to "Thx" or "Patch provided by <insert dude here>" ... just because, even if there is another name on the upload...if it breaks somehow, the sponsor get hit by some stone or will be crucified...
<cjwatson> Broken policy should be changed.
<infinity> The only thing diffstat tells me is "you didn't include 1.5MB of accidentally duplicated source in your patch".
<infinity> Which is nice to know, and all, but...
<LaserJock> cjwatson: agreed, just we keep changing policy all the time and it confuses people
<cjwatson> you can't fall back on "but that's policy" to defend a criticism of policy
<cjwatson> it doesn't make sense :-)
<LaserJock> well sure it does
<LaserJock> if your the MOTU
<cjwatson> but I'm not
<LaserJock> and can't just change policy
 * _MMA_ smells a good UDS topic.
<LaserJock> _MMA_: been, there, done that, still stinks
<cjwatson> well, I can't "just change policy", that's why I'm complaining about it
<cjwatson> or rather I suppose I could but you'd all shout at me :-)
<LaserJock> *I* wouldn't ;-)
<infinity> Changing policy doesn't change behaviour.
<LaserJock> but some people might
<infinity> This is a matter of education, not policy.
<LaserJock> infinity: well, policy is to attach diffstat
<infinity> Educating people that "a good patch is a good patch, don't just parrot 'no debdiff, you lose!'"
<ScottK> I think what we really need are more sponsors.
<cjwatson> That said, I *would* like (after discussion) to make it very clear that debdiffs and diffstats are not hard requirements for uploads to main
<cjwatson> and then we'll be in the frankly bizarre situation that universe's requirements are stricter
<LaserJock> cjwatson: Universe is often stricter
<infinity> And educating people that if they really don't understand a patch, they should ask someone else to help them look at it, not ask for it in 3 more formats. :P
<cjwatson> LaserJock: which is daft
<LaserJock> we can't rely on common sense in Universe
<LaserJock> so we need strict policies
<cjwatson> but the consequences of failure are much less
<ScottK> cjwatson: True, but the experience level of the contributors is much lower in many cases.
<cjwatson> and increasing strictness does not improve quality, in general
<cjwatson> strictness in itself is not a goal to be aimed for
<ScottK> Agreed
<LaserJock> well, the strictness is a reaction, IMO
<cjwatson> reactions are often overcompensatory, and in such cases a counter-reaction is called for
<infinity> \sh: Committed.
<LaserJock> cjwatson: we've been doing counter-reactions since dapper
<LaserJock> one Xorg upload and we've been swinging back and forth on SRUs ever since
<cjwatson> look, I nominally own the stable release updates process, I know what excessive strictness does
<cjwatson> and no, we actually haven't been swinging back and forth as far as main SRUs are concerned
<LaserJock> I'm talking about Universe
<cody-somerville> Maybe the strictness is necessary since the group of people working on universe are generally less skilled and have less experience. The strictness forces them to slow down and think and gain that experience to be able to work without such strictness. Just a thought.
<cjwatson> the policy has been constant since dapper, with a few minor tweaks
<LaserJock> as that seems to be what you are complaining about, correct?
<cjwatson> and it's only recently that we're realising that we probably need to simplify it
<ScottK> Universe has not been constant.
<cjwatson> LaserJock: people apply the debdiff/diffstat madness to my packages in main, if I don't get to them first
<cjwatson> so no, it's not just that that I'm complaining about
<LaserJock> Universe has had something like 4 "SRU policy revisited" I think
<cjwatson> cody-somerville: excessive strictness is not a good thing in itself. Every piece of bureaucracy should be justified
<ScottK> We've gone from motu-sru must approve before upload to all MOTUs can upload, and back to motu-sru must approve before upload in Universe
<_MMA_> This is also a manpower issue. There's often just not the people to help. So processes get put in place which put the work on new contributors.
<LaserJock> cjwatson: ok, well then sorry for being Universe-specific there
<cjwatson> what MOTU can do is actually sort of a different issue
<cjwatson> I care more about what we're presenting to random drive-by contributors
<cjwatson> since those are the people least likely to be interested in putting the effort in to cope with extra bureaucracy
<LaserJock> I agree
<cjwatson> in almost all cases they'll just give up and go away
<LaserJock> look at Planet Gnome or Planet KDE for instance
<LaserJock> there are increasingly more "Ubuntu bureaucracy is nuts"
<Keybuk> _MMA_: isn't that a self-fulfilling doom?
<Keybuk> we don't have enough people to review changes, so we make it harder for people to make them, and thus have even fewer people joining than before
<LaserJock> do we have an alternative
<cjwatson> commit-then-review and review-then-commit is a fairly long-established dichotomy; the problem is when it gets to (iterate-through-several-different-spurious-requirements)-then-review-then-review-then-commit-then-review
<infinity> Or, to bring this home slightly more.  If I didn't have full ubuntu-{core-,}dev rights, I doubt I'd contribute to the distro at all, not because I don't like it, but because sending in a good patch with a good explanation, and being told it's "wrong" because the format is incorrect, or I missed a hoop to jump through is disheartening.
<_MMA_> Keybuk: Just an observation since getting into development.
<LaserJock> we don't have manpower so somebody else has to do it
<\sh> infinity, thx :) when you meet lool in praque, please tell him: greetings from \sh, you owe me a drink , kthx :)
<Keybuk> LaserJock: why does it have to be done at all?
<_MMA_> Keybuk: There's just not a "best" solution. So processes get put in place and here we are.
<cjwatson> LaserJock: we are not the only project of our size. Other projects of our size do not have the same requirements. Therefore there are alternatives, QED. :-)
<LaserJock> Keybuk: what's the "it" there
<Keybuk> LaserJock: I think that was what I was attempting to ask you ;)
<LaserJock> Keybuk: well, some "it"s do need to be done
<Keybuk> ?
<LaserJock> we have a big list of fixed Debian RC bugs that *aren't* going into Hardy
<Keybuk> it's not as if people are sending hand-written instructions to change the code
<Keybuk> a patch either applies or doesn't
<LaserJock> we have a list of FTBFS, uninstallable packages, etc.
<LaserJock> every release we get hammered for not getting fixes in
<elmo> Keybuk: there are people who send kernel patches, with mathematical proofs of the change, it's great
<LaserJock> so there's quite a bit of pressure to get things in
<cjwatson> _MMA_: saying "it's all fixed, might as well live with what we've got" is a pretty defeatist attitude; I think we're smart developers in an interesting and worthwhile project, and should be striving to make it the best we can even if that involves substantial changes
<saivann> mjg59 : Do you know the answer to that? https://bugs.edge.launchpad.net/ubuntu/+source/usplash/+bug/205990/comments/28
<ubotu> Launchpad bug 205990 in usplash "[hardy] splash screen disappears after a few seconds" [Medium,Confirmed]
<_MMA_> cjwatson: Sorry to sound like a dick but are the 'drive by" people really the type of people we want to spend time on? Hell. Looks like Universe has a hard enough time keeping people who have gone through the process around. :)
<cjwatson> _MMA_: yes
<Keybuk> most of core-dev are what I would consider "drive by" people ;)
<cjwatson> _MMA_: only a relatively small number of people actually want to be long-standing contributors to an operating system; but my experience is that there are lots of intelligent and useful contributors outside that fanatical subset
<_MMA_> And sure. I've gotten a little jaded. :P
<cjwatson> (also, I wouldn't be bringing this up if I weren't repeatedly seeing real examples of intelligent contributors driven away by process)
<LaserJock> cjwatson: I think most MOTU appreciate the situation
<Keybuk> those processes we have should be to ensure that any contribution, no matter how small or irregular, can make it into the distro
<LaserJock> most Ubuntu Developers, period
<cjwatson> LaserJock: _MMA_ challenged it, so I responded
<\sh> LaserJock, tbh, actually you as contributor should do what you are willing to do...no one forces anyone to do things...if we don't get RC bugs fixed for universe, hell, we don't have the manpower...we are just people and most of us have a real life which is more important sometimes (only sometimes ;))
<cjwatson> Keybuk: I'd modify that; we do need to ensure that there is quality control
<cjwatson> but process in itself does not produce quality
<cjwatson> it just ensures that the people you have are the type who are willing to endure process
<LaserJock> \sh: which absolutely doesn't matter to upstreams/users/reviewers
<LaserJock> Keybuk: they can
<Keybuk> cjwatson: I'm a greater believer in "it's better to ask for forgiveness than permission"
<_MMA_> Sure. At least in Universe, the "long-standing contributors" are a finite bunch with much work to do. The processes and barriers to "'drive by contributors" IMO have come out a lack of man-power.
<Keybuk> (ie. review after upload)
<cjwatson> Keybuk: to take it to extremes, I wouldn't want an automatic system that applied any patch it saw and rolled it into the distro
<Keybuk> cjwatson: I know someone who does want that ;-)
<_MMA_> *out of a
<Keybuk> LaserJock: I don't think that they can.  I think that the amount of effort required to get a patch in is sufficiently great that most people don't bother
<\sh> LaserJock, yes, but upstreams don't care about distributions...users don't care about people, and reviewers well, depends what review you want? I'm actually using ubuntu for business...and really, I'm proud about what we produced every release, with less power
<Keybuk> (from my own talking to people, especially upstreams)
<LaserJock> sure
<cjwatson> but review should be based on a developer's brain, not on form; and what we're currently doing is absolutely based on form. It would be better to ignore a patch for years (and that's not good!) than to ignore it for half that time and then bounce back to the contributor with a comment that proves that the commenter isn't qualified to deal with the patch
<LaserJock> I'm just saying we aren't throwing away patches
<\sh> LaserJock, and if users and upstreams want something badly, I think we can invite them to work on what they want regarding ubuntu :) I don't chase them away :)
<cody-somerville> I personally don't see the barrier that high.
<cjwatson> people who contribute to free software projects are generally realistic; they know that they might sit there for ages until somebody gets round to them, and that's fine. What they hate is their patch ending up with somebody who knows even less about the code than they do
<cjwatson> LaserJock: pretty sure I've seen examples of patches bouncing through process and eventually getting marked Invalid for lack of response by the contributor, without a real developer having time to get involved at any stage
<LaserJock> cjwatson: well, that's the way Ubuntu works though
<cjwatson> when it would have been better to just leave the patch alone
<cjwatson> LaserJock: it shouldn't be!
<LaserJock> cjwatson: most MOTU know much less about the software than contributors
<james_w> Is there a list that gets notified when any bug has a patch attached?
<cody-somerville> cjwatson, Then maybe the issue is the bug team?
<LaserJock> we have like 20 people for 4k packages
<cjwatson> MOTUs are generally smart and able to learn
<cjwatson> that's part of the process
<cjwatson> sure, they don't know a lot about it going in
<LaserJock> they don't have time to learn
<cjwatson> but in the process of dealing with a patch they should learn enough to be able to cope
<LaserJock> MOTU is about pushing paperwork
<cjwatson> come on, I'm not speaking without experience here
<LaserJock> I know
<LaserJock> but realistically I'm saying that many of the MOTU don't even know how to test the uploads their doing
<cjwatson> being a distribution developer is about integrating other people's code, sure, but when you come to integrate a patch you teach yourself enough about the thing you're working on in order to do it
<cjwatson> that's half of what makes it fun
<cjwatson> and in any case I wasn't really talking about MOTUs, who from what I've seen generally do a decent job of patches once they're in their hands
<LaserJock> a big problem seems to be bug triage
<Keybuk> where I used to work, we had an interview test where you were given the code to a network daemon and had to add a "ping" command to it which replied "pong" when received
<cjwatson> cody-somerville is right to some extent that it's a triage problem, but the policies on what's needed before a bug with a patch attached is triaged are set by MOTU
<Keybuk> the idea being to test how well you could understand code you'd never seen before and how quickly you could modify it as requested
<LaserJock> cjwatson: actually they really aren't
<Keybuk> it always struck me that the kinds of people who do well as a distribution developer are the kinds that complete that test very quickly indeed
<cjwatson> LaserJock: a better job than the problems I'm referring to, at least
<LaserJock> cjwatson: bug work policies are mostly set by the QA team
<cjwatson> I'm pretty certain the QA team would take advice from MOTU on bugs with patches if it were offered :-)
<cody-somerville> People who don't know what they're doing are often triaging bugs and just give "programmed" responses.
<cody-somerville> ie. The whole "No one has touched this bug in awhile, wanna see if it still happens just for the sake of it?"
<\sh> cody-somerville, which is bad, too
<cody-somerville> Why do they do that? Because they're lazy? I dunno.
<LaserJock> cody-somerville: or "I'm closing this bug as it's had 30 days of no activity" even if it hasn't had anything from a dev
<laga> cody-somerville: well, some/many bug reports can often be triaged by people who just paste canned responses like "what version of ubuntu are you using?" etc.. unfortunately.
<zyx386> hi
<zyx386> what is happning with my BUG?
<zyx386> :)
<broonie> laga: That sort of triage does tend to create an unfavourible impression in users if it's done without reading the bug.
<saivann> Do you have so many examples of bug which are not correctly triaged?
<\sh> laga, which is a bug in the "reporting bug mask in LP" we have many old bug reports with patches attached, which are already fixed upstream...which were reported during dapper times...
<Keybuk> LaserJock: I get those
<Keybuk> my reply varies from just reopening it again to livid hatred
<laga> broonie: that's true.
<\sh> laga, problem with those bugs, actually motu needs to take care about deciding if this is worth an SRU...but this means, more work on SRU, less work on latest devel release
<Keybuk> or drive-by duppers
<Keybuk> my *friends*(
<zyx386> i report BUG about usb modem and hardy heron??
<laga> \sh: yeah, i hear SRUs are a lot of paperwork.
<\sh> laga, yepp...so, what to do? working on latest devel release is fun, and working on SRU is responsibility to not break working releases
<\sh> laga, decide for yourself, where the prio will be set by a contributor :)
<saivann> Well the ubuntu bug triage wiki documentation is pretty clear, but there is no information about bug that have patches, why not update it?
<saivann> https://wiki.ubuntu.com/Bugs/HowToTriage
<laga> \sh: especially if you don't get paid :) i'm working a lot with mythtv where there was a new upstream release after about 1.5 years.. all you can do with old bugs is asking if they're still showing up with the latest release because upstream won't support old releases anymore. (and i personally don't care either ;))
<zyx386> saivann: that is my bug
<zyx386> https://bugs.launchpad.net/ubuntu/+source/gnome-ppp/+bug/212980
<ubotu> Launchpad bug 212980 in gnome-ppp "HuaWei E220 and is unknow!?" [Undecided,New]
<awalton__> laga, we've got years and years of bugs like that in nautilus.
<laga> awalton__: auto expiry for the win.
<\sh> laga, see, we have a lack of people for security updates in universe (sometimes, it's less painful then SRUs but many of times, it's even harder) just because you need to know how to reproduce the bugger or sec issue...it's work for people with responsibility and who are taking care...it's difficult, we have special policies..and it's not fun to fix a sec issue in a release from 2006, but it needs to be done...and you always have to fear, that your
<\sh>  update is breaking someone else installation...
<\sh> laga, and money is not my motivation
<zyx386> wel be fixed or not? this bug
<laga> \sh: longer releases cycles (and longer feature freezes) would be a nice thing. it's hard to achieve that feeling of polish and shiny with SRUs :)
<zyx386> because i have just usb modem to internet connection
<saivann> zyx386 : maybe you can speak about this in #ubuntu-bugs
<RainCT> zyx386: I've the same thing. I can explain you how to workaround that if you want. (In Gutsy it worked, btw)
<cody-somerville> RainCT, Maybe you should post your workaround in the bug report for everyone to find?
<zyx386> RainCT: i gutsy worked perfect, with ppp  or gnome-ppp or with vodafone driver for linux
<\sh> laga, time doesn't matter
<laga> \sh: with regard to what?
<\sh> laga, release cycles...
<zyx386> cody-somerville: :)
<laga> \sh: you get more time to fix bugs
<\sh> laga, yes, but for every bug you fix, there will be two new bugs  :)
<RainCT> cody-somerville: well, it involves a bash script, wvdial and binary thing. I might create a package for it
<zyx386> RainCT: i know that is worked not on hardy
<laga> \sh: does that also mean you have less bugs if your release cycle is shorter? ;)
<cody-somerville> RainCT, it would be nice if you could do what is required to fix it for Hardy. Is that your intention?
<\sh> laga, no..that's what I meant with "time doesn't matter" :) manpower is what matters...and people who are tending to be hidden masochistics ;)
<laga> \sh: yeah, that too
<zyx386> RainCT: this dont worked on hardy http://wwwu.uni-klu.ac.at/agebhard/HuaweiE220/
<RainCT> cody-somerville: I've no idea how to fix it, it seems to be a regression in network-admin (they added GRPS/UMTS support but actually what they did is break it, at least for us poor USB modem users :P)
<RainCT> (how to fix it as in how to fix it properly)
<\sh> RainCT, hmmm? in hardy?
<RainCT> \sh: yes
<\sh> RainCT, friend of mine is using his umts card with usb-modem quiet nicely...or are you taking about nozomi stuff?
<\sh> s/taking/talking/
<james_w> I've just sent a mail to the bugsquad list to hopefully get the ball rolling on getting the first step improved, that is getting patches under the eyes of someone who can have a stab at judging it's suitability.
<cjwatson> james_w: thanks!
<cjwatson> Let me tell you a story about contribution
<RainCT> \sh: well, dunno if other models work, but at least the Huawei E220 isn't working anymore
 * ogra_cmpc gets the popcorn
<\sh> RainCT, hmm...qualcomm works
<cjwatson> About eight or nine years ago, before I was a free software developer to speak of, I was investigating a bug in tar that I'd been bitten by
<RainCT> zyx386: run this in a terminal:  cd ~ && wget http://utils.eurion.net/hosted/huaweiAktBbo-i386.out && sudo mv ~/Desktop/huaweiAktBbo-i386.out /usr/local/etc/huaweiAktBbo-i386.out && sudo chmod +x /usr/local/etc/huaweiAktBbo-i386.out
<cjwatson> It turned out that this was actually a bug in glibc. I rolled my sleeves up, figured it out, and posted a long explanation with a patch to the glibc bugs mailing list.
<zyx386> RainCT: usb modem is now popular modem in sweden danmark norway, because you have more speed 7,2 Mbit download and 1,5 Mbit upload, and i well never change that because ubuntu not suport them, i well change my OS for my Hardware :)
<cjwatson> The reply I got didn't consider the patch at all. I was told "if this were a real issue in tar, then why hasn't the tar maintainer told me about it?"
<zyx386> RainCT: thanx that is not the answer is very old solution, itr it
<cjwatson> The tar maintainer happened to be reading this, and forwarded my mail word-for-word to the same mailing list.
<RainCT> zyx386: yeh I know, but that works
<cjwatson> The glibc maintainer then applied my patch.
<zyx386> no
<ogra_cmpc> heh
<infinity> cjwatson: "glibc doesn't have bugs, unless you're in the small set of known contributors allowed to say so".
<cjwatson> Have I contributed to glibc since? Have I heck.
<infinity> cjwatson: I ran into that same pushback the one and only time I found a legit upstream glibc bug.
<zyx386> you can put you solution to the bug report
<cjwatson> Now, lots of people can tell the same kind of story about glibc. But do you see how this is form over substance?
<cjwatson> I wouldn't actually have minded if the glibc maintainer had ignored my patch to this day if he didn't have time to read it. (Well, I'd have minded a bit, but not nearly so much.)
<cjwatson> (FWIW, if you're ghoulish enough to want to read an eight-year-old flamewar, the log is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=59829)
<ubotu> Debian bug 59829 in libc6 "libc6: [PATCH] fnmatch() behaves oddly with *s and FNM_LEADING_DIR" [Fixed,Open]
<Keybuk> cjwatson: nice Ulrichism there
<Keybuk> "I won't even look at this"
<cjwatson> my point wasn't to get into an Ulrich-bash-fest, but to point out the analogy of excessive makework in patch review putting off contributors
<cjwatson> anyway, I've probably beaten this horse to death for now, and will go and do other things :-)
<Keybuk> the trouble with using Ulrich as an analogy is that too many other people have Ulrich stories they wish to share at the bar
<zyx386> saivann: what you talking about? https://bugs.launchpad.net/ubuntu/+source/gnome-ppp/+bug/212980
<ubotu> Launchpad bug 212980 in gnome-ppp "HuaWei E220 and is unknow!?" [Undecided,New]
<cjwatson> Keybuk: ... and a growing number of people have Ubuntu stories they wish to share at the bar :-(
<micahcowan> Someone mind reminding me what the "patching system" where the source package rules consist of actually extracting a tarball and patching that (I know Vim uses it, for example)?
<qense> wikipedia: "Drepper is known within the free software community for his confrontational style"
<Keybuk> cjwatson: indeed
<Keybuk> I think we're reaching Max Mosley levels of un-necessary red tape bondage at this point
<cjwatson> micahcowan: there are a number of them, including dbs, at least one of the ones in cdbs, and a variety of semi-hand-rolled systems
<cjwatson> vim only build-depends on quilt, but IIRC it has a hand-rolled system based on it
<broonie> micahcowan: Are you thinking of dbs?
<micahcowan> dbs... perhaps that's the one.
<cjwatson> I don't think vim uses anything stock
<RainCT> zyx386: I explained how to get it working on the bug (bug 212980)
<ubotu> Launchpad bug 212980 in gnome-ppp "HuaWei E220 and is unknow!?" [Undecided,New] https://launchpad.net/bugs/212980
<micahcowan> cjwatson, hand-rolled... maybe. But it had a name, and was used in at least one more package, IIRC.
<cjwatson> dbs may well be what you're thinking of
<micahcowan> prolly. Thanks!
<qense> is bug 214622 a bug?
<ubotu> Launchpad bug 214622 in gnome-system-tools "Can not change username in users-admin" [Undecided,New] https://launchpad.net/bugs/214622
<qense> because changing your username would require a lot of changes
<RainCT> qense: a bug surely not, at most a feature request
<qense> yeah, we thought that too, but we wanted to check it with the developers
<qense> because a lot of files will need a change
<qense> and $HOME
<saivann> zyx286 : Nevermind, RainCT knows this device more than I do and found what necessary piece of software was needed
<saivann> zyx386 : Nevermind, RainCT knows this device more than I do and found what necessary piece of software was needed
<qense> I'll close the bug and forward him to brainstorm? ;)
<james_w> qense: you could file a feature request upstream perhaps.
<qense> ok
<qense> so that would make it wishlist and add a bug watch
<james_w> qense: yeah, wishlist is the easy part :-)
<qense> but what about user rights?
<qense> Is the ownership per ID or per username?
<james_w> on the filesystem?
<qense> yes
<RainCT> qense: by id
<qense> ok, thx
<qense> an interesting thought about this bug just popped up when I commented it
<qense> it could be a bug caused by policykit
<zyx386> RainCT: thanx for your answer i test it. thanx all
<cody-somerville> qense, Why not check the upstream changelog?
<cody-somerville> qense, Then you'd know if it was done on purpose or not.
<qense> someone found this: gtk_widget_set_sensitive (widget, (login == NULL));
<qense> (james_w's work)
<qense> it means that is only editable when not set
<qense> but we're not sure if that has been added recently or is new
<qense> it was disabled in revision 4018!
<qense>         * user-settings.c (user_settings_dialog_new)
<qense>         (user_settings_dialog_get_data): disallow changing login name.
<qense>         * group-settings.c (group_settings_dialog_new)
<qense>         (group_settings_dialog_get_data): ditto for group name.
<qense> oops
<qense> I thought the link was still at cliboard
<qense> http://svn.gnome.org/viewvc/gnome-system-tools?view=revision&revision=4018
<RainCT> then it's a "I want that feature back"-request ^^
<qense> yeah
<qense> I'm going to mail the developer to ask why it has been removed and decide afterwards if it deserves a feature request
<slangasek> keescook: I need a paranoid's opinion
<calc> hello :)
<keescook> slangasek: haha.  I'm honored/offended.  ;)
<emgent> heya calc :)
<slangasek> keescook: :)
<slangasek> keescook: we're converging on being able to have authenticated filesharing enabled out of the box for hardy after all, but the trade-off is of course that you have to have something creating and keeping NTLM hashes up-to-date
<slangasek> keescook: so you now have not one, but two password hashes for each user, weakest link, etc., etc.
<keescook> NTLM? ewwwww.  isn't that unsalted md4?
<slangasek> keescook: from a security standpoint, is it acceptable to you that we do this by default?
<slangasek> no, that's LanMan
<keescook> okay, less panic.
<slangasek> which, with the current samba package settings, we don't create at all by default
<slangasek> (even though smbpasswd supports it)
<keescook> what is the underlying hashing system for NTLM?
<slangasek> hrm, it's the same as whatever that AD-specific krb5 enctype was... let me check :)
<slangasek> I believe it's arcfour-hmac-md5
<slangasek> so, "md5"
<keescook> unsalted?
<keescook> the shadow file is currently 2-byte salted sha1, IIRC
<slangasek> it is? when did it change from md5?
 * keescook checks... it's been a while since I really looked at this
<slangasek> all the passwords I have on hand still use the $1$ signature that was supposed to denote md5 passwords
<jdstrand> keescook, slangasek: NTLM is md4 and NTLMv2 is md5 according to: http://www.ubiqx.org/cifs/SMB.html#SMB.8
<keescook> yeah, I'm trying to find the $N$ table...
<keescook> jdstrand: oh, hm
<keescook> slangasek: ah, yeah, you're right, $1$ is md5.
<slangasek> jdstrand: that refers to differences in the wire protocol; there are no different NTLM vs. NTLMv2 hashes
<keescook> so, shadow is 2byte salted md5
<slangasek> I'm still looking for the salting info
<jdstrand> ok
<jdstrand> (I see that in that link as well-- further down)
<slangasek> keescook: right, I don't see any evidence that NTLM is salted
<slangasek> keescook: so yes, it's weaker
<keescook> slangasek: yeah, I'm not happy with that.  (e.g. I'm currently almost done generating a rainbow table that can crack all alphanumeric (with some special characters) md5 strings 7 or fewer characters.)
<keescook> only root would have read-access to it, I assume?
<slangasek> the alternative is that we can install libpam-smbpass the same time we install samba if someone wants to enable filesharing, but that's not as seamless because someone has to go back and populate the hashes for any users they want tou se for sharing
<slangasek> correct, root-only
<slangasek> (not even group shadow)
<LaserJock> is pitti on vacation?
<keescook> LaserJock: he's at a conference in US timezone.
<LaserJock> doh, right
<LaserJock> he's in Texas
<slangasek> keescook: so, "not happy", but if the desktop team said it was the right thing to do...?
<laga> cjwatson: you havent looked at the mythbuntu seeds by any chance?
<slangasek> and btw, the reason it's not salted is because the passwords are hashed by the client before being sent across the wire with a separate, unique server-provided salt
<keescook> slangasek: so, my basic objection here is that by providing default interoperability to what are fundamentally a proprietary systems, we reduce the security of Ubuntu as a whole, for everyone, even those that stick entirely to networks of free software systems.
<slangasek> well
<slangasek> it's also the only way to be able to browse from one Ubuntu system to another using Places -> Network :)
<keescook> I realize samba is used by Free systems, too, but to force a lowered standard of password protection as a whole due to limitations imposed to remain compatible with windows makes my skin crawl.
<slangasek> ok
<keescook> I mean, I don't want to be difficult, it's clearly a great feature, but making it the default is unpleasant.
<slangasek> but, if anyone installs the samba package, we're ok to pull in the automatic password sync stuff?
<slangasek> (i.e., pulls it in via nautilus-share or installs the filesharing task on a server install)
<keescook> I think that's a reasonable trade-off, but I'd like to to be noted somewhere non-obscure.
<lamont> Apr  9 09:20:20 mix nagios2: Warning: A system time change of 1 seconds (backwards in time) has been detected.  Compensating...
<lamont> how very, um, odd.
<lamont> I keep seeing those.
<lamont> thank you hardy.... NOT
<ion_> lamont: cat /var/lib/ntp/ntp.drift
<keescook> slangasek: i.e. "installing this reduces the security of your on-disk password storage".
<keescook> though, of course, that's just another "Ok" box that people click without reading, so maybe not
<slangasek> keescook: right, plus users have always had to do that anyway (and we /know/ no one's setting separate Unix and Samba passwords for their users... :), it was just harder to get to that point
<keescook> slangasek: perhaps a note saying "Since NTLM password storage is less secure than Linux passwords, you will need to reset passwords for any uesrs that you want to share files from."
<keescook> so, by default, "no, please", and on-install, "okay, ew"
<slangasek> but yeah, I realize it's a bit unpleasant to have to have a second password hash on the system, I just wanted to gauge your feel for the unpleasantness since I have a long-running bias :)
<slangasek> heh, but that's not true, it's not *because* it's less secure that you have to reset them... :-)
<keescook> slangasek: heh.  what's your opinion about it?
<lamont> ion_: -95.737
<slangasek> also, it's not true because I'm so evil that users won't have to have their passwords reset, they'll just have to log back in. >:)
<keescook> slangasek: true, but some note about it would be handy since it won't work for them until they change their password
<lamont> interestingly, they are new to hardy AFAIK
<keescook> slangasek: ah, cool.
 * keescook uninstalls samba
<slangasek> keescook: my opinion is that the usability of having it work out-of-the-box outweighs the security risks of having the additional root-only password store, weaker passwords or not
<slangasek> keescook: I mean, I've been known to speculate about *replacing* /etc/shadow with /var/lib/samba/passdb.tdb, so :)
<ion_> lamont: That's not a very small drift, so ntpd has to compensate quite a bit. Perhaps nagios has just began to track that.
<slangasek> keescook: heh, uninstalling samba because I'm evil or because you're done poking at this? :-)
<lamont> I supposee
<keescook> slangasek: evil evil!  ;)
<slangasek> cjwatson: ping
<slangasek> jdstrand: also ping
<keescook> slangasek: yeah, my paranoia doesn't agree -- I can't currently crack an /etc/shadow entry in 2 minutes, but I could do it for an otherwise "relatively safe" NTLM password
<ion_> lamont: That's >4 minutes of drift per month.
<jdstrand> slangasek: pong
<keescook> slangasek: though it has taken a team of 6 people 2 months to generate the 500G worth of rainbow tables.  ;)
<jdstrand> keescook: but once done, they are 'done'
<lamont> ion_: yeah, 4:08.8 min/30 days
<jdstrand> (and thus handy)
<slangasek> jdstrand: hi, if I'm changing the default contents of /etc/pam.d/common-{auth,password}, does auth-client-config need any changes to cope?
<keescook> jdstrand: right.  and it's not outside the realm of possibilities for botnets to have a central "look up this md5" server.
<jdstrand> slangasek: no
<lamont> OTOH, ntp used to not step unless time got kinda really wacko
<slangasek> jdstrand: ok
<lamont> oh
<lamont> heh
<lamont> intarwebs FTL
<jdstrand> slangasek: it just looks in those files and sees if it has ever managed them
<jdstrand> slangasek: if it hasn't it does one thing, if it has, another
<slangasek> jdstrand: ok.  if it has managed them, it replaces them wholesale though, right?  so if there were "recommended" changes to the set of default modules, those /should/ be reflected in the alternate configs provided by auth-client-config...?
<jdstrand> keescook: and might I say that your 'skin crawl' statement was rather eloquent?
<ion_> lamont: Are there "ntpd.*time reset" messages in daemon.log?
<lamont> ion_: there's a "oops the intarwebs went splat and so I resynced when they came back" entry. :(
<jdstrand> slangasek: if a-c-c has never been run on the files, then it comments out the existing entry in a way that can be undone, and then puts in its changes
<awen_> if anybody is using kubuntu hardy and have time for it... please test kde-guidance-powermanager from https://launchpad.net/~andreas-wenning/+archive , it has added support for showing power consumption when on battery; please tell if it works for you (or not)
<slangasek> jdstrand: my point is that it would be advisable for the "changes" that a-c-c puts in to also have the "optional smbpass" support..
<jdstrand> slangasek: if a-c-c has touched the files, then the commented section would not be touched, and changing the profile updates the uncommented parts
<keescook> jdstrand: heh, thanks.
 * awen_ go hiding ... wrong channel, sorry
<jdstrand> slangasek: a-c-c ships a cracklib profile for pam_password, and an ldap example and kerberos example
<jdstrand> slangasek: are you saying you would like this updated?
<jdstrand> s/this/these/
<mdke> BalaamsMiracle: once a release, normally.
<mdke> BalaamsMiracle: anything more than that is a bonus
<slangasek> jdstrand: if we're going to include pam_smbpass as an optional module by default, then using a-a-c shouldn't regress that integration, right?
<mdke> BalaamsMiracle: we will do at least one import after release in -updates though
<jdstrand> slangasek: let me put it this way-- you update the pam files, user runs a-c-c, there is not problem.
<jdstrand> slangasek: a-c-c only ships 2 example profiles and the cracklib profile
<jdstrand> slangasek: if pam_password is changing in the default, then I think that profile should be adjusted
<jdstrand> (that's the cracklib one)
<jdstrand> slangasek: can smb_pass be used with cracklib?
<slangasek> jdstrand: er, it is a problem, because the default is going to support pam_smbpass syncing and none of your profiles will... :)
<slangasek> yes, pam_smbpass is entirely stackable
<jdstrand> slangasek: then like I said-- the cracklib one should change
<slangasek> why shouldn't *all* of them change?
<jdstrand> slangasek: the other are clearly noted as examples, but I wouldn't mind changing them accordingly
<slangasek> oh
<jdstrand> slangasek: I think we were talking about different things
<jdstrand> slangasek: but I now know what you want
<jdstrand> slangasek: just tell me what you want and I'll do it
<jdstrand> (how is that for easy-to-work-with ?)
<slangasek> jdstrand: to port the patch from bug #208419 to the a-a-c profiles :)
<ubotu> Launchpad bug 208419 in pam "Integrate samba password in PAM" [Wishlist,In progress] https://launchpad.net/bugs/208419
<jdstrand> slangasek: I don't see that common-password has an updated 'Alternate strength checking for password'
<jdstrand> slangasek: (ie the cracklib part)
<jdstrand> slangasek: I assume 'requisite' is fine there as well?
<jdstrand> slangasek: I take that back
<jdstrand> slangasek: this should be ok:
<jdstrand> pam_password=password required       pam_cracklib.so retry=3 minlen=8 difok=3
<jdstrand> password requisite       pam_unix.so use_authtok nullok md5
<jdstrand> ?
<slangasek> followed by "password optional pam_smbpass.so [...]", yes?
<jdstrand> oh right, yes of course
<slangasek> then it looks correct to me, yes
<jdstrand> ok, I'll make the adjustments
<jdstrand> slangasek: the ldap_example and kerberos_example are a bit more involved: http://paste.ubuntu-nl.org/62673/
<BalaamsMiracle> mdke: Thanks for the info. I think i've got all my questions answered (although if i could have had my way, the documentation translations would be updated once a month or so :-) )
<jdstrand> slangasek: I'd just assume not change them
<slangasek> mvo: 213482 isn't fixable in slapd, the issue is that slapd's dependencies have been removed before the preinst of the new package runs, making it impossible to get a reliable dump of the old db...
<jdstrand> slangasek: they are meant to be jumping off points anyway and I know that they work in at least one configuration-- if I add pam_smbpass, I won't know that this is still true :)
<mvo> slangasek: yeah, I figured that
<slangasek> jdstrand: fair enough, I'll kill those off in intrepid with the reorged pam support then :)
<slangasek> mvo: before or after you assigned the bug to slapd? :-)
<jdstrand> slangasek: I look forward to it
<jdstrand> ;)
<mvo> slangasek: slightly after that, I just checked the chroot to see what fails. do you have a plan already how this can be fixed?
<slangasek> mvo: I have no idea, is there some way that update-manager can fix it by upgrading slapd earlier?
<slangasek> (before the libs get pulled out from under it)
<mvo> slangasek: unfortunately not, it can not modify the ordering that libapt calculates
<slangasek> poo
<mvo> indeed
<cjwatson> laga: I think I thought I had finished the review. What were you still waiting for from me? (Hm, a tasksel upload maybe?)
<cjwatson> slangasek: yo
<cjwatson> Riddell: ubiquity r2619 seems like the wrong approach. Why would we want to *add* explicit sizes (that will break with font changes, different languages, etc.)?
<cjwatson> Riddell: if the widget set isn't making it big enough, surely that's a widget bug
<cjwatson> Riddell: or else there are *too many* explicit sizes constraining it to be smaller
<slangasek> cjwatson: hi, would you mind eyeballing the patch in bug #208419 so I can be assured I'm not overlooking anything due to crossed hats?  Tried to grab pitti for it, but Texas isn't doing much for his availability :)
<ubotu> Launchpad bug 208419 in pam "Integrate samba password in PAM" [Wishlist,In progress] https://launchpad.net/bugs/208419
<cjwatson> Riddell: the use of gettext _("Next") in r2620 isn't great either - it should be using the debconf translation for that
<cjwatson> Riddell: maybe the messagebox in question_dialog should have set_icon done on it to give it the question icon?
<cjwatson> slangasek: ok, queueing up
<slangasek> thanks:)
<cjwatson> oh god, do I have to remember what the difference between required and requisite is?
<slangasek> requisite = terminate the stack on failure :)
<cjwatson> worst naming ever
<mvo> slangasek: so the problem is that the database format changed and that is why the database needs to be dumped/reloaded? and the new slapcat can not read the old format?
<slangasek> mvo: correct; we've always relied on the preinst being able to use the binaries from the previous version, and there've never been issues with this before now
<cjwatson> slangasek: it'll cause some log noise if pam_smbpass.so is missing, won't it? (minor)
<LaserJock> slangasek: are you gonna have any time today to look at flashplugin-nonfree sitting in gutsy unaccepted queue?
<cjwatson> slangasek: so the change to requisite is so that pam_smbpass is invoked even on failure? Is there any possibility that this might cause unexpected things to happen in other auth stacks, which might now have later modules invoked when they weren't previously?
<slangasek> cjwatson: surprisingly no noise if pam_smbpass is missing; I had assumed the same before, Petter Reinholdsen pointed out that it doesn't
<cjwatson> hmm, sure I remember that in the past; ok then
<slangasek> LaserJock: questionable; is it something another archive admin could poke?
<slangasek> cjwatson: the change to requisite is so that pam_smbpass is *not* invoked when the previous module fails
<slangasek> the behavior of 'required' is to continue processing the stack, which we don't want because that would set wrong passwords
<LaserJock> slangasek: well, I asked seb128 and he said he didn't really want to do and suggested you or pitti
<cjwatson> slangasek: apparently I can't read
<cjwatson> ok then
<infinity> slangasek: Looks correct to me, FWIW.
<infinity> slangasek: (I used to do something similar at an old place of employ)
<cjwatson> the ordering in /usr/share/doc/libpam-doc/html/sag-configuration-file.html is confusing. I'd have got it right had requisite been above required, since it's a "harder" failure.
<slangasek> LaserJock: rats; understandable, but inconvenient timing
<LaserJock> it's just after the disaster last time with flash I thought I'd try to get a 0-day SRU through
<laga> cjwatson: i was basically wondering how to get the stuff in 'common' included on the alternate disk w/o installing it with the other tasks i've added.
<LaserJock> but it's gonna take at least 1 day just to get it into -proposed
<cjwatson> slangasek: and yeah, assuming that the pam_smbpass.so options do the right thing, it looks good to me
<seb128> LaserJock: I'm back, but I'm still not comfortable accepting a new version into stable
<slangasek> cjwatson: thanks, throwing it into the real world then :)
<LaserJock> seb128: no problem, I understand
<LaserJock> I just need *somebody* that is comfortable :-)
<seb128> LaserJock: usually we don't get new version there and it's not clear to me it's a good idea
<LaserJock> seb128: it's a new version in name only
<LaserJock> all we did is update the md5sums
<slangasek> seb128: it's flashplugin-nonfree, there are no good ideas :)
<seb128> slangasek: right, better to not touch this thing ;-0
<seb128> ;-)
<LaserJock> it's got a new upstream version because the version reflects the version of flash that's being downloaded
<cjwatson> laga: should be included on your alternates already by virtue of ship inheriting from common
<seb128> I could just accept the thing, but I don't want take responsability for whatever regression it can introduce
<LaserJock> seb128: for proposed it's not the archive admins responsability
<seb128> the bug going on a zillion pages doesn't make thing easier
<seb128> LaserJock: not really true, it's somewhat the responsability of whoever approve the update
<LaserJock> and I approved the update
<seb128> whoever press the button if you prefer rather ;-)
<LaserJock> but for -proposed? I don't see any risk
<seb128> it's still something pushed to some users
<LaserJock> sure
<seb128> it should not be obviously broken
<LaserJock> and that's why I can understand the objection
<seb128> and I don't know how to judge the changes between what gutsy has now and the update
<LaserJock> seb128: did you look at the debdiff?
<mario_limonciell> slangasek, i was just discussing this with cjwatson, it would appear that dvds suddenly aren't including all the lang packs in the livefs.  compare http://cdimages.ubuntu.com/dvd/20080409/hardy-dvd-i386.manifest and http://cdimages.ubuntu.com/dvd/20080408.1/hardy-dvd-i386.manifest
<seb128> so I don't feel comfortable pushing that to users
<seb128> LaserJock: the debdiff doesn't tell a lot about what changed in the new flash version
<seb128> and no I didn't yet
<seb128> but I expect the debdiff not being an issue
<seb128> that's rather the closed source version update which is
<slangasek> mario_limonciell: I'll bet that's my fault
<LaserJock> seb128: well, there's not much you can do about that
<mario_limonciell> slangasek, well was it "intended" to go that way?
<LaserJock> I don't think anybody expects the archive admin to test the flash version
<mario_limonciell> or accidental then
<seb128> I can decide to not accept an updated version to stable ;-)
<slangasek> mario_limonciell: oh, which lang packs do you see as missing though?  the diff shows me version differences, mostly?
<LaserJock> seb128: I'm saying you can't look at the flash source to see what changed
<seb128> right
<slangasek> mario_limonciell: ah, language-support-*
<seb128> that's why I'm not comfortable accepting it
<mario_limonciell> exactly
<slangasek> mario_limonciell: check the bzr log for the seed, there's a glowing arrow pointing at my mistake :-)
<mdke> BalaamsMiracle: I'm afraid that's impossible - too much work is required to correct all the translations
<LaserJock> seb128: I had multiple people test it in Firefox and Konqueror before uploading it
<mdke> BalaamsMiracle: maybe in the future
<LaserJock> seb128: but I understand your objection certainly
<LaserJock> but we *do* need to get somebody who can approve it
<slangasek> seb128: under the circumstances, I would tend to favor getting it into -proposed sooner rather than later, but I'm also not jumping up to push the button myself :)
<mario_limonciell> slangasek, ah rev no 1255.  just taking all the language-support- packages isn't a good idea :)
<seb128> LaserJock: why do we need it in the first place?
<seb128> LaserJock: I would read the bug if there was not enough to spend one hour reading it
<LaserJock> seb128: flash install is broken for Gutsy users
<LaserJock> we check the md5sum of the dowloaded flash package
<LaserJock> every time Adobe does a new release we have to update the md5sum to check
<LaserJock> otherwise postinst bails
<BalaamsMiracle> mdke: I didn't realize that after the translations were submitted, more work was needed to correct those again.
<seb128> they don't keep the previous version available?
<LaserJock> seb128: nope
<seb128> somebody should fix the package to display a "version not available" and not break
<mdke> BalaamsMiracle: yeah
<LaserJock> there's only a "current"
<LaserJock> seb128: uh, yeah
<LaserJock> but as this is a stable release we haven't done that
<seb128> and in hardy? ;-)
<mario_limonciell> I personally think a nice warning "this version isn't available", do you want to install it anyway and explain the possible security implications is the way to go
<BalaamsMiracle> mdke: Woulkdn't it be a good idea to have the admins of the respective translation teams do the correcting?
<LaserJock> seb128: well, nobody's fixed it in hardy so we had to update the md5sum same way
<seb128> alright
<seb128> let me accept the gutsy proposed one
<LaserJock> seb128: you're more than welcome to submit a patch ;-)
<seb128> I'm going to be not happy if that breaks
<seb128> be warned ;-)
<mdke> BalaamsMiracle: it's quite difficult to organise that, generally only a few teams are that well organised
<LaserJock> well, all I can say is I had 4 people test it before uploadin
<_MMA_> seb128: Cant be any more broken. It doesn't work now.
<LaserJock> I'm not going to be happy if it breaks either
<slangasek> mario_limonciell: a surprising number of DVD builds over the past couple of days, someone tweaking something?
<seb128> _MMA_: that is not true, crashing the machine is broken where not installing is not really
<mario_limonciell> slangasek, they kept not being buildable
<mario_limonciell> slangasek, due to failures of the livefs generation
<slangasek> oh
<mario_limonciell> different failures each time around
<seb128> _MMA_: right now it seems to not be installable, which at least doesn't break thing at runtime
<seb128> _MMA_: no?
<mario_limonciell> but they were all transient
<_MMA_> seb128: That's just being overly cautious and paranoid.
<mario_limonciell> slangasek, you can purge anything than the last one though, those other ones aren't useful with the old livefs
<slangasek> mario_limonciell: hmm, but something must've succeeded if there were manifest differences
<_MMA_> seb128: If this untrust of Flash is so huge we should just just get rid of the package all together.
<mario_limonciell> slangasek, well look at anything before the last one, it uses the livefs from 04-05-08
<mario_limonciell> and that older manifest consequently
<seb128> _MMA_: I would not be against that but I guess users would not agree ;-)
<mario_limonciell> so it was just the very last one that finally had a good livefs
<slangasek> mario_limonciell: fair enough
<_MMA_> seb128: Then we should give them a working Flash in a timely manner. It's been tested by a trusted member. I just dont see why the need for resistance.
<seb128> _MMA_: because working for one person is different of non broken
<slangasek> _MMA_: browbeating him for his concerns, /after/ he's already agreed to accept the package, isn't very productive
<mvo> slangasek: I added some info to the bugreport for the slapd thing. it seems to me that if the libsasl2-modules-$foo would be called libsasl2-2-modules-foo for libsasl2-2 the problem should go away. but I have no idea about sasl so I leave that to the server team
<_MMA_> slangasek: We're all friends here. :) This goes to deeper issues also.
<LaserJock> seb128: it worked for like 4 people at least with a variety of browsers
<LaserJock> but after last time with the konqueror issue it is good to test flash for sure
<slangasek> mvo: great, thanks
<_MMA_> It's stunning to me that we've let this wildly important/popular package continue to say broken.
<slangasek> _MMA_: er, "continue"?  AIUI it's *newly* broken, because adobe has again overwritten the tarball on their website with a new security update?
<_MMA_> I just feel a little bad every time I have to point people to Medibuntu for a working package.
<seb128> LaserJock: it could be working for one thousand user it would not mean it's not broken for some others
<LaserJock> seb128: no but that's the whole point of -proposed
<Nafallo> hmm
<_MMA_> slangasek: We should stay up on it then. Issue a new update when they do.
<slangasek> seb128: but requiring 1001 testers before accepting it into -proposed is not a reasonable barrier :)
<Nafallo> pulseaudio doesn't emulate the microphone or something? my mother can't hear me :-/
<slangasek> _MMA_: does medibuntu use the same overall packaging?
<seb128> slangasek: no, but having a diff to read make things easier ;-)
<Nafallo> I would say that's quite a regression in that case.
<_MMA_> slangasek: Best I can say it works. But I would *think* it would be simular yes.
<seb128> LaserJock, _MMA_: update accepted now
<seb128> jdong: around?
<LaserJock> seb128: thanks a ton
<seb128> LaserJock: you are welcome
<phaeron> mmm where did I see you before seb128 .. anyway it was suggested on bug 211252 that I express my concerns here
<ubotu> Launchpad bug 211252 in obex-data-server "Cannot recieve files using bluetooth" [Undecided,New] https://launchpad.net/bugs/211252
<slangasek> _MMA_: the flashplugin-nonfree packaging in Ubuntu is lousy, and adobe's policy of overwriting their existing releases is also lousy.  So there's a limit to how much de-lousing can be done here even in theory, but I thought maybe medibuntu had something better rather than just having a policy of blindly applying any upstream updates immediately.
 * Caesar hates the name medibuntu, he always thinks "medical" before "media"
<_MMA_> DOnt know.
<slangasek> Caesar: I associate it with being "half of a buntu" :)
<seb128> phaeron: no idea about that one, did you comment on the bug?
<phaeron> seb128: nevermind that, about the bug , I reported it. I commented on the bug and was very frustrated so I might have sounded rude. Maybe I was sent here to get punished :P
<Caesar> Any chance I can score a bit of sponsorship for #214770 ?
<seb128> phaeron: to reply to your question on the bug, ubuntu updated because gvfs and other gnome components required the new obex-data-server
<Lutin> slangasek: not sure what you're talking about...medibuntu doesn't have flashplugin-nonfree (haven't read the backlog)
<seb128> phaeron: the issue not fixed, the team is small, overworked, and nobody is looking really at bluetooth issue, you are welcome to send patches though
<slangasek> Lutin: oh, well, ask _MMA_ then
 * _MMA_ looks.
<seb128> phaeron: I can't look at this one I've to bluetooth device to do testing and I've already too much to do on GNOME
<phaeron> seb128: well everything seems to work with the old version and gnome-obex-server , and yes I'd love to send patches , but I can't seem to find the problem . I asked on #bluez and they said the hcidump means that no services are being offered.
<phaeron> seb128: although I am sure that all four servers were running.
<seb128> did you try sending a  bug upstream?
<phaeron> seb128: and I tried to find any permission denied errors using dbus-monitor because I suspected a policykit issue but didn't find any.
<phaeron> seb128: yes I did , one sec
<seb128> does gvfs bluetooth browsing works?
<phaeron> seb128: yes
<phaeron> seb128: last time I tried it does.
<seb128> I'm not going to be really useful there, I've no bluetooth experience, no knowledge of this stack and no device to try
<seb128> but maybe somebody else has an idea
<phaeron> seb128: the new hidd replacement bluetooth input server crashes dbus with an out of memory error
<phaeron> seb128: http://bugs.muiline.com/view.php?id=70
<seb128> hum, upstream is not responsive either
<phaeron> yep
<saivann> is it normal that konqueror-kde4 does not have any dbg or dbgsym packages?
<mario_limonciell> slangasek, how often is the regular DVD cron job supposed to be running?  is it weekly?
<slangasek> mario_limonciell: bi-weekly
<slangasek> mario_limonciell: but I'm running another now after (I think) fixing the seed
<jdong> seb128: yes, sir
<mario_limonciell> on what days then?
<seb128> jdong: do you plan to get transmission update in hardy?
<slangasek> mario_limonciell: on days "2" and "6"
<slangasek> I can never remember cron's base for weekdays :)
<seb128> jdong: the menu item needs to be update to the new upstream version one and we were waiting on you to get an update since you said you would either do that or backport changes
<mario_limonciell> slangasek, did you already queue that new dvd imm, or you were "about" to?
<seb128> jdong: if you are not going to, could you get the menu items changed and notify translators? ;-)
<slangasek> mario_limonciell: already building
<mario_limonciell> slangasek, er o okay.
<mario_limonciell> thanks
<jdong> seb128: I don't plan the update; I plan on backporting the changes pending when charles_ gets back to me on splitting out his big-glob patch into individual ones
<slangasek> mario_limonciell: if you have other changes, we can always try again later :)
<seb128> jdong: could you get the menu item change backport now so translators can work on it?
<mario_limonciell> slangasek, yeah just ubiquity's noninteractive frontend broke, but i'll just hold off until evand is ready to do another ubiquity upload for now
<jdong> seb128: is there a bugno for that?
<jdong> seb128: I assume bug 184238?
<seb128> jdong: bug #184238
<ubotu> Launchpad bug 184238 in transmission "Menu entry should be named "Transmission BitTorrent Client" Instead of only the unclear "Transmission"" [Undecided,Fix committed] https://launchpad.net/bugs/184238
<jdong> seb128: ok lemme prep a debdiff
<seb128> jdong: thanks
<seb128> jdong: subscribe the main sponsors too ;-)
<seb128> jdong: other thing, you were asking about NEW approval before?
 * jdong wonders why on earth "VF" set it to fix committed 3 months ago
<jdong> seb128: yeah for backports
<seb128> jdong: which ones?
<jdong> seb128: mainly the nexuiz binaries
<seb128> what distro is that, gutsy?
<jdong> yes
<seb128> ok, looking to that
<jdong> seb128: does the translation team care if I use a patchsys to deal with debian/transmission-gtk.menu? I'm going to need to add a patchsys for the backported patches anyway
<slangasek> seb128: so, pam is all pimped out now to handle smbpasswd integration; do you want to have a look at bug #208419 as it relates to nautilus-share?
<ubotu> Launchpad bug 208419 in ubuntu-meta "Integrate samba password in PAM" [Medium,Confirmed] https://launchpad.net/bugs/208419
<seb128> jdong: the only thing the translation team care about it to have the strings listed in the template and imported in rosetta so not really ;-)
<seb128> jdong: which means you should make sure that whatever has the _Name and _Comment is changed
<slangasek> mathiaz: and do you want to weigh in on the proposed change to the samba-server task? (again, bug #208419)
<ubotu> Launchpad bug 208419 in ubuntu-meta "Integrate samba password in PAM" [Medium,Confirmed] https://launchpad.net/bugs/208419
<jdong> seb128: it uses debian/transmission-gtk.{menu,mime}... lemme see if the changes have applied logically :)
<seb128> jdong: no, the must be a .desktop somewhere, GNOME doesn't use those
<jdong> seb128: oh oops I found it. So those two files don't matter?
<seb128> jdong: they do for the debian menu and maybe some other environments
<jdong> seb128: ah, so change both. Got it :)
<seb128> right
<jdong> orig: "Transfer files via Peer to Peer". Does "Transfer files via the BitTorrent Peer to Peer Protocol" sound better or worse?
<jdong> I think the key word to mention is BitTorrent though this may be redundant
<jdong> _Comment=Download and share files over BitTorrent
<jdong> ah there we go, upstream's wording
<seb128> slangasek: what is to change, make nautilus-share install libpam-smbpass and display a warning about the need to restart the session?
<slangasek> seb128: I believe so, yes
<slangasek> seb128: do you think this is adequate from a UI perspective?
<seb128> yes
<slangasek> cool
<slangasek> (is anyone else doing this kind of thing with nautilus-share yet, or is hardy going to be the awesomest?)
<seb128> I'm wondering if we should display an extra dialog or just add a warning in the current one about the need to restart the session after the installation
<seb128> (somebody told me that novell is using nautilus-share but I've no idea if they have pam integration)
<slangasek> my feeling is that it should be a dialog displayed after samba is installed
<seb128> right, that's my opinion too
<jdong> seb128: ok ums subscribed
<seb128> jdong: thanks
<jdong> sure. thanks for your help :)
<slangasek> mvo: just glancing at the package, it looks to me like re-adding a libsasl2 transition package should be enough to fix this?
<mvo> slangasek: hm, possible, let me check. I was thinking of this too, but for some reason I discarded it (maybe because it was too easy :P)
<slangasek> mvo: heh :)
<slangasek> mvo: well, libsasl2 -> libsasl2-2 was a gratuitous rename, so I think it should be sufficient
<mvo> let me test, if that is sufficient, I will just upload (change is simple enough)
<mvo> slangasek: that seems to be indeed enough, the upgrade works with it, I upload now, someone will have to NEW it
<slangasek> no problem :)
<mvo> thanks slangasek!
<saivann> tedg : Since you are actually assigned to bug 201626 and that Hardy RC will be ready in a few days, can you look if you can upgrade xscreensaver, and if you can't please demote braid from the xscreensaver package since it cause serious crash with the majority of the graphic cards
<ubotu> Launchpad bug 201626 in xscreensaver "please merge xscreensaver 5.04-4 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/201626
<saivann> tedg : Don't hesitate to ask if I can do something to assist you in this task, thanks for your work
<cody-somerville> Hobbsee, ping
<tedg> saivann: Yes, I'll do it tonight.
<saivann> tedg : Thank you very much for this
<mario_limonciell> slangasek, actually it looks like that livefs build didn't pass: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/hardy/ubuntu-dvd/20080409.1/livecd-20080409.1-i386.out
<cody-somerville> slangasek, I'm pretty sure that Martin and Sarah approved the Abiword FFe in our discussion.
<slangasek> mario_limonciell: ah, fun.  well, that's tracked on http://people.ubuntu.com/~ubuntu-archive/testing/hardy_probs.html then
<slangasek> cody-somerville: the place for a release team member to approve an FFe is in the bug log, which wasn't done
<mario_limonciell> slangasek, ah didn't realize it existed
<cjwatson> any chance that somebody could look at http://revu.tauware.de/details.py?upid=2177 ? (ttf-ubuntu-title, pulling together the divergent work that's been happening for ages)
<Silicium> www.opensnom.org - the Open Snom Implementation
<azeem> Silicium: are you spamming?
<Silicium> nope
<Silicium> iam search interessting peoples :)
<azeem> you pasted that link in both #debian and here, I've notified the network ops to kline you
<Caesar> kthxbye
#ubuntu-devel 2008-04-10
<mathiaz> slangasek: so for the libpam-smbpass seed change, I need to bzr branch ~ubuntu-core-dev/ubuntu-seeds/ubuntu.hardy/, modify samba-server, ci and push.
<mathiaz> slangasek: and then I also need to upload a new version of ubuntu-meta
<slangasek> yep
<wasabi> I'm curious. During a upgrade, a lot of the time, a daemon will be stopped, before popping up the configuration file thing. For instance, in this case... upgrading has stopped apache, and then presented me with a choice to deal with /etc/syslog.conf conflicts.
<TheMuso> cjwatson: I'm assuming the package on revu you pointed to is needed... While I'm not up on font packages, I can certainly have a look in terms of general packaging.
<wasabi> Does anybody think it should be possible, and preferable, to ask these questions before stopping a service in some fashion?
<slangasek> preferable, sure, but there's no good way to predict which packages are going to generate conffile prompts
<wasabi> I personally would prefer upgrades to keep services stopped and in a non functional state for a very short time.
<wasabi> Why doesn't the service restart happen near the end of the process?
<wasabi> For instance, postinst.
<slangasek> fundamentally, to keep the package prerm script as simple as possible
<TheMuso> Oh, ttf-ubuntu-title is already in the archive.
<Riddell> cjwatson: I found a better fix for the edit dialogue sizing issue, setting word wrap on text labels seems to change their properties somewhat so I set it to have a minimum sizehint policy rather than the dialogue
<cjwatson> TheMuso: it's not absolutely critical, but we've been working with the (new) upstream to get everything merged and it would be nice to have the final result in hardy; a not-installed-by-default font should be fairly non-risky
<cjwatson> Riddell: have you tried it with various languages?
<TheMuso> cjwatson: Right, it looks like the version in the archive and the version in revu are the same, in terms of version number, minus a few 0s.
<cjwatson> I suspect they're actually very different inside
<Riddell> cjwatson: the messagebox in question_dialog has a question icon already, that's set by QMessageBox.Question
<cjwatson> the version number is bizarre, but it does collapse to 2.0 rather than 0.2
<cjwatson> Riddell: ah, ok
<Riddell> cjwatson: yes that Next text is wrong, how do I find out what the debconf translation is called?
<cjwatson> Riddell: it's the ubiquity/imported/go-forward template
<cjwatson> (likewise go-back, etc.; see translate_widgets in gtk_ui.py)
<cjwatson> Riddell: in fact, if you just do self.get_string('next') that should do it
<cjwatson> Riddell: so your usual translation code ought to take care of it if you just leave it alone, unless you've also set that button to read something else
<TheMuso> cjwatson: Right I understand what you're getting at, I'll have a look at that today.
 * TheMuso gets breakfast.
<xtknight> is msgid usually the english US version of something?
<xtknight> i don't see a po/en US
<slangasek> that's customary, yes, in part because historically using English msgids meant you were assured the source string was ascii
<slangasek> and therefore upwards-compatible with any other national encodings
<xtknight> ahh
<mathiaz> slangasek: are you sure a new version of ubuntu-meta needs to be uploaded to take into account the samba-server task change ?
<slangasek> mathiaz: hmm, now that you ask the question, no :)
<xtknight> so fixing an english problem means changing all the po/ files
<xtknight> how convenient lol.
<mathiaz> slangasek: I've built a new version of ubuntu-meta, and there isn't change between .99 and .100
<slangasek> xtknight: preferably done with a global find-and-replace, yes :)
<slangasek> mathiaz: then I guess you don't need to upload it \o/ :)
<mathiaz> slangasek: ok - but I think a new version of tasksel should be uploaded
<slangasek> possibly correct
<Riddell> cjwatson: the edit dialogue doesn't seem to be tranlated at all, a job for tomorrow i think along with the buttons
<cjwatson> Riddell: are you using bzr?
<cjwatson> Riddell: 'cos that was a long-standing bug up to 1.8.2, but I fixed it in bzr
<cjwatson> mathiaz: I'll do tasksel now
<Riddell> cjwatson: I'm not, I'll try that
<cjwatson> mathiaz: tasksel only needs to be uploaded when *structural* changes are made to the seeds. Simply adding a package to a seed never requires a tasksel upload.
<mathiaz> cjwatson: right - that's what I was thinking.
<cjwatson> when you said "but I think a new version of tasksel should be uploaded"? :-)
<mathiaz> cjwatson: so I don't need to upload any new package ?
<cjwatson> no, you do not
<cjwatson> samba-server doesn't have an associated metapackage; Launchpad will update Task fields by itself, which is all you need
<mathiaz> cjwatson: oh... awesome :)
<emgent> hi mathiaz :)
<mathiaz> cjwatson: I've just pushed my commit to the ubuntu-core-dev branch and all the rest is taken care automatically
<mathiaz> hi emgent
<cjwatson> mathiaz: yep
<cjwatson> uploaded tasksel anyway for mythbuntu's benefit
<pitti> Hello
 * slangasek waves
<pitti> Riddell: bcm freeze> can you please create a bug report about that? It's probaly not something I can fix in jockey itself, but we can at least investigate it
<emgent> cody-somerville: ping
<emgent> hi pitti
<pitti> LaserJock: looking at -proposed
<cody-somerville> emgent, pong
<pitti>  LaserJock: I don't see flashplugin in -proposed
<LaserJock> pitti: seb128 got if for me
<LaserJock> pitti: however, the verification is done so can we move it to -updates?
<pitti> LaserJock: oh, is it? great, yes, I can do that; what was the bug#?
<LaserJock> pitti: bug #173890
<ubotu> Launchpad bug 173890 in flashplugin-nonfree "flashplugin-nonfree fails to install due to md5sum mismatch" [Undecided,Confirmed] https://launchpad.net/bugs/173890
<LaserJock> next time I'm going to use a new bug, that one is a mess
<pitti> apparently you did not specify a bug# in the changelo?
<pitti> that's baad :/
<pitti> and my clever SRU script doesn't see it that way :)
<LaserJock> well, with as messy as it is I didn't want it
<LaserJock> pitti: ah, sorry about that
<pitti> LaserJock: btw, is someone looking at the previous releases?
<LaserJock> not yet
<pitti> we can probably stop caring about edgy, but dapper/feisty would be nice
<LaserJock> I'll try to rope somebody into it
<LaserJock> it's a trivial thing
<pitti> copied
<LaserJock> awesome, thank you
<cody-somerville> pitti, You approved the Abiword FFe, correct?
<pitti> thanks belong to you :)
<pitti> cody-somerville: no, I said that it's worth considering if there is a tested package for it
<pitti> but it's getting really tight
<pitti> how does the package in the PPA perform?
<pitti> any good/back feedback about it?
<pitti> (sorry, I'm pretty much out of the loop at the conf here)
<cody-somerville> I've heard good things but I haven't tested it myself yet.
<pitti> I just wonder about why nobody seemed to care/notice for 5 months, and suddenly it's generating so much fuss
<LaserJock> pitti: 5 months?
<LaserJock> 2.6 was just released a couple weeks ago
<pitti> I mean tracking 2.5 in hardy, etc.
<pitti> if it's really that fresh, it's quite natural that we didn't get it?
<LaserJock> of course it's our fault for not tracking all our upstreams :-)
<pitti> LaserJock: sorry, I put that badly: I meant, I was interested why it suddenly created so much fuss: whether we ignored 2.6 for so long, or because it is actually so fresh
<LaserJock> it was actually fresh
<cody-somerville> I think lazyness
<cody-somerville> The split up the source packages in the next release from whats in the archive now
<cody-somerville> *They
<LaserJock> cody-somerville: huh?
<cody-somerville> LaserJock, They split up the source package
<cody-somerville> And change how it is packaged all about
<LaserJock> pitti: upstream also had a blog post on Planet Gnome titled "Ubuntu Sclerosis" which has something to do with it as well
<LaserJock> squeaky wheel and all that
<pitti> tsk
<LaserJock> but 2.4 is now long longer maintained, is 2 years old
<LaserJock> and 2.6 fixes something like 7 or so LP bugs and has lots of goodies
<slangasek> yes, apparently asking for a description of the upstream changes in this new version that no one in Ubuntu has seen prior to 2 weeks from the RC is "OMG bureaucracy"
<cody-somerville> I'm pretty sure the changes are listed in the description
<LaserJock> slangasek: yeah, I had a talk with #abiword about that
<LaserJock> cody-somerville: they don't maintain a changelog, which is also helpful :-)
<cody-somerville> Ah.
<cody-somerville> slangasek, I'm going to upload some experimental changes for the xubuntu seeds in regards to language packages, fyi.
<LaserJock> slangasek: I especially like that 2.6 didn't even exist when you made your first comment
<LaserJock> slangasek: I'm glad we have mind-reading release managers ;-)
<slangasek> heh
<keescook> I hate the ff3 type-ahead matching so much.  isn't there anything to be done to make it ONLY search in urls?  geeh
<slangasek> cody-somerville: feel free, just be sure to make them un-experimental by the beginning of next week :-)
<cody-somerville> :)
<StevenK> pitti: Could I bug you to do a sync while you're around?
 * cody-somerville needs several syncs done. :)
<pitti> StevenK: well, try :)
<pitti> keescook: really? I think it's sooo great
<StevenK> pitti: Bug #214434 . Puuhhhhlease :-)
<ubotu> Launchpad bug 214434 in sapwood "Please sync sapwood 3.0.0.debian.1-2  (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/214434
<keescook> pitti: I'm sure it's good for many people, but I don't type page titles into my urlbar.  I type URLs, so I want it to match URLs.  :P
 * pitti turns the sync crank
<keescook> and there doesn't seem to be any config options for it.  :(
<StevenK> keescook: And it tries to match the URL against page titles?
<keescook> StevenK: if I type "f", I have "facebook.com" listed first, and "mattroloff.com" listed second even though clearly it does not start with an "f".
<keescook> I want completion, not searching, basically.
<LaserJock> ah
<pitti> cody-somerville: if you need an urgent sync, toss it to me
<LaserJock> I was gonna say, urls work fine here
<LaserJock> but yeah, searching, not completion
<StevenK> mattroloff.com starts with a silent f. So silent it isn't written. :-P
<keescook> heh
<cody-somerville> bug #214306 is important and bug #214302 would be nice
<ubotu> Launchpad bug 214306 in ristretto "Sync ristretto 0.18-1 from debian unstable (main)" [Medium,Confirmed] https://launchpad.net/bugs/214306
<ubotu> Launchpad bug 214302 in xfce4-mpc-plugin "Sync xfce4-mpc-plugin 0.3.3-1 from debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/214302
<StevenK> keescook: Maybe you have to set the config option in that cesspool of files firefox calls a configuration system.
<keescook> StevenK: according to upstream bug reports, there is no such option.  :(
<StevenK> Those nasty people
<cody-somerville> Also, if a core-dev could take care of https://code.edge.launchpad.net/~xubuntu-dev/ubuntu-seeds/xubuntu.hardy/+merge/202 :)
<StevenK> Are those the experimental changes you warned slangasek about?
<cody-somerville> Yes.
<cody-somerville> Why?
<StevenK> Just curious
<cody-somerville> The code browser doesn't show the blue lines for some reason, weird.
<emgent> it`s 4.04 AM i go to sleep. night people :)
 * cody-somerville waves.
<Hobbsee> cody-somerville: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
<cody-somerville> Hobbsee, I'm good now, thanks anyhow ;]
<StevenK> cody-somerville: You do know that's a script that replies?
<cody-somerville> StevenK, I'm pretty sure she uses @msg or w/e it is called
<pitti> cody-somerville: too bad that xfce.mk will go away; it made things soo nice and consistent
 * Hobbsee looks in
<Hobbsee> pitti!
 * Hobbsee sends pitti to bed.
<pitti> cody-somerville: 214302 needs ack from ~ubuntu-release
<pitti> since it's a new upstream version
<keescook> Hobbsee: it's only 9pm for him.  ;)
<pitti> Hobbsee: huh? it's ten past nine
<cody-somerville> pitti, I think I'm a delegate or w/e it is called :S
<cody-somerville> and it is mostly a bugfix release anyhow
<pitti> cody-somerville: ah, that makes sense
<pitti> cody-somerville: zzzzynced
<cody-somerville> :)
 * cody-somerville hugs pitti.
 * pitti hugs cody back
<Hobbsee> cjwatson: universe is stricter in a lot of cases, yes.  I've also found this rather backwards.  However, the degree of clue, thoughtfulness, and general responsibility for core-dev and motu are very different.  :(
<cody-somerville> Also, I was wondering, why isn't it possible to force syncs where upstream has a different original tarball?
<Hobbsee> cjwatson: it's one of the reasons i'm quite inactive.
<pitti> cody-somerville: because we can't replace files in the archive, only add new ones and obsolete older ones
<pitti> cody-somerville: otherwise you'd potentially modify sources in stable releases, etc.
<cody-somerville> Okay.
<Hobbsee> cody-somerville: the fact that we have to use strictness to make motu's actually think about what we're doing says a lot about the types of people we're giving upload rights to, and that that probably neesd a rethink.
<cody-somerville> pitti, As for xfce.mk, I'm hoping I can get debian to adopt it :)
<cody-somerville> In the mean time, best to reduce delta due to lack of Xubuntu manpower.
<cody-somerville> StevenK, Were you going to do that merge or were you just curious?
<Hobbsee> LaserJock: at some point, relevant, clueful people, would do well to sit down and hash this all out, before MOTU falls to the ground.  What are your thoughts on using the infrastructure from UDS to do so?
<StevenK> cody-somerville: The latter.
<LaserJock> Hobbsee: I don't much like UDSs for this sort of thing unless theres good pre- and post-UDS work
<LaserJock> Hobbsee: james_w and I had some thoughts in -motu
 * cody-somerville needs a core dev to do merge #202 on lp :)
<Hobbsee> keescook: oh, timezone screwage again.  I thought it was 2am or something.
<LaserJock> Hobbsee: also I think he sent an email to ubuntu-bugsquad about patch/debdiff handling
<Hobbsee> LaserJock: neither, but i'm meaning the infrastructure - ie, the VOIP and possibly gobby.
<LaserJock> ugg
<LaserJock> gobby is useful, VOIP is not
<Hobbsee> LaserJock: then again, if the powers that be decide that there is no problem, then the issue is moot.
<Hobbsee> real time chat tends to help.
<cody-somerville> Ubuntustudio reports great success with VOIP
<_MMA_> :P
<cody-somerville> _MMA_, has gotten me into it ;]
<_MMA_> Just for the team anyway.
<LaserJock> the VOIP at UDSs is really nasty
<LaserJock> you can't hear what half the people are saying, people often switch rooms, etc.
<Hobbsee> LaserJock: i'm assuming it would be after it.  Or before it.
<Hobbsee> LaserJock: everyone on headsets, around the world.
<LaserJock> I personally don't like any type of voice communication, but I might be alone in that
<LaserJock> :-)
 * cody-somerville would be up for trying atleast. :)
<Hobbsee> LaserJock: heh.
<Hobbsee> LaserJock: you're not alone - i hate it too - voice is too high.  But i know it tends to work better.
 * LaserJock works in lab all day with no windows, voices scare me :-)
<Hobbsee> heh
<_MMA_> cody-somerville: You'll see UDS VOIP nastiness soon enough. ;) Not as good as Skype unfortunately.
<cody-somerville> :)
<Hobbsee> each time it seems to get better.  So i'll live in hope :P
<LaserJock> like I said in -motu earlier, I think we need to 1) list our developer bug processes 2) figure out what the developer, contributor, and triager should do in each case 3) design processes and policies correspondingly
<LaserJock> 1) can be pre-UDS 2) at UDS and 3) post-UDS
 * _MMA_ remembers Hobbsee in Boston. Wasn't too bad.
<Hobbsee> LaserJock: first, i think  you need to ascertain if people actually care - particularly those in authority.
<LaserJock> Hobbsee: I don't actually
<Hobbsee> LaserJock: no?
<LaserJock> not particularly
<LaserJock> MOTU decide there policies for the most part
<Hobbsee> LaserJock: if you've got no traction with those in authority, then you can either fight to get it fixed with them, or raise people up from underneath.  You have to see if thsoe people care, too.
<LaserJock> Core devs, well good ideas are usually pretty straightfoward there
<Hobbsee> core dev, sure.  I believe our problem is with MOTU, is it not?
<LaserJock> not sure
<LaserJock> but honestly there isn't much "authority" per se
<LaserJock> we just do what we decided to do, not much to it
<Hobbsee> if you attempt to raise people up, and stir them up into some form of change, you can pay a pretty high personal price for that - so people think you're overreacting, all the time, for eg.
<LaserJock> I'm more concerned with getting enough developers involved
<Hobbsee> there's the MC.
<LaserJock> the MC isn't really all that relavent here
<Hobbsee> afaik, they're still the governing body - they have no pwoer, but you can't actually bypass them for new processes either.
<LaserJock> the MC doesn't determine MOTU Policy
<Hobbsee> i thougth they could still veto it?
<LaserJock> mmm, doubtful
<LaserJock> and even if they could I doubt they would
<Hobbsee> LaserJock: i hope you suceed where i haven't, and don't crash and burn.
<LaserJock> well, there's a difference though, honestly
<LaserJock> it's not about what *I'm* doing, it's about what MOTU (and developers in general) is doing
<Hobbsee> 12:32 autofocus_new_items = OFF
<Hobbsee> oops
<Hobbsee> true.  But it's not anarchy.  That's what they keep telling me, anyway.
<LaserJock> no
<LaserJock> that's why we have MOTU meetings, the TB, etc.
<LaserJock> what I'm saying is that we are not dependent on the MC here
<Hobbsee> so policy can change according to the whims of whoever turns up.  Yeah :(
<LaserJock> they are there to make sure we "fight fair" more or less and to give useful suggestions
<LaserJock> yes, so people should show up, right? :-)
<Hobbsee> indeed.
<Hobbsee> The fact that they don't is a sign that it may not be the most effective place for policy decisions.  Of course, that's a catch 22
<Hobbsee> people whine on mailing lists that it should have been at a MOTU meeting, yet don't show up to the meeting.
<LaserJock> that's why I'm saying to have pre-UDS,UDS, and post-UDS involvement
 * Hobbsee nods
<Hobbsee> LaserJock: so, your thoughts for hwo to proceed are to discuss and vote on things at MOTU meetings, and hope that no one tells you that there is no problem?
<LaserJock> people can tell me there is no problem all they want
<LaserJock> if enough people feel otherwise it doesn't matter
<LaserJock> in generally, for obvious stuff we can just do it and if people complain figure it out
<Hobbsee> feel otherwise and turn up to do something, yeah.
<LaserJock> for stuff that needs voting or more discussion, use MOTU Meeting
<LaserJock> and if there's a conflict we can't resolve as MC/TB for guidance
<LaserJock> *ask
<Hobbsee> LaserJock: i'm interested in solving the core problems.  Patching the outside bits, while temporarily helpful, is not the long turn solution, and tends to just lead to more beuocracy, and procedures changing each time.
<LaserJock> sure
<Hobbsee> of course, it's hard to do tha twhen at least 2 members of the MC tell me that there *is* no problem.
<LaserJock> we need a comprehensive look at this stuff
<LaserJock> well, why should that stop you?
<Hobbsee> so presumably it's better to talk to those who are enlightened on the problem, assuming there is one, and i'm not mad,
<LaserJock> sure
<Hobbsee> and get them to show up and deal with it.
<LaserJock> I often come across problems I see that in reality are not a big deal
<Hobbsee> well, i migth attribute it to that too, but the fact that cjwatson and slangasek and such are complaining about the end results of the problem suggest that i'm really not mad, and the problem does exist.
<LaserJock> you gotta be realistic, open to the other side, but if you think you have a good basis for what you're thinking go for it
<Hobbsee> and presumably that it's big enough it needs to actually be sorted out, rather than swept under the carpet.
<LaserJock> yep
<Hobbsee> LaserJock: hwo many people do you think will speak, if members of the perceived "authority" shoot the idea down?
<LaserJock> ok
<LaserJock> first, you're making this a "us and them" deal
<LaserJock> and second, you're assuming "authority" can shoot us down
<Hobbsee> LaserJock: as soon as they say "$person is overreacting", the discussion dies, and no one looks at what person actually said.
<LaserJock> umm, not really
<LaserJock> I've seen more often than not encouragement from the MC to get things done
<Hobbsee> at least, the mailing list posts tend to suggest that.
<Hobbsee> globally, yes.
<LaserJock> I've talked to I think all members of the MC and beyond about issues I'm seeing
<LaserJock> and pretty much everybody agrees that there are issues we should look at
<Hobbsee> certainly, the autority can't shoot things down - but by saying "i don't think this is a problem", then most people will be inclined to believe them.
<Hobbsee> heh, you got all of the MC to agree to that?  wow
<LaserJock> not if those people also see the issue
<Hobbsee> LaserJock: right, so all the issues stuff needs to come from you and others, then.
<Hobbsee> that works.
<LaserJock> so, in general, keep it open, keep it civil, and if it's something that needs to be done it will get done
<Hobbsee> i fail to see hwo my last mailing list post wasn't, and i still got called as overreacting.
<Hobbsee> but, whatever.
<Hobbsee> so i clearly need to go thru you guys, to avoid that.
<LaserJock> well, to be brutally honest, I think you're tending to exagerate stuff a bit to make sure it's getting attention
<LaserJock> there are clearly issues, but the sky is not falling and MOTU will survive
<LaserJock> despite what I sometimes think myself
<Hobbsee> i'd hope MOTU will survive.
<Hobbsee> and i think that it will survive in some form.
<Hobbsee> But i don't think the form will be overly useful, as it'll be filled with beuarocracy, and it will be very hard to get things done.
<LaserJock> nobody likes beuarocracy
<LaserJock> we just don't know always how to fix it
<Hobbsee> whether that actually translates to that the sky has fallen, if MOTU can't effectively get stuff done...that's an exercise for the reader.
<LaserJock> I worry far more about apathy than I do authority
<Hobbsee> i find that due to the apathy, the majority of the decisions get left to the authority.
<LaserJock> right
<Hobbsee> Which is usually bad and wrong, but it happens.
<LaserJock> though authority is often a nice thing to have, it does tend to create "us and them" scenarios that aren't all that good for a community like ours
<LaserJock> so, we have no one to blame but ourselves, no?
<LaserJock> if our apathy leads down a road we'd rather not go
<Hobbsee> indeed.
<LaserJock> but all is not lost certainly :-)
<Hobbsee> although i don't think the blame game is helpful
<Hobbsee> well, all is lost if we keep not caring.
<Hobbsee> or at least, close to lost
<LaserJock> no, but what it *does* mean is that we are also the solution, right?
<Hobbsee> you guys are the solution, sure.
<LaserJock> and you, if you like
<Hobbsee> hah
<TheMuso> Hobbsee: Yes, you too if you want to be.
<cody-somerville> This _feels_ like a scene out of the movie when the bad guys corner the good guy and try to convince the good guy to join them, ;]
<TheMuso> Yeah but there is no evil intent here.
<Hobbsee> cody-somerville: heh
<LaserJock> "Come to the dark side Sarah"
<LaserJock> perhaps we need some sort of MOTU or Developer CoC
<LaserJock> a bit more technical like
<Hobbsee> "you shall employ thought before uploading"?
<LaserJock> something like that
<LaserJock> though perhaps better phrasing ;-)
<TheMuso> haha yeah.
<StevenK> "You shall not peddle crack at your fellow developers"
 * StevenK looks at jtisme 
<StevenK> Doh
 * StevenK looks at jdong 
<TheMuso> haha
<LaserJock> once upon a time I started writing a MOTU Manifesto, perhaps I should finish that
<cody-somerville> I think a first good step would be for us to write down the perceived problems in a wiki problem with solid examples.
 * cody-somerville is having a hard time identifying what exactly the issue is. :/
<LaserJock> yikes, that can get a bit messy
<LaserJock> "problems" are generally general :-)
<LaserJock> it's hard to pull out specifics a lot of the time, especially if it's social issues
<LaserJock> cody-somerville: but I do agree we need to probably do some of that
<cody-somerville> Maybe we need to employ CPS?
<LaserJock> I just don't think a "Everything that's wrong with MOTU" wiki page is going to end well ;-)
<LaserJock> I think we can get a long ways by not asking "what are we doing wrong" but rather "how do we want to work" and "what are we doing right?"
<cody-somerville> I don't necessarily disagree with you.
<LaserJock> I'm just saying that because I think I've been involved in at least like 2 or 3 "what's wrong with MOTU" wiki pages ;-)
<cody-somerville> Right.
<LaserJock> and by the time your done hashing out the problems you don't have any energy for the solution and you feel depressed :-)
<LaserJock> at least that's how it is for me
<cody-somerville> I think maybe the problem is the lack of application of creative problem solving skills (TM).
<cody-somerville> There was a book I started reading once that described a number of CPS techniques that I think would be helpful to us.
<cody-somerville> I'll make a note to stop at the library for it.
<LaserJock> I think the two top social issues are apathy and distrust
<cody-somerville> So the objective is absolving that apathy and distrust?
<LaserJock> which leads to sloppiness and beaurocracy
 * cody-somerville nods.
<LaserJock> well, somewhat
<cody-somerville> So, maybe some team building exercises would be helpful?
<LaserJock> we certainly don't want technical things like workflows, processes, policies to make things worse
<cody-somerville> But how do you plan to measure success?
<LaserJock> but rather better
<LaserJock> well, in some ways it's a bit more fundamental, IMO
<LaserJock> how can you do a team building exercise when 3/4 of the team doesn't show up?
<cody-somerville> So the problem is getting people to show up?
<LaserJock> I tried to get some MOTU Hug Days going so we could do a last minute team QA blitz and we got 0 responses to the -motu email
<cody-somerville> hmm
<LaserJock> as far as people signing up, nixternal did reply with some suggestions
 * cody-somerville wonders why he didn't reply :/
<LaserJock> you were probably too busy
<LaserJock> I kinda feel like we have too much going on
<LaserJock> we have a bazillon teams and "programs", etc.
 * cody-somerville is pretty heavily loaded with work + leading Xubuntu.
 * TheMuso would have likely been one who replied to that, if he was still only a community member.
<LaserJock> right, lots of reasons not to
<LaserJock> so my thinking is perhaps, using a sports phrase, we need to get back to fundamentals
<LaserJock> look at what *has* to be done and work out good workflows/policies/processes for them
<LaserJock> in particular looking at developers
<LaserJock> look at things that are working and things that aren't
<LaserJock> if they aren't then we can drop them until we can make them work
<cody-somerville> What do you feel currently isn't working?
<LaserJock> mentoring
<LaserJock> sponsorship to some degree
<LaserJock> and the "red tape" part is a lot of it
<LaserJock> developers don't want to be paper pushers, right?
<LaserJock> they want to work on fun stuff
<TheMuso> I've never had a problem having to do red tape, as it keeps me on my toes, thinking about why I am doing what I'm doing.
<TheMuso> And it makes me look more carefully at anything I sponsor, and makes me think about how careful I must be with my own work.
<LaserJock> I agree
<TheMuso> For me, anything to keep me aware of how careful we as developers need to be is a good thing.
<LaserJock> but there's a line
<LaserJock> we don't want more than necessary
<TheMuso> Yes I agree, but we need to keep all developers, whether MOTU or not, to be thinking about just what they are doing, and what damage could result as a result.
<LaserJock> for sure
<TheMuso> gah
<LaserJock> but it's kinda like those popup dialog boxes
<cody-somerville> I don't find that my work is inhibited by the current processes.
<LaserJock> people can either give up or just click through
<LaserJock> cody-somerville: you were just complaining about seed changes ;-)
<cody-somerville> Well, that'll be changed soon
<cody-somerville> I do need someone to still do that merge for me
 * TheMuso will.
<cody-somerville> Thanks TheMuso :)
<bryce> LaserJock: is the issue more about not having enough contributors, or about contributions not being high enough quality?
<LaserJock> well, both
<LaserJock> my more immediate concern is consistency
<LaserJock> I need to know that the developers around me are working to the same standards and are being held to the same standards
<LaserJock> I need to know that the bug triagers are going to do things the way I expect them to
<LaserJock> I need to know that what I do matters
<LaserJock> I'm guessing those are key elements
 * cody-somerville nods.
<LaserJock> so I think the problem is in a lot of ways, not about the specific processes (they by-and-large work well) but that we're all on the same page
<TheMuso> cody-somerville: I have a text conflict in supported...
<LaserJock> one thing I've thought about doing is having cheatsheets
<bryce> well, it's good that you don't feel lack of contributors is a big issue - you have some muscle (maybe not as much as you want), but it needs better training to be effective
<LaserJock> a developer cheatsheet, a triager cheatsheet, etc.
<LaserJock> where you can see at a glance what you need to do
 * bryce nods
<LaserJock> because frankly I spend more time looking up the current wiki page standards than I do actually doing the work
<bryce> I have had similar problems with both X bug reporting and triaging, so have been adopting the documentation/training approach, which seems to have had some good results so far
<cody-somerville> TheMuso, It won't merge cleanly?
<LaserJock> bryce: yeah, we've done quite a bit of that and it's helped
<bryce> I put some triager docs and bug reporter docs at http://wiki.ubuntu.com/X, and refer people to those regularly.  I notice people have started catching on
<LaserJock> but I think we're maybe trying to bite of more than we can chew a lot of times
<LaserJock> Universe especially is tricky
<TheMuso> cody-somerville: No. I did a bzr pull from the core-dev tree and then merged yours, and there is a conflict.
<LaserJock> because of the shear numbers of packages and upstreams
<bryce> I'm trying to turn "When reporting an X bug, *always* attach your Xorg.0.log" into an adage that everyone knows without thinking.  ;-)  That alone would save me *soo* much time.
<cody-somerville> TheMuso, I imagine it has to do with emacs?
<bryce> LaserJock: yeah I got the impression from the discussion scrollback that "needs to be more fun" and "needs to be less overwhelming" are also issues
<TheMuso> cody-somerville: Yes.
<LaserJock> bryce: I agree completely
<cody-somerville> TheMuso, One moment please.
<TheMuso> cody-somerville: Sure.
<bryce> yeah, I can sympathize with the overwelming amounts of work - I think it's true for us all.  Certainly with X alone there seems to be no end of bugs.  But I look at firefox or openoffice and things don't seem quite so bad.  ;-)
<LaserJock> bryce: there are something around 200 pages on the wiki for development
<LaserJock> between MOTU and UbuntuDevelopment related pages
<wasabi> the launchpad integration for bug reporting should make all of that automatic.
<bryce> there are a lot of helpful books and so for dealing with overwhelming workloads, that generally recommend some combination of prioritizing, limiting scope of commitments/responsibilities, etc.
<LaserJock> bryce: that's basically what I'm getting at
<wasabi> I'd like to be able to go to the control panel area, and hit Report a Bug or something... and have it automatically attach all files that might even be remotely relevent.
<bryce> LaserJock: information overload?
<LaserJock> figure out what we *have* to do, prioritize it, and then have fun working on it
<bryce> wasabi: I would love to see that too
<bryce> right
<temugen> wasabi: I was JUST thinking the same thing!
<bryce> LaserJock: for volunteer projects especially, morale and fun are the most precious resource
<LaserJock> one thing I think we can do is to develop more pushing of certain things to Debian
<LaserJock> like the low priority stuff
<wasabi> Well, the crash report tool does most of it. Just need a way to file arbitrary bugs using it... and then include the X config/log.
<temugen> I think a bug reporting feature should be added to every distro; it will collect relevant info based on the error you're reporting
<wasabi> And maybe dmesg output, the last hours logs, except security stuff.
<bryce> LaserJock: a good plan, lots of people, useful docs, and plenty of morale can do just about anything ;-)
<wasabi> apport perhaps can be extended to accomplish it.
<wasabi> Heck, I'd like to be able to hit Report a Bug in a running application, and have a core dump attached, even if it's not crashed.
<LaserJock> minimizing divergence from Debian I think is also a key for MOTU
<wasabi> Oh hey, apport is launched for Report a Problem now. Didn't know that.
<LaserJock> the more we have Debian maintain stuff the better off it is for both Debian and Ubuntu
<cody-somerville> Has anyone else experienced bug #214898? lol
<ubotu> Launchpad bug 214898 in ubuntu "latest batch of updates deleted all user docs, pics, music and vids?" [Undecided,New] https://launchpad.net/bugs/214898
<wasabi> Heck, somebody just needs to add X logs to apport files.
<cody-somerville> TheMuso, Try now :)
<LaserJock> bryce: what do you think of the idea of having like cheatsheets for developers and bug workers?
<TheMuso> cody-somerville: Ok jus a sec
<temugen> Apport is nice for bugs related to crashes... but there's a lot of bugs NOT related to crashes that require the same info
<bryce> LaserJock: I think it's a *great* idea
<wasabi> temugen: hit Report a Problem, from any launchpad integrated application.
<LaserJock> bryce: I think we tend to use the same documentation for learning as for reference, which is tiresome
<bryce> LaserJock: I did what I guess could be described as a cheatsheet here - https://wiki.ubuntu.com/X/Reporting
<LaserJock> I don't want to wade through how to make a debdiff, I want to just remember which flags/tags/subs to flip :-)
<TheMuso> cody-somerville: Much better, committed.
<wasabi> The Gnome Main Menu, under System, needs Report a Problem as a link.
<wasabi> Has this been brought up?
<bryce> LaserJock: I don't know how many bug reporters actually read that (I wish I could make them all read it), but it's proven useful for newbie / occasional Xorg bug triagers.  Gives them a paint-by-numbers way of making sure the bug report has the needed info.
<Hobbsee> i'm sure there's something relevant about pitti's mega-killall script.
<wasabi> Dude. apport already does all this. This problem is already solved.
<bryce> LaserJock: yeah I also have my own packaging "cheatsheet" for how to do everything from rolling packages, to doing SRU's, sponsoring other people's uploads, etc.  I refer to it a lot.
<wasabi> X11 needs to put a file in /usr/share/apport/general-hooks that attachs the X logs.
<wasabi> That's all.
<LaserJock> bryce: in wiki page format?
<bryce> LaserJock: nah, just a text file
<LaserJock> I was wondering if I could grab one of those LaTeX cheatsheets of the net and make PDFs
<bryce> LaserJock: it started as just my personal notes when learning packaging, and grew...
<wasabi> bryce: ... in fact you already have a hook for displayconfig. You know this right? :)
<bryce> wasabi: indeed
<wasabi> Move it to general-hooks.
<wasabi> =)
<wasabi> And we can just add a Report a Bug option to the main menu, which should be there anyways. Use that to promote bug filing.
<wasabi> Tada.
<bryce> wasabi: I think the issue is that I stuck it against xorg-server but needs to be against xorg-server-core or something.  pitti gave me a suggestion, I just haven't had time to do it
<LaserJock> well, there was concern about using apport for general bug reporting in stable releases
<bryce> (and yes, I've probably spent 10x that time asking people to attach stuff in the meantime...)
<LaserJock> getting flooded, etc.
<bryce> true
<wasabi> LaserJock: Is that a real concern? Does that really happen?
<LaserJock> yes
<LaserJock> that's why it was turned off for Gutsy
<bryce> to be honest, I kind of wonder if the bug flood from apport is part of what did in displayconfig-gtk
<wasabi> Hmm.
<LaserJock> we use it while in development, but turned it off right before release
<cody-somerville> When we ship such buggy apps...
<cody-somerville> lol
<bryce> just staying on top of the bug reports was consuming most of the development energy, so other important and necessary coding never got done
<wasabi> Somehow I think that needs to be solveable in other ways.
 * cody-somerville coughs something about displayconfig-gtk.
<LaserJock> cody-somerville: obviously we just nee perfect code
<wasabi> I'm not sure what those other ways might be.
<wasabi> MS probably has a department handling the automatic error reporting in Vista/XP
<SitUbuntuSit> !register
<ubotu> By default, only registered users can send private messages - Information about registering your nickname: http://freenode.net/faq.shtml#userregistration - Type Â« /nick <nickname> Â» to select your nickname.
<wasabi> If you're worried about crash reports, do we not have anyway to do automatic duplicate detection?
<wasabi> If you'r worried about everybody leaving messages in easy to make bug reports... that's different.
<bryce> sometimes I find with bugs reported via apport, the user is kind of doing a "fire and forget", and it can be hard to get followup for any additional info, or to test fixes or whatever
<wasabi> crashes should be easily duplicate checkable.
<bryce> (I would sort of like it if apport-reported bugs could be kept separate from "regular" bugs.  But anyway.)
<wasabi> They are tagged, no?
<LaserJock> bryce: the fire-and-forget issue would be huge if we had apport on for stable releases
<LaserJock> that's one thing I don't like about it
<LaserJock> I have a heck of a time getting responses from reporters
<xtknight> you dont even need a LP acct to report with apport do you?
<bryce> if they could be auto-duped they might be more useful, since it'd give you a measure of the "intensity" of a given crash bug.
<cody-somerville> TheMuso, What do you think of me adding ps3pf-utils to the desktop seeds for PowerPC archs (since it is commonly used on the PS3)?
<LaserJock> I thought so, but I've never actually used it so I don't know
<wasabi> I'd say just ignore no responses. Is it that big of a deal?
<wasabi> "Sorry, need more info."  Forget about it.
<LaserJock> wasabi: well, it certainly can be
<wasabi> For the 50 you do that for, maybe 3 actually are obvious from the stack trace.
<TheMuso> cody-somerville: Its up to you, but I don't see a problem in doing so.
<wasabi> and that's 3 bugs solved.
<LaserJock> we are drowning in bugs already
<cody-somerville> TheMuso, Will you merge my seeds again once I push it?
<wasabi> Well, I'd rather have the information recorded than not at all... I guess.
<bryce> yeah, it's not hard to deal with non-responders, but it's a time thing... time I could spend doing other stuff
<LaserJock> wasabi: well, ideally I would to
<LaserJock> but when 90% of my bugs are usless apport reports and I can't get a response from anybody (worst case scenario) then it is a problem
<wasabi> ABout the dupe detection, is there any solution for that? I mean, if 10,000 people hit the same exact crash, the stack trace is going to be pretty much exactly the same.
<wasabi> At least among some very small number of them
<superm1> slangasek, would you please merge debian-cd w/ http://bazaar.launchpad.net/~mythbuntu/debian-cd/mythbuntu-debiancd/ ? It contains updated artwork.  Thnaks
<LaserJock> wasabi: I believe that is being worked on
<superm1> Thanks even
<LaserJock> wasabi: like once a bug has so many dupes then it gets turned into a real bug report
<wasabi> Ahh, yeah. That  seems reasonable.
<LaserJock> rather than getting a report for any little crash
<wasabi> Maybe if the dupe detection just automatically works, it' sjust a matter of sort order.
<cody-somerville> TheMuso, Actually, I'll get back to you on it.
<wasabi> Sort by dupe count desc/apport desc
<bryce> wasabi: I think bdmurray uses bug-buddy to help identify apport dupes
<wasabi> And work from the top, maybe never getting to the bottom. ;)
<wasabi> Could automatically mark apport bugs with superceeded packages as 'obsolete', in a way that htey drop off the default list when a new version is released.
<TheMuso> cody-somerville: ok
<slangasek> Hobbsee: what end result am I complaining about?
<slangasek> superm1: merged, thanks
<superm1> thanks
<lamont> hrm... so I rebooted and got compiz...  and metacity is no longer my windowmanager???
<lamont> hrm.. how do I tell what my window manager is, I wonder?
<TheMuso> cd
<TheMuso> woops wrong tab
<LaserJock> bryce: how about something like http://laserjock.us/files/ubuntu/uqrc.pdf
<LaserJock> but you know, filled in with stuff :-)
<lamont> ** (ck-list-sessions:12271): WARNING **: Failed to get list of seats: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success
<lamont> how very, um, annoying
<StevenK> Failed to execute program <>: Success ? How very curious
<slangasek> that just means it's trying to print errno
<slangasek> and expecting it to be non-zero when, evidently, it isn't
<tjaalton> humm, noticed a rather disturbing bug while resizing my disk using the livecd.. somehow sda1 got mounted during the gparted operations, which obviously meant that resize failed
<tjaalton> I guess there's no way for gparted to prevent that?
<superm1> perhaps the same workarounds employed in ubiquity need to be in a gparted wrapper
<tjaalton> right, also the swap partitions had to be swapoff'ed
<cody-somerville> Can someone give me a bit of sed magic that will append a string after a certain string in a group of files?
<cody-somerville> or better yet, just one file :)
<TheMuso> cody-somerville: SOmething like 's/orig string/orig string and new string/g'
<TheMuso> The g at the end may not be needed.
<TheMuso> Depending on whether the original string occurs more than once, and whether you want to replace more than one occurance.
<cody-somerville> would this work?: sed -i 's/<!-- <include type="file" src="menu2.xml"/> -->/<!-- <include type="file" src="menu2.xml"/> -->\n\n<separator/>\n<app name="Add/Remove..." cmd="gnome-app-install" icon="gnome-app-install"/>'
<cody-somerville> hehe
<StevenK> cody-somerville: You'd need to litter that with escapes
<StevenK> sed -e 's^<!-- <include
<StevenK> Oh
 * cody-somerville sends it through the StevenK preprocessor ;]
<StevenK> sed -e 's^\(<!-- <include type="file" src="menu2.xml"/> -->\)^\1\n\n<separator/>\n<app name="Add/Remove..." cmd="gnome-app-install" icon="gnome-app-install"/>^'
 * jdong notes to self: ask StevenK all sed questions
<StevenK> I'm not sure at all if sed will respect and expand the \n's. It made add literal \n's.
<StevenK> s/made/may/
 * cody-somerville will test.
<cody-somerville> woot woot
<dholbach> good morning
<warp10> good morning
<kagou> Good morning
<xtknight> what package initially creates the Documents, Pictures, Music folders?
<xtknight> i'm seeing a Bug 214898 stating that all his default folders  contain no files anymore
<xtknight> https://bugs.launchpad.net/ubuntu/+bug/214898
<TheMuso> xtknight: xdg-user-dirs I think./
<xtknight> TheMuso, thanks
<xtknight> that's it im pretty sure
<awen_> the writing support for the danish language is broken due to the following bug 214969 ... any ideas on the best solution for this? ... probably either the depend on myspell-da or hunspell-da should be removed; is any of those dictionary-types more used than the other?
<ubotu> Launchpad bug 214969 in language-support-writing-da "language-support-writing-da depends on conflicting packages" [Undecided,New] https://launchpad.net/bugs/214969
<moyogo> hi
<moyogo> I was wondering if it would be possible to go pass feature freeze and update support in 8.04 to Unicode 5.1 that came out last week?
<neftune> moyogo, have the changes in 5.1 been reflected in code yet?
<moyogo> neftune: update to 5.1 would just mean changing the unicode data files in general
<neftune> moyogo, which ones are you talking about specifically?
<moyogo> gucharmap, glib and probably data files perl or python use
<asac> tjaalton: there? can you explain me why you decided to make a hard depends out of libflashsupport? because of the bug?
<asac> bug 183943
<ubotu> Launchpad bug 183943 in flashplugin-nonfree "flashplugin-nonfree should include libflashsupport as a dependency" [Medium,Fix released] https://launchpad.net/bugs/183943
<tjaalton> asac: yes, so it should work without that now?
<asac> tjaalton: w definitly cannot keep it anymore ... it causes crashes like hell :(
<asac> tjaalton: i am just trying to figure for whom it breaks.
<asac> tjaalton: so far it works for everyone
<asac> i asked
<asac> tjaalton: could you try what i asked on the bug?
<tjaalton> asac: ok.. I had some problems with it back then, so I'll try without the lib now
<asac> tjaalton: thanks
<neftune> moyogo, it looks like glib 2.16.3 just added 5.1 support and is already in hardy. python's "unicodedata" module has lagged considerably in the past
<moyogo> neftune: yeah I just realized glib has :-), so I guess it leaves only some apps and libraries
<RaND1> bonjour
<moyogo> neftune: gucharmap would get 5.1 if the unicode data was regenerated when build
<stgraber> seb128: Are you aware that your last totem upload breaks youtube playing (I get the no plugin for youtube warning) where it used to work just before the update ?
<seb128> stgraber: yes, there is several comments about that on launchpad, I doubt I'll have time to look at it before hardy though, youtube plugin require universe plugins anyway, would be nice if somebody checked upstream if they know about the issue
<neftune> moyogo, http://bugzilla.gnome.org/show_bug.cgi?id=527238
<\sh> asac, the problem is just: without libflashsupport flashplugin will  only play sound via alsa , so someone need to setup .asoundrc correctly...and stop pulseaudio, when it's enabled by default (via esd sound mixing)...or with flashsupport you need to adjust your PA stuff to let the flash plugin stream play on your default device...which is hard to accomplish without padevchooser installed by default
<asac> \sh: yeah, but libflashsupport causes crashes ... and those are not rare
<\sh> asac, I'm running now with flashsupport and pulse since I found out how pulse actually worked...and since then no problems anymore
<asac> \sh: all the people i asked today had no problems with keeping pulseaudio enabled
<asac> \sh: go to youtube video ... wait till sound plays, hit browser back ... hit browser forward, wait till sound plays and repeat
<asac> you will see a crash
<\sh> (on i386 that is...I have to recheck the situation on amd64 still)
<\sh> asac, ahhhh
<asac> often it happens after the second time ... sometimes it needs 10
<\sh> asac, yes...this i see with latest flashplugin too...I wondered if that was because of the new flashplugin
<asac> no thats flashsupport
<\sh> groovy
<asac> \sh: can you test if moving away libflashsupport.so really breaks sound for you again
<\sh> asac, give me a sec
<asac> everyone i asked had problems earlier in this cycle but don't have sissues now
<asac> \sh: i think fixing asoundrc for some users is ok, requiring to disable pulseaudio would be a bad trade :(
<\sh> well, moving flashsupport out of the way, restarted firefox, gives me no sound in the moment, because .asoundrc is set to use pulse
<\sh> I would need to set asoundconf back to alsa device != pulse
<\sh> which I will do now
<Amaranth> \sh: and then you need hardware mixing
<\sh> Amaranth, yepp.
<\sh> and this is not working, I'll restart the session to be sure...
<Amaranth> no one has hardware mixing :)
<Amaranth> unless they have an X-Fi or something
<\sh> Amaranth, nope it worked before without pulse..so it should work now, too
<\sh> brb
<kagou> mvo around ?
<Amaranth> you have a high-end sound card then
<asac> \sh: try plain default setup and at best without your funky bluetooth thing ;)
<asac> (for now)
<mvo> kagou: yes
<asac> Amaranth: straber could play multiple streams in flash without flashsupport ... and has no hardware mixing according to him
<asac> stgraber that is
<Amaranth> in flash, sure
<Amaranth> because pulseaudio will release the device after being idle for a bit
<Amaranth> then dmix takes over
<kagou> mvo, can i assign you to Bug #208419 specially the nautilus-share problem. We need to add/or modify a patch to install libpam-smbpass in the same time that samba
<ubotu> Launchpad bug 208419 in nautilus-share "Integrate samba password in PAM" [Medium,Confirmed] https://launchpad.net/bugs/208419
<asac> then where is the problem?
<asac> and ... is that problem worse than crashing firefox :/
<\sh> asac, layer 8;)
<\sh> asac, asoundconf is not enough...I had the change the default sound card in gnome settings
<\sh> to
<\sh> o
<\sh> now I have sound
<Amaranth> asac: you can't play a sound in anything else at the same time as flash
<asac> Amaranth: stgraber could use mplayer at the same time iirc
<\sh> pressing back button, pressing forward...no crash and sound
<\sh> but only via alsa
<Amaranth> because if flash is playing pulseaudio can't get its exclusive grab of the card and if pulseaudio is playing flash is blocked
 * \sh can use rhythmbox at the same time too :) via usb headset mixer
<stgraber> http://www.stgraber.org/download/pulse.png, that's firefox without libflashsupport + mplayer using esd + mplayer using pulse
<Amaranth> \sh: that's a different device, cheater :P
<\sh> Amaranth, nope...I have both sounds on my headset
<mvo> kagou: ok, I will check the bug out
<Amaranth> stgraber: err, that says flash is going through pulse
<Amaranth> so either asoundrc or libflashsupport
<stgraber> Amaranth: I don't have a .asoundrc
<Amaranth> perhaps it is the default then
<asac> and he doesn't have flashsupport.
<asac> maybe latest flash update uses pulse now?
<Amaranth> but flash is going through pulse which means either flash grew pulse support without telling about it or alsa is routing things through pulse
<\sh> anyways...i have alsa now, and I can listen to two different sounds from two different apps at the same time
 * asac digging in the dark
<\sh> no PA daemon running, esd totally shut down in sound settings
<kagou> thanks mvo
<asac> \sh: can you see if you can get it working without soundrc?
<Amaranth> \sh: then you are not using pulse at all
<asac> but with pulse enabled?
<Amaranth> \sh: so that doesn't count either :P
<asac> like what stgraber has?
<stgraber> maybe flash can use ESD and Pulse has its ESD compatibility stuff ?
<tjaalton> asac: uh, my ff3-session got busted somehow, it just keeps on loading new windows.. is this something new with beta5?-)
<\sh> ok now pulse started...
<\sh> asoundrc is set to use my usb headset
<\sh> (which I need, I don#t have speakers on my pc here)
<asac> tjaalton: not sure what you describe :)
<\sh> so...ff3+flash is using still alsa...
<\sh> now setting back to pulse output
<tjaalton> asac: started ff, it first loads the session ok (~10 windows with a lot of tabs), then a second later it loads it again, and again until the machine is so slow that the process slows down :)
<Amaranth> \sh: close firefox and rhythmbox, set to pulse, open rhythmbox, open firefox
<\sh> Amaranth, I did :)
<Amaranth> either flash will magically be going through pulse now or you get no sound
<asac> stgraber: can you test this as well ^^
<Amaranth> ugh, last penguin.swf post was in december
<\sh> WTF?
<\sh> my usbheadset device disappeared now while switching to pulse
<\sh> grmpf..restarting session
<asac> would starting firefox with esd wrapper help if we detect pulse?
<Amaranth> and no changelog
<Amaranth> asac: isn't flash a separate process now?
<Amaranth> i thought it used XEmbed
<asac> isn't wrapper inherited to child processes?
<soren> slangasek: I'd like to get and ACK on bug 213991 before I upload.
<ubotu> Launchpad bug 213991 in libvirt "libvirt should allow for 'model' of nic" [Wishlist,New] https://launchpad.net/bugs/213991
<stgraber> asac: working
 * soren goes to bed
<Amaranth> asac: the esd wrapper is for things using /dev/dsp, not alsa
<stgraber> asac: rhythmbox + firefox, both going through pulse
<asac> right ;)
 * Amaranth wishes adobe published a changelog somewhere
<asac> (but without flashsupport i guess)
<stgraber> no flashsupport indeed
<asac> actually i think if we find that flash goes through pulse i don't see why flashsupport would be required
<\sh> Amaranth, ok...back to pulse...flash tries to connect to pulse but is not establishing the connection or crashes...you can see that with padevchooser -> volume control
<Amaranth> maybe you have a system config to route alsa through pulse and flash is less stupid now
<\sh> (without flashsupport in /usr/lib)
<Amaranth> if you don't have a system config to route alsa through pulse i'd say hardy is pretty broken, actually :P
<asac> \sh: please be sure that everything is clean and you can still reproduce. maybe pulse server was busted after playing around that much.
<stgraber> Amaranth: mplayer -ao alsa fails so I guess I don't
<asac> (i don't trust pulse that much)
<Amaranth> I guess we'd rather preconfigure everything with support to use pulse and leave everything else nonworking
<asac> Amaranth: if that means no sound in flash its a pretty tough decision
<asac> tjaalton: do you use a special extension to restore your session?
<\sh> asac, nope...I restarted pulse
<\sh> asac, rhythmbox goes through pulse now
<\sh> and flash tries to establish a connection on pulse...but doesn't succeed...and flashsupport is now in /root and not in /usr/lib anymore
<tjaalton> asac: no, it's built-in
<tjaalton> asac: I think ff2 already had the feature, before you needed an extension for it
<asac> \sh: but if flash tries to establish a connetion to pulse it isn't it a pulse bug?
<\sh> asac, nope
<tjaalton> "before that.."
<asac> \sh: why? i mean it tries to use pulse
<\sh> asac, I wonder what magic adobe implemented now to try at least a pulse connection
<\sh> asac, yes...but I think somethings changed in flashplugin without knowing it...I didn't see that behaviour with 115 but now with 128
<\sh> aeh 127
<asac> yeah. but why doesn't pulse accept the connection. thats what bothers me
<asac> stgraber: does it work for you?
<\sh> asac, because something's wrong in flashplugin...it's not pulse
<asac> \sh: maybe you tweaked pulse in some way?
<\sh> asac, nope
<stgraber> asac: yep, that's why I get the "Adobe Flash: Flash Animation" in pavucontrol
<\sh> asac, I need flash at work :) so I'm not a friend of breaking my working environment
<stgraber> \sh: i386 or amd64 ?
<\sh> stgraber, i386 right now...I test with amd64 this evening
<stgraber> I'm running 64
<tjaalton> asac: I know what it's doing.. it opened all the windows that I had opened at some time during the last session. it loaded 87 windows in total :)
<\sh> stgraber, do you see this flashing connection thingy in volume-control of padevchooser?
<asac> tjaalton: ah. so not a bug?
<\sh> stgraber, for application streams?
<asac> tjaalton: ah now i read what you mean
<tjaalton> asac: it is, it should load what I had when I closed firefox
<asac> tjaalton: can you reproduce?
<tjaalton> asac: I'll try to reproduce with a clean profile
<asac> tjaalton: maybe that happened when the upgrade was pushed underneath while running firefox?
<stgraber> \sh: no, I have "Adobe Flash: Flash Animation" there while watching something on youtube
<tjaalton> asac: well, then I had to kill it since "file - quit" didn't work. it loaded fine with beta5 then, but this is probably the first time I've restarted since the update
<\sh> stgraber, well, not here..I moved libflashsupport.so out of the way, as discussed, and now I have a flashy thingy...
<\sh> I'm trying to record that now
<\sh> give me some mins
<ogra_cmpc> tjaalton, did your vdr upload fix the xine frontend ? (i recently got a dvb-t stick, when i tried vdr it didnt wnat to work with xine)
<asac> tjaalton: ok. i'd file it under the "all kind of obscure things can happen if you don't close firefox while upgrading"
<stgraber> \sh: the only difference I see between your flash and mine is that I'm using nspluginwrapper
<tjaalton> ogra_cmpc: I don't know, never used that myself. It probably needs some fiddling because 64bit FTBFS'd
<tjaalton> ogra_cmpc: I'll check what debian has now
<ogra_cmpc> ah, k, i'll wait then, no pressure or something :)
<Amaranth> asac: I wonder why that is
<Amaranth> Does firefox not keep its own resources in memory?
<asac> Amaranth: it loads things lazily
<asac> Amaranth: so if you don't use a module (mostly chrome files), then upgrade and then try a previously not used feature it will either pull in incompatible modules (like in firefox2) or nothing (like now)
<\sh> stgraber, asac : http://archive.linux-server.org/flashproblem.ogg
<asac> note: this is not really about shared libs, but about the chrome/*.jar files
<asac> \sh: strange. but i don't see why this is not a pulse bug
<\sh> asac, because with the old flashplugin this didn't happen...
<asac> well ... the old plash plugin apparnetly didn't try pulse at all
<\sh> asac, so something changed during the update from 115 to 124
<\sh> asac, right :)
<stgraber> \sh: yours is "alsa playback" mine isn't ...
<asac> that still doesn't tell me that its a flash bug. maybe flash could workaround a bug in pulse.
<\sh> stgraber, again...everthing is setback to pulse..
<Amaranth> asac: I'm be much more likely to blame flash than pulse
<\sh> stgraber, only libflashsupport.so is moved away
<Amaranth> flash doesn't do _anything_ right
<asac> Amaranth: why?
<asac> but pulse does?
<Amaranth> "hmm, lets see how many alsa connections we can open"
<tjaalton> asac: seems that sessionstore.js is reducing in size now that I let firefox start without killing it, so no urgent need to do anything :)
<asac> hehe
<\sh> stgraber, the alsa playback is triggerd from flash, not from anything else :)
<stgraber> here I have no mention of alsa in pavucontrol, like if flash is trying to connect using ESD or Pulse and not alsa
<asac> tjaalton: ok thanks.
<tjaalton> (reducing when I close windows)
<\sh> stgraber, yepp...esd is not running, only PA
<\sh> stgraber, which is somehow the default when you click on sound settings, esd mixing
<\sh> stgraber, and this evening I'll have to see how my amd64 is behaving
<asac> Amaranth: if we have an idea what flash does wrong, we could raise that with adobe. but i can't go there claiming that they are broken if we are not sure whats going on on pulse side.
<stgraber> it seems that flash is using ESD here and my pulse is listening to ESD connection (first time I use pulse, so I assume it's the default)
<asac> (well ill do anyway, but i want to know as much details as possible)
<Amaranth> stgraber: ah, right
<stgraber> asac: looks like flash can use ESD instead of alsa, then it works with pulse using the ESD compatibility of pulse
<Amaranth> it tries alsa, fails, tries oss, fails, tries esd, gets pulse
<asac> stgraber: ok. so how does it work?
<stgraber> asac: as Amaranth said
<asac> stgraber: would we need to change anything to make everything work?
<Amaranth> _but_ if pulse is configured to release the device on idle then flash can snag it and break pulse
<stgraber> asac: I never changed my pulse config, so I'd assume listening on ESD port/socket is default
<asac> Amaranth: ah. so you say flash would end up in alsa if pulse releases it?
<\sh> grmpf
<Amaranth> yes
<asac> \sh: tweaked that?
<Amaranth> I'm not sure if we have pulse configured to hold on to the device, the default is to release it after 10 seconds or so
<stgraber> \sh: can you try : mplayer -ao esd something-here ?
<\sh> asac, no...this alsa playback is bugging me...why does pulse catch that...
<\sh> stgraber, yepp
<asac> \sh: this means that esd released your device (like Amaranth said)
<asac> lets figure if thats the default
<\sh> stgraber, it's connecting to pulse
<\sh> stgraber, I can see the stream normally...without flashing
<asac> we have:
<asac> ### Automatically suspend sinks/sources that become idle for too long
<asac> load-module module-suspend-on-idle
<asac> is that the config?
<stgraber> asac: I don't think having pulse locking the device is a good idea (most games won't work if we do so) but flash shouldn't try alsa/oss first and start with pulse (if we can change this behaviour)
<asac> stgraber: ok. but can we reproduce \sh flashing?
<stgraber> asac: without the ESD part of PA I think so
<Amaranth> asac: Right, we either need to not load that module or somehow make flash use esd first
<asac> stgraber: what do you mean? how did you enable the ESD part?
<stgraber> I just tried on a newly installed computer and PA is listening for ESD connection by default (ie. mplayer -ao esd /usr/share/sounds/login.wav works)
<Amaranth> he has pulse active and has that module installed :)
<stgraber> Amaranth: seems to be the default ...
<asac> \sh: ^^ ??
<Amaranth> pulseaudio-esound-compat
<\sh> mplayer -ao esd /usr/share/sounds/login.wav <- works :) via pulse
<Amaranth> ah, ubuntu-desktop depends on that package :)
<\sh> ii  pulseaudio-esound-compat                                                    0.9.10-1ubuntu1                             PulseAudio ESD compatibility layer
<\sh> yes..
<asac> sorry, i don't get why \sh doesn't have that default even though he didn't change any pulse config. what am i missing?
<Amaranth> but flash can't connect to pulse using the esd compat stuff
<Amaranth> that seems to be the problem for \sh
<Amaranth> but not a problem for stgraber
<asac> Amaranth: why does he use compat stuff and stgraber not?
<Amaranth> They both do
<\sh> asac, diff in amd64 and i386?
<\sh> asac, nspluginwrapper e.g.?
<asac> ok, so its nspluginwraper vs. not nspluginwrapper?
<asac> i can't imagine why
<Amaranth> They both have the compat stuff and it works with mplayer but doesn't seem to work for \sh with flash
<Amaranth> I can't imagine nspluginwrapper breaking a wire protocol
<Riddell> evand, cjwatson: small fix to gtk_ui.py committed, please check for sanity
<Amaranth> But I have seen stranger things
<asac> Amaranth: actually in this case it would not be "breaking", but "fixing"
<asac> stgraber: uses nspluginwrapper
<Amaranth> Oh, \sh is the one with x86?
<asac> yeah
<asac> thats even more crazy
<\sh> Amaranth, right
<stgraber> \sh: can you run "pacmd"
<\sh> yes
<stgraber> \sh: then : list-modules
<stgraber> \sh: and look for : module-esound-protocol-unix
<\sh>  index: 6
<\sh>         name: <module-esound-protocol-unix>
<\sh>         argument: <>
<\sh>         used: -1
<\sh>         auto unload: no
<Amaranth> that's what i get too
<stgraber> \sh: same here ...
<Amaranth> used is weird but it is -1 for everything :P
<\sh> groovy
<Amaranth> crap don't run 'exit' in there
<Amaranth> it doesn't exit the shell, it exits pulseaudio
<stgraber> Amaranth: list-modules is : List loaded modules so ...
<stgraber> use ctrl+d to exit the shell
<asac> Amaranth: maybe i missed it, but does it work for you? (in ephy obviously :))
<Amaranth> i don't have ephy installed :P
<Amaranth> i was just about to test this
 * asac bows down
<Amaranth> i still have flash 124 :/
<Amaranth> ephy will be cool again when it uses webkit, right now i don't see a use :)
<pwnguin> TheMuso: then feel free to have a look at bug #203429
<tjaalton> ok, so how should I test this pulse/ff/flash -madness?
<ubotu> Launchpad bug 203429 in initramfs-tools "resume script missing functions" [Undecided,Fix released] https://launchpad.net/bugs/203429
<pwnguin> whoops
<pwnguin> 11538 jldugger  20   0  687m  72m  22m S  190  7.2  13:21.50 pluginappletvie
<Amaranth> ok, what version of flash should i have?
<Amaranth> doesn't matter, works with the one i have
<Amaranth> oh, i need to move libflashsupport aside
<Amaranth> duh
<stgraber> Amaranth: 124
<asac> tjaalton: use the latest, use default setting for everything pulse related ... then see if rhythmbox works together with flash sound
<Amaranth> ALSA lib pcm_dmix.c:874:(snd_pcm_dmix_open) unable to open slave
<Amaranth> about a bazillion times
<Amaranth> no sound, obviously...
<stgraber> you probably already have an alsa software running (rhythmbox ?)
<ogra_cmpc> Amaranth, thats exactly the error libflsashsupport works around :)
<Amaranth> ogra_cmpc: I know :P
<Amaranth> stgraber: No, I have pulse running
<Amaranth> The whole point is to get flash talking to pulse :P
<ogra_cmpc> wont work without libflashsupport
<asac> ogra_cmpc: yesterday you said that flashssuport just cares for open file descriptors ;)
<Amaranth> ogra_cmpc: stgraber's system apparently says otherwise
<ogra_cmpc> asac, exactly ... and the message above is one of the symptoms
<Amaranth> and libflashsupport causes crashes
<Amaranth> so 3 systems, 3 different outcomes
<Amaranth> this sucks :P
<asac> well, flashsupport crashes for everyone ;)
<stgraber> ogra_cmpc: here flash just uses ESD and everything works fine (tm)
<ogra_cmpc> Amaranth, libflashsupport worked fine for three releases in ltsp
<ogra_cmpc> stgraber, yeah, thst indeed different
<Amaranth> \sh gets a pulse connection error, I get an alsa connection error, stgraber gets everything working
<asac> ogra_cmpc: that doesn't matter. and its likely that its due to a race/deadlock so you might just not have seen this
<Amaranth> i think there is an env variable to make it choose which to use by default
<tjaalton> asac: ok, not using any .asoundrc tricks, "software sound mixing" is on, and the rest should be default as well. If I start firefox/flash first all is well, but if I leave RB running and restart ff, the flash clips stay grey
<ogra_cmpc> asac, how about setting the good old DSP environment variable in /etc  ?
<ogra_cmpc> and poiint that to esd
<asac> ogra_cmpc: the wrapper only works for oss according to Amaranth
<ogra_cmpc> iwj took that out a while ago, how about trying if it works now :)
<Amaranth> i thought, anyway :/
<ogra_cmpc> well, how did stgraber then get flash talk to esd ?
<asac> you can test it i guess, by manually running firefox wrapped
<asac> if that works id consider to wrap firefox i ncase i can detect pulse enabled
<Amaranth> padsp certainly doesn't help
<Amaranth> what is the esd one?
<Amaranth> esddsp?
<asac> thats what i don't know and nobody could tell me :( ... maybe just esd /usr/lib/firefox-3.0b5/firefox ?
<ogra_cmpc> right
<Amaranth> rhythmbox is playing 'mad' music :P
<asac> ogra_cmpc: i have no esddsp
<ogra_cmpc> esddsp is corret
<Amaranth> fits the mood
<asac> do i need a package for that?
<Amaranth> asac: esound-clients
<stgraber> oh, I just noticed, I'm not running PA using the init.d script but it's gnome that's starting it ... not sure it makes any difference though
<asac> ok ... \sh does it work to run firefox as above?
<ogra_cmpc> asac, esound-clients
<asac> tjaalton: and you?
<\sh> hmm...via esd?
<ogra_cmpc> but i dont know how trhe dependency chain is here, it might conflict
<stgraber> so it's running as myself and not as "pulse"
<Amaranth> but esddsp is broken, it tries to preload non-existent files
<tjaalton> asac: sorry, what?
<asac> ERROR: ld.so: object '/usr/lib/libesddsp.so.0' from LD_PRELOAD cannot be preloaded: ignored.
<asac> thats what i get
<ogra_cmpc> eek, indeed
<asac> tjaalton: nevermind ... esddsp is broken too :(
<asac> that lib doesn't exist at all
<asac> damn
<asac> where is it?
<Amaranth> it moved to /usr/lib/esound/libesddsp.so.0
<Amaranth> change the script
<\sh> asac, what do I need to do? sry..didn't catch it..doing some real life work too here;)
<asac> run esddsp /usr/lib/firefox-3.0b5/firefox
<asac> \sh: ^^
<ogra_cmpc> mv .asoundrc.asoundconf  .asoundrc.asoundconf.old && asoundconf set-pulseaudio
<Amaranth> no help
<ogra_cmpc> does that chzage something ^^^^
 * \sh needs to install that first
<Amaranth> ogra_cmpc: that's not what we want :P
<ogra_cmpc> Amaranth, that should be exactly what you want
<asac> can't we fix human beings not caring about sound?
<\sh> asac, sound and linux is evil...and I wonder when we can fix that
<ogra_cmpc> cant we just fix libflashsupport ?
<asac> ogra_cmpc: feel free. i tried, but didn't succeed
<asac> and warren didn't want to take a look apparently
<Amaranth> ogra_cmpc: no, that breaks pulse
<\sh> asac, no change with flash thingy on padevchooser volume control
<Amaranth> because it doesn't handle flash opening 1024 connections
<\sh> same with padsk
<\sh> padsp even
<asac> Amaranth: can't pulse close idle connections :) ?
<Amaranth> that being asoundconf change
<ogra_cmpc> Amaranth, indeed you need libflashsupport for the handles
<ogra_cmpc> but in that setup it works stable since feisty for ltsp
<\sh> ogra_cmpc, libflashsupport is not nearly alpha stage regarding adobes comments ,->
<asac> ok. so our bug is that flash doesn't close asound handles?
<ogra_cmpc> \sh, libflashsupport was abandoned by adobe over a year ago
<asac> \sh: i doubt that adobe really considers flashsupport a solution at all
<ogra_cmpc> its maintained in the pulseaudio source since 6monthjs
<\sh> well, what I don't understand is, what flash is doing since new version...the old 115 didn't try to connect to pulse somehow...and never showed this behaviour
 * \sh tries to find the damn changelog for flash linux
<Amaranth> \sh: new flash doesn't try for me either
<Amaranth> there is some flash specific env variable to make it prefer esd, i swear
<asac> stgraber: can you dump your envs?
<asac> Amaranth: can't you block the other options somehow? so it ends up trying esd?
<Amaranth> that's what i'm saying
<asac> no i mean to test, block them outside of flsah ;)
<Amaranth> although the more i think about it the more i think that might be been a feature of the original (horrible) libflashsupport
 * asac runs strings on the binary
<\sh> Amaranth, no env var for me here...
<Amaranth> no, there is no way to block
<ogra_cmpc> asac, you didnt ask in #pulseaudio about http://www.pulseaudio.org/ticket/225 yesterday, right ?
<Amaranth> because it is already blocked, it tries until it isn't blocked :P
<\sh> and firefoxrc tells me that dsp is none
<ogra_cmpc> asac, i pinged the channel with a question bout it, lets see what the actual maintainer say :)
<asac> \sh: firefoxrc is not considered
<stgraber> http://ubuntu.pastebin.com/f1f783113
<asac> should be removed
<stgraber> asac: ^
<\sh> asac, I'm just checking what could lead to something which makes sense
<ogra_cmpc> \sh, all we need is a fix for http://www.pulseaudio.org/ticket/225
<asac> yeah. what firefoxrc did was to tell firefox start script to start with a wrapper
<ogra_cmpc> fiddling around with esd and other stuff doesnt really get us anywhere
<asac> no luck parsing the strings output of flashplugin binary so far (searching for ESD env)
<ogra_cmpc> asac, forget it, flash alsways used libesd directly, i doubt they fixed that when they switched to alsa support
<asac> FLASH_ALSA_DEVICE
<Amaranth> asac: apparently we are the first to find that, whatever it may be
<dholbach> thekorn: does launchpadbugs.commentsbase.attachments work for you?
<Amaranth> google knows nothing
<dholbach> thekorn: I tried it on https://bugs.launchpad.net/ubuntu/+source/acidbase/+bug/135425/comments/1 and the set is empty
<ubotu> Launchpad bug 135425 in acidbase "Attack names not shown on default install" [Undecided,New]
<ogra_cmpc> Amaranth, not really, else there wouldnt be a bug abo8ut it upstream
<Amaranth> ogra_cmpc: err, i meant FLASH_ALSA_DEVICE
<ogra_cmpc> Amaranth, ah
<asac> Amaranth: the reason why nobody saw that is because the backtrace gives no info about that
<asac> we found the way to reproduce by accident
<asac> and maybe its only uncovered in ffox 3 (which is not yet that wide spread)
<Amaranth> asac: err, i meant FLASH_ALSA_DEVICE
<Amaranth> :P
<asac> oh ;)
<\sh> what could be the value...export FLASH_ALSA_DEVICE=pulse doesn't fix it ,->
<asac> there is also a string: SOUND_COMPLETE :)
<dholbach> thekorn: and it crashes with the HTML connector: http://paste.ubuntu.com/6692/ :-(
<ogra_cmpc> \sh, padsp ?
<Amaranth> \sh: i imagine it is something like 'hw:0'
<\sh> Amaranth, I wonder if we can work around it when introducing a monitor device or something :)
<\sh> I mean I can reroute a PA monitor device to a pcm.monitor device :)
<\sh> which then can be used for recording software not capable of pulse
<ogra_cmpc> \sh, did you try with padsp as device ?
<\sh> ogra_cmpc, padsp /usr/lib/ff-3.0b5/firefox doesn't change anything....
<ogra_cmpc> if you route it through various monitors it very likely that yous sound gets async over time
<\sh> ogra_cmpc, or you mean export FLASH_ALSA_DEVICE=padsp ?
<ogra_cmpc> yes
<\sh> no change
<\sh> same behaviour...flashing in pulse but no sound
<\sh> lunch
<\sh> bbl
<MacSlow> I get "unsupported version 0 of Verneed record" for svn's /usr/lib/libsvn_wc-1.so.1
<MacSlow> Anybody with a clue what that means?
<asac> ogra_cmpc: i think i joined the pa channel late. what was the outcome?
<thekorn> dholbach: bug.comments[x].attachments is always empty in the text mode, because LP's +text does not link an attachment to a comment
<dholbach> thekorn: ah ok - I just wondered if there was a way to figure out how old a patch is
<Riddell> cjwatson: how come partition_button_undo is a special case for translations?  just because there was an existing string for it and not for the others?
<thekorn> dholbach: can you please file bug bugreport on the crash in the html-mode, this should work,
<mvo> kagou: nautilus-share should be fixed
<dholbach> thekorn: will do
<thekorn> you should be able to workaround this by calling b.attachments before b.comments[x].attachemnts
<Riddell> cjwatson: the partitioner has lost the default mountpoints and partition types, is that deliberate?  http://kubuntu.org/~jriddell/tmp/partition-buttons.png
<tjaalton> asac: heh, seems that enabling libflashsupport again didn't change my situation. the flash-videos get hung almost like they did without the lib (when RB is playing in the background)
<tjaalton> asac: hum, refresh sorted that out
<ogra_cmpc> asac, that pulse bug sounds suspiciously like we could just fix it by dropping the second pthread_mutex_lock() from FPI_SoundOutput_FillBuffer
<asac> ogra_cmpc: is it guarded by a !same_thread NOR ui-thread ?
<ogra_cmpc> hmm
<ogra_cmpc> could we drop the FF side here ?
<asac> ogra_cmpc: firefox side? what do yo umean?
<ogra_cmpc> well, there is a pthread_mutex_lock() as well as one issued by libflashsupport
<ogra_cmpc> we only want one, right (at least to teh same mutex)
<asac> ogra_cmpc: which line do you refer to in flashsupport?
<ogra_cmpc> i didnt look at the code, just followed the logic in the bug
<ogra_cmpc> oh
<ogra_cmpc> i was unbder the impression FPI_SoundOutput_FillBuffer comes from libflashsupport
<ogra_cmpc> seems its not
<ogra_cmpc> asac, did anyone try with libflashsupport connected directly to alsa ?
<ogra_cmpc> (needs a recompile of libflashsupport with alsa dep added)
<asac> ogra_cmpc: i tried it
<ogra_cmpc> ah, k
<asac> it crashes even easier
<asac> but in general the same
<ogra_cmpc> yeah, one layer less :(
<\sh> back
<amitk> ogra_cmpc: had a chance to try the kernel I posted yesterday?
<Ng> hmm, I just applied the last day or two's worth of hardy updates and my theme (darklooks) started showing black on black tooltips. the colour options in Appearances let me fix it, but what could have reset that? (or at they options that I couldn' previously override?)
<munckfish> cjwatson: is it a convenient moment to chat about ps3 port stuff?
<ogra_cmpc> amitk, looks good so far ... (beyond tha fact that the kernel takes 5 min to boot (guessiong thats through debug stuff you enabled tohough) and usplash being totally broken)
 * ogra_cmpc hugs amitk 
<ogra_cmpc> oh, wait, now it got stuck
 * ogra_cmpc tries agign
<amitk> ogra_cmpc: don't enable wireless for now, when n-m asks for access, deny it
<ogra_cmpc> ah
<ogra_cmpc> right, i had the keyring question
<Hobbsee> slangasek: i thought it was you, anyway
<ogra_cmpc> amitk, bah, nm as a whole seems broken ... even making a new connection breaks
<kagou> thank you mvo :)
<ogra_cmpc> amitk, beyond that its just beautiful :D
<amitk> ogra_cmpc: also try the -13 kernel that I am uploading to rookery, it should allow wireless to work too.
<ogra_cmpc> amitk, any idea what causes the NM breakage ? anything i can work on to take load off you ?
<ogra_cmpc> ah, ok
<ogra_cmpc> its funny, your kernel seems to become fster with every boot
<amitk> ogra_cmpc: it learns its way around ;)
<ogra_cmpc> the first one took nearly 10 mins ... the subsequent ones about 5 ... now its less than one
<ogra_cmpc> i.e. as fzast as mine
<amitk> ogra_cmpc: could be garbage collection on the flash FS?
<\sh> are the buildds already on manual?
<Hobbsee> should'nt be
<\sh> good
<ogra_cmpc> amitk, hmm, right
<ogra_cmpc> amitk, i'm at my 20th successfull suspend cycle now, i guess we can consider that part working :)
<amitk> ogra_cmpc: heh, now to figure out which one of our 1000 patches is breaking it in the Ubuntu kernel ;)
<ogra_cmpc> ouch
<Mithrandir> amitk: "git bisect" :-)
<ion_> amitk: git-bisect or the equivalent for whatever VCS you're using should help a lot.
<amitk> ogra_cmpc: the -13 kernel i sent is a patch on top of stock 2.6.24.2, so atleast we have it working on 2.6.24
<amitk> Mithrandir: yeah... already prepping for git bisect
<cody-somerville> slangasek, Once my push mirrors on launchpad, will you merge the xubuntu seeds and rebuild please (with a cherry on top)? :)
<cody-somerville> https://code.edge.launchpad.net/~xubuntu-dev/ubuntu-seeds/xubuntu.hardy/+merge/203
<jeromeg> cody-somerville: hello
<cody-somerville> Hello jeromeg
<jeromeg> i was thinking of something the other day
 * cody-somerville nods.
<jeromeg> shouldn't the xfce about dialog in the menu display the version of xfce and ubuntu the system is using ?
<laga> cjwatson: i hate to be wasting your time, but the mythbuntu.hardy seeds don't work with germinate: http://www.pastebin.ca/979505 maybe you can take a look? http://bazaar.launchpad.net/%7Emythbuntu/ubuntu-seeds/mythbuntu.hardy/ is current
<cody-somerville> jeromeg, Good point. It already displays the version of Xfce but not Xubuntu.
<jeromeg> cody-somerville: oh ok
<cody-somerville> jeromeg, Would you be kind enough to file a bug against xfce4-utils (source package)?
<kagou> mvo still around ?! :)
<jeromeg> cody-somerville: i'll
<jeromeg> cody-somerville: i could propose a patch, but i've no idea on how to localize the string
<cody-somerville> jeromeg, We only use the numbers after release.
<jeromeg> cody-somerville: sorry, by localize i meant, make it display in french in a french environment, in english, in german in ...
<jeromeg> so that it fits all languages
<cody-somerville> "Xubuntu 8.04" is pretty universal :)
<jeromeg> oh ok :)
<jeromeg> i thought something like "Your system runs Xubuntu 8.04."
<mvo> kagou: why
<jeromeg> but yours is fine and does not need translating :)
<mvo> kagou: yes :)
<cody-somerville> jeromeg, Well, how is the current text translated? If it isn't already translated, I wouldn't worry about it.
<jeromeg> i've no idea
<cody-somerville> jeromeg, and it is too late to add new strings anyhow even if we wanted it translated
<kagou> mvo, as you know nautilus-share, we need to solve Bug #212098 and may be you can create a patch
<ubotu> Launchpad bug 212098 in nautilus-share ""easy" file sharing not notifying about logout/restart" [High,Confirmed] https://launchpad.net/bugs/212098
<jeromeg> cody-somerville: i think it was translated in launchpad, but now that xfce moved to universe...
<mvo> kagou: I will have a look
<kagou> mvo, great. I was thinking about a popup notification (dbus ?!!)
<jeromeg> cody-somerville: for example the logout dialog is not translated anymore, because there is xubuntu patch to add a suspend button
<cody-somerville> jeromeg, We should see about tackling that issue for Intrepid.
<jeromeg> cody-somerville: yep
<kagou> mvo, your last patch for nautilus-share working great :) Thanks you
<mvo> kagou: great, thanks
<ogra_cmpc> amitk, ok, nm working again ... sound is MIA now :)
<Keybuk> http://svcs.cs.pdx.edu/gitweb?p=dolt.git
<Keybuk> ^ slangasek will explode with joy
<cody-somerville> jeromeg, As for now, you can just pull the info from /etc/lsb-release and slap it on the top of the paragraph :)
<asac> \sh: http://paste.ubuntu.com/6697/
<asac> i guess thats what you are seeing
<asac> ogra_cmpc: stgraber: Amaranth: maybe read this as well ^^
<ogra_cmpc> yeah
<ogra_cmpc> sounds familiar
<asac> so \sh probably had the plugin loaded
<asac> ogra_cmpc: which lock did you suspect?
<Riddell> evand: I've implemented the resize widget in kde_ui, see also 215131
<Riddell> bug 215131
<ubotu> Launchpad bug 215131 in ubiquity "resize widget changes for clarity" [Undecided,New] https://launchpad.net/bugs/215131
<evand> Riddell: fantastic!  Thanks a bunch.  Do you think it is ready for Hardy, or should it wait for Intrepid?
<\sh> asac, what plugin?
<\sh> ag...
<asac> \sh: from what i understand thats about the PA plugin for alsa
<asac> \sh: "Opened 3 months ago
<asac> oops
<asac> \sh: http://paste.ubuntu.com/6697/
<\sh> asac, when it means: pcm.!default { type pulse }
<\sh> ctl.!default { type pulse }
<\sh>  then yes
<ogra_cmpc> thats what we use in ltsp
<ogra_cmpc> (which works fine apparently)
<\sh> you need to, when you have apps which are not running with pulse natively
<\sh> (as I need to run, e.g. recordmydesktop ;))
<\sh> asac, will it be fixed, when removing this alsa plugin, or will flash+flashsupport still crash?
<asac> \sh: thats about how flash tries to work without flashsupport
<asac> apparently it works for some though ... which is interesting at least
<asac> \sh: flashsupport is rather inheritantly broken
<\sh> as I said, sound + linux is sometimes really crappy ;)
<asac> yeah, thats no news :)
<asac> for all of us i guess
<ogra_cmpc> asac, thats very likely HW specific
<ogra_cmpc> cards that can do dmix might provide a free channel for direct flash access aside of pulse
<\sh> ogra_cmpc, no..I think the HW problems are somewhat solved, the problems are the different sound architectures introduced over time
<ogra_cmpc> \sh, i meant the fact that it works for some
<\sh> ogra_cmpc,oh, ok :)
<ogra_cmpc> if alsa can do dmix because you have HW that can, it will be possible to run pulse and flash native on alsa alongside
<ogra_cmpc> sadly the cheap cards cant do dmix
<ogra_cmpc> and indeed cheap == majority :P
<ogra_cmpc> if all cards would have dmix support we could get rid of soundservers altogether
<\sh> well, I would say: integrated cards == majority...
<tjaalton> dmix == software mixing?
<tjaalton> at least that's how I've understood it..
 * asac ETOOMUCHSOUNDCONFUSION
<tjaalton> :)
<kagou> hey slangasek
<ogra_cmpc> http://alsa.opensrc.org/home/w/org/opensrc/alsa/index.php?title=DmixPlugin
<ogra_cmpc> asac, come on, its only three layers
<apachelogger_> hum
<\sh> ogra_cmpc, two layers too much :)
<apachelogger_> mvo: pling
<ogra_cmpc> \sh, fully agreed
<\sh> ogra_cmpc, let's fix it for intrepid ;)
<ogra_cmpc> even though you wont get around kernel vs userspace
<\sh> ogra_cmpc, of course...use the technique we used when we were young...two tins with a nylon fiber...to transmit soundwaves from a to b ;)
<Riddell> evand: yeah, it's mostly a copy of the gtk code
<ogra_cmpc> \sh, nowadays you need four cans and two strings ... stereo, you know ... :)
<evand> Riddell: ah, indeed.  Just pulled.  Mind if I subscribe ubuntu-release to the bug, or can you approve it?
<Riddell> evand: approve?
<Riddell> subscribe away
<evand> Riddell: It needs a UI freeze exception, no?
<asac> why does alsa need such cryptic things like asoundrc ... it should just work, shouldn't it?
<\sh> ogra_cmpc, oh damn...yes :)
<emgent> heya
<ogra_cmpc> asac, its should, yes ... asoundrc is a wrokaround and fine tuning tool
<asac> yeah ... still everywhere i look i see "use this or that asoundrc" ... and i don't understand any of those
<ogra_cmpc> but you have working sound ... you jusy introduce an unstable layer through adding pulse
<asac> i still don't get why we did that without checking for regressions in all major apps
<asac> i mean esd was not enabled by default in gutsy?
<\sh> asac, the problem starts, when you use e.g. a headset via usb...it's add a new soundcard actually...and then you need to point alsa to the correct soundcard to use
<\sh> asac, with pulse enabled it's a bit easier...now you click and point ;)
<ogra_cmpc> asac, i dont think anyone actually had assigned a task for sound
<ogra_cmpc> which is odd
<asac> ogra_cmpc: so where did this come from?
<ogra_cmpc> upstream
<ogra_cmpc> afaik gnome defaults to pulse
<ogra_cmpc> so we did the switch too
<asac> yes, but why is it enabled by default now?
<ogra_cmpc> it always was
<ogra_cmpc> login and logout sound depend on it
<asac> oh. so things have just improved that much that we now notice that somethign like firefox is broken with esd :)
<Ng> asac: do you know if it's deliberate that network manager doesn't do the equivalent of "iwconfig wlan0 ap off" when it switches from wireless to wired?
<asac> and thus weadded flashssupport )
<asac> Ng: the driver should do the same for wlan0 essid off
<ogra_cmpc> no
<ogra_cmpc> upstream added pulse
<asac> Ng: i think network manager does that
<ogra_cmpc> we followed
<Ng> asac: ah interesting, because it's not doing that here on 4965 and so after I switch to wired, the wireless chip is in a loop trying to get on the AP
<asac> ogra_cmpc: but before it was esd. and with esd everything was broken for me all the time
<asac> Ng: yeah. try the linux-backports module for iwl
<Ng> asac: I've tried lbm and lum
<Ng> hmm, "iwconfig wlan0 essid off" has associated me with a nearby Belkin AP
<Ng> I've definitely never associated with that before
<asac> Ng: thats a driver issue for sure
<asac> Ng: check if the module is set to "auto-associate" ... if there is such a parm at all
<asac> Ng: is the bheaviour any different if you turn of wireless completely in applet?
<Ng> no such parameter i can see for iwl4965
<Ng> I'll test shortly
<asac> Ng: parm:           disable_hw_scan:disable hardware scanning (default 0) (int)
<asac> no idea if that will make you loopy
<Ng> asac: I'd rather give up wired than have to specify all my wireless networks by hand ;)
<asac> Ng: he? does that really stop network manager from finding networks?
<Ng> asac: oh, I don't actually know, I was guessing based on the description
<asac> Ng: try. for me these HW_XXX things read more like: let the driver do some magic that nobody wants anyway ;)
<Ng> asac: hey, I want lots of magic! ;)
<Ng> but I will explore more options
<cody-somerville> slangasek, I got disconnected. Did you see my request?
<\sh> heading for home...cu later
<emgent> bye \sh
<afflux> mvo: bug 206866 is ubuntu-only since the crash was introduced in compiz' patch 037_fullscreen_stacking_fixes.patch. I heard you're packaging a new upstream release, could you please add a check to the call in plugins/move.c whether "w" is actually valid? This should fix this bug.
<ubotu> Launchpad bug 206866 in compiz "compiz.real crashed with SIGSEGV in updateWindowAttributes()" [Medium,Triaged] https://launchpad.net/bugs/206866
<mvo> afflux: let me have a look
<afflux> mvo: another thing is bug 209216, do you think we should set it to wontfix?
<ubotu> Launchpad bug 209216 in compiz "Attempted to unregister path (path[0] = org path[1] = freedesktop) which isn't registered" [Low,New] https://launchpad.net/bugs/209216
<asac> lamont: any idea why firefox 3 translation tarball didn't appear in http://people.ubuntu.com/~lamont/translations/ ... though its in .changes?
<asac> lamont: http://launchpadlibrarian.net/13136097/firefox-3.0_3.0~b5%2Bnobinonly-0ubuntu1_i386.changes
<lamont> asac: are translations still being pushed through my people account?
<lamont> and no, no clue without going to look.
<asac> lamont: according to carlos yes.
<asac> lamont: xulrunner-1.9 worked, firefox-3.0 didn't for whatever reason.
<carlos> lamont: as far as I know, yes
<lamont> ok
<asac> lamont: would be really cool to get this sorted before i upload the next update ( so we can test if everything works now)
<asac> lamont: or at least an idea why this isn't working ;)
<asac> pitti is unfortunately away this week
<ogra_cmpc> seb128, where does get gnome the info about screensize from ? my panels seem to think the screen is only 1024x768 while i have 1280x800 atm
<seb128> ogra_cmpc: it has no guessed value
<ogra_cmpc> weird
<seb128> ogra_cmpc: that usually happens when you have multiple screens
<seb128> ogra_cmpc: ie a projector connected to a laptop
<ogra_cmpc> hmm, i only have one LCD panel
<seb128> the panel will adapt to the projector resolution
<ogra_cmpc> lol
<seb128> what?
<ogra_cmpc> seb128, thanks, lots of hugs for you
<seb128> np ;-)
<ogra_cmpc> it hs an external output and obviously changing the resolution for that from 1024x768 to off fixes it
<ogra_cmpc> even though there is nothing connected to it ... weird
<infinity> carlos: Err, we've been uploading translation tarballs with package uploads for years now... Are you serious that you (or someone) still fetches stuff from lamont's home on rookery?
<carlos> infinity: we keep them for debugging purposes
<carlos> infinity: that's why we only keep last 9-10 days
<mjg59> slangasek: Hm. Can one fix to hotkey-setup be made?
<mjg59> slangasek: The init script should be "echo -n 7", not "echo -n 4"
<mjg59> slangasek: (breaks lid closing on various HP machines)
<laga> mjg59: "lid closing"? resulting in crashes?
<mjg59> Yes
<ogra> bitter
<laga> hum
<infinity> carlos: Kay, well I can look into why broke in this case, but I assume that the actual translation workflow (which is, I hope, done via the soyuz upload queue) has not been harmed by this?
<laga> i guess i should try that, because i'm getting these crashes. there's also a bug report somewhere.
<carlos> infinity: no, we had a bug there
<carlos> and we are trying to confirm that we got those translations
<carlos> infinity: if you did any change that may explain the lack of firefox tarball
<carlos> you don't need to do anything
<infinity> carlos: I can't explain the lack of tarball, no.  I'm going to look into it shortlyish.
<carlos> infinity: ok, thanks
<laga> mjg59: are you referring to this bug? https://bugs.launchpad.net/ubuntu/+source/acpid/+bug/157691/
<ubotu> Launchpad bug 157691 in acpid "Hardy/Gutsy crashes when the lid is closed on a HP 6710b, HP 6510b and HP 2510p" [Undecided,Confirmed]
<mjg59> Yeah, that'd be it
<mjg59> No clue why it's filed against acpid
<laga> no clue either. i had a workaround on my normal install, but it'd always freeze when testing LTSP. glad that it gets fixed, though :)
<Keybuk> ?!!
<Keybuk> half of vmware is missing from my disk
<mjg59> slangasek: #157691 has a debdiff attached now
<LaserJock> an important half? :-)
<Keybuk> LaserJock: the init script, and stuff in /etc
<ted1> A sign you should start using virtual manager :)
<Keybuk> ted1: is that that thing that requires processor features I don't have? :p
<ted1> Oh, it still runs (mostly) without those :)
<Keybuk> vmware works fine for me
<Keybuk> :)
<Keybuk> since I have a real, genuine, licence :p
<ted1> VMWare never worked for me, and virt-manager has worked well once soren sat down and made me actually read the documentation and follow ALL of the steps instead of the ones that looked like fun.
<LaserJock> I've had the most luck with vmware but I'd love to get something faster (as always)
<laga> ted1: what does virt-manager use? kvm?
<ted1> laga: Yeah, kvm.
<laga> i usually use virtualbox, but sometimes i have odd problems with it.. mostly pebkac, though ;)
<Riddell> evand: I think that's my ubiquity hacking for the day done, I made a small change to gtk_ui you might want to check for sanity
<Mithrandir> vmware is so tedious and proprietary.  It might become slightly more uninteresting if they get their modules into mainline. :-)
<slangasek> soren: I'm not sure I understand what's being proposed in 213991 - just getting libvirt to support passing an additional option to kvm?
<megabyte405> Wondering what the deal is with having some of the boost packages in universe, specifically libboost-regex-dev and libboost-date-time-dev
<soren> slangasek: Pretty much. To be perfectly honest, it's slightly more involved than that, but essentially you're right. There'll be a small change to virtinst as well to actually make use of it.
<evand> Riddell: looks ok, though I modified your fix for the crash when .disk/info doesn't exist slightly.
<Riddell> evand: ta
<kagou> slangasek, , i'v talk to mvo about Bug #212098
<ubotu> Launchpad bug 212098 in nautilus-share ""easy" file sharing not notifying about logout/login" [High,Confirmed] https://launchpad.net/bugs/212098
<ted1> megabyte405: No one has requested to move them?
<ted1> megabyte405: But, I'm pretty sure with the ASIO MIR approved on getting the Abiword one finalized, they'd come into main too as they're dependencies of ASIO
<evand> Riddell: thanks for the fixes, much appreciated.
<megabyte405> ted1: OK - we got a tentative "ok" on libasio-dev (Depends on abiword getting updated, which seems pretty likely at this point) which depends on those, does that mean tey'd come in?
<kagou> i don't know if we should patch nautilus-share or if we should patch samba+libpam-smbpass for nautification
<megabyte405> ted1: ah, great, you answered my question before I finished typing it :)
<ted1> megabyte405: Heh, yeah.  How are the Abiword packages coming along?
<megabyte405> ted1: great, I am about to upload a new one that has the tcp backend (read: libasio-dev) enabled, which should put them basically in release form
<LaserJock> megabyte405: what about that scrolling issue?
<megabyte405> Just put up the MIR for libwv-1.2 which I'm hoping should be straightforward, since it's just a library we stopped copying and pasting into the source tarball
<LaserJock> I get something quite similar in Firefox soemtimes
<megabyte405> LaserJock:  I am thinking that is abiword showing a bug in Ubuntu (uneducated guess is X), since Martin, another Abi dev, doesn't get it in Fedora, I didn't patch that part of the code in the package, and I don't see it in Windows either
<slangasek> cody-somerville: merged, and rebuild started
<megabyte405> LaserJock: and your comment adds credence to my suspicion.  For what it's worth, I had to scroll quite fast to trigger it - certainly annoying, but not a show stopper.
<slangasek> Keybuk: yes, I was tickled to see the dolt announcement :)
<slangasek> Keybuk: unfortunately, so far it only handles "compile", not "link", so the better part of the work is still to be done :)
<slangasek> kagou: that wasn't me, just the network bouncing my connection, but hello :)
<Nafallo> hehe
<kagou> :)
<Keybuk> slangasek: heh
<ogra> erm
<ogra> You might want to run `apt-get -f install' to correct these.
<ogra> The following packages have unmet dependencies:
<ogra>   udev: Conflicts: volumeid but 117-4ubuntu2 is installed
<ogra> E: Unmet dependencies. Try using -f.
 * ogra just tried to set up a pbuilder
<mjg59> slangasek: Did you see my poke?
<Keybuk> ogra: hmm, I saw that in my early testing
<Keybuk> if you were setting up a pbuilder, why would volumeid be installed?
<ogra> no idea
<ogra> i installed pbuilder and ran sudo pbuilder create
<ogra> no fancy settings or so
<Keybuk> it's Priority: important
<Keybuk> and Task: minimal
<Keybuk> I wonder whether that means debootstrap drags it in?
<ogra> that would be it
<slangasek> mjg59: patch in #157691> this is definitely correct for all intel/ati/radeon systems?
<soren> If you don't pass --variant=buildd to debootstrap, yes, it grabs Priority: important.
<slangasek> soren: yeah, the libvirt change looks ok then
<mjg59> slangasek: It's what I actually meant to do the first time, I misread the spec
 * ogra wonders how to configure this funny touchpad on teh new lappie  
<soren> slangasek: Thanks very much.
<Keybuk> ogra: should fix itself next time the publisher thuds then
<megabyte405> Is Martin Pitt here?
<ogra> Keybuk, i have Ã¼lenty other pbuilders so i personally dont mind ...
<slangasek> mjg59: oh, well, if it's the /spec/, then no possible harm can come from following it, right? ;)
<mjg59> megabyte405: He's at a conference today
<ogra> megabyte405, he's at a conference
<mjg59> slangasek: Oh, potential for failure and misery, but in principle it's the safest of the options
<megabyte405> ah - well he just commented on an MIR we need for abiword :)
<slangasek> mjg59: ok, let's get it in and keep an eye out for regressions
<mjg59> slangasek: If you could upload that, that would be great
<slangasek> right, grabbing
<ogra> geez vbox on this new laptop is faster than native ubuntu on my old one
<slangasek> mjg59: uploaded
<mjg59> slangasek: Thanks!
<\sh> asac, well, I could reproduce the crash of flash this morning on the i386 desktop, but I tried it now with amd64 .. and this works like a charm, using pulse
<infinity> asac / carlos : translation mirror stuff fixed-ish.  Should be able to find firefox-3.0 in 20080410 now.
<carlos> infinity: cool, thanks
<infinity> carlos: So, to be clear, that's not used by rosetta anywhere, right?  You just use it as a backup/verification source?
<infinity> carlos: Actual imports are done via soyuz uploads, I hope...?
<carlos> infinity: right
<carlos> infinity: yeah
<infinity> carlos: Kay.  Is there still value in having the backup/verification?
<carlos> well, in this case was useful ;-)
<infinity> carlos: If there is, we should get it moved to ~ubuntu-archive, so poor lamont can stop owning it. :)
<carlos> but I think that I'm the only one using it
<infinity> carlos: Well, I'm happy to either ask the distro guys to take ownership of it in ~ubuntu-archive, or kill it off completely, I just don't want lamont maintaining it for another 3 years. :)
<lamont> infinity: I don't maintain it. :-)
<\sh> infinity, rock...thx for the wine p-a-s entry...looks like that YokoZar and I will get more bug reports for wine on lpia now :)
<carlos> infinity: let me check with jtv and danilo and I will tell you what to do
<infinity> lamont: That was kinda my point. :)
<lamont> heh
<lamont> it's currently maintained through the process of "malevolent neglect"
<Nafallo> haha
<Nafallo> hello everyone I didn't say hi to :-)
<cody-somerville> slangasek, It appears the cds are still obese!
* slangasek changed the topic of #ubuntu-devel to: Archive: frozen like a penguin paradise | Ubuntu 8.04 LTS Beta released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<cody-somerville> Ah, the alternative cds are fine but the live cds are not.
<slangasek> cody-somerville: due to the same package set as before?  I may have failed to account for propagation delays
<cody-somerville> slangasek, let me check
<cody-somerville> slangasek, right. No change between manifests.
<xhaker> mjg59: Help me out. I got /sys/devices/virtual/backlight/acpi_video{0,1}
<xhaker> mjg59: i guess there was supposed to be only one there. I am investigating why my dell changes brightness 2 steps at a time
<bobbo> Should fixes for bugs like Bug #184084 be left to Intrepid seeing as we are in Final Freeze now?
<ubotu> Launchpad bug 184084 in checky "Extension description mentions Iceweasel/Icedove/Iceape" [Undecided,Confirmed] https://launchpad.net/bugs/184084
<lamont> jdstrand/kees: Apr 10 08:15:39 mix kernel: [36454.520112] audit(1207836939.319:6): type=1503 operation="inode_permission" requested_mask="::rw" denied_mask="::rw" name="/dev/tty" pid=3491 profile="/usr/sbin/cupsd" namespace="default"
<lamont> oh, wait.  my bad.
<lamont> I think that means it's not asking for mmap anymore
<keescook> lamont: righto!  it just wants to spew to the tty.
<lamont> denied
 * lamont looks at the actual logfile to make sure that was all
<slytherin> hi, is the 'gnome panel freezes when clock applet is clicked' occurring again for anyone?
<slangasek> lamont: hey, has anyone prodded you about helping to get more info for bug #81242?
<ubotu> Launchpad bug 81242 in postfix "postfix-ldap is linked against gnuTLS" [Medium,Triaged] https://launchpad.net/bugs/81242
<lamont> keescook: yep.
<lamont> slangasek: I've been waiting for someone to tell me what to do with it...
<lamont> I just link against libldap2
<slangasek> lamont: how about what I wrote in the last comment? :)
<lamont> happy to switch to another lib...
<lamont> (since turning off ldap support would be more likely to get me shot...)
<asac> infinity: thanks a lot!
<slangasek> lamont: i.e., "please give me stderr from this failing command"
<slangasek> lamont: actually, a) you link against libldap-2.4-2, b) there is no other lib kthx
<slangasek> having postfix be the only thing in main linking to a different LDAP implementation would be more likely to get you shot by *me* ;)
<lamont> heh
<lamont> the comment from upstream is more upstream bitching about the exit()s in the code existing at all - the code should really report an error back to the caller.
<slangasek> yes
<lamont> and, as you say, there are very few exit() calls in the library today, so triggering such a failure could be problematic
<slangasek> but I need to know /which/ one postfix is triggering, because I don't have time to convert all the uses of exit() before release ... :)
<lamont> depending on the user, I expect any of those fatal logs could be it...
<lamont> that is, I rather doubt that there is a test case, and that upstream would say "all"
 * Caesar wishes Adobe would learn something about release mangement and versioning for their Linux Flash plugin
<lamont> OTOH, what about making gnutls and ssl just be friends?
<lamont> gnutls and ldap.
<lamont> sort of like making it so that db4.2 and db4.3 can be linked in the same app.....
<slangasek> um
<slangasek> this is *not* an issue with gnutls and ssl being loaded at the same time
<slangasek> or if it is, we need a test case to show why
<slangasek> other apps are able to get by with both loaded; c.f. apache
<slangasek> it's definitely not a symbol conflict error - it may be a resource contention error over entropy, but in that case I still need to see the stderr to figure out where the contention is happening
<Riddell> evand: really my last commit to ubiquity today, might be time to ask slangasek about that map patch you had earlier and upload :)
<evand> Riddell: thanks, and whoops.  I hadn't noticed that the change needed to be made in the KDE ui.  I actually have one last thing I'd like to try to get in :/, but I should be done with that within the hour.
<soren> I've been a bit disconnected (being at the LF summit, traveling, etc.)... What's the current policy for uploading? Do we ask permission for even critical bugfixes or how does it work right now?
<mjg59> xhaker: The patch to fix that breaks other things. I'll investigate it at some point, but it's likely to require major restucturing
<slangasek> soren: 1) read ubuntu-devel-announce, 2) profit? :)
<xhaker> mjg59: ok, so it is known to behave like that. thanks.
<soren> slangasek: Reading e-mail over this sorry excuse for an internet connection makes me cry, but ok, I'll see what I can squeeze throguh. :)
<slangasek> soren: maybe just https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-April/ then? :)
<soren> That's what I'm doing :)
<soren> So I need to "get in touch with ubuntu-release" or do I need to milestone a bug?
<slangasek> in regards to what?
<slangasek> you don't need to do either of those things to be able to upload
<soren> True.
<slangasek> though presumably if you're uploading, the bug should be milestoned in its own right?
<soren> That sounds reasonable. :)
<Keybuk> soren: I find that bribing slangasek helps
<Keybuk> "If you approve this upload, This milestoned bug will be fixed"
<soren> Does it count if I have to milestone a bug first?
<soren> :)
 * slangasek hehs
<Keybuk> I think that vorlon knows about "Activity Log"
<slangasek> yes...:)
<soren> I was afraid that might be the case.
<Keybuk> slangasek: I will obviously have a pending udev upload soon
<Keybuk> now that I've got vmware working
<Keybuk> and that I've beaten evand for various issues, I can test my fix properly
<slangasek> Keybuk: great! :)
 * evand rubs the lumps on his head from the abuse.
<Keybuk> (the 117-5 fixed just about everything else, I decided not to wait since volumeid had to go)
<Keybuk> evand: you love it
<evand> hahah
<soren> slangasek: In this particular case, I have an upload that fixes some things, that *should* have been reported and milestoned, but weren't. You want me to file the bug first to have some sort of virtual paper trail?
<slangasek> soren: if the bug isn't filed yet, don't go to the extra effort until the release team has had a chance to look at it in the queue
<slangasek> soren: if we need a paperwork trail we can come back to you
<soren> slangasek: Cool. That's what I wanted to know, I suppose. Thanks.
<Griffon26> How long would it approximately take for Ubuntu to have the latest versions of libxml2 & libxslt that were released this week available somewhere (like universe maybe)? I'm a Gnome Planner developer and I am wondering if making those versions required deps would cause much delay in availability of Planner on Ubuntu (because of testing and such).
<Keybuk> Griffon26: at this point, we're pretty much entirely frozen for our release
<Keybuk> they'll be in 8.10 for sure
<jcastro> Griffon26: until then you might consider having a team PPA for Planner
 * Griffon26 grabs a dictionary
<jcastro> Griffon26: basically a seperate repository. I can help you go through it if you want.
<Griffon26> I'm an upstream dev. I don't know much about Ubuntu =)
<Griffon26> I was just looking for a ballpark figure. I'm not running Ubuntu myself.
<jcastro> Griffon26: It's my job to help upstream devs like yourself get squared away on ubuntu
<jcastro> Griffon26: I'm on my way to lugradio live tomorrow but if you send me a mail (jorge@ubuntu.com) I can answer any questions you might have about ubuntu. I can give you the quick version of everything you might need to know about ubuntu
<Keybuk> slangasek: if I smack a package upload through the queue myself, is that naughty? :p
<slangasek> Keybuk: probably :)
<Keybuk> ie. readahead-list
<Griffon26> jcastro: I may only need an answer to the following question, otherwise I'll send you mail. Is there a reasonably easy way for users to get upgrades to packages in between releases?
<jcastro> Griffon26: a PPA would be the best bet (personal package archive), otherwise between releases you have -updates which is for security and major bugfixes, and -backports.
<Griffon26> I see
<laga> Griffon26: does the user have to build something from source if he wants to use the new version of planner?
<jcastro> Griffon26: the downside to PPAs is users need to know about them and add them manually.
<Griffon26> laga: I'm assuming they will until you have a binary version of the release that I'll do this weekend.
<keescook> well, -security is for security.  :P
<jdstrand> -updates will have security and SRU (stable release updates)
<jdstrand> hi keescook!
<keescook> we confused ourselves.  ;)
<LaserJock> -updates doesn't have security
 * keescook hugs jdstrand
<LaserJock> -security has security
<laga> Griffon26: well, that binary version will happen in 8.10 then which will also have the dependencies. so i guess your new version of planner will also have to go to a PPA
<Griffon26> laga: it's just that if I dep on the new libxml2/libxslt versions, people who build from source on Ubuntu may suddenly need to upgrade libxml2/libxslt as well
<jdstrand> -updates does have security, whenever there is a sync
<laga> Griffon26: unless people build it themselves
<jdstrand> LaserJock: ^
<jcastro> Griffon26: yeah, you can also put those deps in the same PPA if you want.
<ogra> mjg59, do you happen to know anything about "IDEACO IDC 6680" touchscreens ?
<LaserJock> jdstrand: well, that's kinda iffy
<jdstrand> LaserJock: we ask for a sync of -security to -updates for large packages like the kernel, firefox, etc
<jdstrand> LaserJock: this is to reduce the load on security.ubuntu.com
<laga> Griffon26: i understand the problem.. i guess the PPA is the best thing you can do. i assume that libxml2 and libxslt are rather important packages, so building them from source might not be a good idea
<LaserJock> jdstrand: so there are exceptions ;-)
<jdstrand> LaserJock: IIRC, the admins will periodically sync -security to -updates without us explicitly requesting it also
<mjg59> ogra: Nope
<mjg59> ogra: What does it present as?
<laga> keescook: -security also gets new hardware support sometimes ;)
<ogra> mjg59, simple input event device, it even works just not in sync with my finger or the stylus
<jdstrand> this just happened recently actually-- I requested a sync for firefox, but they just sync'd it all
<ogra>  /dev/input/event9 atm
<LaserJock> jdstrand: all of what?
<Griffon26> jcastro: laga: I think I have a good idea of what's possible now. I'll recommend on our list that whoever builds it in Ubuntu also publish a PPA with libxml2/libxslt.
<jdstrand> whatever we uploaded to -security that wasn't in -updates yet (eg mysql)
<jcastro> Griffon26: ideally, you'd want someone who us a planner enthusiast who is willing to maintain your package in ubuntu, then he/she goes through our developer process.
<jcastro> but that is rare. :D
<jdstrand> LaserJock: rmadison mysql-server-5.0 | grep gutsy
<Griffon26> yeah, people building Planner from source are rare. Somehow the cross-section between project managers and software engineers is not that large. I wonder why ;-)
<jdstrand> LaserJock: I didn't ask for mysql to be sync'd, yet, there it is
<jdstrand> :)
<jcastro> Griffon26: if someone is interested send them my way and I'll go through the process with them
<Griffon26> jcastro: will do. Thanks for your help. Both of you.
<LaserJock> jdstrand: odd, I don't think that's policy but they probably had a reason
<jdstrand> LaserJock: pretty sure it all gets back to the load on security.u.c
<LaserJock> sure, but that would be only exceptions to the rul, not the rul
<jdstrand> this is something that has probably evolved over time, I don't make those decisions ;)
<LaserJock> in any case, security goes to -security and SRUs go to -updates
<LaserJock> whatever the archive admins do aftward I don't much care :-)
<keescook> slangasek: do universe things ever make it into the release notes?  it might be nice to mention the selinux work.
<jcastro> keescook: I think a "tour of the universe" might be useful come to think of it
<jdstrand> jcastro: I like the sound of that
<jdstrand> "tour of the universe"
<jcastro> http://fridge.ubuntu.com/node/51
<jcastro> that was pre-dapper when I did that.
<jdstrand> cool
<jcastro> I'll ping corey and/or mgunes, see if they're interested in doing another tour
<slangasek> right, if we have a "tour" type page, that would be suitable; obviously selinux wouldn't fall under errata though, and I don't imagine it would go in the press release
<keescook> slangasek: yeah, I'd like to find a place for it since it's been a long-standing gripe ("but Ubuntu can't use SELinux") that's fixed now.
<jdstrand> maybe if the release notes linked to the tour page?
<jcastro> burgundavia once did a universe tour, one thing a day for a week, which is also a pretty good idea to get sustained interest
<_MMA_> jcastro: mgunes has been MIA. He's had some personal issues. An email sould get a responce. Though it might be delayed.
<Keybuk> slangasek: ok to accept readahead-list?  ok, great!
<slangasek> Keybuk: bwuh?  has it even been uploaded yet?
<Keybuk> slangasek: yes :-)
<slangasek> I haven't seen it in the unapproved queue...
<Keybuk> it didn't spend very long there <g>
<slangasek> heh
<Nafallo> haha
<slangasek> bryce: is bug #137234 covered by your projector work?
<ubotu> Launchpad bug 137234 in xserver-xorg-video-intel "[gutsy] Second display not enabled with "intel" video driver" [High,Confirmed] https://launchpad.net/bugs/137234
<ted1> Is there a place to get an old debian package?
<ted1> It doesn't seem to be in the pool anymore.
<bryce> slangasek: btw, there is a sync request that's been in for -amd, that didn't make it in before the cut off (we've been testing the fix, but unfortunately whomever does syncs didn't get to it in time).
<slangasek> bryce: I'll have a look at all those goodies today/tomorrow
<bryce> slangasek: cool thanks.  It apparently is very strongly desired by the LTSP guys, and upstream.
<bryce> (and ogra for edubuntu)
<slangasek> ah, that one :)
<calc> hello
 * slangasek waves to calc
<slangasek> bryce: so I didn't see that you answered wrt bug #137234?
<ubotu> Launchpad bug 137234 in xserver-xorg-video-intel "[gutsy] Second display not enabled with "intel" video driver" [High,Confirmed] https://launchpad.net/bugs/137234
<bryce> oh sorry, looking
<ogra> bryce, btw, i have a new laptop with intel card ... apparently the external output ws enabled by default which caused gnome to think it is on a 1024x768 display
<ogra> (screen size is 1280x800, i had a floating bottom panel)
<bryce> slangasek: I'll reply - that bug seems to be a mix of S-Video not working, plus VGA-projector troubles; sounds like things have improved in Hardy for him, but still having some trouble.
<slangasek> bryce: ok, thanks
<bryce> slangasek: a lot has improved in the couple months since the last comment, so it's quite possible the issue got fixed with one of our patches; I've asked him to retest
<slangasek> bryce: ok.  it came to my attention because he brought it up (on u-d-discuss) in response to my call for bugs that should be critical; but yes, this only proves that he /thinks/ the bug is still there :)
<bryce> people find X crashes/corruption so scary that I hear that a lot
<bryce> of course, they also extrapolate that the crash they see must affect all Ubuntu users (sometimes they're right, but usually not)
<Nafallo> hehe. I wonder why :-P
<bryce> then I ask for a ''full backtrace'' and I think that completely pushes them over the edge of sanity
<Nafallo> :-)
<slangasek> well, yes, this particular bug submitter also believes that "the most likely environment to use ubuntu is academia" (?) :)
<Nafallo> slangasek: :-)
<bryce> slangasek: btw the sync request is bug #211385
<ubotu> Launchpad bug 211385 in xserver-xorg-video-amd "please sync xserver-xorg-video-geode (main) from Debian (main)" [Undecided,New] https://launchpad.net/bugs/211385
<calc> i'm so tired, i'm going to be dead tomorrow due to this crappy jetlag :(
<Nafallo> calc: changed to summertime recently? :-)
<calc> Nafallo: change from -5 to +1 today
<calc> er -5 to +2 maybe
<calc> 7 hours difference
<Nafallo> calc: where are you? :-)
<calc> Prague
<calc> I was in Houston yesterday
<Nafallo> sounds more like +2 indeed :-)
<calc> got on the plane at Wed 3:30PM got to the hotel at Thu 12:00PM, heh
<Nafallo> us Londoners stole +1 ;-)
<calc> ah yea
<Nafallo> :-)
<mario_limonciell> ArneGoetje, ping.  I was checking to see if you were aware of breakage in terms of language packs?
<mario_limonciell> ArneGoetje, see http://cdimages.ubuntu.com/dvd/20080410/report.html or http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/hardy/ubuntu-dvd/20080410/livecd-20080410-i386.out for information
<mario_limonciell> slangasek, it looks like the issue is actually that openoffice.org-hyphenation-en-us got moved to universe for some reason or another?
<mario_limonciell> slangasek, were you aware of whether that was intended?
<slangasek> mario_limonciell: it wasn't moved, it was never /in/ main
<slangasek> we've worked this out, the dependency has been moved back to openoffice.org-hyphenation
<mario_limonciell> in the very near past you worked it out?  that dvd was just queued a few hours ago
<slangasek> yes
<ted1> So, seriously, is there no Debian archive somewhere?
<slangasek> ted1: sounds like you're looking for snapshot.debian.net?
<mario_limonciell> slangasek, so should all pending language issues be fixed at this point if another DVD is made (we've been trying to get a good one the last few days)
<ted1> slangasek: Yes, yes I am.  Thank you.
<ogra> hmm, f-spot segfaults on a fresh install
<Nafallo> ugh
<slangasek> mario_limonciell: looks like it, yes
<slangasek> mario_limonciell: want me to fire one off?
<ogra> http://paste.ubuntu.com/6719/
<Nafallo> ogra: I get a SIGSEGV after I Quit via the menu :-)
<ogra> with f-spot ?
<Nafallo> ogra: yes. not fresh install though.
<mario_limonciell> slangasek, yeah if you can
<Nafallo> ogra: upgraded gutsy.
<ogra> it looks like that are two errors ...
<Nafallo> ogra: at least :-)
<slangasek> mario_limonciell: running a livefs build only
<ogra> one is a missing sqlite db and the other is that it cant connect to dbus
<mario_limonciell> slangasek, yeah probably a good idea (waste of space to make dvds when that livefs is what keeps failing)
<stratus> ogra: the missing sqlite db is well known issue
<ogra> stratus, any idea if thats fixed in debian ?
<slangasek> mario_limonciell: can I just leave it running and wait for feedback from you if there are still failures?
<mario_limonciell> yeah
<mario_limonciell> i'll check on it in an hour or two
<slangasek> (or if you want me to follow through with an ISO build)
<slangasek> hmm, takes longer than an hour to finish, doesn't it? :)
<slangasek> if it succeeds anyway
<stratus> ogra: see 81905 in lp
<mario_limonciell> well it will fail within an hour at least :)
<slangasek> ok :)
<stratus> ogra: it seems that f-spot have no idea where the sqlite db is and guesses that the table tags is missing
<stratus> ogra: did f-spot setup .gnome2/f-spot/photos.db ?
<ogra> yup
<stratus> is it a really fresh install, right? I assume you didn't copy your home directory there.
<ogra> right
<cellofellow> !bug 206149
<ubotu> Launchpad bug 206149 in ubuntu "The system doesn't recognize my Realtek RTL8185 wireless card." [Undecided,New] https://launchpad.net/bugs/206149
<stratus> then sqlite .gnome2/f-spot/photos.db and check if the missing table is there
<ogra> and -b ./ solves it
<stratus> oh cool
<stratus> probably a bug during the build, f-spot has no base dir set or a wrong one
<ogra> yeah
<ogra> smells like that
<ogra> i still have a segfault on exit though
<ogra> but it starts and runs fine
<stratus> oic
<cellofellow> any idea what's up with that bug?
<stratus> at least no d-bus related bug too
<LaserJock> slangasek: is it ok if I upload a translation update of edubuntu-docs?
<slangasek> LaserJock: yes
<LaserJock> thanks
<Keybuk> slangasek: ping?
<slangasek> Keybuk: pong
<Keybuk> slangasek: proposed udev patch
<Keybuk> http://people.ubuntu.com/~scott/fix-persistent-net.pl.txt
<Keybuk> well, patch/er/
<tjaalton> slangasek: uploaded new lrm for the latest ABI. it also fixed faulty dh_strip which was supposed to skip stripping nvidia, but didn't since the versioning was changed
<slangasek> Keybuk: looks sane to me... :)
<slangasek> tjaalton: thanks, will process it
<tjaalton> slangasek: thanks
<Keybuk> slangasek: I've tested it in every crazy situation I can replicate
<slangasek> Keybuk: let's go for it then :)
<slangasek> tjaalton: I note there's an open bug report for the nvidia stripping thing, and it's not mentioned in the changelog, so please close by hand
<Keybuk> slangasek: uploaded
<tjaalton> slangasek: right, will do
#ubuntu-devel 2008-04-11
<superm1> slangasek, looks to be passing this time around
<superm1> its at the part where it's mastering it into the squashfs now
<Keybuk> slangasek: This upload awaits approval by a distro manager
<ogra> slangasek, http://paste.ubuntu.com/6725/ ok to upload ?
<slangasek> Keybuk: I'll get back around to the queue in an hour or so :)
<Keybuk> I can approve it if you're too busy ;)
<slangasek> ogra: sure, go ahead
<ogra> thanks
<keescook> slangasek: rsync security fix uploaded to hardy main.
<emgent> heya keescook :)
<keescook> hiya emgent
<slangasek> Keybuk: hrm, not sure why the version number checks in udev.{preinst,postrm} have been bumped...
<Keybuk> slangasek: consistency
<Keybuk> they match a block in postinst
<slangasek> well, ok... :)
<superm1> slangasek, okay yeah it just finished the livefs
<slangasek> superm1: ok, everything good for me to do an ISO build then?
<superm1> slangasek, i'd think so :)
<megabyte405> could someone please review the updates to bug #202174 ?  I think we're just about there - the actual package itself is done, now it's just the "paperwork"
<ubotu> Launchpad bug 202174 in abiword "Please update to version 2.6" [Medium,New] https://launchpad.net/bugs/202174
<megabyte405> Thanks!
<ogra> oh, and the debdiff is only 30M ...
<ogra> why the heck did he attach that ?
<ted1> Because it's "required"
<ogra> heh
<ted1> That's what a FFe says.
<slangasek> no, it doesn't.
<ogra> between two differnt upstream versions ?
<ted1> No, wait, for sponsorship that's what you're supposed to have, right?
<ogra> that would be pretty mad
<ted1> Yeah, I think it should only be between the packaging.  But, it's funny none the less :)
<slangasek> for sponsorship, possibly; but the rules have changed a couple times over the past months
<ted1> BTW, if someone could sponsor the xscreensaver update that'd be nice :)
<ogra> ted1, if you say its fine i'll upload
<ted1> Yeah, it looks good.  There's a bunch of things that are syncing with Debian, but they're fine.
<ted1> I looked at 5.05, but there's a bunch of changes :(
<ted1> (upstream)
<ted1> Unless we have a reason, I think we'll have to wait 'till Ibex for that one.
<ted1> Or maybe 8.04.1
<ted1> What are the "rules" going to be for that release?
<slangasek> "fix bugs, don't introduce them" ;)
<ogra> :)
<ted1> Oh, that's no fun.
<ted1> The Abiword package doesn't have a launchpad integration patch... is that a big deal?
<slangasek> did it before the update?
<ted1> 30MB ago?
<slangasek> yes :)
<ogra> the abiword-gnome package should bring it in
<slangasek> should bring what in?
<ogra> launchpad integration
<ted1> slangasek: Nope, it doesn't seem to.  Even with abiword-gnome.
<ted1> Hmm, they have a "Check for updates" item on their menus.
<ted1> Goes to a webpage to check, that's funny.  I guess for Windows users.
<ogra> oh shudder
<ogra> since when does xss need quilt ?
<ogra> even for building a source package ... grmpf
<ted1> Heh, so on the styles dialog, the sample text is "What Hath God Wrought"
<slangasek> ted1: then I guess it's not a big deal. :)
<ogra> ted1, uploaded
<ted1> Okay, playing around I can't find anything wrong with it.  I do like Abiword.
<ted1> ogra: Thank you.
<zul> slangasek: http://pastebin.com/d7a75c694
<slangasek> zul: er, I don't think you've really fixed bug #208300 there, since you're still numbering from zero? :)
<ubotu> Launchpad bug 208300 in xen-3.2 "xendomains init script has error" [Undecided,New] https://launchpad.net/bugs/208300
<slangasek> zul: also, what's with the undocumented changes to xend.init?
<zul> slangasek: erp...ill document them
<slangasek> ted1: renumbering patches makes baby Jesus cry
<zul> slangasek: http://pastebin.com/d44650f37
<slangasek> zul: looks good. I assume you've verified that the first "field" can never have embedded spaces?
<zul> slangasek: taken directly from debian but yes
<slangasek> ok
<slangasek> go for it then :)
<zul> thanks that hopefully will make people happy
<YokoZar> Do emails to ubuntu-devel need to be signed?
<TheMuso> YokoZar: no.
<emgent> good night people
<Hobbsee> mmm...penguin paradise...
<tedg> slangasek: Yes, I agree.  I don't know why the Debian folks chose the same numbers and then merged in ours.  It didn't seem worth redoing and having sync issues later.
<tedg> slangasek: GSS merges have been hell.
<tedg> slangasek: Sorry, xscreensaver.
<keescook> slangasek: any news on getting 203262 fixed?  seems like quite an eye-sore even if it is harmless.
<slangasek> keescook: er?  not sure how I would have any news on it, the bug isn't milestoned and I'm not otherwise subscribed - did you send me some ping on IRC about this that I missed?
<keescook> errr?  Weird, I swear I had milestoned it.  sorry then.
<slangasek> k then :)
<keescook> I'm milestoned it now.  I had pinged cr3 about it before but never heard back.
<slangasek> ok
<slangasek> bryce: hrm, why did bug #211385 not get ubuntu-archive or ubuntu-release subscribed to it... I only noticed by accident that it was in the list of bugs I'm directly subscribed to
<ubotu> Launchpad bug 211385 in xserver-xorg-video-amd "please sync xserver-xorg-video-geode (main) from Debian (main)" [Undecided,New] https://launchpad.net/bugs/211385
<slangasek> bryce: hrm, this sync request is making me uneasy; we have to rename the driver package to get the bugfixes? :/
<kagou> Good morning
<dholbach> good morning
<kagou> hey dholbach
<dholbach> hi kagou
<kagou> dholbach, seem's that Hardy will be a great release.
<kagou> everyone is working hard on it. thanks to all
<dholbach> :-)
<slangasek> with the most evil samba integration ever, muhahaha
<StevenK> Can you quote that in the release notes?
<kagou> slangasek, indeed :D
<slangasek> StevenK: hmmmno.
<kagou> so slangasek have you had time to see the bug for nautilus-share (notification for logout/login after samba/libpam-smbpass installation) ?
<Whoopie> Keybuk: Hi, looking at the latest libpam-thinfinger package, there's a typo in the pam-thinkfinger-enable script. It should be pam_thinkfinger.so, not pam_fingerprint.so
<StevenK> slangasek: Awwww
<warp10> Good morning
<slangasek> kagou: well, I've seen it, but it's really in the hands of the desktop team
<kagou> morning warp10
<warp10> hey kagou
<kagou> slangasek, so should I assign Bug #212098 to ubuntu-desktop
<ubotu> Launchpad bug 212098 in nautilus-share ""easy" file sharing not notifying about logout/login" [High,Confirmed] https://launchpad.net/bugs/212098
<slangasek> kagou: assigned to desktop-bugs now; I hadn't seen that it wasn't assigned yet
<kagou> no it wasn't
<Chipzz> Whoopie: file a bug-report. things tend to get lost on irc ;)
<superm1> slangasek, would you mind releasing mythbuntu-control-centre?  i was just tracking these two bugs all night and finally got them verified so i uploaded it.
<slangasek> releasing it from where?
<superm1> it said that a release manager had to let it through
<slangasek> superm1: mm, currently the only related package I see in the queue is mythtv, not mythbuntu-control-centre
<superm1> interesting.  i just uploaded it.
<superm1> try refresh now that :20 hit?
<slangasek> superm1: right, now it's there :)
<slangasek> superm1: how about this mythtv upload?  Is that supposed to go through as well?
<superm1> slangasek, yeah, i didn't want to pester on that though, it's not a very high priority right this minute, whereas the mythbuntu-control-centre prevents a lot of people from even launching the app
<slangasek> well, I'm looking at the queue, I might as well kick things out of it :)
<superm1> then yes, anything i've uploaded (mythtv, mcc, xmltv) clear away :)
<tjaalton> superm1: what is atieventsd supposed to do? seems to only cause a lot of bugreports..
<superm1> tjaalton, it handles display switching
<StevenK> It's another clock applet
<superm1> when you unplug and plug in an external monitor
 * StevenK glances at slangasek 
<slangasek> dholbach: looks like you sponsored bug #193256?  has this been acked by motu-release for a freeze exception?
<superm1> (or its supposed to)
<ubotu> Launchpad bug 193256 in glipper "glipper background is not transparent" [Low,Confirmed] https://launchpad.net/bugs/193256
<slangasek> StevenK: TICK TOCK TICK TOCK
<tjaalton> superm1: ok, great.. bug 194249 has 20 dupes now, and I guess there'll be more :)
<ubotu> Launchpad bug 194249 in linux-restricted-modules-2.6.24 "[fglrx] atieventsd crashed with SIGSEGV in _XSend()" [Critical,Triaged] https://launchpad.net/bugs/194249
<StevenK> slangasek: Hah
<superm1> tjaalton, well that's definitely something that can be brought up as a top priority issue in the call w/ AMD then
<superm1> tjaalton, make sure bryce knows that is a top one
<tjaalton> superm1: he should know about this one :)
<dholbach> slangasek: it's a small bug fix?
<dholbach> one line even
<dholbach> or do they need to get approved by motu release too?
<dholbach> ok... look like we need to
<superm1> good mornin dholbach
<dholbach> hi superm1
<superm1> dholbach, re that FFe from tseliot, does everyone in motu-release have to ack it, or is the 2 in there now sufficient?
<slangasek> dholbach: yes, this way motu-release approve the changes so ubuntu-archive don't have to think about it before pushing the button :)
<dholbach> superm1: 2 should be sufficient
<superm1> dholbach, were you going to upload it then, or was there anything else you were holding off on ?
<\sh> dholbach, all fixes, it doesn't matter how small they are, need an ack of m-r
<\sh> dholbach, at least, this is what I understand from last mail to u-m ml
<dholbach> \sh: ok
<dholbach> superm1: waiting for mvo or bryce to say "OK, I'll help Alberto with getting stuff in, etc"
<munckfish> Hi, I'm trying to get a package for PS3 updated before release. this is my first time thru the process and I'm not a core or motu ...
<munckfish> I have a fix prepared and have subscribed ubuntu-main-sponsors
<superm1> dholbach, ah okay.
<superm1> dholbach, just wanted to make sure his effort here doesn't end up lost with how long he's been at this
<dholbach> superm1: yeah
<dholbach> slangasek: TheMuso is OK with glipper upload
<superm1> dholbach, i'd expect though, nothing would be needed additionally out of core-dev for it
<superm1> dholbach, given it would live in universe
<munckfish> do I need to wait for the sponsor to finish review before following the freeze exception process?
<superm1> and of the normal motu folks should be able to help with any necessary sru/backports
<dholbach> superm1: I just wanted SOMEBODY :)
<TheMuso> 5~/c
<munckfish> Got to go to work, bye!
<tjaalton> slangasek: the amd -> geode rename was explained in the changelog, and it's like i810/intel in the sense that geode is the one that is supported from now on
<mvo> Riddell: what do you think about #205079 ? only few duplicates so far, but it might turn out to be a pretty nasty one. it seems it only affects kubuntu with nvidia-glx-new
<cjwatson> Riddell: it's deliberate that default mountpoints have gone away, but odd that default types aren't showing; may be an obvious consequence of the first though, so I'll have a look
<cjwatson> Riddell: please set up a CIA client for your ubiquity commits as documented on http://wiki.ubuntu.com/InstallerDevelopment
<cjwatson> laga: germinate is crashing because you forgot to put an entry for common in STRUCTURE
<Whoopie> Keybuk: opened a ticket for the pam-thinkfinger script. it's bug report 215543
<mvo> Riddell: let me know what you think and if we should milestone it
<cjwatson> LaserJock: having everything from -security synced to -updates where possible *is* deliberate policy, and mysql-server-5.0 was not an exception. See https://wiki.ubuntu.com/ArchiveAdministration#head-6f9ab205555c4f923ea4f111d779b3e273af3a95
<Keybuk> Whoopie: uploaded fix
<Keybuk> cjwatson: thinkfinger pending approval
<cjwatson> slangasek crashed?
<cjwatson> Riddell: committed another KDE translation fix to ubiquity, I think it's obvious but perhaps worth double-checking at this point
<cjwatson> err. by which I mean 'I've typed debcommit but it hasn't come back yet'
<Keybuk> cjwatson: idle 1h22
<cjwatson> k
<cjwatson> lemme catch up and have breakfast and stuff
<Whoopie> Keybuk: great, thanks!
<seria-mau> hi. any change #215561 get's fixed before release of hardy?
<seria-mau> s/change/chance/
<Riddell> cjwatson: that fix looks sensible, I'll give it a quick test
<cjwatson> thanks
<Riddell> mvo: mm, that should probably be milestoned although I wouldn't know where to start with debugging it
<\sh> damn...
<\sh> dput ubuntu is a bad idea for ppa packahes *grmpf*
<asac> cjwatson: bug 214620 ... this means that either firefox 3 postinstall is broken and installs the update-notifier file regardless of firefox running _or_ firefox was indeed running when the livecd was produced. can i rule out the latter?
<ubotu> Launchpad bug 214620 in firefox-3.0 "hardy livecd asks for firefox-3.0 restart" [Undecided,Incomplete] https://launchpad.net/bugs/214620
<cjwatson> seria-mau: does http://www.doc.ic.ac.uk/csg/faqs/latex.html (last question) help?
<cjwatson> asac: of course I can't be certain but I'm pretty confident you can rule out the latter
<cjwatson> I'd be amazed if IS were randomly running firefox X-forwarded from build daemons
<mvo> Riddell: ok, I may be able to put together the required hardware and give it a try
<asac> cjwatson: so its produced on buildds. ok :)
<cjwatson> asac: is it possible that 'pgrep -c firefox' would match firefox.postinst?
<asac> good idea
<cjwatson> you might want to use -x and give a more exact match
<cjwatson> asac: yeah, the live filesystem is built on dedicated buildds (I think they aren't actually used for normal build work)
<Riddell> mvo: do you think it needs that hardware or would happen with just the package installed?
<seria-mau> cjwatson: interesting. thanks! :)
<seria-mau> cjwatson: but i can't recall using this on a debian system i had. maybe they have a patch for this?
<mvo> Riddell: I suspect it needs the hardware running
<cjwatson> seria-mau: Ubuntu doesn't modify TeX much at all; we basically just take the Debian packages
<Riddell> evand (cjwatson): I'm still getting a crash when /cdrom/.disk/info doesn't exist, "File "/usr/lib/ubiquity/ubiquity/frontend/gtk_ui.py", line 2661, in _set_new_os_title if fp: UnboundLocalError: local variable 'fp' referenced before assignment"
<cjwatson> seria-mau: so I guess it would be either that it was introduced in an upstream version of TeX between the vintage of the Debian system you were using and now, or that it was patched in Debian since we last synced from them, or some other random factor ...
<cjwatson> Riddell: I'll fix it in a moment
<cjwatson> needs to initialise fp at the top
<cjwatson> seria-mau: in fact our texlive-base package is currently identical to Debian's
<cjwatson> Riddell: I don't think your format checkbutton handling in ubiquity r2635 is quite right. can_activate_format is not identical to "has a filesystem"
<cjwatson> Riddell: why doesn't /cdrom/.disk/info exist, anyway?
<Riddell> cjwatson: I'm running ubiquity from an installed system
<cjwatson> ah
<cjwatson> well, committed
<Keybuk> cjwatson: and another udev upload in the queue too :-)
<Keybuk> time to move the desktop to hardy, I think
<cjwatson> Keybuk: thinkfinger done
<Chipzz> cjwatson: dunnow if you saw this yesterday evening:
<Chipzz> 08:01 < Whoopie> Keybuk: Hi, looking at the latest libpam-thinfinger package, there's a typo in the pam-thinkfinger-enable script. It should be pam_thinkfinger.so, not  pam_fingerprint.so
<dholbach> can any archive-admin check if I can upload http://launchpadlibrarian.net/13352969/ttf-wqy-zenhei.debdiff ?
<Riddell> dholbach: yes I believe that's been approved
<cjwatson> Chipzz: that was what was fixed in the upload I just approved
<dholbach> Riddell: gracias
<cjwatson> Keybuk: how come the udev bug fixed by your upload is marked Invalid?
<Chipzz> cjwatson: ah k; I told the guy to file a bug-report (since bugs get lost on irc etc), but he didn't respond
<Keybuk> cjwatson: I did?
<Keybuk> hang on, let me check I typed the right bug number in then :p
<cjwatson> so saith activity log
<Keybuk> oh right, got you
<Keybuk> I moved it to lvm2
<Keybuk> but then realised it was a udev bug after all
<Keybuk> cjwatson: ok, LP makes sense again now :-)
<\sh> man...I think i'm getting too old for sysadmin jobs...
<\sh> ps -ef
<\sh> grmpf
<Whoopie> Chipzz: sorry for not responding. I filed a bug and cjwatson already approved it.
<cjwatson> Keybuk: would it be safe/reasonable to do the whole-disk+removable check in https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/192794/comments/13, rather than just turning it on for all whole-disks?
<ubotu> Launchpad bug 192794 in udev "vol_id not run for entire-disk device breaks LVM across entire disk" [High,Confirmed]
<Keybuk> cjwatson: I don't know whether that would fix the problem, or whether it would hide others
<ogra_> seb128, the trick to get my desktop size in gnome right seems not to affect gdm, the login screen is still at 1024x768 on a 1200x800 screen (and sitting in the top left corner), according to all docs i found gdm parses xorg.cof and picks the first resolutio it finds, but that doesnt seem to be th case for me
<cjwatson> calc: what's the uninstallable openoffice.org-style-default on http://people.ubuntu.com/~ubuntu-archive/testing/hardy_probs.html about?
<Keybuk> cjwatson: putting it back the way it was in gutsy seemed safest
<seb128> ogra_: we have several bug about that, I would tend to say that's an xorg bug
<ogra_> seb128, i would agree here, the dpi setting is also extremely wrong, the font for the input field is bigger than the field
<cjwatson> Keybuk: could you commit your grub change to the bzr branch, please?
<Keybuk> *mutters about stupid bzr branches*
<Keybuk> You've got to admit, the work flow for this is terrible
<Keybuk> grab a source package to make a drive-by change
<Keybuk> carefully examine the apt-get source output to see if there's a bzr branch
<Keybuk> checkout the bzr branch
<Keybuk> realise that the URL it gave you isn't writable
<Keybuk> delete the bzr branch again, and checkout using bzr+ssh this time
<Keybuk> cd into the directory, but wait, there's only the contents of the debian/ directory in tehre
<Keybuk> ...now what do you do?
<laga> you complain in #ubuntu-devel i guess
 * laga hides
<\sh> HCT !
 * \sh runs
<Ng> if one sets custom colours for a gtk theme in the appearances capplet, where is that information saved?
<Keybuk> Ng: I think it writes you a custom .gtkrc
<Keybuk> \sh: note the "H"
<Ng> Keybuk: that's what I was expecting, but I have none. I'm thinking gconf:/apps/gnome/interface/gtk_color_scheme
<Keybuk> could be
<\sh> Ng, eventually .config/gtk-2.0 ?
 * Keybuk inserts another point into his rant
<cjwatson> writable URLs> use debcheckout -a
<Keybuk> realise that after changing https to bzr+ssh, it still doesn't work ("connection timed out") and change code.lp.net to bazaar.lp.net
<cjwatson> which gets rid of your entire rant except for debian/-only branches
<Keybuk> can't use authenticated mode on repository 'https://code.launchpad.net/~ubuntu-core-dev/grub/ubuntu' since it is not a known repository (e.g. alioth)
<Keybuk> cjwatson: don't get me *started* on debcheckout ;)
<cjwatson> Keybuk: you need to upgrade devscripts to current
<cjwatson> $ debcheckout -a grub
<cjwatson> declared bzr repository at bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu
<cjwatson> bzr branch bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu grub ...
<Keybuk> it doesn't get the .orig.tar.gz
<Keybuk> so you can't make a package from it anyway
<Keybuk> doesn't deal with debian-only
<Keybuk> doesn't deal with pitti's strange habit of bzr branches with a debian directory inside them but nothing else
<Keybuk> etc.
<cjwatson> orig> true; it's clearly the right interface though
<cjwatson> debian-only branches should die a painful death
 * Amaranth hides his debian-only branches
<Keybuk> hah!
<Amaranth> I'm not even sure how else to do it
<cjwatson> they won't work with the automatic bzr import plans anyway
<cjwatson> Amaranth: import upstream into bzr, branch from upstream
<Amaranth> I mean, compiz is in git :P
<cjwatson> bzr-git
<Keybuk> grub-ubuntu is at least not debian only
<Amaranth> Does that not suck now?
<cjwatson> or tailor
<Keybuk> but it makes the silly mistake of putting auto-generated files inside revision control
<cjwatson> or anything that does the conversion. This is not rocket science
<Amaranth> We could also just use git for packaging :P
<Keybuk> Amaranth: I would rather die
<cjwatson> we do need to get git import support in Launchpad
 * Ng hits up blueprints.launchpad.net ;)
<cjwatson> once that's there nobody needs to do it by hand
<Whoopie> is somebody working on #205990? I'm also affected.
<Whoopie> bug 205990
<ubotu> Launchpad bug 205990 in usplash "[hardy] splash screen disappears after a few seconds" [Medium,Confirmed] https://launchpad.net/bugs/205990
<Keybuk> Whoopie: not that I know of, feel free to have a go
<Keybuk> cjwatson: there, committed, happy now?  :p
<cjwatson> thanks
<Keybuk> to be fair to bzr
<Keybuk> my principle gripes go away when
<Keybuk> 1) bzr is fixed to apply the same timestamp to all files modified by any single working tree operation
<Keybuk> 2) thus it can be standard policy to just import the entire package
<Whoopie> Keybuk: problem is where to start. I see that usplash segfaults, but don't see a crash dump.
<Keybuk> 3) and we can "upload" with a bzr commit, rather than needing to generate any kind of source package (so .orig doesn't matter)
<Keybuk> Whoopie: crash dump will end up inside the initramfs, which is somewhat pessimal
<Amaranth> Keybuk: isn't that a dpkg thing?
<Amaranth> new package format or whatever
<Keybuk> Amaranth: I'm a firm believer in having no such thing as a source package
<Keybuk> ooh, libtool 2.2!
<laga> Keybuk, Whoopie: if you add break=bottom to the boot options, i think you get a shell inside the initramfs. maybe you can recover the crash report from there
<Keybuk> laga: the crash happens after that, sadly
<ogra> Keybuk, then the crash log should be outside initramfs as well, no ?
<Keybuk> ogra: no
<Keybuk> usplash is run from the initramfs
<Keybuk> so it's in the initramfs namespace
<Keybuk> its / is the initramfs /
<ogra> well, either t doesnt log at all or usplash has a time machine built in then
<Keybuk> its /dev is the initramfs /dev
<Keybuk> all things that usplash does are inherently contained within the initramfs
<Keybuk> the last thing that initramfs does is run init
<Keybuk> init is run in a new namespace, with a new /
<Keybuk> so all children of init share that namespace
<cjwatson> ogra: it doesn't need a time machine; it's started before the new / is mounted
<Keybuk> (what we call "userspace")
<laga> Keybuk: maybe you can sez up some bind mounts: mkdir -p $rootfs/initrd; mount -o bind / $rootfs/initrd
<Keybuk> that doesn't change the already running usplash
<ogra> hmm, couldnt we have a tmpfs that we move mount for such logs ?
<Keybuk> so any attempt by usplash to read or write files happens inside the initramfs
<laga> (i actually wonder why /initrd isn't populated on my box..)
<ogra> at least during development
<Keybuk> laga: that'd cause the initramfs to always exist
<Keybuk> the nice thing about the current system is that once usplash exits, the initramfs can be entirely cleaned up and use memory no more
<laga> Keybuk: then add it only for your testing.
<laga> or add a boot option "keep_initramfs"
<Chipzz> Whoopie: no biggie :)
<Keybuk> laga: that's not a bad idea
<Keybuk> obviously the mkdir would fail
<laga> Keybuk: mkdir -p will fail? dunno ;)
<Keybuk> laga: root filesystem is always mounted read-only
<laga> Keybuk: just wrap it in || true
<laga> Keybuk: oh. i didn't know that, i was only working with ltsp-ish initramfs scripts. then move it to a tmpfs
<Keybuk> Whoopie: if you fancy some fun
<Keybuk> edit /usr/share/initramfs-tools/init
<Keybuk> before the maybe_break init add
<Keybuk> mount -n -o bind / ${rootmnt}/initrd
<Keybuk> save that, make sure you have a /initrd, run update-initramfs -u, then reboot
<Keybuk> you may end up with a core file in /initrd
<Keybuk> (you might want to stick ulimit -c unlimited at the top of init to make sure)
<mvo> Riddell: I think I can reproduce #205079 :-D
<Riddell> mvo: you found an nvidia card?
<mvo> Riddell: yes
<mvo> Riddell: crashes in dpkg-reconfigure with the qt frontend then
<mvo> on a gutsy install with latest nvidia-glx-new
<Riddell> fooey
<mvo> milestoned and set to high
<mvo> I will investigate
<Riddell> mvo: let me know if I can help
<Riddell> not that I know much about qt debconf or perl-qt
<mvo> I thinks its something in the nvidia stuff that just gets triggered by perl-qt
<mvo> I will keep you updated
<Whoopie> Keybuk: ok, won't find the time today, but will definitely do tomorrow.
<amitk> ogra: On installing a new kernel, the boot freezes at "Loading hardware drivers" (comming from /etc/init.d/udev) for 1-2 minutes before continuing. Have you seen this?
<Keybuk> amitk: /var/log/udev
<amitk> I am investigating if 'udevadm trigger' has something to do with it.
<amitk> Keybuk: thanks
<Keybuk> amitk: sounds like a kernel device is taking a long time to timeout or be set up
<Keybuk> if you can stick that file somewhere, I can tell you which one and why
<amitk> Keybuk: Are those timestamps after each UEVENT line?
<Keybuk> amitk: the difference between the timestamp of a UDEV line and UEVENT line for the same device is the revealing thing
<Keybuk> or the lack of a UEVENT line for a UDEV line
<calc> cjwatson: its uninstallable because andromeda replaces it but not versioned replaces
<calc> cjwatson: so it can just go away completely from what slangasek mentioned which i will be doing on the upload on monday/ish
<calc> monday/tuesday once i verify the build works
<ogra> amitk, did you change the kernel options applied to grub ?
<calc> cjwatson: well replaces/conflicts/etc
<ogra> it nees clocksource=hpet, else it will hang for ages
<amitk> ogra: just removed 'quiet splash'
<ogra> check that you still have that
<cjwatson> calc: that output is completely unaffected by Replaces, so that's not possible
 * calc looks at andromeda
<cjwatson> calc: (the analysis is purely in terms of dependencies - Pre-Depends,Depends,Conflicts)
<cjwatson> calc: but if it's an unversioned Conflicts, yes that's possible
<calc> cjwatson: ah yea its unversioned conflicts
<calc> cjwatson: i just looked at the control info
<calc> it replaces/preovides/conflicts all unversioned
<calc> meeting back on, bbl
<cjwatson> calc: *nod*
<siretart> slangasek: do you insist on stripping/cleaning the patch of bug #131914? - the jack plugin is not compiled in by default, it would be a convenience for ppl who are rebuilding xine from source for that
<ubotu> Launchpad bug 131914 in xine-lib "please update the pulseaudio plugin" [High,Triaged] https://launchpad.net/bugs/131914
<mvo> Keybuk: could you please have a look at #205911 and let me know the diff looks good and if you would accept it?
<amitk> Keybuk: UEVENT[1207912040.014865] add      /devices/pci0000:00/0000:00:1e.2/sound/card0
<amitk> UDEV  [1207912212.320071] add      /devices/pci0000:00/0000:00:1e.2/sound/card0
<calc> cjwatson: essentially all the bugs i marked today as targeted for 8.04 i already have fixes for and will be uploading in the next build
<cjwatson> great
<calc> i just marked them after seeing slangasek's email to make sure it was clear i intend to fix them for the release :)
<Keybuk> amitk: ok, likely a modprobe taking a long time then
<Keybuk> mvo: isn't there a bug already open about that?
<Keybuk> mvo: bug #116468
<ubotu> Launchpad bug 116468 in upstart "recovery menu hookins for upstart" [Wishlist,Triaged] https://launchpad.net/bugs/116468
<mvo> Keybuk: oh, I must have overlooked that one, sorry
<Keybuk> mvo: but yes, the patch looks vaguely sound
<Keybuk> there was another suggested upstart change reecntly
<Keybuk> oh, that's right, to tty1
<ogra> amitk, well, remember, i had sound probs with that last kernel from you, if it angs at sound drivers now that sounds like its related ... are you missing any intel hda patches we apply usually ?
<Keybuk> I'll do that after this gutsy->hardy upgrade finishes
<mvo> Keybuk: great, thanks
<mvo> Keybuk: how is it (the upgrade) going so far?
<Keybuk> mvo: no problems so far, other than the usual "cups has a minor comment change so needs to discard all of your config changes" issue
<Keybuk> oh, and epiphany crashed
<Keybuk> but I was somewhat expecting that
 * mvo nods
<mvo> yeah, conffile merging would be good, especially with stuff like cups or gdm.conf-custom
<ion_> It would be nice if the previous dist version of conffiles were saved somewhere and dpkg made a three-way merge.
<cjwatson> StevenK: right, assuming I didn't screw this up, you should be notified of moblin image build failures now
<ion_> davmor2: Please!
<Keybuk> ion_: there's been a patch for that for years
<cjwatson> and, in general, the release team and appropriate leads should be notified of CD image build failures
<jwendell> hi, pochu
<amitk> ogra: this is happening on a Ubuntu kernel too, I just downloaded the -16 kernels to 'forward-port' the patch if required
<ogra> weird
<jwendell> pochu, could you make a package (in your ppa) for patch attached to bug 181648
<ubotu> Launchpad bug 181648 in vino "vino-server crashed with SIGSEGV" [Medium,Incomplete] https://launchpad.net/bugs/181648
<ogra> it doesnt happen on any kernels i have used here yet
<ogra> there is a delay at that point for ure, but thats not more tha 20sec or so
<Keybuk> "What would you like to do about bash_completion?"
<Keybuk> now _there's_ a leading question
<ogra> i thought that was added back week ago ?
<ogra> *weeks
<mvo> Keybuk: I filed a bug about that one already
<ion_> mvo: Any news about apt-zsync, btw? :-)
<mvo> ion_: no, sorry. lack of time .(
<ion_> mvo: I see. I wish i'd manage to contribute something, but i haven't had the energy to get any coding done for a while.
<pochu> jwendell: sure, will do that in a minute
<cjwatson> amitk: -16? Has there been another ABI bump?
<jwendell> pochu, thanks... that bug is so difficult to debug... I'm not sure if that patch will work...
<pochu> jwendell: uploaded
<pochu> jwendell: I'll ask for testing in the bug :)
<jwendell> pochu, thanks ;)
<Keybuk> mvo: upgrade finishes
<Keybuk> now I reboot ;-)
<mvo> good luck!
<\sh> which package is needed to get totems youtube plugin to run?
<ogra> gtreamer-*-swfdec ?
<ogra> *gstreamer
<seb128> the current hardy version is broken
<seb128> there is a fixed update waiting for approval
<seb128> but I guess slangasek is not awake yet
<ogra> we need more RMs :)
<Keybuk> mvo: it's ok, you're not fired ;-)
<Keybuk> I had a bug on reboot, but that one appears to be assigned to me
<Keybuk> so I'm going to have to fire myself <g>
<mvo> Keybuk: *puhh* I was slightly worried because the reboot took so long :)
<mvo> Keybuk: what is the bug?
<Keybuk> fsck ended with a reboot
<Keybuk> cjwatson: ooh, I just found a nice bzr feature
<Keybuk> bzr co ... debian
<Keybuk> inside an unpacked source tree
<amitk> cjwatson: yes, abi bump due to virtio
<Keybuk> it'll make the existing debian directory have a .bzr, and update the tree
<Keybuk> and will conflict anything different
<pitti> Hobbsee: mega-kill script?
<pitti> lamont: translations> no, we use dpkg-distaddfile to add the translations tarball to the changes, and soyuz tosses it straight to rosetta; that has worked for literally years
<pitti> lamont: so you can remove your p.u.c./translations dir if you want
<pitti> Keybuk: pitti's strange habit> I'm inclined to say that almost all packaging branches on alioth are done that way, and the majority of bzr branches, too
<lamont> pitti: carlos and others(?) use them for debugging porpoises.
<pitti> lamont: OIC
<mvo> Riddell: looking at the bug, I'm inclinded to say that its a generic libqt-perl problem, I can make it crash here pretty easily, it seems to be not very stable :/
<Keybuk> mjg59: I see what you mean about the terminal fonts going greyscale
<mvo> Riddell: see e.g. #215660 -> happend by just pressing cancel on dpkg-reconfigure debconf
<Keybuk> mjg59: I hadn't noticed the difference on my laptop, but it's much more noticeable on the desktop
<Riddell> mvo: mm, seems probable
<ogra> Keybuk, dont you and mjg59 have this discussion every time this time of a release ?
 * ogra has a dejavu
<Keybuk> ogra: mjg59 and I have many healthy discussions :-)
<ogra> and traditions it seems :)
<Keybuk> cjwatson: new upstart for you! :D
 * cjwatson migrates over to pterm/gtk2, not before time
<cjwatson> pitti: I think this is because alioth does not feature a sophisticated system for importing code from upstream, so people do whatever is quickest for them
<cjwatson> we're in a position to present something that's easier
<pitti> cjwatson: I guess Keybuk alluded to "keep debian/ in bzr" rather than "debian/ is the root dir of the branch"
<Keybuk> pitti: right
<pitti> Keybuk: easy to migrate, though, "bzr mv" FTW :)
<cjwatson> pitti: ah, well, I think we should do neither ;-)
<pitti> doesn't work if you bzr-svn from alioth, but in some cases it might
<cjwatson> and yes, for packaging-only branches I agree
<pitti> Keybuk: but frankly, I think we need to get along with that structure; everyone uses it
<pitti> maybe bzr-builddeb handles that appropriately?
<pitti> (I still haven't tried it)
<Hobbsee> pitti: your mega-killall-gnome script, iirc
<pitti> Hobbsee: oh; haven't used that in a while
<Keybuk> pitti: it's the fact that you can't tell what the structure is until you checkout that winds me up
<Keybuk> it makes grabbing a source package to change a difficult process
<Mithrandir> Hobbsee: pkill -u $USER? :-)
<Hobbsee> Mithrandir: :P
<jdong> Mithrandir: magical, but don't do it when you have screen sessions running </bad personal mistake>
<jdong> :)
<jdong> there's gotta be some sort of UNIX idiocy award that I should be nominated for :)
<Mithrandir> jdong: that's what you have Other Machines for. :-)
<jdong> haha :)
<Keybuk> Mithrandir: err, that's kinda unnecessary?
<Keybuk> kill -TERM -1
<Keybuk> works just as well
<lamont> seb128: compiz lacks focus=strict, FTL
<jdong> Keybuk: does -1 match all processes?
<Keybuk> jdong: yes
<Keybuk> well, all processes except itself and init
<jdong> Keybuk: oh I get it. yeah, that makes sense
<lamont> ** (ck-list-sessions:22809): WARNING **: Failed to get list of seats: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success
<lamont> pitti: why does console-kit hate me?
<ogra> lamont, do you have /etc/X11/Xsession.d/90-console-kit ?
<ogra> that should set up a session in any case now
<lamont> yep
<ogra> and also /usr/bin/ck-launch-session
<lamont> mode 755 root:root binary
<ogra> then it must be something personal i guess
<lamont> yeah - it works elsewhere.
<lamont> OTOH, it'd be nice if devices mounted, or there was some hint of where to start looking in the twisty little maze of dbus passages
<ogra> env |grep XDG
<ogra> does that return a cookie ?
<lamont> XDG_DATA_DIRS=/usr/local/share/:/usr/share/:/usr/share/gdm/
<lamont> '
<ogra> XDG_SESSION_COOKIE is what you want
<lamont> not there
<lamont> machine is probably feisty era for it's coldinstall
<ogra> ck-launch-session xterm
<ogra> does ck-list-sessions return anything inside the xterm ?
<ogra> or anything for XDG_SESSION_COOKIE
<lamont> yeah - the same error message as above, no COOKIE
<ogra> wow, that seems to go deeper ...
<ogra> the xterm should have had a cookie
<lamont> oh, I think it's the same issue,and that X is valiantly trying to start the session in a correct manner
<lamont> and that dbus or something is b0rked in some way
 * lamont brb - rebooting for something else
<pitti> lamont: I honestly don't know
 * pitti -> travelling back home
<ogra> pitti, whats really weird is that not even ck-launch-session works here, i should at least set the cookie variable
<ogra> pitti, safe return
<ogra> s/i/it/
<lamont> ogra: any thoughts?  (and any idea if this could relate to why have no sound now after the upgrade)
<cjwatson> Keybuk: upstart approved
<seb128> could somebody approve totem and cairo?
<ogra> lamont, do you have a session dbus running ? there should also be some dbus related stuff in env
<seb128> totem has a simple svn change to fix the youtube playing code
<lamont> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-79gOEYXwn8,guid=550a39ea67cfc5bc3440374147ff68be
<ogra> lamont, DBUS_SESSION_BUS_ADDRESS should be in your environmet
<seb128> and cairo is the new stable version (which has no code change over the snapshot we had) and a patch fixing printing crashing xerox printer at the canonical office (and likely at other places too)
<ogra> hmm, looks ok
<lamont> ogra: OTOH, there is no /tmp/dbus-* stuff
<ogra> abstract :)
<lamont> huh?
<ogra> its somewhere hidden in proc, i forgot where exactly though
<lamont> ah, ok
<lamont> 105       6499  0.0  0.0   4104  1748 ?        Ss   07:33   0:00 /usr/bin/dbus-daemon --system
<lamont> lamont    8833  0.0  0.0   4104  1724 ?        Ss   07:33   0:00 dbus-daemon --fork --print-address 25 --print-pid 27 --session
<lamont> that's my grep dbus output from ps
<ogra> looks fine
<ogra> the --session bit is the one you look for
<ogra> lamont, the code of ck-launch-session thinks it logs to syslog ... anything in there that could be related ?
<lamont> any clue what service or name it uses?
<ogra> ConsoleKit ?
<Keybuk> lamont: d-feet is your friend
<lamont> Keybuk: ??
<Keybuk> lamont: it's a graphical d-bus debugger
<Keybuk> lamont: e.g. http://people.ubuntu.com/~scott/d-feet.png
<Keybuk> you can then execute any d-bus method, etc. in python syntax from within it
<ogra> lamont, oh, btw, is /usr/sbin/console-kit-daemon running at all ?
<cjwatson> oh, that's nice
<lamont> ogra: no, it's not.
<ogra> aha
<ogra> heh
<ogra> could have saved us some time if i had asked that earlier :)
<lamont> ogra: so the next question, of course, is "why isn't it running?"
<ogra> yeah
<lamont> Keybuk: what bus address do I use when adding a connection in d-feet?
<Keybuk> lamont: you should just be able to connect to the system bus or session bus]
<ogra> lamont, org.freedesktop.ConsoleKit.serviceis what you look for
<lamont> ogra: no.
<lamont> the syntax for the stupid bus address is what I'm looking for
<Keybuk> lamont: ?
<lamont> there we go
<Ng> lamont: see File menu
<lamont> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-79gOEYXwn8,guid=550a39ea67cfc5bc3440374147ff68be
<ogra>  /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service is what starts it
<Keybuk> lamont: File -> Connect to ... bus
<lamont> and just use the unix:abstract=/tmp/dbus-79gOEYXwn8
<lamont> Keybuk: ah. I was using the cute little plug button
<Keybuk> lamont: that's for connecting to other things
<munckfish> cjwatson: got time for a real quick chat on ps3 stuff?
<Ng> heh, apport and d-feet aren't great friends, but this is a very cute tool
<Keybuk> e.g. you can stick unix:abstract=/com/ubuntu/Upstart in there if you're using upstart 0.5
<Keybuk> Ng: the hardy consolekit outputs bad xml for its session introspection iirc
<lamont> the only thing under org.freedesktop that I have is PowerManagement
<cjwatson> munckfish: sure
<Ng> Keybuk: I see some mild traceback in the parent shell, but apport seems to interpret each one as a crash ;)
<munckfish> cool how u doing? I just sent a mail to the cell list
<munckfish> Cause I'm a bit new around here
<munckfish> I was afraid to just leave things
<munckfish> as they are
<munckfish> in case that bug just sits without attention
<Keybuk> dbus-send --system --dest=org.freedesktop.ConsoleKit --type=method_call --print-reply /org/freedesktop/ConsoleKit/Session1 org.freedesktop.DBus.Introspectable.Introspect
<Keybuk> Ng: note <property ... /> followed by </property>
<munckfish> cjwatson: are you aware of the current state of things re PS3/kboot?
<cjwatson> #ubuntu-release is a good pestering location
<Keybuk> lamont: definitely sounds like ConsoleKit is not running
<munckfish> aha ok
<cjwatson> and I think this does need to be expedited
<Ng> Keybuk: ah
<munckfish> yes
<lamont> Keybuk: the question is, how does it get launched?
<munckfish> Being that i'm the only person who has reviewed it
<lamont> or what do I change where so that it does
<Keybuk> lamont: ck-launch-session called internally by things like gdm
<munckfish> I'd like some other PS3 user to try it out and review my debian script changes
<lamont> ck-launch-session fails to launch a session
<munckfish> now, I subscribed ubuntu-main-sponsors
<cjwatson> I'll grab it and have a look
<munckfish> but I'm guessing the reviewer needs to be a PS3 user
<munckfish> cjwatson: that would be brillaint
<Keybuk> lamont: what does it do?
<munckfish> hmm spelling
<cjwatson> not sure I'll actually be able to *try* it, mind
<munckfish> umm ok
<lamont> Keybuk: ck-launch-session xterm gives me an xterm, with no XDG_SESSION_COOKIE defined
<munckfish> what would you need for that?
<cjwatson> err, tedious local problems
<lamont> Keybuk: and that would be what we're trying to debug...
<ogra> Keybuk, its run from a Xsessio.d script
<ogra> gdm has its own mechanism
<cjwatson> but given it's totally busted at the moment, this is not actually as major a concern as you might think
<ogra> and it only runs if gdm didnt set the cookie already
<munckfish> cjwatson: oh I see
<munckfish> well ...
<munckfish> fine
<munckfish> :S
<ogra> Keybuk, a gdm user should never have to run ck-launch-session, its a safety net for startx
<munckfish> Ok well, it builds, it boots
<munckfish> If the stuff I've updated in control, etc are cool with you
<munckfish> then I'll start pestering ubuntu-release
<munckfish> will someone from there do the upload then?
<Keybuk> lamont: I don't think ck-launch-session generates the cookie
<munckfish> instead of the usual process where a sponsor does it?
<Keybuk> I think it only registers any existing one
<ogra> lamont, your problem is no "lamont> ck-launch-session fails to launch a session" ... your prob is dbus fails to launch the ck daemon
<ogra> Keybuk, ck-launch-session xterm
<Keybuk> ogra: won't generate a new cookie
<ogra> you will have a new cookie in env in that term
<lamont> ogra: ok.  how make dbus launch session?
<Keybuk> oh, sorry, yes it does
<ogra> lamont, is /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service existing ?
<ogra> thats what is supposed to start the daemon
<ogra> based on credentials from /etc/dbus-1/system.d/ConsoleKit.conf
<lamont> ogra: the onlyyep
<lamont> er, yep
<ogra> hmm
<munckfish> cjwatson: ok, pls let me know somehow if you're happy, either here or on the bug. and I'll pester ubuntu-release
<munckfish> thx
<lamont> should ~/.dbus/session-bus have 2 entries in it if I'm only logged in  once?
<ogra> hmm, i only have one
<ogra> but then my other laptop has six
<lamont> yeah, and the files have a comment that says DBUS_SESSION_BUS_ADDRESS overrides the file
<ogra> the number behind the dash in the key name there is the display
 * lamont has two *-0 files
<lamont> so how do I tell dbus to launch the ck-session-daemon"
<lamont> ?
<mvo> Riddell: I updated #205079, its indeed a nvidia issue, we can work around it in the upgrader or we need a sru for linux-restricted-modules in gutsy and add a check in the upgrader that it wll not continue without that sru installed. you pick :)
<Riddell> mvo: great
<Riddell> mvo: a sru may not get in the archive in time for RC or final
<cjwatson> munckfish: really minor, but debian/patches/03-configure-kboot-build.patch introduces answers as well as config/answers, which looks tautologous
<mvo> Riddell: yeah, that is my concern as well, also we might be able to fast-track it a bit
<Riddell> mvo: making the dist upgrade tool do the work seems simplest to me
<cjwatson> munckfish: I have to say I'm not seeing a whole lot else wrong, assuming it's working for you
<cjwatson> (aside from the graphics problem, which I think should be fixed in current kernels)
<mvo> Riddell: ok, I will prepare a fix
<cjwatson> munckfish: what kernel version are you using?
<shaya> I did an upgrade from dapper to hardy and I don't think the fstab was rewritten to use UUID (I had to do it manually)
<shaya> I remember back in the dapper->edgy upgrade days that was specifically taken care of, was that dropped?
<shaya> Is dapper->hardy not a valid upgrade path?
<pochu> it is
<shaya> what package should be taking care of the UUID stuff?
<cjwatson> udev
<cjwatson> shaya: how long ago did you upgrade? there were recent fixes
<shaya> a week ago?
<cjwatson> been fixed since
<shaya> ok
<cjwatson> see bug 209347
<ubotu> Launchpad bug 209347 in udev "upgrade-manager fails to properly update /etc/fstab for hda -> sda change" [High,Fix released] https://launchpad.net/bugs/209347
<shaya> yea
<shaya> I see
<shaya> ok, just wanted to make sure it was known.  didn't have that many issues in my upgrade
<shaya> and hardy seems more stable than dapper (for some reason w/ dapper my old T21 would freeze every so often, been rock solid w/ hardy)
<Keybuk> pitti: around?  my iAudio has stopped opening rhythmbox again
<Keybuk> and, in fact, rhythmbox doesn't even acknowledge its existance
<lamont> cjwatson: 206113 - you want an upload based on the feedback we have?
<cjwatson> lamont: suggests it hasn't regressed the normal case, which is good, so yeah, I think so
<lamont> ok.  I'll get that uploaded today... who wants to drive the freeze execption process? (it is the one package I have that doesn't get synced, fwiw.. go udev)
<seb128> Keybuk: he's travelling back to europe
<Keybuk> ah, damn
<Keybuk> I wonder whether it's the int_outof thing being broken again
<Keybuk> I remember fixing that in some way last time
<Keybuk> seb128: hmm
<Keybuk> what does rhythmbox now use to detect media players?
<seb128> Keybuk: hal
<Keybuk> yes, but what properties, etc.
<seb128> lshal --monitor, plug, see if it's detected?
<Keybuk> it is
<Keybuk> and it has portable_audio_player.* stuff
<seb128> I think it looks to portable_audio_player being in the device capability
<seb128> is the issue rhythmbox not being opened when you plug the player or rhythmbox not listing it at all?
<Keybuk> both
<Keybuk> rhythmbox is neither opened nor lists it
<seb128> do you have the mtp plugin enable if you need it?
<Keybuk> don't need that, it's just a big disk
<Keybuk>   portable_audio_player.access_method.protocols = {'storage'} (string list)
<Keybuk>   portable_audio_player.audio_folders = {'MUSIC/'} (string list)
<Keybuk>   portable_audio_player.input_formats = {'audio/mpeg'} (string list)
<Keybuk>   portable_audio_player.output_formats = {'application/ogg', 'audio/x-ms-wma', 'audio/flac', 'audio/x-wav'} (string list)
<Keybuk>   portable_audio_player.playlist_format = {'audio/x-mpegurl'} (string list)
<Keybuk>   portable_audio_player.playlist_path = {'PLAYLIST/%File'} (string list)
<Keybuk> that all looks correct to me too
<seb128> Keybuk: run rhythmbox -d and look at the log when plugin the player?
<lamont> ogra_cmpc: and back in history: Apr 11 07:44:29 mix ck-launch-session: error connecting to ConsoleKit
<cjwatson> munckfish: 1.6 looks like the version of the HowToUsePS3Linux document?
<cjwatson> or is it just me
<munckfish> Hi cjwatson
<seb128> Keybuk: gconftool -g /apps/rhythmbox/plugins/generic-player/active too
<Keybuk> (16:13:07) [0x6aa500] [rb_removable_media_manager_mount_volume] rb-removable-media-manager.c:429: detecting new media - hal udi=/org/freedesktop/Hal/devices/volume_uuid_43DB_3ADE
<munckfish> 1.6 is the overall release version
<munckfish> see this ...
<munckfish> http://www.kernel.org/pub/linux/kernel/people/geoff/cell/CELL-Linux-CL_20080201-ADDON/CHANGES-e.txt
<Keybuk> (16:13:07) [0x6aa500] [free_dbus_error] rb-generic-player-source.c:1318: finding audio player udi: dbus error: No property info.capabilities on device with id /org/freedesktop/Hal/devices/usb_device_e21_500_100_if0_scsi_host_scsi_device_lun0
<munckfish> That's what I presumed ben took
<Keybuk> (16:13:07) [0x6aa500] [rb_generic_player_is_volume_player] rb-generic-player-source.c:793: device is not an audio player
<munckfish> the orig version number from
<seb128> Keybuk: ah
<seb128> Keybuk: <seb128> I think it looks to portable_audio_player being in the device capability
<cjwatson> munckfish: you're quite right; I was confused because README-e.txt lies and says 1.5.1
<seb128> Keybuk: that would be the issue then
<Keybuk> seb128: but no FDI file sets that? :)
 * Keybuk just grepped through
<seb128> Keybuk: is hal bug
<munckfish> cjwatson: yeah it's a touch messy up there
<Keybuk> sets that for _ANY_ audio player
<amitk> ogra_cmpc: do you have a description of the cmpc filesystem -> squashfs, unionfs, fuse seemed to be used, but deleting files isn't reclaiming any space
<munckfish> cjwatson: ok, I see that kboot-11/answers file in my patch :(
<munckfish> I dunno how it got there
<munckfish> but I'm certain it's a no-op
<Keybuk> seb128: missing for just about everything in 10-usb-music-players.fdi
<munckfish> I can tidy that out in a future build
<munckfish> cjwatson: kernel version is what's provided from upstream which is 2.6.24
<munckfish> I think ben was happy to just take that
<munckfish> networking is disabled
<amitk> ogra_cmpc: I mean, how are the various filessytems cobbled together
<Keybuk> seb128: adding that capability fixed it
<Keybuk> I'll file a bug for pitti on Monday
<seb128> Keybuk: ok, good
<Keybuk> someone changed rb's behaviour with media players?  everything shows up in the Library now?
<cjwatson> munckfish: yeah, I saw it was what he suggested
<cjwatson> munckfish: just so I can check it, what URL did the tarball come from?
<munckfish> I wrote that into debian/copyright just as ben had originally done
<cjwatson> so you did
<seb128> Keybuk: no, there was a bug about that but it's supposed to be fixed, maybe you used it while it was buggy and have duplicate entries in the database now?
<Keybuk> seb128: I upgraded to hardy today
<Keybuk> ?
<seb128> hum, k, so it's not fixed
<Keybuk> are they not supposed to appear in the Library ?
<seb128> Keybuk: http://bugzilla.gnome.org/show_bug.cgi?id=519737
<ubotu> Gnome bug 519737 in iPod "Duplicate tracks added to library after pluging in ipod" [Normal,Resolved: fixed]
<munckfish> cjwatson: next build I'll add a README.maintainer to tie up these sort of loose end questions
 * calc thinks he will never get used to jumping so many timezones
<Keybuk> aww
<Keybuk> this fixed my #
<Keybuk> #1 bug with rhythmbox though :-)
 * calc is about to pass out
<Keybuk> with this "bug", it now shares the music on my iAudio on the network <g>
<seb128> Keybuk: which was the need to import everything again every time you plug it?
<seb128> Keybuk: ah, right ;-)
<cjwatson> munckfish: debian/copyright's fine, I was just blind
<Keybuk> of course, the mac can't play oggs anyway, but hey-ho :p
<munckfish> cjwatson: to be honest I didn't notice ben had written the orig info there until days later
<munckfish> it was where I expected to find that
<munckfish> but I see it's common practice to put it there
<Ng> re hardy's Active Directory support, can we support the situation where $HOME should be mounted from a server?
<laga> is there a nice way (eg a library) to edit /etc/sudoers?
<ogra> Ng, pam_mount or pam_script should help
<wasabi> Ng: That's ungodly hard to do right. But pam_mount might get you there.
<wasabi> Oh. Hi og.
<wasabi> re.
<ogra> heh
<wasabi> I also don't think it's worth doing at all. Even windows doesn't network mount it's equiv of $HOME.
<ogra> so i just Ã¶earned the hard way that ctrl-alt-bs in vbox isnt a good idea to restart the vm's X
<wasabi> ogra, haha. Host got it?
<laga> hah.
<ogra> indeed
<laga> happened to me while someone was logged in on my VM to fix something for me :)
 * ogra tries to recover all windows he had open
<cjwatson> munckfish: hmm, did you diff the new kboot script against the old?
<cjwatson> munckfish: since I notice that the old copyright file listed substantial modifications to that
<Ng> ogra: ok, just wondering if it works OOTB
<ogra> i dont think so
<Ng> ok
<ogra> but i might be wrong :)
<cjwatson> munckfish: not everything will be suitable since I think now it's using a built-in udev (which is ugh, but we're limited in time)
<cjwatson> munckfish: that said, unfortunately it isn't very clear what changes Ben made
<ogra> seb128, btw http://paste.ubuntu.com/6766/ helps me ... the prob seems to be in general that X ust enables all outputs by default
<munckfish> cjwatson: yes I did
<ogra> err, ignore the commet in that file :)
<munckfish> cjwatson: but because of the way our changes were kept in the debdiff along with
<munckfish> all other patches
<munckfish> from upstrea
<munckfish> there was no way I could see what was ours or theirs or what :(
<munckfish> cjwatson: so I just took upstream's without modification
<munckfish> and cause it appears to work
<munckfish> ..
<cjwatson> munckfish: yeah, it looks OK actually
<cjwatson> (being on the phone and reading diffs simultaneously is hard)
<ogra> still better than having someone reading them for you on the other ear i bet :)
<slangasek> tjaalton: well yes, it's explained in the changelog, but it's still a case of renaming a package < 1 week before RC...
<slangasek> Keybuk: "debcheckout -a"
<superm1> slangasek, i wanted to ask you, would it be a good idea/feasible to ship linux-backports-modules's latest version as of when the gold disk is mastered on the DVD?
<slangasek> oh, cjwatson said that too :)
<davmor2> guys I'm trying to do an upgrade from dapper to hardy.  I have sudo apt-get installed update-manager-core and then done sudo do-release-upgrade --devel-release.  I get an error return of edgy:  error: no such option: --mode.  What's gone wrong?
<superm1> slangasek, so that's a yes? :)
<slangasek> Keybuk: and the auto-generated files in the grub bzr repo are all from the upstream repo, I'm afraid :)
<davmor2> afk but leave a note and I'll attempt it latter
<slangasek> siretart: bug #131914 - yes, I do; whatever that jack change is, I think it's out of scope for the freeze exception
<ubotu> Launchpad bug 131914 in xine-lib "please update the pulseaudio plugin" [High,Triaged] https://launchpad.net/bugs/131914
<seb128> slangasek: hey, can you accept the libcairo update, it's an update to 1.6.0 (no code change since the 1.5.20 snapshot) and an extra git patch from today to not crash the xerox printers at the office ;-)
<siretart> slangasek: the jack plugin was rewritten as well as the pulseaudio plugin. we don't compile the jack plugin anyways, but I understand your position
<mvo> davmor2_away: could you please tell me what version of update-manager-core you have installed?
<siretart> I'm currently a bit in a hurry, so I'll work tonight (or tomorrow) on that
<cjwatson> munckfish: ok, I'm happy with this and am uploading it, but it will take a while
<cjwatson> munckfish: please poke #ubuntu-release as necessary
<slangasek> superm1: hrm, I don't think I understand your question... a good idea for who to ship it, and what else would be shipped other than the latest version?
<slangasek> seb128: yes, at 5:30 PDT you want pitti cjwatson Riddell, not me :-)
<seb128> slangasek: right ;-)
<seb128> thanks
<Keybuk> hmm
<slangasek> seb128: so does this fix the last of our evince printing problems? :)
<seb128> slangasek: that fixes the problems which were a concern for hardy I think, I would not say it fixes all the potential printing problems there ;-)
<slangasek> seb128: dude, you bumped the shlibs by hand for a no-code-change revision? :)
<Keybuk> please gods, don't let me have to file a wishy-washy-hand-wavy bug report like "music files sound terrible when played on hardy"
<slangasek> Keybuk: I thought we had mpt to file those bugs now :)
<seb128> slangasek: just updating to the stable version as noted in the changelog
<seb128> slangasek: we don't have testing transitions, should be no issue
<seb128> slangasek: but I can do without that if you want
<Keybuk> slangasek: he does the visual bits ;)
<Keybuk> yay, I don't have to file the bug
<Keybuk> woz alsa bug
<munckfish> cjwatson: If you're uploading, then what more do I need from ubuntu-release?
<Keybuk> well, silly alsa "Tone" mixer setting
<slangasek> seb128: already accepted, just looks funny to me :)
<Keybuk> where ON seems to mean "make all songs sound like Klingon Opera"
 * mpt daydreams about audio feedback in interfaces
 * slangasek daydreams about force feedback in interfaces
<seb128> slangasek: ok, thanks ;-)
<Keybuk> slangasek: so it's very hard to press ENTER after "rm" ?
<slangasek> Keybuk: so it's very hard to click 'submit' when posting to forums
<Keybuk> rofl
<mpt> That doesn't require force feedback, just anti-gravity for the cursor
<slangasek> heh
<munckfish> cjwatson: sorry i don't fully 'get' the process yet
<munckfish> there are still some shady corners
<munckfish> forme
<LaserJock> cjwatson: ah, thanks for the link. My point was more from the uploader's perspective (we don't upload to -updates for security fixes), but that certainly makes sense to do.
<mario_limonciell> slangasek, I was referring to adding it to the seeds so that it is available to be possible to be installed from the DVD for folks who will be needing items in it (such as the newer iwlwifi)
<slangasek> mario_limonciell: ah.  yes, that's probably reasonable; where is lbm currently seeded?
<mario_limonciell> slangasek, i dont think it is currently?
<slangasek> nowhere?  Then it should be on the component-mismatches report, let's see :)
<slangasek> why, indeed it is
<mario_limonciell> slangasek, I was just thinking it'd be useful to show up in the pool/, didn't investigate much beyond that
<nxvl> the last kernel broke my system
<nxvl> i can't boot using it
<nxvl> it hangs
<pwnguin> -16?
<pwnguin> nxvl: try waiting like five minutes if you're using 2.6.24-16
<nxvl> pwnguin: this is the one i can't boot
<nxvl>  pwnguin i need to pick -15 to boot
<pwnguin> where does it hang?
<cjwatson> munckfish: since we're in freeze, -release has to approve
<nxvl> pwnguin: loading modules
<pwnguin> nxvl: i've already brought the subject up on #ubuntu-kernel
<nxvl> pwnguin: when i came back it was on text mode and the last think it says was "loading modules manualy"
<pwnguin> nxvl: there will probably be a new kernel build shortly to fix that. seems like the sound modules had a patch that introduced a deadlock
<nxvl> is there any way i can check my apt history to check what is exactly what i upgrade?
<munckfish> cjwatson: ok I see
<cjwatson> nxvl: /var/log/dpkg.log
<mvo> nxvl: and /var/log/apt/term.log
<raboof> a source package is in a specific component (main, universe, etc), so it's not possible to have a source package produce one binary in main and one in universe, right?
<crimsun> yes, it is possible.
<crimsun> of course, the source would be in the main component in that example.
<Tm_T> oh, crimsun :)
<crimsun> however, it's completely possible to have main source produce nothing but universe binary packages.
<raboof> crimsun: interesting
<pwnguin> im confounded as to why one would want a source package in main to produce universe binaries
<Tm_T> pwnguin: some legal issue?
<pwnguin> the distinction between main and universe isnt legal
<Tm_T> true that
<Tm_T> hmm, in main you can have something as sourcepackage which you like to compile with something you need from universe
<raboof> i'm investigating if it'd be feasible to request libjack to be put into main
<Tm_T> then binary can or cannot be in main? :)
<raboof> but I don't think it's desirable to put all of jack in main
<raboof> (e.g. jackd)
<Tm_T> raboof: reasons not to be in main?
<crimsun> it was demoted after edgy IIRC
<Tm_T> pwnguin: I mean, if you like to have some extraplugin or such
<crimsun> sorry, no, breezy.
<raboof> Tm_T: no particular reason, i just figured the proposal that makes the least change would have more chance of getting though :)
 * _MMA_ will be working on getting JACK back in main for Intrepid.
<raboof> and moving only libjack to main seemed like a smaller change than also moving over the rest of jack
<raboof> _MMA_: oh, it was in main before?
<_MMA_> Yes. That's what crimsun said.
<_MMA_> "crimsun: it was demoted after edgy IIRC. sorry, no, breezy."
<raboof> (doh, didn't realize that that was about jack :) )
<raboof> Tm_T: hm, so a target in a source package in 'main' may depend on packages in universe if the target also goes into universe?
<Tm_T> raboof: well, dunno, can you put binary to main if you need something from universe to build it, as in, can you provide "quarantee" if it need part you cant quarantee?
<pwnguin> Tm_T: ah, i meant a source package in main to produce ONLY universe binaries
<raboof> Tm_T: the binary would go into universe
<Tm_T> raboof: yu
<Tm_T> pwnguin: I know, that could be weird, even unneeded, but possible perhaps
<siretart> raboof: that would allow me to reenable the xine jack plugin!
<crimsun> and a host of other things, like the PA jack module, etc., etc., etc. ...
<_MMA_> :P
<raboof> yeah, and the asound jack plugin, which is why I'm looking into this at all :)
<_MMA_> I'm hoping it can go back in without a MIR but we'll see. I started the process a bit ago. https://wiki.ubuntu.com/MainInclusionReportJACK
<evand> slangasek: in case you didn't catch it, I updated the patch in 215347.  Does cjwatson's comment and the updated patch change your decision, or should I punt the patch to Intrepid and release a new ubiquity with the accepted changes?
<sabdfl> slangasek: who would be the best person to look at this?
<sabdfl> https://bugs.launchpad.net/bugs/192294
<ubotu> Launchpad bug 192294 in xen-3.2 "[hardy] "ip" broken" [Undecided,Confirmed]
<slangasek> sabdfl: I was looking at it right now; but it's not reproducible on a hardy kernel, the only people reporting the problem are running non-Ubuntu kernels - I was just about to ask for more info on the bug
<slangasek> evand: I'll look at the patch shortly
<evand> slangasek: thanks
<xtknight> seems to be a boot problem w/ latest kernel.  Bug 215833.  it's happening for a lot of us
<ubotu> Launchpad bug 215833 in ubuntu "system won't boot after kernel 2.6.24-16-generic update" [Undecided,Confirmed] https://launchpad.net/bugs/215833
<xtknight> it would be nice to have some advice on how to debug or if it's already dealt with
<davmor2> mvo: ping
<mvo> davmor2: pong
<davmor2> mvo: sorry about the delay what info did you need?
<davmor2> about the update
<mvo> davmor2: you said do-release-upgrade gave you edgy instead of hardy, what version of update-manager-core do you have?
<LaserJock> sabdfl: got a sec?
<sabdfl> sure LaserJock, what's up?
<davmor2> mvo: whats the command to get the version I keep getting the name and not the version
<mvo> davmor2: please run "dpkg -l update-manager-core|less"
<seb128> slangasek: around?
<slangasek> seb128: 'sup?
<seb128> slangasek: did you read what xtknight wrote some line before?
<seb128> slangasek: just trying to make sure we don't have a linux or udev screweup before everybody runs away for the weekend
<crimsun> seb128: should be fixed in l-u-m 2.6.24-16.22
<seb128> ok, good
<slangasek> seb128: yes, it's already fixed in LUM but he disconnected before I could reply :)
<seb128> ok, good
<davmor2> mvo: update-manager-core 0.56-dapper4
<mvo> davmor2: could you please enable dapper-proposed and universe in there and see if you can get update-manager-core 0.56-dapper5?
<mvo> davmor2: and let me know if that fixes it?
<davmor2> mvo: np's
<mvo> davmor2: its a bug that its in universe, I'm checking that out currently
<mvo> davmor2: it maybe a side effect of a bug that got fixed for -dapper5, feedback would be great
<davmor2> mvo: np's I'll check it out now
<davmor2> mvo: it doesn't seem to like proposed? 404 not found
<ogra> slangasek, i got another ldm fix i'd like to upload http://paste.ubuntu.com/6788/
<mvo> davmor2: yeah, there is something fishy going on
<ogra> (there is a subsequent ltspfs fix as well i need to test more first)
<davmor2> mvo: hmmmm not good.  do you have a copy of the updated version anywhere?
<slangasek> ogra: eh? why do you need hexdump?
<mvo> davmor2: http://people.ubuntu.com/~mvo/update-manager/update-manager-core_0.56~dapper5_all.deb should work
<slangasek> ogra: should this LDMINFO_IPADDR be /conditionally/ defined, for forwards-compatibility with some future version of ldm that does export it, or is that not an issue?
<Shiba> I'm trying to resolve an automount problem on ubuntu 6.10 (both 64-bit and 32-bit).  I have an NFS share that is correctly exporting /home, and automounts are working for user accounts at login.  However, for directories not associated with user accounts, automount fails: "automount [pid]: failed to mount /home/dir".  Since this same configuration works on rhel/fedora/elsewhere, I suspect that this was patched as a "security" feature by the Ubuntu develop
<Shiba> ers.  Can someone confirm?
<ogra> slangasek, later versions export it
<keescook> Shiba: I use automount for /home okay
<keescook> (though I'm using 8.04, not 6.10)
<Shiba> keescook: it works for users' home directories when they log in, but if you try to access some file not in your home directory (but still in hte NFS export) the mount fails
<ogra> slangasek, but the later versions change a lot other stuff as well that would require more ltsp changes .... hexdump is used by a later line you dont see in the patch ...
<Shiba> i.e. you can log in and access .bashrc, but not /home/cvs
<keescook> Shiba: that sounds like a permissions problem?
<ogra> slangasek, err, sorry, not a later line in that script, a line in the screen.d script
<Shiba> keescook: unlikely.  this works on other machines installed with RHEL and Fedora
<keescook> Shiba: what does your auto.master entry for /home look like?
<Shiba> hang on, gotta log into that machine
<davmor2> mvo: that seems to of cracked it
<davmor2> mvo: I'll let you know for sure shortly
<slangasek> ogra: ok, please upload
<ogra> thanks
<mvo> cjwatson: would it be possible that you check bug #211978? its a sru for dapper and pitti is traveling so he can't approve it but it would be good to have it in the archive
<ubotu> Launchpad bug 211978 in update-manager "do-release-upgrade -d doesn't work immediately after running do-release-upgrade" [High,In progress] https://launchpad.net/bugs/211978
<mvo> davmor2: great, that sounds encouraging
<Shiba> keescook: I just deleted the entire automount configuration and rewrote it and now its working.  Not sure what was wrong before, but thanks for your time :)
<mvo> cjwatson: hm, its a bit confusing https://edge.launchpad.net/ubuntu/dapper/+source/update-manager-core/0.56~dapper5 ssays its biuld, but I do not see it in the pool (neither in main nor universe)
<keescook> Shiba: heh, okay, glad I could help.  :P
<mvo> cjwatson: https://edge.launchpad.net/ubuntu/dapper/i386/update-manager-core/0.56~dapper5 points into the void too
<davmor2> mvo: I don't think it liked the proposed being there in the update so I just blocked it off and am trying again
<davmor3> mvo: A unresolvable problem occurred while calculating the upgrade.
<megabyte405> If someone could take a look at this, it would be great
<megabyte405> https://wiki.ubuntu.com/MainInclusionReportLibwv-1%2e2
<mvo> davmor3: could you please give me the output of /var/log/dist-upgrade/main.log and apt.log ?
<davmor2> the update from gutsy -> hardy leaves BitTorrent Download Client in Internet and that's the only flaw I've found so congrats
<davmor2> mvo: Np's
<davmor2> mvo: http://www.davmor2.pwp.blueyonder.co.uk/apt.log   ï»¿http://www.davmor2.pwp.blueyonder.co.uk/main.log
<mvo> davmor2: for the dapper->hardy I would recommend to use the gtk version or run "do-release-upgrade -d -m desktop" - the default for the do-release-upgrade is the server mode that behaves slightly different from the desktop mode
<lamont> mvo: why does my freshly installed gutsy box think that there are no updates available when I run update-manager -d?
<mvo> lamont: did you update update-manager too?
<mvo> lamont: or is it a fresh-fresh install?
<lamont> fresh install, dist-upgraded to a yesterday-ish copy from the mirror
<lamont> meta-release-lts-development is the april 1 version of the file
<lamont> I suppose I could/should freshen taht?
<lamont> oh
<lamont> it needs the s/lts-// file to be there for leaving gutsy
<lamont> my bad
<mvo> lamont: that is your interessting proxy setup that made it fail?
<lamont> yeah
 * mvo nods
<lamont> it's the fact that changelogs doesn't really exist here.
<davmor2> mvo: that's done it it's downloading packages now.  I'll ping you in a bit if it's successful
<mvo> davmor2: great, thanks
<LaserJock> if a dput is stopped part way through an upload can I just reupload ?
<davmor2> mvo: I've passed on the word about the update-manager-core_ubuntu5 and the correct command for the update to testing for you :)
<davmor2> mvo: are you incharge of update manager for gutsy too?
<mvo> davmor2: aha, nice
<mvo> davmor2: yes, the gtk and cli version at least
<davmor2> mvo: I got 2 apps listed that shouldn't be.  BitTorrent Download Client and serpentine do you want me to bug report it and if so against what?
<mvo> davmor2: ok, please include the logs in /var/log/dist-upgrade to the report
<davmor2> mvo: we're just talking about this on testing.  Should the package be removed or would the update just see it as a user added app?
<mvo> davmor2: my guess (without seeing the logs) is that it assumes it might be of value for the user
<mvo> davmor2: its tricky, even if we changed gnome-bittorrent to transmission some users may not like this change
<davmor2> mvo: have you ever used gnome-BT
<davmor2> I'll upload the logs for you it'll be the same place with the innovative name of apt2.log give me a minute though
<mvo> davmor2: thanks
<davmor2> mvo: I couldn't be bother to arse around so I've overwritten the original versions so it's http://www.davmor2.pwp.blueyonder.co.uk/apt.log and http://www.davmor2.pwp.blueyonder.co.uk/main.log
<slangasek> fta, asac: given that bug #195013 has a branch associated, why is it still only 'confirmed' rather than 'fix committed'?  What remains to be done?
<ubotu> Launchpad bug 195013 in xulrunner-1.9 "Firefox 3 and xulrunner 1.9 needs translations" [High,Confirmed] https://launchpad.net/bugs/195013
<fta> slangasek, the branch is for point 1 only, not point 2
<fta> maybe my comment was a bit vague
<slangasek> fta: is "producing locale packages" contingent on having this uploaded and in the archive..?
<fta> the "producing locale packages" is still in progress. the desktop file part has been released with b5 last week
<slangasek> ok
<slangasek> are there any more changes that need to be made on these packages in connection with producing the locale packages, or is that entirely a LP translations issue?
<fta> slangasek, it's done by carlos. he said earlier today that tomorrow's lang packs will include b5 entries
<slangasek> fta: then AIUI, it would be correct here to mark each of these package tasks as 'fix released' and open a separate task for the LP aspect
<fta> slangasek, you're probably right. I'm not involved in those locales pkgs at all so i'm not aware of all the details. maybe asac knows more.
<slangasek> fta: well, I'm fairly certain that the translations don't get re-imported into the firefox packages, they just get pulled in via the langpacks - so I'm going to go out on a limb and make the change :)
<davmor2> mvo: this upgrade is going to take a fair amount of time and I'm off now but it is definitely working now.  :)
<davmor2> the dapper one
<slangasek> mario_limonciell: btw, I think fixing the regexp in the platform supported-kernel seed was enough to make backports-modules show up again :)
<infinity> slangasek: Want to confirm https://bugs.edge.launchpad.net/ubuntu/+source/tar/+bug/215940 for me?
<ubotu> Launchpad bug 215940 in tar "Itermittent testsuite failure on (at least) amd64" [Low,New]
<slangasek> infinity: other people are allowed to do that too, surely? :)
<slangasek> (done)
<mario_limonciell> slangasek, ooh great, thx :)
<infinity> slangasek: You were the last to speak in #-devel, you lose. :)
<infinity> slangasek: (I could comfirm it myself, but that seems terrible form, and a complete misunderstanding of what the "confirmed" tag means, IMO)
<infinity> slangasek: "Yes, I confirm that I filed the bug!"
<slangasek> infinity: sure, that's exactly what you /would/ say if you were stalking me to make sure that I was the last one to have said something in the channel before you spoke...
<slangasek> infinity: oh, well, I confirm my own bugs all the time :P
<infinity> slangasek: Would you like some "haha" with your "Mua"?
<slangasek> only if it's well-aged
<asac> slangasek: i kept the bug open to document that firefox has no translations and didn't know where to move this so it keeps showing up as a release blocker.
<slangasek> asac: oh.  that's fair; but I think we probably don't need three tasks open, do we?  then it shows up in my list three times :-)
<asac> slangasek: does closing this help you?
<asac> if so we can keep it closed. otherwise id like to open it for firefox at least (as a compromise)
<slangasek> if you're concerned about tracking it, yes, go ahead and keep it open for firefox
<asac> ok reopenig firefox-3.0 task
<slangasek> it helps me to not have three clones of a single bug taking up space when there's nothing to be done on any of the packages, but 1 should be ok :)
<asac> slangasek: hmm midbrowser is not fixed. it doesn't ship the translations to rosetta yet.
<slangasek> oh
<slangasek> I guess that should be reopened then :-)
<asac> the packaging is done by cwong. ill talk to him
<asac> (moblin)
 * slangasek nods
<xtknight> It would be nice if Bug 215027 could be looked at for eligibility of a Freeze Exception.  Hardware Drivers dialog is broken.
<ubotu> Launchpad bug 215027 in jockey "jockey-gtk crashed with AttributeError: 'tuple' object has no attribute 'getSections'" [Undecided,Confirmed] https://launchpad.net/bugs/215027
<slangasek> evand: latest patch in bug #215347 still partially invalidates existing translations; is the change to the error message important enough that we want to do this, knowing that it means an untranslated error message for many users?
<ubotu> Launchpad bug 215347 in ubiquity "freeze exception: clear_partitions warning." [Undecided,New] https://launchpad.net/bugs/215347
<slangasek> (darn, it's already after 6 there, isn't it)
<YokoZar> slangasek: Does launchpad prioritize translations in any meaningful way?  It would seem like it would be nice to have a means of marking translations like that urgent
<slangasek> I have no idea, I've never touched LP translations
<blueyed> pitti: Will apport (reporting) stay enabled for release? We would like to enable it in adept/Kubuntu then, too. (it's disabled there since Gutsy)
<mdke> YokoZar: yes, translations are prioritised by putting certain templates at the top of the list of translatable Ubuntu packages, I think
<mdke> ah, yes "
<mdke> "Templates that are considered more important for translation are listed first"
<cjwatson> slangasek: in reality we've rarely done much to ensure importing of translations for d-i components :-/
<slangasek> cjwatson: ah, well then :)
<slangasek> cjwatson: so you'd recommend pushing this in spite of the translation issue?
<megabyte405> could someone take a peek at this MIR we need for the abiword release?  (it's a package we used to put in the source tarball itself, since it's maintained by the same community - we just split it out for 2.6 now) Bug #215209
<ubotu> Launchpad bug 215209 in wv "Main Inclusion Report for wv" [Undecided,New] https://launchpad.net/bugs/215209
<slangasek> megabyte405: the set of "someone" who can approve MIRs is two people, neither of whom are likely to be around this time of day, I'm afraid
<megabyte405> slangasek: alright.  We did get a comment on the report, which involved my elaboration a bit of it, but perhaps that wasn't from within the set.
<megabyte405> I have subscribed ubuntu-mir - is that all I should/can do?  (AbiWord is otherwise ready to go, just this "paperwork" portion)
<slangasek> that's the right process, yes
<megabyte405> great
<megabyte405> I imagine that those following the process get the best results and the least-frustrated dev attention? :)
<ogra> it didnt actually get a positive comment from pitti
<slangasek> ah, I suppose so, though I don't look much at MIRs myself :)
<ogra> did you consider talking to the kword guys ?
<cjwatson> slangasek: I don't feel strongly about the exact form of the warning, only that there should be one even if you're using d-i rather than ubiquity
<cjwatson> slangasek: if you'd rather have the same warning currently in ubiquity so that we can copy translations over, that's fine with me
<megabyte405> ogra: No, I'd imagine that a port from their end would be equally unlikely in this short time frame.  Would be nice in the long term, though, so I will put it out there in the abi communitiy and hopefully Dom (the wv guy and main abi maintainer) can shoot them a quick email
<ogra> it doesnt seem likely to me that we get wv into main if wv2 is there ...
<ogra> (but then i'm not the one to decide, its just what my gut feeling and experience tells me)
#ubuntu-devel 2008-04-12
<megabyte405> ogra: unfortunately whoever decided to do a rewrite of wv did everyone a disservice - wv2 has been basically unmaintained for four years now, with just a vulnerability patch in 2006
<megabyte405> They are not interchangeable, wv is under active maintenance and improvement (since any word import bug in AbiWord tends to end up being a wv issue) whereas wv2 is not
<slangasek> http://cmpalmer.blogspot.com/2008/03/john-mccain-is-he-cylon.html
<megabyte405> not to mention that we used to just have the latest wv included in each abi release source tarball, until 2.6 when we decided that that was too messy in case a wv release independently came out between an abi release
<slangasek> whoops, cut'n'paste error, but enjoy anyway ;)
<ogra> lol
<cjwatson> soren: mouse doesn't seem to be working in kvm any more; do you know what's up?
<cjwatson> soren: (with -15)
<Whoopie> Keybuk gave me the advice to mount the initramfs to /initrd. but the command fails:  mount -n -o bind / ${rootmnt}/initrd
<Whoopie> mount: Mounting / on /root/initrd failed: Invalid argument
<ogra> hum
<Whoopie> this is to get the crash dump when usplash crashes on startup. Does anybody know how to mount the initramfs?
<ogra> seems i lost my compiz decorations with the recent uprade
<emgent> someone know why modsecurity is only in dapper and edgy?
<Khajavi> any one know how can I install php-gtk ?
<Fujitsu> That sounds so utterly and unspeakably wrong.
<blueyed> emgent: build failure? what's the package name exactly?
<jdong> Fujitsu: what, php-gtk? :D
<jdong> Fujitsu: I've been unfortunate enough to inherit PHP shell scripts before.
<Fujitsu> I too have inherited some lovely PHP shell-script imitations at work.
<emgent> blueyed: ?
<xtknight> any news on Bug 215778?  seems a little serious to me.  (all amd64/nvidia fail)
<ubotu> Launchpad bug 215778 in linux-restricted-modules-2.6.24 "2.6.24-16.30 kernel update - nvidia: module license 'NVIDIA' taints kernel" [Undecided,Confirmed] https://launchpad.net/bugs/215778
<emgent> Fujitsu: you know why mod-security is only in dapper-edgy ?
<xtknight> amd64+nvidia rather
<emgent> license problem ?
<xtknight> not sure.  regression from -15
<emgent> dendrobates: some idea? :)
<xtknight> nvidia freezes when you try to modprobe it (and it says taints kernel at bootup), but i dont know if it always says taints kernel
<emgent> anyway ubuntu kernel 2.6.24-16-generic have some problem
<Fujitsu> emgent: (From Debian) RoM; undistributable for legal reasons
<emgent> argh
<emgent> :(
<dendrobates> emgent: nope, I thought the main changes were in virtio.
<blueyed> xtknight: it always taints the kernel, that's a "normal" log entry. It fails somewhere after that then probably.
<xtknight> blueyed, yeah.  any suggestions on how to make its failure more verbose?
<emgent> blueyed: what build failure?
<blueyed> emgent: of "modsecurity". your already answered question.
<emgent> oh ok, now i understand :)
<xtknight> sudo modprobe nvidia reports a problem with the install command of nvidia.  then sudo modprobe -i nvidia says nvidia module doesn't exist, or something to that extent.  actually it was freezing but that was before l-u-m update.  after l-u-m updates there's just problems modprobing nvidia but it doesnt freeze on modprobe
<xtknight> it shows errors instead
<xtknight> if there is any debugging or cmds i could run to debug nvidia i would be glad to
<xtknight> people say the official nvidia.com one works
<xtknight> same version AFAIK
<kirkland> anyone around that can sponsor a fix to jockey?
<nucco> hi, anyone has a clue why rhythmbox grinds my HDD, and then freezes my system when I'm running on batteries?
<nucco> I'm asking in here because I think there'd be more clued folks...
<jscinoz> Where does the acpi/suspend whitelist live? Suspend works fine on my laptop but i don't want to wait around for upstream to add it.
<kagou> Good morning
<blaamann> This must be an Firefox package config error http://dpaste.com/44451/ ?
<blaamann> It is in Hardy
<jscinoz> acpi makes me cry.
<jscinoz> Where does the acpi/suspend whitelist live? Suspend works fine on my laptop but i don't want to wait around for upstream to add it.
<AnAnt> Hello, how can I create a source.changes file for a source package ?
<hunger> Would it be possible to update git-core to the new version?
<Mithrandir> hunger: while frozen for release?  Quite unlikely.
<hyperair> would it be possible to alter the gksu package to shift the nautilus-gksu extension to the correct directory?
<Whoopie> Keybuk: Hi, I tried to mount the initramfs, but it fails with "mount: Mounting / on /root/initrd failed: Invalid argument"
<Keybuk> Whoopie: did you remember --bind?
<Whoopie> Keybuk: command was mount -n -o bind / ${rootmnt}/initrd
<hyperair> change bind to --bind
<hyperair> eh wait
<hyperair> no
<Keybuk> mount -n --bind / ${rootmnt}/initrd
<Whoopie> ok, I try again
<Whoopie> Keybuk: btw, do you use thinkfinger? sometimes, hald-addon-input gets stuck and uses 97% cpu. and then, no sudo commands are working. reboot is the only solution
<Keybuk> no, I don't
<Keybuk> fingerprints are not a good authentication mechanism
<Keybuk> while they happen to be unique
<Keybuk> they're not _secret_
<Whoopie> yeah :)
<hyperair> but it is convenient isn't it
<Keybuk> you may as well just set no password at all
<hyperair> if there is no password then you can't authenticate can you?
<Keybuk> that's the point
<Keybuk> if there's no password, it's very convenient to use your computer
<hyperair> you can't log in if there's no password
<hyperair> very much like root
<Keybuk> yes you can
<hyperair> eh?
<hyperair> really?
<Keybuk> you just type your username (or click it) and you'll be logged in
<hyperair> but root has no password
<ion_> Reading a fingerprint is a nice alternative for typing your username when logging in, but not for typing your password. :-)
<Keybuk> no, root has a locked password
<hyperair> aaah
<hyperair> i see
<Keybuk> :*: <- locked
<Keybuk> :: <- no password
<hyperair> i see
<Whoopie> Keybuk: some error message
<Keybuk> hmm
<Keybuk> Whoopie: you put it as the last command before run-init?
<Whoopie> Keybuk: http://en.pastebin.ca/982154
<Keybuk> and you get invalid operation?
<Keybuk> *sigh* it clearly doesn't want to let you do that, then
<Whoopie> Invalid argument
<Keybuk> the initramfs / must be special in some way
<Amaranth> ion_: can you do that?
<Amaranth> make fingerprint match to username instead of using it for password, i mean
<Keybuk> Amaranth: not with pam
<tormod> pitti: you being the old "maintainer" and the only core-dev knowing this package, what do you think about bug #192772?
<ubotu> Launchpad bug 192772 in linux-wlan-ng "please merge linux-wlan-ng 0.2.8+svn1851+dfsg-1 from Debian main unstable" [Low,Confirmed] https://launchpad.net/bugs/192772
<Whoopie> Keybuk: hmm, I'm open to test anything you advice me :)
<Keybuk> ok
<Keybuk> remove the mount, but keep the ulimit
<Keybuk> edit /usr/share/initramfs-tools/scripts/init-top/usplash
<Keybuk> stick cd /dev/.initramfs just inside the if [ $SPLASH = "true" ] block
<Keybuk> update-initramfs -u
<Keybuk> then try again :)
<Whoopie> Keybuk: as first command inside the if block?
<Whoopie> where should I find the crash dump then?
<Whoopie> Keybuk: hmm, /dev/.initramfs has a core file.
<Whoopie> Keybuk: great, the core file is indeed from usplash. Core was generated by `/sbin/usplash -c -x 1024 -y 768'.
<Whoopie> Program terminated with signal 11, Segmentation fault.
<Keybuk> ok
<Keybuk> great
<Keybuk> add to your /etc/apt/sources.list:
<Keybuk>   deb http://ddebs.ubuntu.com hardy main universe
<Keybuk> then apt-get update
<Keybuk> and apt-get install usplash-dbgsym libusplash0-dbgsym]
<Keybuk> also libx86-1-dbgsym
<Keybuk> that should help you get a better stack trace
<emgent> heya
<Whoopie> so I need to reboot and catch a new core file, right?
<Keybuk> no
<Keybuk> you can trace that one
<Whoopie> ok
<Keybuk> the dbgsym packages just have the bits that were "stripped out"
<mdke> stgraber: i see a few documentation related ideas on brainstorm.u.c, could you perhaps create a "documentation" category for those? http://brainstorm.ubuntu.com/idea/5589/
<Whoopie> Keybuk: following https://wiki.ubuntu.com/Backtrace, I get: http://en.pastebin.ca/982176
<Keybuk> Whoopie: gdb /sbin/usplash core
<stgraber> mdke: doing a quick search on the website it appears we have ~50 ideas related to documentation or howtos. So we'll probably add a documentation category in the next code/db update (monday or tuesday)
<Whoopie> Keybuk: http://en.pastebin.ca/982178
<Keybuk> ok
<Keybuk> extract a full backtrace from that
<Whoopie> Keybuk: http://en.pastebin.ca/982182
<Keybuk> great
<Keybuk> can you file a bug with that?
<Keybuk> "usplash segfault in bogl_tcfb_put" and attach the trace
<Whoopie> I would attach it in bug 205990, ok?
<ubotu> Launchpad bug 205990 in usplash "[hardy] splash screen disappears after a few seconds" [Medium,Confirmed] https://launchpad.net/bugs/205990
<Keybuk> ok
<Keybuk> it looks to me like it's gone out of the bounds of the framebuffer
<mdke> stgraber: great, thanks. can the documentation team be given moderator rights over such a category? (~ubuntu-core-doc on LP)
<Whoopie> Keybuk: can i quote you in the bug report?
<Keybuk> sure
<Whoopie> done
<Keybuk> great, thanks
<Whoopie> thanks a lot for your help
<Keybuk> no worries
<Keybuk> given the level of that bug, it's sadly unlikely to get fixed in time for hardy
<Keybuk> but I'll make sure someone looks at it
<Whoopie> Keybuk: it's interesting that it doesn't affect everybody.
<Keybuk> Whoopie: yeah, can you add as many relevant details as you can think of?
<Keybuk> are you using i386 or amd64?
<Keybuk> what graphics card?
<Keybuk> what resolution?
<Keybuk> attach /etc/usplash.conf
<Keybuk> attach output of update-alternatives --display usplash-artwork.so
<Keybuk> also obviously dpkg-query -W usplash usplash-theme-ubuntu
<Whoopie> ok
<stgraber> mdke: we are not directly linked to LP (yet) so we can't use LP's team as ACL. But if you have people in the doc team interested in being a moderator on Brainstorm, ask them to reply to this mail : https://lists.ubuntu.com/archives/ubuntu-devel/2008-March/025155.html
<mdke> stgraber: sure thing; thanks
<mdke> stgraber: is it possible for ubuntu-core-doc members to have a developer role just for the documentation category, or are the permissions not so subtle yet?
<stgraber> mdke: permissions are common to the whole website for now. Developer on Brainstorm means (at least for me) : Someone who knows enough of Ubuntu's development to correctly answers questions about the release to come.
<stgraber> mdke: so some of your guys may also ask for the Developer role if they think they know Ubuntu's development well enough for that (as they are writting the doc I'd assume they do)
<mdke> stgraber: ok, thanks for the clarifications
<stgraber> np
<hunger_t> Mithrandir: You could stuff git-core into backports if it can not make it into the normal repos;-)
<kagou> is it possible to have translation packages rebuilt for hardy ?
<theunixgeek> The clipboard bug REALLY needs to be fixed.
<Keybuk> "the clipboard bug" ?
<Hobbsee> theunixgeek: clipboard bug?
<Hobbsee> [23:15] <theunixgeek> The clipboard bug REALLY needs to be fixed.
<Hobbsee> wfm?
<theunixgeek> Hobbsee: the one where you copy something from one application, close the window, and then try to paste it in another.
<Keybuk> theunixgeek: that's not a bug
<Hobbsee> theunixgeek: install gliper.
<Keybuk> the clipboard is designed to work that way
<theunixgeek> Keybuk: don't tell me that's a feature :P
<Hobbsee> theunixgeek: also note that the same behaviour is observed on all linux systems, and all windows systems.
<Keybuk> and is also designed to allow other applications to intercede to avoid it
<theunixgeek> Keybuk: it should be changed. it's extremely inconvenient
<Hobbsee> I'm unsure of on macs, but I expect it is the same.
<theunixgeek> Hobbsee: no.
<Hobbsee> theunixgeek: yes.  try it.
<Keybuk> I think it is the same on Macs
<theunixgeek> it isn't.
<Keybuk> or the Mac at least fails the same way as Windows (loses rich metadata and leaves plain text/wmf/etc.)
<theunixgeek> just tried it.
<Hobbsee> theunixgeek: vista?
<Keybuk> theunixgeek: remember that Macs tend to leave applications running when you close the window
<theunixgeek> opened textedit, typed "hello", copied, quit TextEdit, lauched safari, pasted
<Keybuk> you have to actually _quit_ the application
<theunixgeek> Keybuk: I quit the apps
<theunixgeek> Hobbsee: h/o
<theunixgeek> Hobbsee: same as the mac
<Keybuk> theunixgeek: try copying test from adobe acrobat with formatting into safari's html editor
 * Hobbsee doens't recognise h/o
<theunixgeek> Hobbsee: hold on
<theunixgeek> :)
<Hobbsee> theunixgeek: you will be pleased to note that your problem will be solved with glipper, or klipper, if you're of that side.
<theunixgeek> Hobbsee: I think it should be changed in Ubuntu itself. for newcomers it can be very inconvenient. I reinstalled 3 times to see if the problem could be fixed when I was a newcomer
<Keybuk> theunixgeek: it's on the roadmap, just a long way off
<theunixgeek> Keybuk: lol, should be pushed up
<Keybuk> there are far more important things closer
<theunixgeek> ok
<Keybuk> as with most things, if you'd like to hurry it along, help out! :-)
<Keybuk> most of the discussion of this kind of thing is taking place within freedesktop.org
<Keybuk> http://www.freedesktop.org/wiki/ClipboardManager
<Keybuk> for example
<theunixgeek> thanks
<Keybuk> http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt too
<Keybuk> there are a lot of attempts to work out how to do clipboards properly
<Keybuk> the principle problem is that a clipboard isn't just "text"
<Keybuk> it's actually an atom held by the copying application
<Keybuk> the pasting application can negotiate with the copying application the exact contents
<Mithrandir> and you have legacy apps.  If it was redone today, we'd probably have done it another way.
<Keybuk> so if you copy HTML from Epiphany, and paste into Abiword, the two can negotiate and agree a method of pasting that preserves formatting
<Keybuk> but if you paste into GEdit, the two might only negotiate a method that preserves the text
<theunixgeek> I see
<Keybuk> copy and SVG from Inkscape into GIMP, it might paste a bitmap of it
<Keybuk> but paste into GEdit, it might paste the actual XML data
<Keybuk> obviously if the copying application exits, the atom is lost
<Keybuk> which is why you see the behaviour you observe
<Keybuk> so, it's not a bug, because it's a side-effect of the clipboard being significantly more powerful
<Keybuk> but obviously, it's something that could do with more work :-)
<theunixgeek> I see
<theunixgeek> thanks for the information
<Keybuk> the usual way is that you have a third program
<Keybuk> which can keep hold of the atoms after the running application has quit
<Keybuk> that third program might only preserve a few common formats (this is what windows and mac do, iirc)
<Keybuk> or that third program might know how to start enough of the copying program back up again when it's needed for paste
<Keybuk> (OLE Clipboard on Windows, etc.)
<ion_> I'd really love to have all the different clipboards synchronized all the time.
<Keybuk> obviously if you were going to do this *right*
<laga> ion_: the "middle mouse button" clipboard and the "right click, paste" clipboard?
<Keybuk> you'd want the clipboard to be available over the network too
<ion_> laga: Yeah
<laga> ion_: yeah. annoying to no end.
<Keybuk> ion_: ugh, I like the fact they've made those separate :)
<infinity> Same...
<Keybuk> read the fd.o clipboard spec for why they MUST be separate
<Keybuk> (otherwise your Ctrl+C/Edit->Copy clipboard is overwritten every single time you highlight anything)
<ion_> keybuk: Yes, i know some people like it, but i would like to have the option for them to be synchronized, and i'm quite certain that the option should be on for newbies.
<Keybuk> ion_: apt-get source gtk
<Keybuk> that option should be OFF
<Keybuk> for exactly the reason explained above
<laga> Keybuk: then turn off the "copy to clipboard on highlight"
<Keybuk> newbies don't need to know about the middle mouse button shortcut
<Keybuk> laga: why?  it doesn't interfere
<Keybuk> with the way it is today, people who use Ctrl+C and Ctrl+V can keep doing that without surprise
<laga> newbies will find that shortcut eventually :)
<Keybuk> people who use highlight-click can keep doing that without surprise
<Keybuk> AND, most importantly, neither of them conflicts with each other
<laga> yeah, but you're right. it's not good to break existing behavior
<Keybuk> your suggestion would break *both* sets of people :-)
<laga> :)
<Keybuk> I suspect ion_'s real problem is that he's using Firefox, or OpenOffice, or some application that doesn't behave
<Keybuk> FF certainly used to just copy selection into every single clipboard it could
<laga> it's most apparent for me in ff, yeah
<ion_> Well, yeah. :-)
<Keybuk> see also "why Keybuk uses Epiphany #194"
<infinity> Firefox behaves better than it used to...
<Keybuk> ion_: so you want all applications to behave like the one broken one?
<ion_> I guess i would be happy if shift-insert did the right thing everywhere.
<Keybuk> ion_: that tends to mostly
<Keybuk> except, of course, Mono applications
<Keybuk> which for no readily apparent reason, ignore it
<infinity> Keybuk: Ironic, given the origin of the keyboard shortcut and the origin of Mono/.NET
<Keybuk> wasn't Shift-insert some IBM attempt to standardise?
<infinity> Widely used in DOS.
<infinity> Yay, edit.com
<infinity> Is it wrong that I still miss qbasic nibbles?
<Keybuk> infinity: I still miss QuickBasic
<Keybuk> that had a *to die for* IDE
<Keybuk> a debugger that could tell you the current value of the variable
<Keybuk> where it was set to that value
<Keybuk> what it was before
<Keybuk> etc.
<Mithrandir> Keybuk: I think somebody wrote about an extension to gdb where you could go back in time and get answers to questions such as "what touched this memory location last".
<tseliot> hi all, I'm having this problem with debdiff. Is it a known problem?
<tseliot> http://pastebin.com/m2d0aaf16
<tseliot> on Hardy
<Hobbsee> tseliot: what's at 489?
<tseliot> ï»¿Hobbsee: $first =~ s/ $dir1\/$sdir1/ $sdir1/;
<geser> tseliot: what did you tried to do?
<tseliot> geser: the MOTU guide suggests that we do somthing like "debdiff xicc_0.2-2.dsc xicc_0.2-2ubuntu1.dsc"
<geser> if called it like that then it should work
<tseliot> ï»¿geser: is this the only way to provide a patch? Would a diff -Nurb be acceptable in a bugreport?
<geser> if you do it in both versions of the unpacked source packages, it should be acceptable (but no guarantee)
<tseliot> ok, thanks
<geser> but I still fail to understand why debdiff failed for you
<tseliot> ï»¿geser: wait, problem solved, my bad.
<geser> what was the problem?
<tseliot> geser: well, I didn't notice that I was using the wrong version of the dsc as the first parameter. I should get some sleep :-p
<kirkland> Keybuk: you around?
<Keybuk> kirkland: yup, what's up?
<kirkland> Keybuk: bug #214914
<ubotu> Launchpad bug 214914 in jockey "jockey-gtk crashed with AttributeError in enabled()" [Critical,In progress] https://launchpad.net/bugs/214914
<kirkland> Keybuk: has 87 duplicates, and getting a whole lot of attention
<kirkland> Keybuk: pitti is probably in route back home now from Austin
<kirkland> Keybuk: i posted a debdiff last night
<Keybuk> has pitti reviewed that debdiff?
<kirkland> Keybuk: nope, he's probably traveling/jetlagged
<Keybuk> well, and it's a Saturday
<kirkland> Keybuk: yup
<Keybuk> I'd generally rather he reviewed it, since jockey is his baby
<Keybuk> he's back at work Monday morning
<kirkland> Keybuk: okay...  the debdiff adds a missing [0] on the end of any array, fwiw
<Keybuk> we're in freeze anyway, and I expect all the RMs are away
<Keybuk> so any upload wouldn't get processed until monday
<kirkland> Keybuk: fair enough
<kirkland> Keybuk: thanks for the info
<Hobbsee> Keybuk: all the RM's who can do anything, anyway.
<alex-weej> kernel update today in hardy, known issues?
<alex-weej> going from 24-15 to 24-16 has screwed me i think
<protonchris> alex-weej: is the kernel hanging when trying to load modules?
<protonchris> alex-weej: if so, there is a fixed package out.  It might on not hit your mirror yet.
<alex-weej> i am using the main archive now, i've got 24-16.30 installed right now
<alex-weej> let me try one more time and figure it out
<alex-weej> BRB
<alex-weej> 16.30 doesn't work from the main archives either...
<alex-weej> is taht the most up to date kernel?
<alex-weej> it appears that at least some modules are loading
<alex-weej> lsmod lists a lot
<protonchris> Might be a different issue then.
<alex-weej> but kvm_intel notably fails during startup
<alex-weej> there's lots of errors about snd_intel_hda symbols
<alex-weej> evilware-nvidia X doesn't work, trackpad doesn't work, and even my ethernet driver doesn't work
<alex-weej> and atheros wifi never worked in hardy so it is basically networkless!
<alex-weej> and -15 doesn't have any header packages in the archive anymore so i can't build my wifi driver :(
<protonchris> IIRC, my issues were fixed with the 2.6.24-16.22 version of linux-ubuntu-modules
<alex-weej> i have 16.22 of that already installed
<protonchris> No idea.  I haven't encountered any problems with the new kernel.
<alex-weej> are you on amd64?
<protonchris> No i386.
<alex-weej> ok
<hyperair> does anybody know anything about Bug #185854
<ubotu> Launchpad bug 185854 in gnome-system-tools "Setting static IP in Network Settings doesn't produce correct data" [High,Confirmed] https://launchpad.net/bugs/185854
<hyperair> it's a high priority confirmed bug but no action seems to be taken
<hyperair> if ubuntu hardy is released with this bug still open nobody will be able to set a static IP
<hyperair> not a very nice image to set for a LTS release is it
<Chipzz> hyperair: this is not the appropriate place to pimp your favorite bug ;)
<hyperair> sure it isn't
<hyperair> i'm just asking for opinions
<hyperair> and it isn't my favourite bug either
<Chipzz> also
<Chipzz> it's a weekend
<Chipzz> so you're not very likely to get opinions now ;)
<hyperair> aaah
<hyperair> i see
<Chipzz> btw, what you're claiming is plainly false: 18:18 < hyperair> if ubuntu hardy is released with this bug still open nobody will be able to set a static IP
<Chipzz> it's mentioned at the very top that if you correct /e/n/i it does work
<hyperair> hmm?
<hyperair> fine
<hyperair> let's correct that
<hyperair> nobody without technical knowhow
<Chipzz> haven't read the whole bug-report though
<hyperair> but yes the problem here is gnome's configuration of /e/n/i, not of the underlying network system
<Chipzz> people with static IPs are hardly ever people without technical know-how
<Chipzz> also
<Chipzz> another point
<hyperair> it doesn't work for DHCP users either
<hyperair> i've tried using DHCP on wlan0 and it doesn't work
<Chipzz> the recommended approach for configuring your network will be network-manager in hardy
<laga> Chipzz: even for servers?
<hyperair> that doesn't mean every other method should be broken
<pochu> for servers you aren't likely using gnome-system-tools
<pochu> hyperair: if I were you I would raise it on Monday on #ubuntu-bugs or #ubuntu-desktop
<hyperair> alright
<hyperair> i will
<hyperair> thanks
<Chipzz> laga: servers generally don't come wit a GUI, so recommended approach for servers would be /e/n/i (I think(
<hyperair> Chipzz:there are currently users who want to have both wired and wireless connections simultaneously on #ubuntu+1
<hyperair> imo it's not possible with networkmanager
<hyperair> and since the manual is fscked at the moment, there isn't a gui method
<Nafallo> hyperair: that is possible. you just need to configure your profiles.
<Nafallo> on my personal server I use quagga for configuring the network interfaces.
<hyperair> like through sys/admin/network?
<hyperair> it can be done through sys/admin/network
<hyperair> _if_ it works
<Nafallo> hyperair: yea. or network-manager/manual
<hyperair> but obviously it won't work at the moment _because_ of the above bug
<hyperair> and since it has been open for 4 months i'm beginning to get worried
<Nafallo> k
<afflux> hyperair in #ubuntu-bugs raised this, and I, too, think bug 185854 should be looked at asap.
<ubotu> Launchpad bug 185854 in gnome-system-tools "Setting static IP in Network Settings doesn't produce correct data" [High,Confirmed] https://launchpad.net/bugs/185854
<hyperair> eheheh i raised it here earlier afflux
<hyperair> i was told to go to #ubuntu-bugs
<afflux> omg
<afflux> I'm blind, forgive me please.
<hyperair> =D
<hyperair> thanks for your concern anyway
<afflux> I ran in this earlier, but I thought it was just me having forgotten something
<hyperair> hahahaa
<hyperair> np np
<afflux> anyway, I think this may even be critical importance, as I think there are quite a lot of people who don't like dhcp in their network. I could change it, but I think I'll leave the devs to decide this.
<afflux> brb, testing some n-m stuff
<syke> howdy
<syke> the -16 kernel update appears to have a broken nvidia module; there isn't a bug report yet
<syke> is this a case of waiting for the archive mirrors to update, or a known issue, or..?
<hyperair> i'd really like to reply, but i'd be replying to you in more than one channel xD
<syke> heh
<pecisk> Anyone knows any hope for fix before release for this https://bugs.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/185854?
<ubotu> Launchpad bug 185854 in gnome-system-tools "Setting static IP in Network Settings doesn't produce correct data" [High,Confirmed]
<laga> yeah, that'd be great
<Chipzz> pecisk: you're the 2nd one to ask in about one or 2 hours :P
<laga> you're not the.. right :)
<pecisk> Chipzz: yeah, but it is not even funny anymore :) such trivial bug in LTS, come on
<superm1> ugh whoever added kubuntu_30_displayconfig_no_xorg_correct_detection.patch to kde-guidance
<superm1> really fscked up things
<wasabi> Keybuk: congrats
<laga> why? (kde-guidance makes my X segfault)
<superm1> well because mythbuntu-common uses xorgconfig
<superm1> and suddenly xorgconfig returns tupples
<superm1> instead of contexts
<laga> ah. API breakage
<Chipzz> pecisk: I have made several comments on that to the previous guy
<slangasek> superm1: pitti has reverted it as soon as he noticed
<slangasek> it massively broke jockey as well
<superm1> slangasek, okay so an ubuntu14 upload will be fixing it then?
<superm1> ah yeah
<superm1> i see
<superm1> awesome.  thanks
<pecisk> Chipzz: it is not that I can't fix it manually by myself, I just would like to avoid to having Ubuntu bad reputation because of this :( Just question is there any hope for fixing this before final release? I wanted to try myself, but then fell ill
<Chipzz> pecisk: one thing I pointed out was the following:
<Chipzz> 18:24 < Chipzz> the recommended approach for configuring your network will be network-manager in hardy
<Chipzz> the gnome-system-tools way is deprecated as I understand it
<pecisk> o_O
<pecisk> it doesn't make sense
<pecisk> network-manager don't have manual IP configuration
<ogra> sure it has
<pecisk> nor it can write anything to /etc/network/interfaces
<pecisk> really, how?
<elmo> err
<elmo> "manual configuration in network-manager" == gnmome-system-tools
<ogra> click on the NM icon its the last optoin in the menu
<pecisk> gosh
<superm1> ogra, that opens network-admin i thought?
<pecisk> ogra, it _is_ g-s-t
<pecisk> duh
<ogra> oh, where did the NM tool for manual config go ?
<ogra> we had that in until beta
<pecisk> ogra, wonder, it NEVER had
<elmo> ogra: it never had one
<pecisk> ogra, it is for wireless networks
<pecisk> wow, there is saying "eat your own dog food" for reason, isn't there
<LaserJock> I thought it had one at some point to, but perhaps not
<Nafallo> ogra: you mean the link from network-manager to whatever is in gnome-control-center? :-)
<ogra> i'm pretty sure i had it in applcations->systemtools for weeks
<ogra> and that app was started from the NM menu at that time
<pecisk> and even so, g-s-t is way too advanced to bee deprecated just because someone can fix propably one liner
<LaserJock> oh, yeah. did that do static?
<ogra> i think so
<LaserJock> that was the Network Manager Editor or some such
<Nafallo> ogra: that's the network-manager thing indeed. that .desktop got dropped since it belongs in right-click nm-applet and choose edit wireless networks :-)
<ogra> yeah
<pecisk> it is for WIRELESS, damn
<pecisk> I want my manually configured IP address for wired network, and it worked until betas
<pecisk> ok
 * pecisk off to fix it myself
<laga> pecisk: make sure to add a debdiff to the ticket
<pecisk> sure
<laga> much appreciated.
<LaserJock> that would suck if wired static IPs wouldn't work anymore
<LaserJock> all my desktop machines have static IPs
<superm1> LaserJock, yeah i've seen a few people with mythbuntu boxes complaining that static ips stopped working too
<superm1> which it boiled down to that tool
<LaserJock> :(
<kestaz> why ubuntu hardy beta ships with transmission 1.06 ?
<jdong> kestaz: because 1.10 released too late for us to consider shoving it into Hardy blindly
<kestaz> jdong: so 1.10 will be in final hardy release ?
<jdong> kestaz: with input from a transmission developer I've decided to keep Hardy on 1.06 because it's been fairly well tested, and provide 1.1x in the hardy-backports repository
<kestaz> jdong: ok
<jdong> kestaz: right now Hardy's completely frozen and only important bugfixes are allowed in with case-by-case approval
<jdong> kestaz: but I've been testing 1.11 locally and preparing a backport for it. it should basically coincide with release day if all goes well
<alex-weej> are packaged kernels supposed to be ABI compatible within x.y.z-a versions?
<alex-weej> -16 broke some stuff today, but -15 is broken now, too
<alex-weej> at least, my sound modules won't load
<alex-weej> (unknown symbols)
<RussellGee> -16 works perfect with me
<alex-weej> amd64
<alex-weej> kills the nvidia driver
<alex-weej> there are lots of reports of it already, that's known
<alex-weej> i'm just perplexed as to why -15 is broken now too
<RaND1> bonsoir amis dÃ©veloppeurs ^^
<sommer>  zzzzzzzzzzzzzz444
<sommer> woops
<LaserJock> yeah, it is a snooze in here ;-)
<sommer> heh, mystyp
<sommer> mistyped... garr
<ion_> sommer: Booze and keyboards don't mix. ;-)
<sommer> heh, true, but this time my xo fell off my lap, and I mashed the keyboard picking it up :)
<sommer> the booze will probably come later, heh
<emgent> heya
<macogw> hi, i just uploaded a diff to bug #215729 and someone in #ubuntu-bugs suggested i ask in here about what to do next
<ubotu> Launchpad bug 215729 in seahorse "Seahorse fails to import keys" [Undecided,In progress] https://launchpad.net/bugs/215729
<Whoopie> macogw: you should diff with "diff -u ..." (just a comment from a user :))
<LaserJock> macogw: huh, that's rather annoying. I like to use seahorse for importing keys
<macogw> LaserJock: it would work for importing from a local file, but it couldnt download because it was doing search=ABCDEF12 instead of search=0xABCDEF12
<LaserJock> right yeah
<macogw> kinda seemed like core functionality of seahorse
<LaserJock> macogw: you know any packaging?
<macogw> no
<macogw> ive made one deb, and i had a friend sitting next to me telling me what to do
<LaserJock> macogw: can you check upstream for a bug report on this?
<macogw> there isnt one
<macogw> already looked
<LaserJock> k, odd
<LaserJock> I would think that would be noticed pretty fast
<macogw> maybe people assume someone else has already reported it
<LaserJock> just wondered if it was something we introduced but my guess is no
<macogw> its not in the debian/patches/ directory anywhere
<LaserJock> yeah
<LaserJock> well, I can turn your patch into a package, if you like
<macogw> ok
<afflux> macogw: I'm not a real glib programmer, but IMO as you're using gchar (and I think this is good) you should use the g_strcpy functions (or similar).
<macogw> afflux: oh. whats the difference?  i used gchar because the fpr var did and i didnt want to use different types and break what i know nothing about
<afflux> macogw: it's the glib character type, I'm not sure what the exact differences are ;)
<macogw> ok
<afflux> macogw: okay, I think it should be no issue for you. The glib docs list gchar as "Types which correspond exactly to standard C types, but are included for completeness"
<macogw> ok
<macogw> ive never really played with glib itself, just gone "O_o why all the renaming?" while poking at things that happen to use glib
<macogw> thanks for the info
#ubuntu-devel 2008-04-13
<pooq> hello
<TheMuso> .c
<pooq> anyone home?
<LaserJock> I'm actually at my grandfather's house
<LaserJock> slangasek: can I upload a fix for #215729 ?
<LaserJock> bug #215729
<ubotu> Launchpad bug 215729 in seahorse "Seahorse fails to import keys" [Medium,In progress] https://launchpad.net/bugs/215729
<iwkse> hello, i have some deb packages, ubuntu-language packages in hurdy, which have cyclic dependency and i can't install them. Anybody helps?
<iwkse>  hi, i'm trying  to install some deb packages, the ubuntu-languages ones in hurdy but installation fails due to dependency errors. Any help?
<iwkse> sorry wrong paste
<Fujitsu> Does Ekiga not do Pulse?
<lamont> WTF does music player steal *(^)*^_+ focus when it hasn't been told to, I wonder?
<Fujitsu> lamont: Rhythmbox?
<lamont> whatever the default app is for sound CDs.... give me a minute and I'll doublecheck which one it is
 * lamont finds himself getting closer and closer to putting something in to cause focus to be unstealable
<lamont> and I need to spend the time to fix compiz to understand keyboard-focus-policy == strict, like metacity does
<lamont> yeah - rhythmbox
 * lamont goes to file the bug
<lamont> bug 216593
<ubotu> Launchpad bug 216593 in rhythmbox "rhythmbox steals focus on startup" [Undecided,New] https://launchpad.net/bugs/216593
<lamont> stupid app
<lamont> I wonder how much of gnome I'm going to have to fork for my work surfaces to be usable again.  le sigh
<Fujitsu> lamont: Rhythmbox always knows best.
<macogw> lamont: huh?
<lamont> macogw: huh what?
<macogw> lamont: whats so unusable you need to fork gnome?
<lamont> gnome needs to stop stealing focus
<macogw> Fujitsu: does "rhythmbox always knows best" still include it not allowing you to interrupt its music playing to shut down?
<lamont> and given the time in the release schedule, it's doubtful that the bugs will be fixed before release --> fork
<lamont> oh, and I still need to figure out why I have no console-kit-daemon running on this machine...
<lamont> does that get started at login, or gdm-start?
<lamont> because with pmount going away, I get to do sudo mount for all my USB drive needs, which is really a sucky way to run a desktop
<macogw> lamont: its perfectly normal...if you're using fluxbox
<lamont> just because I put a CD in does not mean that I want rhythmbox to splat on my screen and interrupt the typing I'm doing in my mail app
<lamont> no clue what fluxbox is
<lamont> nor are there any processes on the machine with 'flux' in their ps output
<macogw> lamont: the window manager Damn Small Linux uses instead of a full DE
<macogw> lamont: there's a Fluxbuntu as well
<lamont> ok.
<lamont> I use metacity, was switching compiz-wards for some of the nice window features, learned that metacity's keyboard-focus-policy 'strict' magically turns into "click-for-focus" and haven't finished tracking down where to smack that so that it understands properly
<lamont> then again, given that 'strict' is documented only in the patch that has added it since warty, it's unsurprising that compiz has no clue about it
<macogw> why would metacity's settings affect compiz?
<lamont> well, not sure.
<lamont> I just know that when I change metacity's focus-policy to 'sloppy', then compiz behaves more correctly
<lamont> (and no metacity running on the box when compiz is on)
<macogw> does "more correctly" mean ffm?
<lamont> the specified window manager is metacity... no clue what compiz is doing to bolt itself in.
<lamont> ffm?
<macogw> focus follows mouse
<lamont> focus-policy "strict": The answer to the question "when should the new window get focus?" is "NEVER EVER EVER. KTHX"
<macogw> oh
<lamont> and other than that, it's focus follows mouse.
<lamont> so it tweaks the metacity logic where it's thinking about giving focus to a new window and says 'FAIL'
<macogw> oh wait oh neat
<macogw> er..just "oh neat"
<lamont> it does produce the interesting feature that the mouse can be sitting in the window, and the focus is still in the (completely obscured) window that had focus before the new window popped up
<macogw> yeah thatd be odd
<lamont> I haven't ever decided in the 3.5 years the patch has been there whether I consider that a bug, or a feature.
<macogw> i have a little problem like that with using multiple workspaces and ffm
<lamont> but it's definitely different
<lamont> apparently vncviewer feels that it should deiconify, center, and take focus on any videomode change, too.  TOTAL LOSS
<macogw> because if i have firefox maximized in focus on one workspace and switch to my pidgin workspace, even if my mouse is sitting right on top of an IM window, nothing on that workspace has focus
<macogw> i have to move out of the window over the desktop, then back to it to focus it
<lamont> is that because ffox took focus?
<macogw> yeah
<lamont> that'd be a firefox bug.
<macogw> but i dont think it should retain focus if it's not the active workspace
<lamont> I will forgive something that is asking for a password stealing focus.  That's about the only thing
<macogw> oh it is. you're right. gnome terminal releases focus when its not on the active workspace
<macogw> thats not a ff bug i expect to see fixed
<macogw> they have much more pressing bugs
<lamont> like tossing images into half-oblivion
<macogw> one of their devs finally got text shadow working....after the bug's been open since the 90s
<lamont> "just use view image and you can see it without it offset up and cropped" is not a solution
<macogw> its not in ff3 though, just in trunk
<macogw> they really need to fix the 10-year-old printing bug though
<macogw> i have to use Konqueror to print -_-
<lamont> hrm.. printing works for me...
<macogw> not always properly
<lamont> anyway, off to spend time with family.  bbl
<macogw> if a div runs over the end of the page and onto the next, it truncates it at the end of the first page
<macogw> k have fun
<matisse> i want to make a package of nspluginwrapper. what option should I use in dh_make ?
<matisse> "Type of package: single binary, multiple binary, library, kernel module or cdbs?"
<matisse> btw; Hi
<jdong> matisse: why are you making a package of it?
<matisse> didn't find it with apt-cache search
<matisse> And I thought it would be better if it is integrated in the package database
<jdong> matisse: nspluginwrapper is in Universe
<jdong> nspluginwrapper | 0.9.91.5-1ubuntu1 | gutsy/multiverse | source, amd64
<jdong> nspluginwrapper | 0.9.91.5-2ubuntu2 | hardy/multiverse | source, amd64
<matisse> I've added universe I think...
<macogw> matisse: did you apt-get update since adding it?
<matisse> dont know
<matisse> propably
 * ryanakca wonders how thunderbird got into main without a long description...
<matisse> sudo apt-get update ?
<jdong>  Thunderbird is a mail/news/RSS client. XXX Todo
<macogw> ryanakca: under the assumption that we all know what it is?
<ryanakca> Yes
<jdong> nice.
<ryanakca> macogw: Joe Average who just switched from <insert OS here> or Joe Average who isn't computer litterate probably doesn't know what Thunderbird is.
<macogw> ryanakca: i know, but im just guessing thats how nobody noticed...they didnt bother to check
<ryanakca> Ah
 * ryanakca guesses its too late to get a patch in?
<macogw> you can probably get that through feature freeze...its not like changing the long description is going to break any sort of APIs or anything
<ryanakca> Ok, will get to it
<macogw> one of my friends has a bug with update manager and figures its not being looked at because almost anyone able to fix it is probably using command line updates
<jdong> "XXX TODO" is a good sign this is by accident and not on purpose
<jdong> :)
<jdong> macogw: what is the bug?
<macogw> jdong: update manager's hanging when he hits apply, i think
<macogw> im searching launchpad
<ryanakca> macogw: *nods*... Its a pitty that everything is so much quicker and easier with the CLI than the pointy-click interfaces... once you know how that is...
<macogw> bug #192140
<matisse> jdong: well, i don't understand this. There are multiverse and universe package source added in /etc/apt/sources.list but I still dont find anything. Is it because I have a 32-bit system ?
<ryanakca> Who do I subscribe to the thunderbird bug?
<macogw> O_o ubotu timed out
<jdong> macogw: that is correct
<macogw> jdong: https://bugs.edge.launchpad.net/ubuntu/+source/synaptic/+bug/192140
<jdong> err, matisse
<ubotu> Launchpad bug 192140 in synaptic "update manager hangs at "applying changes" window" [Undecided,New]
<macogw> oh *now* ubotu works!
<ryanakca> All the sponsors, https://bugs.edge.launchpad.net/ubuntu/+source/thunderbird/+bug/195059
<ubotu> Launchpad bug 195059 in thunderbird "Thunderbird package description ends with "XXX Todo"" [Low,Triaged]
<ryanakca> There's a debdiff there and everything, you just need to upload it :)
<crimsun> matisse: cf. `rmadison nspluginwrapper'
<jdong> macogw: yeah LP is hanging erratically today
<macogw> odd
<macogw> i havent rebooted in 2 days so im gonna go do that so kernel updates go into effect
<macogw> brb
<matisse> nspluginwrapper | 0.9.91.5-2 | testing/contrib | source, amd64
<matisse> nspluginwrapper | 0.9.91.5-2 | unstable/contrib | source, amd64
<matisse> so, which problem is easier to solve ? :-)
<crimsun> use -uubuntu
<matisse> crimsun: with which command ?
<matisse> apt-cache search... ?
<crimsun> your version of rmadison doesn't default to "ubuntu".
<jdong> matisse: what is the purpose of nspluginwrapper on i386?
 * jdong is curious
<matisse> solving a problem with firefox
<matisse> http://clemens.endorphin.org/weblog/archives/2007-09.shtml#e2007-09-25T20_54_32.txt
<matisse> stop firefox from crashing on youtube f.e.
<jdong> matisse: interesting idea. well you can do simple modifications on the existing package to make it build on i386
<matisse> crimsun: well, now I got the same output, but why should I need that ?
<matisse> first of all I would like to download that package :-)
<crimsun> matisse: it answers your question from :55
<matisse> <matisse> so, which problem is easier to solve ? :-) ?
<matisse> my clock is a bit different I think :-)
<matisse> jdong: "existing package" - do you mean the package given on that website ?
<jdong> matisse: one sec I'll hack the package to build a 32-bit one for you
<jdong> took a bit more work than I assumed :D
<matisse> ok
<matisse> dh-make doesnt build a file.deb ...
<matisse> instead I have file.orig.taz.gz  and file.tbz2
<jdong> it's not meant to directly build a deb
<jdong> it turns a source package into a Debian source package
<matisse> and out of this I have to build a deb-package ?
<jdong> matisse: hold on I've almost got one built for you
<jdong> matisse: there's a threading crasher patch that's in the Ubuntu package which needed some tweaking to get rid of its 64-bit assumptions
<matisse> what other feature did you put in ?
<jdong> matisse: nothing. It's the Ubuntu package with as few changes as possible to make it build in 32-bit
<jdong> matisse: see if this works: http://jdong.mit.edu/~jdong/motu/nspluginwrapper_0.9.91.5-2ubuntu2+ia32~8.04prevu1_i386.deb
<jscinoz> Did Sun GPL their JVM yet?
<jdong> jscinoz: kind of
<jdong> openjdk is in hardy
<jdong> icedtea was in Gutsy
<jdong> the "stable" sun-java5/6 are still closed source DLJ licensed
<jscinoz> so for performance, what is better, sun-java6 or openjdk?
<jdong> I doubt they're any different
<jscinoz> i can't get either to use pulseaudio >_<
<jscinoz> they both need/take exlusive control of /dev/dsp >_<
<jdong> padsp?
<matisse> f**king dependencies...
<jscinoz> jdong, tried starting firefox with FIREFOX_DSP="padsp" java still eats /dev/dsp
<jscinoz> or fails out output sound if something is already using it
<jscinoz> also, java still doesnt show up in pavucontrol >_<
<jdong> matisse: what dependencies is it having trouble finding?
<jdong> matisse: could be my oversight
<jdong> debian/control looks fine to me
<matisse>  nspluginwrapper hÃ¤ngt ab von libcairo2 (>= 1.6.0); aber:  Version von libcairo2 auf dem System ist 1.4.10-1ubuntu4.4.
<matisse>  nspluginwrapper hÃ¤ngt ab von libpango1.0-0 (>= 1.20.1); aber:  Version von libpango1.0-0 auf dem System ist 1.18.3-0ubuntu1.
<jdong> matisse: are you running Gutsy?
<matisse> yes
<jdong> matisse: oops sorry, I assumed you were running hardy *slaps himself*
<jdong> one sec :)
<jscinoz> hmm
<jscinoz> why do the repos have both planetpenguinracer and extremetuxracer, afaik, extremetuxracer is the only fork actively being maintained
<jdong> matisse: try http://jdong.mit.edu/~jdong/motu/nspluginwrapper_0.9.91.5-2ubuntu2~ia32~7.10prevu1_i386.deb
<jdong> speaking of nspluginwrapper, I just realized today it doesn't actually build against firefox/xulrunner
<jdong> I wonder why the heck my rebuild of it in the archives "fixed" the bug for people
<jdong> do placebo bugfixes actually work or did something ABI-incompatible happen in GTK/glib-land?
<jscinoz> What are the advantages of usplash over existing, more advanced userland splash screens?
<jscinoz> seem's like duplication of effort
<Fujitsu> usplash works.
<Fujitsu> That one of them.
<Fujitsu> *That's
<jdong> and doesn't require anything in kernelspace
<jscinoz> What about splashy?
<jscinoz> its in the repos, runs in userland and is years ahead of usplash
<matisse> btw: installing worked
<jdong> splashy came after usplash :)
<jscinoz> with the next milestone bringing festival and GL support :D
<jscinoz> fbsplash is strange, supposedly runs in userspace, yet needs a custom kernel >_<
<jdong> am I the only one who just wants to get rid of all bootsplashes altogether? :)
<jscinoz> jdong then go purge usplash :P
<jdong> jscinoz: I do and it shaves 1.5s off my bootup
<jscinoz> splashy is so much better than usplash IMO, much simpler theming system, easier to make it work with hibernate/resume, and easy install
<crimsun> I figure if I'm running KDE4, startup time is the least of my worries.
<jscinoz> jdong, thign is when you've got working suspend/resume, and 10+ days without a full reboot, startup time doesnt matter too much :P
<jscinoz> Anyone else think that PPR could probably be nuked from the repo now that ETR is in there?
<jdong> jscinoz: as do I but suspend/resume is worthless in Hardy as a more than one day solution when you are testing core-level things which require a reboot t activate
<jscinoz> is there really any point having non-maintained forks in the repo?
<jscinoz> jdong, rebooting is for adding hardware! :P
<jdong> jscinoz: no it's not, it's also for applying new kernels, new glibc, etc etc etc
<jscinoz> aye :P i was just joking mate :P
<jscinoz> i use :P too much >_<
<jdong> jscinoz: and plus, boot time is one of those silly races geeks like to have with each other
<LaserJock> I boot a lot with my laptop
<jscinoz> windows xp cheats on boot time :P
<matisse> oh man, now I want to go on with that firefox enhancing and I dont even find a libflashplayer.so...
<LaserJock> several times a day
<jdong> jscinoz: and so far I'm down to 17s on a crappy macbook hard drive so I win :)
<jdong> jscinoz: XP doesn't cheat... it's just really good.
<jscinoz> loads the bare minimum to get the login scree nup, and then once you login you have like another 5min before its usable
<jdong> jscinoz: it does dynamic profiling, block reordering, and uses a parallelized bootup system
<jdong> jscinoz: IMO the login screen should be shown when it can be
<jdong> jscinoz: OS X is the true definition of cheating.
<jdong> jscinoz: launchd doesn't even fire up any services on bootup, it just sets up a dummy socket file. on the first access launchd then goes start the service
<jdong> i.e. it's like inetd for the whole system
<jscinoz> oh
<jscinoz> didn't know that
<slangasek> LaserJock: bug #215729> by "fix", you don't mean the patch that's been included in that bug report, right?
<ubotu> Launchpad bug 215729 in seahorse "Seahorse fails to import keys" [Medium,In progress] https://launchpad.net/bugs/215729
<jscinoz> my boot time is 23 seconds, using concurrenccy=shell
<slangasek> LaserJock: because that patch assumes that malloc() and g_free() can be used interchangeably, and also uses strcpy() and strcat()
<jdong> jscinoz: I use upstart :)
<LaserJock> slangasek: bah, I did use that
<jscinoz> i tried to get runit to work
<jscinoz> because its apparently very very fast
<LaserJock> slangasek: please reject the upload then
<slangasek> LaserJock: ok :)
<jscinoz> but i managed to break things to the point of needing a chroot to fix it
<LaserJock> slangasek: "It worked for me"
<jdong> jscinoz: most boot system errors do need a chroot fallback :)
<jscinoz> i overlooked that runit doesnt include any services >_< so you need a new init script for every damn service
<slangasek> LaserJock: yeah, it works, but malloc()+g_free() is technically wrong and may suddenly start segfaulting with some future version of glib2.0
<jscinoz> either that or i overlooked something
<LaserJock> slangasek: can you fix it or should I somebody to do it?
<LaserJock> *find somebody
<LaserJock> I need to stop IRC, I keep just randomly loosing words :-)
<jdong> LaserJock: I think I found one of your o's though :)
<LaserJock> darn
<jscinoz> jdong, i love that no matter how bad you mess things up, a chroot can pretty much always fix it
<LaserJock> I hate not having spell checky things in irssi
<Fujitsu> jscinoz: Whereas in Windows you're screwed.
<LaserJock> not that it would help with my inability to choose the right homonym
<jdong> jscinoz: oh, try trashing libc6 or the ext3 superblock area
<Fujitsu> This is why we have a backup superblock.
<jscinoz> filesystem damange is fun >_<
<Fujitsu> And backups.
<jscinoz> speaking of which, when is ext4 coming?
<Fujitsu> Damaging an LVM PV is worse :(
<StevenK> There is more than one backup superblock
<jdong> jscinoz: only when upstream considers it stable.
<jscinoz> jdong :P
<jscinoz> one thing that annoys me to no end, is the acpi whitelists
<jdong> jscinoz: a filesystem isn't one of those things to rush
<jscinoz> having a laptop that works perfectly with suspend but isnt whitelisted means i can't use s2both >_< only s2ram (with --force) and s2disk
<Fujitsu> Who do I file a bug against if g-p-m complains that suspend fails, when it works fine?
<jdong> Fujitsu: I'm guessing pm-utils
<jdong> jscinoz: well a bug should be filed against pm-utils to put your laptop in the whitelist
<jdong> jscinoz: the % of systems that suspend is definitely in the minority
<jscinoz> jdong already did, but i can't imagine them doing it this year >_<
<jdong> which is why the whitelist is there
<jscinoz> where does the acpi whitelist live anyway? i'd change it myself if i could find the darn thing
<Fujitsu> g-p-m lets it suspend, but complains on resume that it failed.
<jscinoz> jdong, any idea where the whitelist lives, i know my hardware works fine with the --force option to ignore the lack of whitelist entry, but obviously i can't use s2both without the entry, and thus i need to add it myself >_<
<Fujitsu> s2both? Is that like Vista's suspend to RAM and disk?
<jdong> Fujitsu: right
<jdong> jscinoz: I'm not 100% sure but I think we still use acpi-support for that
<jdong> jscinoz: see /usr/share/acpi-support
<jdong> you could just follow back from the s2ram script
<jdong> s/script/source
<jscinoz> jdong, i added my laptop in the appropriate file in there, however it still complains it's unknown >_<
<jdong> well you're a smart guy, look through the source to the pm-utils scripts :)
<jscinoz> alrighty :P
<jscinoz> how come the packaging for a bunch of packages is in svn/bzr, rather than coming with the source you get with apt-get source
<jdong> because it is easier to collaborate on / manage changes in a VCS
<jdong> and the packaging does come with the source package
<jscinoz> oh
<jdong> it's just that contributors are recommended to grab the VCS version which may be substantially newer
<jscinoz> meh, i'm only adding 3 lines to acpi-support and its only for my own use, so i honestly can't be bothered getting the vcs version :P
<Fujitsu> And makes people who do use the VCS substantially less furious.
<matisse> jdong: seems to work much better. thanks for the help
<slangasek> LaserJock: I can fix it, but not this evening
<jscinoz> i hate that.
<jscinoz> added my laptop to the whitelist, but the darn thing is still unknown
<jscinoz> I can see why torvalds hates ACPI :P
<LaserJock> slangasek: so if I can find somebody in the mean time it might be better? :-)
<slangasek> probably :)
<jscinoz> i bet i'm doing something really simple wrong >_<
<slangasek> jscinoz: suspend to ram/disk uses pm-utils now, not acpi-support
<slangasek> (so the really simple think you did wrong was to believe jdong, I guess ;-)
<jscinoz> and where could i find the  whitelist now?
<jscinoz> i was editing /usr/share/acpi-support/Dell\ Inc..config
<jscinoz> because thats what s2ram -l returns for me
<slangasek> I have no idea about whitelists
<jscinoz> see http://pastebin.com/m2c845158 and http://pastebin.com/m780596d6
<jscinoz> >_<
<slangasek> I just know acpi-support isn't used anymore for suspend/resume
<jscinoz> ack
<jscinoz> but why does pmi depend on it then?
<matisse> bye, thanks again for the help
<jscinoz> I'm unfamiliar with bash case syntax, would "XPS M1330"*) match "XPS M1330                    "?
<slangasek> should, yes
<jscinoz> strange
<slangasek> "pmi"?
<jscinoz> because thats what i've added to the whitelist but s2ram still says my model is unknown :(
<slangasek> acpi-support is still used for other things, just not for suspend/resume
<jscinoz> powermanagement-interface
<slangasek> may be a bug
<LaserJock> slangasek: so I'm assuing I want g_malloc instead of malloc
<slangasek> LaserJock: yes
<LaserJock> slangasek: what's wrong with strcpy and strcat though?
<slangasek> LaserJock: there's no bounds-checking in either of them; in this case the buffer is of fixed length so it doesn't have any immediate practical impact, but there is the risk that a change later to one part of the code without changing another would cause buffer overflows
<slangasek> so it's not a very defensive programming practice
<LaserJock> I see
<jscinoz> looking at http://pastebin.com/m2c845158 and http://pastebin.com/m780596d6 can anyone see why its not matching my laptop on the acpi whitelist?
<slangasek> the other thing I would worry about, if no one else has looked at these issues yet, is whether there are memory leaks...
<blueyed> slangasek: bug 63450
<ubotu> Launchpad bug 63450 in acpid "acpid install fails (because of hal running)" [High,Triaged] https://launchpad.net/bugs/63450
<jscinoz> hmm..
<slangasek> blueyed: does that have a verb to go with it? :)
<blueyed> slangasek: please look at it.. :)
<slangasek> blueyed: the patch looks reasonable/correct to me; I'm not in a position to sponsor it this evening
<jdong> slangasek: oops. What are the remaining things we use acpi-support for in Hardy? I always get confused on this
<jscinoz> acpi-support *seems* to contain the suspend whitelist
<jscinoz> but adding my laptop too it still makes it detect as unkown >_<
<Hobbsee> greetings
 * Hobbsee blinks
<Hobbsee> no, don't make it take 2000-odd days to download the new kernel, please.
<slangasek> jdong: acpi-support is used for mapping acpi events into something useful (like key events)
<slangasek> LaserJock: strncpy/strncat would be better, yes
<pitti> hey all
<pitti> Keybuk: I saw the music player bug, I'll look at it tomorrow
<pitti> megabyte405: wv> *shrug* it had been in main until gutsy, so it won't kill us
<megabyte405> pitti: ah, great.  Like I said, it's completely different than wv2, and I gather that wv2 was a moderately hostile fork/rewruite by the KDE folks and so now they're completely different
<pitti> superm1: I reverted that guidance patch completely, since the way he did it was absolutely wrong
<megabyte405> pitti: I have the AbiWord package all done and ready to go, so as soon as someone has time to look at it and approve it, we'll be golden
<pitti> superm1: so mythbuntu etc. should work again, too
<megabyte405> Is libloudmouth going into main?  It looked like it from component mismatch lists...
<pitti> megabyte405: that doesn't block uploading it
<megabyte405> pitti: OK.  I have the bug for the abiword 2.6 upload, with both sponsors and release team subscribed, but I haven't seen any action to move to the upload since I put up a "final" package a few days ago
<theunixgeek> Why did they change the 6.10 Beta wallpaper?
<laga> 6.10?!
<theunixgeek> laga: yes, 6.10!!! :D
<theunixgeek> http://www.thecodingstudio.com/opensource/linux/screenshots/index.php?linux_distribution_sm=Ubuntu%206.10%20Beta
<theunixgeek> the wallpaper was awesome.
<theunixgeek> anyone know where I can get it?
<theunixgeek> I think they should create a tarball of all past Ubuntu wallpapers, including testing ones.
<theunixgeek> Or have they already done it?
<kleppari_> hi, I just noticed that the lighttpd package creates the user www-data, with the login shell /bin/sh
<kleppari_> why does this user have a login shell?
<theunixgeek> Aha, I think they have! https://wiki.ubuntu.com/Artwork/Archives
<theunixgeek> Does anyone have the Edgy Eft beta wallpaper?
<elmargol> Hi I have a problem using dh_shlibdeps, is this this right place to ask some questions? in #ubuntu-moto noone answered my questions :(
<pecisk> People, there is a fix rolled in for serious bug, someone can take a look at it, please include in Hardy, yes, there are debdiff too. It works with lot of testing https://bugs.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/185854
<ubotu> Launchpad bug 185854 in gnome-system-tools "Setting static IP in Network Settings doesn't produce correct data" [High,Confirmed]
<crimsun> pecisk: most employees are back to work tomorrow (Monday local business hours)
<pecisk> ok ok
<james_w> pecisk: it's on my list of things to look at tomorrow.
<pecisk> thanks
<pecisk> :)
<james_w> I did say that in the bug report.
<pecisk> I did lot of testing and it works, sort of
<james_w> ah yeah, thanks for the testing, it's a good report of what you did, so it will help to know if this fix is appropriate.
<james_w> I haven't looked at the details yet.
<hklv> I'd like to recompile my own Ubuntu distribution for a specific target (geode-lx). I don't want to switch to Gentoo for this, because I'm a Debian/Ubuntu user. Where should I start?
<superm1> thanks pitti.  yeah i told our users to try again with the new guidance and things work correctly
<mdke> slangasek: I asked LaserJock to upload gnome-user-docs for me so you'll see it in the queue - similar to the ubuntu-docs upload of the other day it refreshes translations for LP and should be the last upload necessary
<mdke> *from LP
<superm1> mdke, did you find out if the FF translations issue will be resolved in time for the RC?
<awen-> pitti: I'm terribly sorry about the api-breakage in guidance-backend ... it was really not intended
<awen-> pitti: but thanks a lot for the quick reaction! ... very unfortunate that both I, and the one who sponsored the upload was away, when this happened
<mdke> superm1: no, I haven't heard anything.
<superm1> mdke, whom will be handling it?  asac ?
<mdke> superm1: I guess so. I mailed him a couple of weeks back but haven't heard anything
<asac> mdke: ?
<asac> once pitti is back i will proceed with the translations
<asac> mdke: haven't received a mail from you afaik
<xtknight> asac, i believe you were handling bug 213827 ?  not sure what the status of this is
<ubotu> Launchpad bug 213827 in flashplugin-nonfree "typo in prerm file breaks failed-upgrade processing" [High,Fix committed] https://launchpad.net/bugs/213827
<mdke> asac: that's a bit odd. I sent it on 24 March
<asac> xtknight: it hsa my approval. someone should upload
<asac> mdke: subject?
<mdke> asac: "Firefox default home page not translated/localized"
<mdke> asac: superm1 has taken the diagnosis of the bug report a bit further since I sent the email though
<asac> not in inbocx
<mdke> asac: that's a bit odd. Maybe it got spam filtered
<xtknight> asac,  ah ok anything i should do with the bug , then?
<asac> mdke: most likely. do you send html mails?
<mdke> asac: no
<asac> xtknight: yeah ... coordinate the upload ;)
<asac> find someone who can test and push the package to the various places.
<asac> i can do this, but it'll take some time until i have the time to do that
<xtknight> ok ill ask in motu
<asac> xtknight: thanks
<mdke> asac: if you happen to find out why it got filtered, I'd be interested: that way I can try and prevent it happening in future
<asac> mdke: i don't understand whats the problem
<asac> mdke: i found your mail ... i sorted it to my ubuntu list folder
<mdke> ah, ok.
<asac> mdke: as far as i understand it, it will show in the language you selected in the language selector
<asac> we will fix this in intrepid to use the environment instead, but in general it should work
<mdke> asac: superm1's analysis seems to suggest that it's broken because firefox translations aren't working yet.
<superm1> i experimented with a variety of languages, and nothing was translated whatsoever
<mdke> asac: but the startpage translation mechanism is rather complicated so that's why I posted the link to the page which Ian wrote to explain how it works
<asac> mdke: i think in short it just means: startpage is handled through alternatives
<asac> mdke: that alternative is independent from firefox locales
<asac> and is changed when you change the default language in language support
<asac> mdke: can you please test that this is the case?
<superm1> it appeared to me that the default start page is handled via the translation jar for FF in FF2
<superm1> because no alternatives are available in /etc/alternatives/firefox-home-page
<superm1> other than the default
<mdke> it's not so simple I don't think; because mozilla-firefox-locales-all  is built against ubuntu-docs and we can't add languages in ubuntu-docs which don't have firefox translations in existence
<superm1> and that's how it was in FF2
<mdke> I'll try switching the default language now, but I doubt it works, otherwise the bug wouldn't have been filed
<superm1> that's exactly what i've done already.  i've installed into a different language using recent daily disks, and i've also tried to switch the language using the language support drop down
<superm1> (in system->administration)
<asac> mdke: yeah ok it was done by the locale packages
<asac> what a crappy mechanism
<mdke> asac: yes; it was quite complicated but I understood that there was no other way
<mdke> asac: so do you think when firefox translations are fixed it will work again?
<asac> its not in firefox anymore, but in ubufox
<asac> let me check what happens if i install kubuntu-docs
<mdke> bbiab
<asac> ok so what do we want? always display /usr/share/ubuntu-artwork/home/locales/index-LANGCODE.html ?
<asac> and use -C.html in case it doesn't exist?
<asac> there is something broken. that page doesn't point to the translated page for kubuntu
<asac> Riddell: is the alternative mechanism broken for kubuntu?
<asac> read above
<asac> only kubuntu-LANGCODE.html point to the translated kubuntu file
<asac> every index-LANGCODE.html points to the english kubuntu thing
<asac> mdke: superm1: http://people.ubuntu.com/~asac/ubufox.xpi ... try that and be sure that you disable networking in network manager before starting firefox the next time
<asac> otherwise you will end up on an online page
<asac> mdke: you need the translation installed to make this work
<asac> superm1: ^^
<asac> for now just install the .xpi from mozilla.org for beta5
<superm1> asac, okay give me a few moments.  this machine that i'm on doesn't have any other locales in place.
<asac> http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0b5/linux-i686/xpi/
<asac> superm1: first instlal the langpack from that url ... then update ubufox
<asac> then restart after going offline :)
<asac> (in nm)
<asac> before restart export LANG=lang_code
<superm1> a well forward order would have been useful :)
<asac> he?
<asac> i see. sorry for that
<superm1> okay let me go offline and see how it works for the start page now
<superm1> back in a min
<superm1> asac, Â¡Bienvenido a Ubuntu 8.04 LTS!
<superm1> :)
<asac> superm1: be sure that you are looking at offline page
<superm1> i made sure
<superm1> the URL was a local URL
<asac> so you have file:/// in url=
<asac> ?
<asac> ok
<superm1> (after ubuntu-docs was installed)
<superm1> yeah
<asac> now i only have to figure why index-LANGCODE.html always points to english page in kubuntu
<asac> superm1: can you confirm that it does
<asac> ?
<superm1> in kubuntu?
<asac> well ... if you install kubuntu-docs :)
<superm1> i've only got an ubuntu install
<superm1> oh
<superm1> let me see
<awen-> asac: I'm on kubuntu hardy ... what should I check?
<asac> awen-: /usr/share/ubuntu-artwork/home/locales/index-de.html ?
<asac> is that translated? or just the english kubuntu page?
<superm1> shouldn't it be : /usr/share/ubuntu-artwork/home/locales-kubuntu
<superm1> the index-LANG.html files are in the directory i just said above ^
<asac> superm1: the home/locales is a alternative
<superm1> ah
<asac> firefox-homepage-locales
<asac> its a slave of firefox-homepage
<asac> so if you change that ... it should auto change that dir link as well
<asac> it does that for me, but there is crap in that dir
<awen-> asac: it is just the english
<asac> yeah
<awen-> both in locales and in locales-kubuntu
<asac> look at the content of the locales-kubuntu directory
<asac> the links are bogus
<asac> they should point to the kindex-LANGCODE.html ones imo
<asac> instead every index-XXX.html points to index.html
<superm1> well /usr/share/ubuntu-artwork/home/locales-kubuntu/kindex-es.html is all in spanish
<superm1> as it should be
<asac> superm1: yes. but look in the dir
<asac> the links are wrong
<asac> index-de.html -> kubuntu-de.html that should be ... but it isn't
<superm1> hm oh i see
<superm1> you're right
<asac> did it ever work for kubuntu?
 * asac  installs kubnutu-docs in dapper
<asac> superm1: how does the online page work for you btw?
<superm1> it appeared to redirect properly
<asac> is it instantaneous?
<superm1> both when i had the locale to spanish or english
<superm1> <1 sec
<superm1> it was pretty quick
<asac> good
<superm1> what was the incentive in it's implementation?  to provide more up to date links and translations more easily when available?
<asac> ok in dapper thre were no translations at all
<asac> superm1: the idea is to provide a better homepage for users that are online
<asac> dapper == no translations for kubuntu
<superm1> ah.  a more "relevant" homepage w/ online links and such
<asac> yeah
<asac> news, more links to online resources and all that
<asac> i have no idea how it will look like in hardy though. its still being worked on
 * asac installs kubuntu-docs in feisty
<asac> no translations for kubuntu in feisty either :/
<asac> last chance: gutsy ;)
<Dossy> Hi, I've been searching on the wiki - how do packages make it from Debian into Ubuntu?
<superm1> Dossy, they are synced during the first 2/5 of the development cycle automatically when there is no variance, and merged manually by MOTU and core-dev otherwise
<Dossy> superm1: thanks!
<superm1> np
<asac> ok translations existed in gutsy, but links are broken
<asac> so not a regression
<asac> anyone can confirm that the local startpage was never translated in firefox in kubuntu?
<asac> awen-: ?
<mdke> asac: I believe that kubuntu-docs has added translations for hardy. nixternal is the guy who will tell you for sure
<asac> not online :)
<mdke> not currently
<awen-> asac: I have allways used kubuntu in english, so I don't really know, sorry
<Dossy> So, is there a name for the version _after_ hardy heron?
<megabyte405> intrepid ibix
<Dossy> Oh my, you're not kidding.  Intrepid Ibex ... wtf?  https://lists.ubuntu.com/archives/ubuntu-devel/2008-February/025136.html
<mdke> it's only a codename
<Dossy> well, it seems people often refer to the versions by their codenames... ubuntu gutsy, hardy ... intrepid?  heh.
<mdke> I like it, myself
<Dossy> it's definitely not the worst, and it's only for 6 months anyway :)
<bardyr> Dossy, its not that bad people will just call it ubuntu mountain goat
<asac> anyone here can reproduce bug 212648
<ubotu> Launchpad bug 212648 in linux-restricted-modules-2.6.24 "[nvidia-new] a visit to http://www.themareks.com/xf/ in firefox hardy causes X to restart" [Medium,Confirmed] https://launchpad.net/bugs/212648
<laga> asac: not me. running nvidia 169.12+2.6.24.12-16.34 on hardy amd64 with a geforce 7600GS
<asac> laga: what xorg options?
<laga> http://www.pastebin.ca/983913
<laga> the singlecards one is in my serverlayout section
<asac> laga: that paste is empty
<laga> sorry
<laga> asac: not empty for me?
<johanbr> asac: Works for me too. Same driver version, 8400 card.
<asac> maybe use paste.ubuntu.com ... no idea whats going on
<asac> oh now it works
<asac> strange
<laga> asac: http://paste.ubuntu.com/6925/
<laga> heh
<asac> laga: any change if you remove the argb options?
<laga> brb
<johanbr> asac: No argb options for me. Still works.
<laga> no change
<laga> still working
<laga> thanks for pointing me to that web page
<asac> k thx for testing
 * laga logs X files
<laga> err, loves
<asac> lol
<tseliot> asac: no problems with my 7300. It looks like only geforce 8400 and 8800 cards are affected.
<rep> i was guided here from #ubuntu - we were trying to find the package python-samba (samba-python?) which consists of python bindings to samba and existed in ubuntu feisty and also does in debian etch. but gutsy is somehow missing it... i am on my way to building them from source now - but wondered where the package is...
<pheld> is there a workaround for the delay compiz introduce to gtk widgets on multihead setups yet?
<pheld> on display :0.1 everything works ok, but on :0.0 application menus etc have a delay of 2 or 3 sec before anything happens
<stgraber> rep: python-samba only existed in Feisty (according to rmadison)
<asac> anyone with geforce 8400 or 8800 here?
<asac> if so, please test the url in bug  bug 212648
<ubotu> Launchpad bug 212648 in linux-restricted-modules-2.6.24 "[nvidia-new] a visit to http://www.themareks.com/xf/ in firefox hardy causes X to restart" [Medium,Confirmed] https://launchpad.net/bugs/212648
<johanbr> asac: As mentioned, I have an 8400 card. Works fine.
<asac> then i don't know
<johanbr> asac: Oh, I'm supposed to click a link too. Let me check.
<asac> hehe
<stgraber> bug seems to be confirmed :)
<asac> stgraber: you see it?
<stgraber> asac: no but the "Remote closed the connection]" just after he clicked a link :)
<asac> hehe :)
<asac> i don't see quits and joins :)
<asac> tjaalton: bryce: what xorg version do we have atm?
<stgraber> probably not a bad thing if you are in chans like #ubuntu :)
<tjaalton> asac: 7.3
<asac> tjaalton: its a mystery how to figure that
<asac> i see 2:1.4.1~git20080131
<tjaalton> it's basically what the xorg-server is
<asac> ah
<asac> :)
<asac> tjaalton: what version is 1.4.1?
<tjaalton> so R7.3 had xorg-server 1.4..
<asac> tjaalton: why do we ship a pre snapshot of 1.4.1?
<tjaalton> asac: because 1.4.1 won't be released
<asac> never or just not in time?
<tjaalton> 1.5 is close
<tjaalton> never, it seems
<asac> and 1.5 will be released in sync with fedora i guess?
<tjaalton> yes
<asac> that sucks
<asac> tjaalton: how many x devs are redhat guys?
<tjaalton> why? at least it's released.. it was originally planned to be released in February :)
<tjaalton> at least ajax and airlied
<asac> tjaalton: well, it sucks that we will ship a nightly while fedora will get the stable thing
<johanbr> asac: As you might have guessed, that link did crash X for me.
<tjaalton> our version is a stable version
<tjaalton> 1.4 + fixes
<asac> i thought 1.4.1 is not released?
<asac> ok
<tjaalton> it was planned, and there's a git branch for it which we've synced with
<asac> johanbr: ok. thanks.
<asac> tjaalton: so we have the very latest from 1.4 branch?
<tjaalton> asac: yes
<asac> or are we missing fixes?
<tjaalton> asac: we should have everything from the 1.4-branch, but certainly it's 1.5 that gets most of the attention now
<asac> tjaalton: do you have a fglrx setup?
<tjaalton> asac: nope.. (and btw, fglrx/nvidia don't work with 1.5 yet, nvidia beta does)
<asac> ok
<asac> tjaalton: do you have a xaa setup?
<asac> (!= nvidia)
<tjaalton> asac: you mean the zoom-bug?
<asac> yeah ;)
<asac> i fell really bad about releasing with black images on ubuntu.com just one click from homepage away :(
<tjaalton> hmm no, I've got nvidia and intel (exa)
<tjaalton> i know, but it's not fixed upstream yet :/
<asac> its tricky irony to have a black image next to the paragraph that reads "ubuntu just works" :/
<asac> tjaalton: strange things about all this is that neither the image tiling corruption bug nor the black image bug is reproducible with xserver in gutsy
<asac> at least thats what people told me (no guarantees)
<tjaalton> asac: "someone" should git-bisect :)
<ion_> I haven't taken a look at the bug report about the black image issue, but the image's offset actually seems to be calculated incorrectly. On many images, the picture goes completely outside the black box, but on some images, a part of the image is visible within the box.
<ion_> That might help with tracing it down.
<asac> ion_: yes, but thats a x bug
<asac> ion_: it works with exa
<asac> ion_: you can see that by scaling http://www.ubuntu.com/files/u3/desktop-tn.png
<asac> it matches your description
<ion_> Yeah
<asac> and you cn fix it by XAANoOffscreenPixmaps "true"
<ion_> Ok, thanks
<ion_> Would it be a huge performance issue to use that workaround by default.
<ion_> ? that is.
<tjaalton> AIUI it would hurt performance on non-composited desktop
<asac> yeah thats what bryce said. but personally i don't see any performance impact on my desktop :)
<asac> i am now asking cworth if there is a way to make cairo mimic that behaviour somehow
<ScottK2> slangasek: Are you around?  I'd like permission to upload a non-api breaking fix to Bug #203378.
<ubotu> Launchpad bug 203378 in kde-guidance "Guidance displayconfig does not automatically detect monitor config on systems with no xorg.conf" [Medium,In progress] https://launchpad.net/bugs/203378
<asac> but that would likely slow down all firefox users i guess
<asac> dunno what is worse
 * ScottK2 heads out to dinner and will read the scrollback.
 * asac in cairo hack mode ...disabling xrender everywhere
<slangasek> ScottK2: go ahead
<asac> tjaalton: bryce: turns out that fedora has XaaNoOffscreenPixmaps "true" by default for every driver
<tjaalton> asac: really? I want some proof :)
<asac> 22:09 < otaylor> asac: as I said, we disable offscreen pixmaps by default
<asac> tjaalton: he gets me a prove now :)
<tjaalton> oh right..
<asac> tjaalton: something else:)
<asac> 22:11 < cworth> vlad_: Not with XAANoOffscreenPixmaps=True, there's not. That fixes performance and  quality bugs.
<asac> so it appear to fix performance bugs :)
<tjaalton> "xserver-1.5.0-xaa-sucks: Disable XAA offscreen pixmaps by default.  They're almost always a performance loss anyway.  Use Option "XaaOffscreenPixmaps" to turn them back on.
<tjaalton> "
<asac> bryce: ^^^ please read the last few lines and make this happen :)
<asac> 22:12 < otaylor> $ cvs -d :pserver:anonymous@cvs.fedoraproject.org:/cvs/pkgs get xorg-x11-server     look at devel/xserver-1.5.0-xaa-sucks.patch
<tjaalton> oh bugger.. "Remove vmmouse again, way too broken.  Let this be a lesson to you: never try.
<asac> 22:13 < asac> cworth: so performance improves as well with XAANoOffscreenPixmaps=True ?
<asac> 22:13 < cworth> asac: Often, yes.
<asac> ok enough i guess ;)
<tjaalton> soren: ^^
<soren> tjaalton: Wuh? Says who?
<soren> tjaalton: Or where is that quote from?
<Riddell> asac: no
<tjaalton> soren: so sayeth ajax (it's from the fedora xorg-server changelog)
<asac> Riddell: sorry ... what did i ask :) ?
<asac> Riddell: if translation ever worked in firefox?
<soren> tjaalton: They've been using it by default for several releases now?
<Riddell> asac: "is the alternative mechanism broken for kubuntu?"
<soren> tjaalton: ..or so I'm told.
<asac> Riddell: please look in the folder with index.html
<asac> Riddell: the links are wrong
<asac> the alternative mechanism is correct, but all languages link to index.html
<tjaalton> soren: apparently not anymore.. I need to check if it's due to hotplugging changes that it got dropped
<soren> tjaalton: Are we going to follow suit for hardy?
<soren> tjaalton: If so, could we at least use mdetect's vmmouse detection stuff and enable it conditionally?
<tjaalton> soren: if we revert the change then yes
<soren> tjaalton: That would be lovely. I would have been happy that way from the start! :)
<tjaalton> soren: good :)
<soren> tjaalton: Er... If you do, please poke me. I have a tiny, tiny patch to the vmmouse code that makes it work for kvm as well as vmware, by the way.
<soren> tjaalton: By "vmmouse" I mean the detection code in mdetect.
<asac> Riddell: do you see what i mean?
<tjaalton> soren: ok, will do
<asac> Riddell: http://paste.ubuntu.com/6929/ (ubuntu-docs) ... http://paste.ubuntu.com/6930/ (kubuntu-docs)
<Riddell> asac: ok, I'll look at that tomorrow
<asac> Riddell: thanks
<Tyrone> hi, is anyone capable of helping out with a java bug?
<Amaranth> is cdimage down?
<Nafallo> np
<Nafallo> no
<davmor2> Amaranth: I can access it
<Amaranth> yeah, it seems touchy
<Amaranth> i can connect again now
<Amaranth> and now i can't
<Amaranth> wth
<Nafallo> Amaranth: run a mtr against it then :-)
<Amaranth> it dies in canonical
<Amaranth> it's connection refused error
<Nafallo> let me run a mtr :-)
<Amaranth> and going again
<Amaranth> and going fast this time, yay
<davmor2> Amaranth: try running on chromium.ubuntu.com/cdimage
<Nafallo> carbon works for me :-)
<Amaranth> and now its slowing down again :/
<Amaranth> crap
<Amaranth> 99K/s
<Nafallo> Amaranth: which host are you going to?
<Nafallo> Amaranth: netstat :-)
<Amaranth> starts with a b?
<Nafallo> beryllium :-)
<Amaranth> yeah
<davmor2> it plays up go with chromium it's stable
<Amaranth> connection error :/
<Nafallo> hmm. I only get beryllium from host now :-P
<Amaranth> can't wait 90 minutes to get this iso
<Nafallo> Amaranth: what iso is it?
<Amaranth> daily amd64 live
<Keybuk> *sigh*
<Keybuk> printing is an absolute *mess* in hardy
<soren> Please don't tell my printer that.
<Amaranth> worked fine last time i tried it
<Amaranth> although that was 2 months ago
<Keybuk> every single time I print:
<Keybuk> Apr 13 22:14:31 quest HP_LaserJet_1018?serial=KP0VDES: prnt/backend/hp.c 496: unable to connect hpssd socket 2207: Connection refused
<Keybuk> Apr 13 22:14:31 quest kernel: [204293.531254] usblp0: removed
<Keybuk> and then it won't print again unless I purge everything and redo it from scratch
<Nafallo> Amaranth: mirroring :-)
<Amaranth> going to chromium sends me to cdimage.ubuntu.com :P
<Nafallo> Amaranth: http://home.nafallo.info/tmp/hardy-desktop-amd64.iso
<davmor2> http://carbon.ubuntu.com/cdimage/daily-live/current/hardy-desktop-amd64.iso
<Amaranth> hrm, starting to blame my ISP :P
<Amaranth> Nafallo: i only get 60K/s from your link
<Amaranth> and 150K/s from davmor2's
<YokoZar> Is the login screen supposed to be centered?  This changed for me recently
<Vadi> Anyone know if a channel for help on application development on ubuntu?
<ion_> vadi: The distribution is irrelevant in that question.
<Vadi> ion_: Sorry, didn't catch you there.
<ion_> Application development on Ubuntu is just like application development on any other similar platform.
<YokoZar> Vadi: Basically developing applications for Ubuntu isn't much different from developing applications for Linux in general.  If you've already got an application and want to package it, then #ubuntu-motu is a good idea
<Vadi> No, I don't want to package it for Ubuntu. I
<Vadi> *I'm just having trouble with making a launcher for it - it launches fine in the terminal, but fails when I use xterm. Is there a channel where a dev can get help?
<Vadi> I need the exact opposite of "Development of Ubuntu (not support, not application development on Ubuntu)", second part. Does something like that exist though?
<ion_> If you're programming in C, search for a C channel. If you're programming in Ruby, search for a Ruby channel, etc.
<Vadi> It's not a programming-language specific language though. Just trying to make a graphical launcher for my program.
<Vadi> (which is command-line only, but requires no input, and is used by non-technical people)
<ion_> You must be using *something*, search for channels about that something. :-P
<ScottK2> slangasek: Thanks.  I'll try and get finished with testing and upload later tonight.
#ubuntu-devel 2009-04-06
<ScottK> slangasek: kde4libs built on ia64 after your qt4-x11 fix.  Thanks.
<calc> is usr/share/icons/locolor still a legitimate icon theme dir?
 * calc was wondering if he should remove that along with the gnome dir from OOo since iirc that was an old kde 2.x dir
<Riddell> calc: it's just an icon theme like any other
<Riddell> it's the KDE 1 icons which do still exist in kdeartwork for anyone strange enough to want them
<Riddell> no point keeping them in OOo anyway
<calc> ok
<calc> that removed ~ 250KB from openoffice.org-common :)
<Hobbsee> sbeattie: yeah.  maybe mine just hates the world or something, although i think i saw someone else mention it in -bugs a fwe days ago
<slangasek> ScottK: aha, great \o/
<slangasek> ScottK: now it's just hppa (strigi) cluttering up component-mismatches
<ScottK> slangasek: I got started on retries.
<ScottK> Unfortunatlely sparc didn't like something about your qt4-x11 change.
<slangasek> I had already given back strigi once this morning on hppa, still FTBFS with the same error; apparently qt is uninstallable there
<slangasek> bah, sparc shouldn't have cared about that change at all, it's just being a whiner
<picklesworth> is there some accepted standard for passing files between running apps that talk to each other over dbus?
<picklesworth> or should I just do whatever makes sense? :)
<slangasek> bleh, qt on hppa needs manual bootstrapping; phonon and qt have a circular dep.
<ScottK> Ouch.  When did we do that?
<slangasek> ScottK: qt4-x11 (4.5.0~+rc1-0ubuntu1), 19 Feb 2009, AFAICS
<lamont`> wtf does network mangler ((or whoever) decide to put both search and domain directives in named.conf?
<lamont`> slangasek: ew
<lamont`> er, resolv.conf that is
<slangasek> you object to having both?
 * lamont makes a note to remember to edit network mangler's postinst _BEFORE_ removing it remotely next time
<mneptok> lamont: i'm in Boston, and will accept assassination contracts for Red Hat's Westford office ;)
<lamont> mneptok: I do not publicly issue contracts for wetwork
<lamont> it's amusing how many people think that having domain and search directives in resolv.conf actually does anything
<lamont> (other than helping pre-1990 programs)
<lamont> meh.  not worth figuring out what all dbus is doing under the covers for the networkmanager stop call in prerm
<lamont> I just hate fighting network mangler, is all
<lamont> the cute part this time was that since it got dragged in on the upgrade, the machine got ipv6 addresses only.. not sure why it hated the ipv4 dhcp response
<lamont> (and it was an old-n-crufty machine, so not sure I care enough to worry about it)
<slangasek> lamont: huh?  of course search and domain directives do something...?
<calc> OOo 3.0.1-9ubuntu1 will be uploaded in about 2hr
 * calc headed to bed now
<shahan> hi, i was wondering if sed supports backreferences in ranges using patterns?
<robert_ancell> does anyone know of a public sftp server I can connect to to test bug 27109?
<ubottu> Launchpad bug 27109 in nautilus "nautilus uses 100% cpu after closing a ssh session" [Medium,Triaged] https://launchpad.net/bugs/27109
<seb128> hey robert_ancell
<robert_ancell> seb128: hey seb
<hyperair> robert_ancell: set up a ssh host locally?
<seb128> robert_ancell: don't you have ssh access to the GNOME boxes to upload tarballs or to some canonical servers?
<robert_ancell> hyperair: yeah, was thinking of that but looking for easier option first :)
<hyperair> robert_ancell: or register for an account at alioth.
<hyperair> robert_ancell: but really, you can't get any easier than sudo apt-get install openssh-server =p
<robert_ancell> hyperair: does that do sftp?  Or is sftp just scp?
<hyperair> robert_ancell: sshd does sftp and scp
<hyperair> robert_ancell: they're different protocols i think,  but they're both provided by sshd.
<robert_ancell> hyperair: cool, my local server was already working for sftp :)
 * robert_ancell finds it confusing that nautilus refers to sftp as "SSH"
<hyperair> robert_ancell: hahah =p
<hyperair> well it is ssh://
<hyperair> sftp:// and ssh:// are equivalent.
<robert_ancell> 2 products for the price of 1!
<hyperair> heh
 * hyperair prefers rsync through ssh
<bryce> kirkland: here's the page I mentioned the other day - http://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.html (and let us know how the race went)
<Ng> slangasek: is it just me, or did your upload of hotkey-setup break its init script?
<Ng> lala, nm, there's a bug report already
<lamont> slangasek: only one of them does, removing all effects of the other
<lamont> I think the last one matters, but haven't bothered to check
<Ng> slangasek: bug #356157
<ubottu> Launchpad bug 356157 in hotkey-setup "package hotkey-setup 0.1-23ubuntu10 failed to install/upgrade: subprocess post-installation script returned error exit status 2" [Undecided,Confirmed] https://launchpad.net/bugs/356157
<cjwatson> I've answered the mail to ubuntumembers about Ubuntu community training with proper references; I imagine I'm not the first to have done so but thought I'd mention it so that others can delete the mail that was spammed to an unreasonably large number of people ;)
<lifeless> Should we disable 'contact this group' for, oh I don't know, every group ?
<Hobbsee> lifeless: can you?
<cjwatson> lifeless: it certainly ought to have a bloody great warning
<cjwatson> lifeless: since if nothing else it doesn't go to anything like a mailing list, so members of the group won't see followups
<cjwatson> (actually I think the total result would be worse if it did, but nevertheless ...)
<lifeless> Hobbsee: its just code
<Hobbsee> cjwatson: oh, it does make it relatively clear that you're about to send mail to 450 people.  But it doesn't include the blink tag or anything, or smack them in the face.
<Hobbsee> presumably people do read that
<Hobbsee> lifeless: i know it's theoretically possible.  :)  I'm just more wondering if a) it would be permissable to be done, and b) it would get done without being quickly reverted
<elmo> cjwatson: there's bugs about both the flawed semantics of c-t-u with groups, and that c-t-u works with groups of people > e.g. 50
<elmo> FWIW
<cjwatson> elmo: thanks
<mvo> doko: I noticed that you reverted the change for the supported/unsuppored logic in python3.0 - with my latest pycentral changes it should no longer die if a runtime is neither support/unsupported. changing this also means that rtinstall is never run for python3.0 (because its not in debian_defaults).
<mvo> (not sure if that matter for 3.0 though)
<doko> mvo: it should be fine for 3.0, we don't have any third party stuff packaged for 3.0 yet (and we should not, because we do know that 3.0 is only short term supported)
<mvo> ok
<Ng> mvo: the patch in the latest compiz upload has at least one notable regression - bug #355330
<ubottu> Launchpad bug 355330 in compiz "[Jaunty] Calendar applet popup opens under focused windows" [Low,Confirmed] https://launchpad.net/bugs/355330
<Ng> mvo: but perhaps the gnome applet is doing the wrong thing
<seb128> Ng: as you can see mvo already milestoned the bug ;-)
<mvo> Ng: yeah, I noticed this morning
<seb128> Ng: we discussed it this morning on #ubuntu-desktop it breaks other case too, session dialogs being one of those for some users, gnome-do too
 * mvo prepares a fix
<Ng> seb128: that must be a different bug then, 355330 is unmilestoned. I'll read #ubuntu-desktop backscroll and dupe it
<Ng> thanks :)
<seb128> Ng: bug #355379
<ubottu> Launchpad bug 355379 in compiz "Clock applet doesn't display the calendar over a focused window (dup-of: 355330)" [Undecided,New] https://launchpad.net/bugs/355379
<ubottu> Launchpad bug 355330 in compiz "[Jaunty] Calendar applet popup opens under focused windows" [Low,Confirmed] https://launchpad.net/bugs/355330
<seb128> Ng: well, milestoned -> has a jaunty task
<seb128> that's how jaunty bugs are tracked
<Ng> oh :)
<Ng> gar, all the dupes of this have dupes already
<Ng> there :)
<mvo> sorry, working on a fix as we speak
<cjwatson> nggh, my master installer translation files all broke
<ogra> cjwatson, ah, btw, i noticed on the partman page where we have $(RELEASE) there is also a stray $(OS) at the top line
<ogra> (i was assuming you look into ( vs { anyway for that page, but didnt want to leave it unmentioned
<ogra> )
<cjwatson> ogra: I mailed ubuntu-translators about it and have been told that it's fixed
<ogra> ok, then it should show up soon i guess
<cjwatson> ogra: but I'll need to do an import, which is part of why I ran into the problem mentioned above ...
<ogra> ah, k ... i'll report if i see it fixed, i'll do a daily install every day anyway
<dschulz> hi all
<dschulz> anyone noticed the error in hotkey-setup package after updating?  there's an error in the initscript
<Ampelbein> dschulz: bug #356157
<ubottu> Launchpad bug 356157 in hotkey-setup "package hotkey-setup 0.1-23ubuntu10 failed to install/upgrade: subprocess post-installation script returned error exit status 2" [High,Triaged] https://launchpad.net/bugs/356157
<dschulz> yes
<dschulz>  found it
<facundobatista> Hi all
<facundobatista> tkamppeter, I wanted to tell you that I'm here if you want to try anything (I commented the bug #348316... with the updated cups package I don't see my printer anymore, if I downgrade to your PPA version I see it again)
<ubottu> Launchpad bug 348316 in hal-cups-utils "Printer (HWModel Name) May Not Be Connected" [High,Fix released] https://launchpad.net/bugs/348316
<tkamppeter> facundobatista: When you upgrade to CUPS 1.3.9-17 you must remove the usblp module from the blacklist. The official CUPS package does not contain the new libusb-based backend, as the USB backend was not what caused the bug.
<facundobatista> tkamppeter, oh! I try this now
<facundobatista> tkamppeter, ok, now I removed it from the blacklist, and loaded it (sudo modprobe usblp), and I see it with lsmod
<facundobatista> tkamppeter, now I see the printer (it even appears automatically when unplu/plug the cable), I can send a test page to the printer, it puts a job in the queue, the job disappears, I have a notification that the job was printed, and the printer goes to idle state
<facundobatista> tkamppeter, but the printer just doesn't do anything, no printing at all
<qense> It seems there is a typo in the latest version of hotkey-setup on jaunty
<Hobbsee> https://launchpad.net/bugs/356157
<ubottu> Launchpad bug 356157 in hotkey-setup "package hotkey-setup 0.1-23ubuntu10 failed to install/upgrade: subprocess post-installation script returned error exit status 2" [High,Triaged]
<qense> ah
<qense> already reported, thanks for the link
<qense> sometimes I get the feeling I'm just too lazy, sorry for letting you search up things I could have found myself
<Hobbsee> it was mentioned in here a couple of hours ago, so was a matter of scrolling ;)
<qense> ok :)
<qense> a huge list of duplicates
<Tm_T> Hobbsee: as I mentioned elsewhere, makes kinda worried when you notice who's the maintainer of the package, don't they test them? (;
<Hobbsee> Tm_T: at this point of the release?  yeah...
<Tm_T> Hobbsee: indeed
 * Hobbsee ponders uploading the fix, but notes it's now just been assigned to slangasek
<Tm_T> Hobbsee: to be done when?
<Hobbsee> Tm_T: asap, i guess?
<Tm_T> I hope so (:
<Tm_T> still, that's kind of things that shouldn't go to users at all IMO
<Hobbsee> anytime you want to start responding again launchpad, feel free...
<Hobbsee> 43 seconds and no timeout.  Good!
<Tm_T> whoa
<Tm_T> "answer to me, baby"
<Tm_T> (baby being genderless in this case)
<ogra> poor baby
<thiebaude> someone asked me, how many devs are working on 9.04?
<Tm_T> ogra: not as poor as me, anyway
<Tm_T> thiebaude: depends on how you count
<ogra> Tm_T, shit happens in development releases, so such stuff goes out to users ... thats why they are called *development* releses ;)
<ogra> *releases
<thiebaude> Tm_T: canonical wise
<Tm_T> ogra: I know, but some level of professionalism in core team, please (;
<Tm_T> ogra: I'm too used to messages like "I commit this but haven't tested at all" and everything breaks in upstreams
<ogra> even prtofessionals make mistakes ... we're all humand
<robbiew> Hobbsee: Thanks for sponsoring the fix for bug 356157 :)
<ogra> *humans
<ubottu> Launchpad bug 356157 in hotkey-setup "package hotkey-setup 0.1-23ubuntu10 failed to install/upgrade: subprocess post-installation script returned error exit status 2" [High,Fix released] https://launchpad.net/bugs/356157
<Tm_T> ogra: I know (:
<Tm_T> ogra: still weird, no testing apparently
<Tm_T> robbiew: (:
<robbiew> Tm_T: noted
 * robbiew will reinforce the importance of testing *before* uploading
<Tm_T> robbiew: FYI I'm usually the test monkey in many places oftentimes
<ogra> robbiew, pfft, that takes out all the fun communication with users ;) how else shall we train our diplomacy ?
<Hobbsee> robbiew: no problem.
<Tm_T> ogra: war is best way to do diplomacy anyway!
<Hobbsee> robbiew: pbuilder hooks or piuparts ftw!
<cjwatson> Tm_T: the usual (unfortunate but understandable) pattern is that it was tested but then a slightly different version was uploaded by mistake. I don't think we need to throw around comments about professionalism for a single pre-release mistake
<robbiew> Hobbsee: liw as been looking into piuparts
<robbiew> cjwatson: +1
<Tm_T> cjwatson: I know, it was meant to be a humour, sorry if not apparent
<Hobbsee> robbiew: indeed.
<tkamppeter> facundobatista: Your printer (HP LJ P1002) is too new, it is not yet supported.
<robbiew> Tm_T: this late in the release...humour is the first thing to go :P
<Tm_T> cjwatson: I guess this is the "finnish honesty" you can see in Linus' comments too (:)
<Tm_T> robbiew: to go in, you mean
<Hobbsee> robbiew: just add more beer, and the humour will likely come back ;)
<facundobatista> tkamppeter, not supported by who? gnome? kernel? ubuntu?
<Tm_T> Hobbsee: or puke
 * calc feels less stress today after getting 8 targeted bugs finished last night :)
<robbiew> Hobbsee: heh...oh, it comes back...about 2am London time on the day of the release
<Tm_T> robbiew: when 2 months more testing is announced?
<Hobbsee> robbiew: yeah, i remember that well...
<tkamppeter> facundobatista: Linux. The printer most probably needs to get a firmware file uploaded into it whenever it is turned on. This firmware file is not yet available wioth the driver packages.
<cjwatson> thiebaude: from Canonical, on the general order of 50 (that isn't an exact number); but many Ubuntu developers are not employed by Canonical, and of course many of Canonical's staff are working on things other than Ubuntu or only contribute to Ubuntu occasionally
<Tm_T> indeed
<Tm_T> cjwatson: is team numbers kept somewhere in one place?
<Tm_T> team member numbers that is
<cjwatson> Tm_T: to get the answer to thiebaude's question you need to take the intersection of a couple of teams
<cjwatson> (one of which is private)
<Tm_T> cjwatson: aye, also just being part of the team doesn't mean youre currently working
<slangasek> Ng, Hobbsee, nxvl_: ah, whoops - sorry :/
<Tm_T> cjwatson: would be nice to build a graph of team sizes etc from release to release
<facundobatista> tkamppeter, I'm using the Foomatic/foo2xqx driver... in the driver's page, it says that it supports HP LJ 1005, but at the same time it says that I shouldn't use the package from Ubuntu, but install the tarball they provide there
<facundobatista> tkamppeter, do you know why?
<tkamppeter> facundobatista: This is because the author insists to download and install the firmware files from the internet during the compile and build process and not by a user utility as HP does ("hp-plugin").
<facundobatista> tkamppeter, but there's a firmware for my printer in that case... but it's not yet in the packages?
<tkamppeter> So you do not need to try to rebuild foo2zjs. You can try to set up your printer with "hp-setup", but probably it does not get recognized as HPLIP's current model list does not contain it.
<tkamppeter> facundobatista: Building foo2zjs starts getweb with the model name of the printer as argument.
<tkamppeter> facundobatista: The foo2zjs version I packaged one day before Feature Freeze did not yet list the printer in "getweb".
<tkamppeter> facundobatista: Did you download the newest version? Did it add support for the P1002?
<facundobatista> tkamppeter, well, I have a confusion here... my printer is HP 1005, but through usb I see it as P1002, do you know why this duality?
<tkamppeter> facundobatista: This is extremely strange for me.
<tkamppeter> facundobatista: Can you report an upstream bug on HPLIP, on https://launchpad.net/hplip/?
<tkamppeter> facundobatista: They do not fix hardware bugs, but they could take into account this version of the P1005 in their driver.
<tkamppeter> facundobatista: In which country did you buy that printer?
<facundobatista> tkamppeter, I have in my disk the foo2zjs tarball from one month ago, and in its INSTALL file it says to execute "./getweb P1005", so it was supported then
<facundobatista> tkamppeter, Argentina
<facundobatista> tkamppeter, I'll bug the hplip project about how it recognizes my printer
<tkamppeter> facundobatista: You should perhaps try to load the P1005 firmware file into your printer and see whether it works then. Then your printer principally works but the wrong self identification breaks the automatic setup.
<facundobatista> tkamppeter, how can I load the firmware? using hp-plugin?
<cjwatson> slangasek: FYI I finally managed a successful installation with grub2 today, after a few bug-fixes
<tkamppeter> download it with getweb and convert it with arm2hpdl. Then do "sudo -s" and after that "cat <converted firmware file> > /dev/usb/lp0",  then do "exit".
<facundobatista> tkamppeter, oh, ok
<robbiew> cjwatson: sweet!
<facundobatista> tkamppeter, did that, the printer *did* something (like ininting), and went back to idle/ready state
<facundobatista> tkamppeter, I printed a test page, but it stayed in "processing", and then received a notification asking if the printer was disconnected... ??
<tkamppeter> Seems that the printer crashed internally, due to a firmware which is not 100% compatible with it.
<facundobatista> tkamppeter, which project should I bug about this firmware? hplip?
<facundobatista> tkamppeter, otoh, which is your opinion about trying the hplip binary to set up everything?
<tkamppeter> facundobatista: Simply try it, but HPLIP will not recognize your printer as supported due to the bad self-identification. Please bug the HPLIP project about the firmware.
<facundobatista> tkamppeter, ok!
<facundobatista> tkamppeter, thank you!
<MacSlow> bryce, hey there... does http://launchpadlibrarian.net/24174661/Stacktrace.txt look like something familiar to you (in regards to known bugs/issues in xlib or xcb)?
<slangasek> cjwatson: grub2> ah, great!
<cjwatson> slangasek: Julian Edwards informed me a while back that they have an experimental test rebuild system in Launchpad, and I forgot to actually give it a test run. I'd like to do so now; it uses the normal buildds so it'll create a *lot* of pending builds, but they'll all be scored down to 4
<cjwatson> slangasek: would that be OK?
<slangasek> cjwatson: that seems ok, yes
<cjwatson> I might do it just for the primary architectures
<lamont> wtf does gimp think that doing forcing a fullsize window for the pic is anything close to the right answer?
<slytherin> seb128: Do you have any plan on cherry picking Jan Schmidt's enhancements to DVD playback (http://noraisin.net/~jan/diary/?p=90). This will require changes to gst-plugins-base, totem and gst-plugins-bad. If not, do you mind if I work on it?
<seb128> no
<lamont> or is that just the same stupidity that makes firefox think that the fact that it finished rendering a page means that I want it to deiconify even though I just iconfied it?
<seb128> slytherin: feel free to work on it
<slytherin> seb128: Even when I am cherry picking the changes it introduces new API in -base, so I will need FFE, right?
<seb128> yes, you can work on it, I can't tell if it will be accepted or not I'm not the one deciding there
<seb128> I also need to reply to your upload on the list
<slytherin> seb128: Ok.
<Tm_T> robbiew: hmm, should I poke you when I get issues with this new package too?
<seb128> it seems to be a "let's change the build system, we don't know why but that seems to work better so it must be something to get"
<seb128> slytherin: which I disagree with
<robbiew> Tm_T: heh...you can, but please file a bug also ;)
<Tm_T> robbiew: well I don't know if this worth a report, just asking should this happen? http://paste.ubuntu.com/145536/
<robbiew> Tm_T: yuk
<robbiew> slangasek: ^^?
<slangasek> bluh
<slytherin> seb128: I know. I don't have any argument in favour in the change except that it works better. As I said I am not expert in autotools.
<slangasek> robbiew: I'll poke at it and do evil things
<seb128> slytherin: "work better"
<seb128> slytherin: on what basis do you assume that?
<robbiew> slangasek: heh...ok, thanks
<cjwatson> slangasek: https://edge.launchpad.net/ubuntu/+archives, FYI
<cjwatson> i386 only (by accident but actually that's probably OK)
<slytherin> seb128: I did quite a good amount of testing with many DVDs I have and I have feed back from at least 2 users on the bug that the change worked. I wish I could gather more feedback.
<seb128> slytherin: we have no idea of what the change do, it might change things in a better way for your 3 users and break for a thousand user out there
<picklesworth> Tm_T: http://ubuntuforums.org/showthread.php?t=1117615
<picklesworth> You'll need to fix /etc/init.d/hotkey-setup yourself, unfortunately. This post shows how: http://ubuntuforums.org/showpost.php?p=7023434&postcount=6
<picklesworth> I'm sure the package will never upload an untested package again ;)
<slangasek> I'm fairly certain of the opposite
<slangasek> I'm too old to learn that lesson :P
<picklesworth> heh
<Tm_T> picklesworth: I know
<slangasek> anyway, I have a fix that should work for recovering from the broken state
<slangasek> I suppose I should test it first though :-P
<Tm_T> slangasek: aye, that's my meaning at this
<slangasek> yep, fix checks out
<slangasek> robbiew: don't look at my patch
<robbiew> slangasek: lol...ok
<Tm_T> slangasek: meaning, is, getting it fixed properly, not making you feel sad (:
<slangasek> cjwatson can look at it if he wants, though
<slangasek> Tm_T: right :)  well, fix is uploaded now
<cjwatson> only if I know where it is
<slytherin> seb128: I have made multiple calls for testing multiple times on IRC (#ubuntu+1) for packages in my PPA and didn't get any regression report.
<slangasek> cjwatson: hotkey-setup 0.1-23ubuntu12
<cjwatson> ah
<Tm_T> slangasek: good, I'll keep poking if something comes up
<slangasek> cjwatson: using prerm failed-upgrade \o/
<cjwatson> slangasek: the test rebuild is a bit of a wash, they all fail to upload
<seb128> slytherin: I've seen no evidence recently that DVD playback is broken for the majority of users
<slangasek> cjwatson: heh
<cjwatson> slangasek: I'm asking muharem about it
 * slangasek nods
<calc> argh, a catalan language update for OOo managed to break the build :\
<slangasek> make the translation coordinator fix it
<calc> slangasek: it was a GSI attached to a bug report and aiui the guy who used to do catalan (jordi mallach) no longer does it
 * calc will just be dropping it from the next upload probably tomorrow
<slangasek> calc: but Ubuntu now has a translations coordinator, who also speaks Catalan :)
<calc> slangasek: ok
<slytherin> seb128: So what do you suggest, apart from analysing the changes I did.
<seb128> slytherin: having somebody to try to understand what the change is doing before pushing it to jaunty one week before freeze this way
<slytherin> seb128: Ok. I will try to get hold of someone.
<slangasek> ScottK: two steps forward, one step back for qt on hppa; strigi builds, but phonon FTBFS because automoc4 (or something it calls) segfaults :P
<cjwatson> slangasek: hotkey-setup> yum!
<slangasek> :-)
<Tm_T> slangasek: ouch
<BUGabundo> we are getting reports on +1 that the daily installer lost support for ext4 using the manual option!
<BUGabundo> is this know issue?
<calc> hotkey-setup seems almost broken in a way package management can't fix, even purge force-all wouldn't remove it until i fixed the init script
<calc> then installing the new version worked ok
<BUGabundo> lol calc
<slangasek> calc: ahh, but it can be fixed, you just have to channel IanJ when patching the package
<slangasek> (fix uploaded, as mentioned above - will be available in ~1h)
<calc> slangasek: ah ok
<calc> slangasek: oh the ordering of when helper scripts fall back could then move the broken init script out of the way (i'm guessing?)
<slangasek> calc: don't actually need to move the broken init script out of the way, I just added code in the prerm of the new package version to skip invoking the init script altogether
<calc> eg:
<calc> ah :)
<d3xter> colin: ping
<calc> yea i saw where it tries the new prerm script (had forgotten about that ordering in policy)
<calc> slangasek: thursday is just the last day new uploads will be accepted without a really good exception right? (meaning OOo doesn't have to be completely finished building by then?)
<BUGabundo> d3xter: I already asked! we just have to wait for a reply on it
<slangasek> calc: right - though it would certainly be nice if OOo was done before then...
<calc> slangasek: i'm trying to determine when i need to do my next upload since 9ubuntu1 had issues with catalan and thunderbird
<d3xter> thx, i've read your msg right after i sent my ^^
<calc> slangasek: i think it would be best to wait at least one day to see if any other bug reports come in before uploading again though
<slangasek> calc: does OOo really need an upload for an OOo-l10n build failure?
<slangasek> makes me think the OOo/OOo-l10n split is worse-than-useless
<cjwatson> BUGabundo: known and fixed
<calc> slangasek: there were a couple of issues in OOo that didn't get discovered until too late, the thunderbird issue and a desktop file issue
<BUGabundo> cjwatson: thanks
<cjwatson> BUGabundo: bug 354851
<ubottu> Launchpad bug 354851 in partman-ext3 "No ext4 option in manual partitioning using livecd installer" [Undecided,Fix released] https://launchpad.net/bugs/354851
<BUGabundo> cjwatson: is there a LP bug I can refer users to?
<BUGabundo> bah.. thanks
<slangasek> calc: ah, ok
<calc> slangasek: yea the split is really not too useful imho, it may become more useful when we eventually go to a full split build
<calc> slangasek: the full split build has something like 15 source packages, and won't require building all of OOo just for languages
<slangasek> calc: well, AIUI we currently have lots of code duplication in the tarballs of the two source packages; will that be fixed?
 * calc is considering forking from debian for OOo 3.1 packaging and then seeing if he can get the changes integrated back into debian version
<calc> slangasek: yea long term that will be fixed. currently it is 100% duplication
 * slangasek nods
<calc> slangasek: all i do is rename the orig.tar.gz :\
<slangasek> forking from Debian> yuck, only if you're planning on discarding the debian/ directory and redoing it from scratch :)
<calc> i think it is supposed to be fixable by 3.2 (karmic) if things go well
<slangasek> lamont: we don't have an hppa porter box?
<lamont> slangasek: wongi
<calc> slangasek: yea i am thinking of doing a complete repackaging while using his rules file as a guide, the more i see bits of the rules the more scared i become ;-)
<Mirv> calc: have you discussed with rene about the idea?
<BUGabundo> cjwatson: one more question if I may. can the base ubuntu be installed and then install the ubuntu-netbook-remix package?
<calc> Mirv: not yet, i am going to see if it is feasible first then discuss with him
<slangasek> lamont: ah, thanks; adding to the wiki then
<cjwatson> BUGabundo: no idea, not my field
<Mirv> calc: ok.
<BUGabundo> oh who is then ?
<calc> Mirv: we were originally going to fork for the split build anyway this release, but that looks to be delayed
<calc> Mirv: while doing some of the split build work i started noticing that the rules file could do for a major cleanup
<cjwatson> BUGabundo: I'd probably start with #ubuntu-mobile
<Mirv> calc: anything to make maintaining OOo easier would probably be very welcome, it's just so huge and rene is I guess still the "OOo team" in Debian...
<jefferai> Anyone know what should be creating /var/run/network directory in Jaunty?
<jefferai> in previous versions it was /etc/init.d/loopback
<jefferai> but that doesn't seem to exist anymore
<calc> Mirv: yes pretty much just me and rene between ubuntu and debian
<calc> Mirv: some of what i want to do wrt packaging is get closer to the packaging layout of upstream... without the braindamage of core## packages
<calc> Mirv: so we won't run into each user level application needing to depend on each other
<bryce> MacSlow: not offhand; get a full backtrace and file a bug
<MacSlow> bryce, that's all I have right now
<bryce> MacSlow: ok, well not enough in that backtrace to analyze; just indicates some sort of crash malloc'ing memory in xcb
<MacSlow> bryce, yeah... that's from a bug filed against notify-osd... and that stracktrace indicates that the error does not really happen in notify-osd
<MacSlow> bryce, I thought you might recognize a "pattern" and happen to know a bug in xlib or xcb related to that
<bryce> ah, nope
<LaserJock> bryce: quick question, my X locks up, keyboard is dead, but my mouse (either touchpad or external) will move, do you know a likely culprit?
<bryce> LaserJock: too generic of a symptom to say
<LaserJock> hmm, ok
<bryce> LaserJock: that's basically a GPU lockup.  lots of stuff can do that
<LaserJock> ah
<LaserJock> would not running compiz help?
<slangasek> could also be an input dev bug, though?
<LaserJock> it started in the last ~ 1 week and it's done it about 3 times
<bryce> LaserJock: quite possibly
<LaserJock> I have to hard reboot
<sbeattie> LaserJock: are you able to ssh in?
<LaserJock> good question, I'm not sure
<bryce> slangasek: possibly, but I think a gpu lockup is more likely
<LaserJock> next time I'll find a machine to ssh with
<slangasek> fairy nuff
<LaserJock> it's just odd to have the cursor working just fine but everything else just lock up
<bryce> LaserJock: if you know it worked properly a week ago, reverting packages until you find the one that causes it could be helpful
<LaserJock> I was wondering since the intel drivers have been updated
<BUGabundo> LaserJock: I got that on the Dell machines I was testing last week
<bryce> I've put in several -intel patches recently, and in my experience with them, fixing one bug seems to cause another somewhere else :-/
<BUGabundo> they add the lovely intel 865
<BUGabundo> the live cd would freeze but cursor still worked
<LaserJock> bryce: I'll right, I'll try going back on -intel and see if that seems to solve it
<LaserJock> bryce: it's often enough to  be annoying but not often enough to be easy to debug :-)
<sbeattie> bryce: what's useful to do for debugging a lockup like that
<bryce> sbeattie: I don't have a good debugging procedure for lockups yet
<bryce> sbeattie: any error message you can get is usually handy
<bryce> they're usually not in Xorg.0.log tough, so you have to poke around
<bryce> backtraces are only marginally useful
<bryce> sbeattie: turning off DRI or other X subsystems to narrow it down can be useful
<bryce> sbeattie: the most helpful thing is to bisect or revert backwards until you find the change that caused it
<LaserJock> bryce: I'll start with 2:2.6.3-0ubuntu1 and bisect my way
<sbeattie> bryce: okay. The lockup I saw didn't show anything useful anywhere, only after trying suspend-resume to unwedge it did i start getting "[mi] EQ overflowing. The server is probably stuck in an infinite loop." in the log
<LaserJock> I'm pretty sure it started after ubuntu1
<bryce> I put up a http://wiki.ubuntu.com/X/Glossary to help explain some of the technical terms you see in X error messages
<sbeattie> bryce: note that I do little to no 3d stuff; my wm doesn't composite.
<bryce> sbeattie: well... like I mentioned before, gpu lockups are kind of a generic symptom and can occur due to a wide variety of things
<kirkland> james_w: where can I find some documentation on bzr-builddeb?  like how to setup my debian/rules properly?
<james_w> hey kirkland
<bryce> 3d stuff tends to trip up the gpu more, because 3d code is often newer, the registers vary more widely from hw to hw, and there's a lot more to 3d than 2d
<james_w> kirkland: it should require no changes to debian/rules
<james_w> kirkland: or anything in debian/ at all
<kirkland> james_w: howdy
<kirkland> james_w: hmm, okay.  where can i find some instructions on making my get-orig-source target correct?
<kirkland> james_w: b/c right now, builddeb is not happy with my get-orig-source
<james_w> kirkland: do you have a log?
<james_w> builddeb was actually broken with get-orig-source until a few days ago, so if you don't have the latest package it won't work
<kirkland> james_w: http://pastebin.ubuntu.com/145602/
<kirkland> james_w: let me update
<james_w> kirkland: ah, it's failing before where that fix would kick in so it's something else
<james_w> that's an interesting get-orig-source you have there
<james_w> is the intent to use the cwd without ./debian/ as the .orig.tar.gz?
<kirkland> james_w: http://pastebin.ubuntu.com/145602/
<james_w> kirkland: are you trying to tar up the cwd without ./debian/ to create the .orig.tar.gz?
<kirkland> james_w: yes, and without the .bzr
<calc> elmo: so thunderbird did actually work in the past for the users who are reporting the problem now?
<kirkland> james_w: i'll pastebin the rule too
<elmo> calc: yes
<james_w> kirkland: you realise that can easily lead to broken packages?
<kirkland> james_w: i did not realize that
<james_w> ones that aren't a danger to the archive at least, but would still be a pain
<elmo> calc: and it works for them again if I s/sensible-ooomua/thunderbird/
<elmo> calc: (I haven't tried xdg-mailer or whatever it was you suggested)
<calc> elmo: interesting, ok, i will look into the file that the patch that adds "sensible-ooomua"
<kirkland> james_w: i can drop that --exclude
<james_w> kirkland: well, it makes it easy to create a broken package if you try and build a -2 at least
<james_w> kirkland: and you don't have the original .orig.tar.gz in the correct place
<kirkland> james_w: http://pastebin.ubuntu.com/145616
<calc> elmo: afaict it has used that setting since at least hardy, so maybe the file the patch changes has otherwise changed as well
 * calc hopes that made sense :)
<james_w> kirkland: as it will create you a new .orig.tar.gz that won't be the same, and so will be rejected by soyuz/dak
<kirkland> james_w: hmm, i expected the diff.gz to contain the debian dir
<james_w> kirkland: yes, it will
<james_w> kirkland: but with .tar.gz the contents of the files is not all that matters
<james_w> kirkland: even if you don't touch anything outside of ./debian/ in -2 the md5sum of the .orig.tar.gz would still change
<LaserJock> hence why pristine-tar exists for VCSes
<james_w> kirkland: so, the immediate issue is that it is not running get-orig-source in a directory that is named screen-profiles or screen-profiles-${VER}, so it falls over.
<james_w> kirkland: I could fix that, but I don't think there is a lot of point
<james_w> kirkland: as http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules states "get-orig-source (optional) [...] This target may be invoked in any directory"
<james_w> kirkland: so I think you should re-think your get-orig-source. I can help you come up with a good solution that works for you if you like, but first I must eat...
<kirkland> james_w: please, you bet
<kirkland> james_w: i've recently gotten a lot of requests for other distros to pick up this package
<kirkland> james_w: i'm trying to rework my build/release procedure such that it's still smooth for me, but also works for them
<kirkland> james_w: siretart_ is handling the ITP for debian
<kirkland> james_w: he's the first consumer I'm trying to satisfy
<Chipzz> why do you package those seperately anyway?
<Chipzz> wouldn't it make more sense to ship these in /usr/share/doc/screen in the screen package?
<GuyFromHell> Anyone here using an update XChat and some form of galago notifications? Are you getting an icon on your popups?
<maxb> Chipzz: Personally I think it's far more elegant to put a loosely coupled addon in its own package
<festor>  I use ubuntu beta 9.04 (now in livecd) and I dont see any ext4 option in ubuntu installer
<mcas> hi
<mcas> can anyone tell when there will be the next translation sync?
<cjwatson> mcas: I saw language-pack builds going through today ...
<mcas> ok thx cjwatson
<james_w> GuyFromHell: I am, and yes, the stock_person icon if I am not mistaken
<GuyFromHell> james_w, may i inquire specs? distro, version, and galago program?
<james_w> ubuntu jaunty with notify-osd
<james_w> xchat 2.8.6-2.1ubuntu4, notify-osd 0.9.8-0ubuntu1
<GuyFromHell> james_w, interesting, mine doesn't work on same configuration unless the string is changed from "notification-message-im" to "notification-message-IM"
<james_w> are you using the xchat-gnome variant?
<GuyFromHell> james_w, no, the original
<james_w> that changes the icons that you get?
<GuyFromHell> james_w, my notify-osd seems to be newer, perhaps they added case sensitivity...
<GuyFromHell> james_w, i had no icon from the deb install
<james_w> ah, it's not stock_person I don't think
<GuyFromHell> james_w, i think this is that was meant to be: http://www.cs.rpi.edu/~mukhea2/stock.png
<GuyFromHell> is that what you're getting?
<james_w> GuyFromHell: I assume you have libnotify installed?
<james_w> GuyFromHell: it's similar, but I can't be sure
<GuyFromHell> james_w, that's what i have after putting  a patch on x-chat to capitalize 'im' in 'notification-message-im'
 * GuyFromHell debates with himself on what to do
<GuyFromHell> i guess I'll file a bug report and see if anyone else is getting this behavior...
<james_w> GuyFromHell: http://people.ubuntu.com/~jamesw/Screenshot.png
<clearscreen> Not sure if this is the right place to ask.. but I'm a new C++ programmer looking for a new open-source project with a relatively small codebase / small group of developers.. any suggestions? I browsed through countless of sourceforge pages but either wasnt interested, it was a huge project, or it was completely inactive (not a single commit)
<GuyFromHell> james_w, it may just be my icon theme, lemme see if it supplies this, i thought the icon was part of human only though :/
<Ampelbein> clearscreen: try the gnome-project. http://live.gnome.org/GnomeLove There are simple tasks to start and you can get in touch with an active community.
<clearscreen> Ampelbein: Problem is that I do want to be hands-on with the code, but am not even closed to experienced enough to deal with something like gnome.. Would probably be clueless about a lot of things and produce crap :P
<james_w> GuyFromHell: got it
<james_w> GuyFromHell: the fallback icon for non-Human is capitalised, which is probably a mistake
<james_w> GuyFromHell: so it seems a bug against notify-osd to make it lower-case is the right thing
<GuyFromHell> james_w, so asking for icon -im falls back to -IM?
<Ampelbein> clearscreen: thats fine. the folks at gnome are mostly helpful and will point out what is wrong/could have been better. check out the simple tasks listed on the site and you will be learning-by-doing. GNOME is a big project, but there are many small programs which you could start working on.
<james_w> GuyFromHell: no, it doesn't. xchat asks for -im and if you are running human you get it. If you aren't running human then it tries to use the fallback, but doesn't exist
<james_w> GuyFromHell: your capitalisation change would mean that you always get the fallback whether you run Human or not, which would be undesired I guess. So making the fallback the same as what xchat is requesting and what human provides would seem to be the solution
<GuyFromHell> james_w, ah i see what you're saying now.
<GuyFromHell> james_w, i'll go ask #dx what they think about this
<james_w> sure
<kees> Keybuk: I see no reason to keep /dev/kmem if it's disabled by default in our kernels.
<slytherin> Can any of the core dev's take a look at bug 349146 and let me know if this is intentional.
<ubottu> Launchpad bug 349146 in human-icon-theme "Logout icon looks like shutdown" [Undecided,New] https://launchpad.net/bugs/349146
<kees> Keybuk: I have no opinion about doing an open() test on the special device to see if it should be created.  on the one hand, it'd be nice to play with a kernel that has it enabled for some reason.  on the other hand, no one should use kmem.
<clearscreen> Ampelbein: Mmmm I'm not so sure, I'll keep looking around :P
<james_w> kirkland: hey, so I assume you set things up like that originally so that you only had a single branch to worry about?
<Laney> Keybuk: Do you have a minute to look at an automake problem? (you did the update). The smuxi package now fails to build (http://is.gd/r3I3) with the error "shift: 2219: can't shift that many". I've confirmed that downgrading to the older version renders it buildable again.
<Laney> I don't know if this is a regression or a bug in upstream's usage or what
<adelie42> If I am starting a new project and want it hosted on launchpad, I just register a branch, correct?
<jpds> adelie42: And the project, best ask Launchpad questions at #launchpad
<adelie42> k
<GuyFromHell> james_w, Just in case you were wondering, a bug has now been filed against notify-osd to rename the icon.
<james_w> I saw, thanks
<GuyFromHell> james_w, oh didn't see you were in #dx too
<johanbr> clearscreen: ekiga is c++ and they're short on developers
<sbeattie> tedg: are you no longer maintaining gnome-screensaver's packaging in bzr+ssh://bazaar.launchpad.net/~ted-gould/gnome-screensaver/ubuntu-packaging ?
<tedg> sbeattie: I think someone may have moved it over to ~ubuntu-desktop.  I know they were discussing doing that.
<sbeattie> okay, thanks, the vcs tag for it is wrong, then.
<tedg> sbeattie: Yup, here it is: lp:~ubuntu-desktop/gnome-screensaver/ubuntu
<sbeattie> tedg: cool, thanks.
<picklesworth> Hm... are the DX team people aware of this bug report?: https://bugs.launchpad.net/bugs/343219
<ubottu> Launchpad bug 343219 in fast-user-switch-applet "Adding Fast User Switcher applet causes shut down options to disappear from System menu" [Undecided,New]
<jpds> That's intended bahaviour.
<picklesworth> indeed, and it's also wrong behaviour ;)
<jpds> If you remove fusa, you get the System menu back, one or the other.
<Laney> There is a regression in the version of automake that's currently in Jaunty which is rendering at least one package unbuildable. I've almost confirmed that http://git.savannah.gnu.org/cgit/automake.git/diff/?h=branch-1-10&id=f9a3dde93cbd6497966d45631ec1cf665b09e3a9 fixes it
<Laney> I don't know how to work up a patch for a git-maintained package though
<dtchen> git format-patch
<Keybuk> gnargh, apport is popping up for valgrind again
<Laney> bluh
<slytherin> any maintainer of human-icon-theme here?
<Laney> Keybuk: You forked automake! What's the best way to patch it now?
<jpds> slytherin: kwwii.
<Laney> the git repo doesn't appear to be current
<cjwatson> Laney: apt-get source automake, hack, upload?
<cjwatson> Laney: the git repository is the Debian package, by the looks of things
<slytherin> jpds: is it just me who find logout icon more like shutdown?
<Keybuk> Laney: ?
<clearscreen> slytherin: its a man walking about.. looks like logging out to me :P
<Keybuk> Laney: what do you mean?
<slytherin> clearscreen: are you using human theme?
<clearscreen> slytherin: if that's the default theme for 9.04, then yes.. cant remember changing it
<clearscreen> I could be wrong though
<Laney> Keybuk: Should I add a patchsys or what?
<Laney> cjwatson: Right
<Keybuk> Laney: I updated our package to a new upstream version, is that what you mean by "forked" ?
<Laney> Keybuk: yes
<cjwatson> Laney: please don't ever add a patch system in Ubuntu to a package (from Debian) that doesn't have one
<Keybuk> Laney: never add a patchsys to a package that doesn't have one
<Laney> right
<Keybuk> Laney: that's hardly a "fork" - that's a relatively standard practice
<clearscreen> slytherin: nevermind :)
<slytherin> clearscreen: You can verify in system -> preferences -> appearance
<Laney> excuse my terminology then
<Keybuk> laney: I used the upstream orig.tar.gz, so when Debian update too, we simply drop out diff
<clearscreen> slytherin: yeah, using glossy
<Laney> I didn't mean ti imply anything negative
<Laney> o
<Keybuk> Laney: then I'm unsure what your point is?
<Keybuk> Laney: perhaps you should rephrase your exclamation as a question?
<Laney> I wanted to know in which format the patch should come
<Laney> is all
<Keybuk> Laney: what patch?
<jcole> didrocks: according to the evolution developers, it looks like your evoltion-mapi package is very out of date
<Laney> the one I'm about to supply
<Keybuk> Laney: and what does that do?
<Keybuk> why haven't you send that patch upstream instead?
<Laney> it is upstream, I'm backporting it
<Keybuk> is there a new upstream release containing the patch?
<Laney> it's a regression vs 1.10.1
<Keybuk> Laney: ref?
<Laney> no
<Laney> http://git.savannah.gnu.org/cgit/automake.git/diff/?h=branch-1-10&id=f9a3dde93cbd6497966d45631ec1cf665b09e3a9
<cjwatson> Keybuk: to be fair, he gave a reference above
<cjwatson> 21:32 <Laney> There is a regression in the version of automake that's currently in Jaunty which is rendering at least one package unbuildable. I've almost confirmed that
<cjwatson>               http://git.savannah.gnu.org/cgit/automake.git/diff/?h=branch-1-10&id=f9a3dde93cbd6497966d45631ec1cf665b09e3a9 fixes it
<cjwatson> 21:32 <Laney> I don't know how to work up a patch for a git-maintained package though
<jcole> didrocks: this may be why so many people are having issues
<Keybuk> ah, I missed that bit
<Keybuk> shaky network here
<Laney> no worries
<Laney> just want to ensure it gets in
<Keybuk> Laney: just apply the patch directly to the sources, add a changelog entry (-0ubuntu2) and upload
<jpds> slytherin: re: logout icon: true...
<Keybuk> Laney: obviously there should be a Launchpad bug for this, targeted to jaunty, etc.
<Laney> ok
<Laney> debdiff following shortly
<kees> Keybuk: did you see my backscroll on my okayness with dropping /dev/kmem?
<Laney> watch this space etc
<Keybuk> kees: no, I don't keep backscroll
<Keybuk> kees: I saw your e-mail about that
<kees> 19:11 < kees> Keybuk: I see no reason to keep /dev/kmem if it's disabled by default in our kernels.
<kees> 19:12 < kees> Keybuk: I have no opinion about doing an open() test on the special device to see if it should be created.  on the one hand, it'd be
<kees>               nice to play with a kernel that has it enabled for some reason.  on the other hand, no one should use kmem.
<slytherin> jpds: I filed bug 349146, but looks like it has not come to attention of the maintainers.
<Keybuk> kees: well, it'll be created automatically if the kernel supports it
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/349146/+text)
<Keybuk> since the kernel has a /sys/devices/virtual/mem/kmem or something
<kees> Keybuk: works for me
<Keybuk> we just force it anyway
 * Keybuk can't remember why
<Keybuk> probably because devices.txt said we should
<Keybuk> oh, hmm
<Keybuk>   * Add /lib/udev/devices/kmem as there's no sysfs node for it yet.
<kees> Keybuk: yeah, it's a legacy device at this point.
<Keybuk> wonder if that's been fixed
<kees> Keybuk: it has (intrepid has it)
<kees> dapper and gutsy don't.  hardy has kmem disabled so I can't check
<Keybuk> ah yes, it uses device_create()
<Keybuk> that's ok then
<calc> what type of threading issue would running strace on a process cause not to happen?
<cjwatson> calc: anything that's a race condition
<Laney> bug 356612 for the automake patch
<ubottu> Launchpad bug 356612 in automake1.10 "Regression vs 1.10: depfiles problem causes some source packages to ftbfs now" [Undecided,New] https://launchpad.net/bugs/356612
<cjwatson> (I wouldn't put it past there to be other threading problems that strace might mask, but races are the standard answer to this question and threaded code is full of them if written even slightly incautiously)
<calc> cjwatson: ok
<seb128> calc: that's probably not the issue there though, it's just a function calling xrandr, there is no possible race since it doesn't depend of any other code
<calc> seb128: its failing inside of spawn_with_input afaict and doesn't fail if i strace it
<calc> spawn_with_input seems to just spawn a thread and and execute the program
<seb128> not something which should be subject to races
<calc> when i straced i did strace -f -p pid -o output
<calc> not sure if that could mask any other types of issues though
 * calc looks at OOo 3.1.0 rc1 debian orig size and dies... 764MB just for orig
 * picklesworth looks at calc's message... "but how did he write that?" "...he must have been dictating"
<calc> picklesworth: heh :)
<calc> picklesworth: so 1.5GB+ for OOo source in karmic if it isn't a bug in debian packaging :\
<directhex> calc, 764 meg orig? so... we're breaking the 10 gig pbuilder requirement then
<directhex> ?
<calc> directhex: i have no idea what is going on, i'm still downloading it, i think rene might have screwed up the orig.tar.gz
<calc> i can't imagine how it would have gotten that large between a couple of OOo milestone releases
<calc> it was only 400MB at 310m6
<picklesworth> OO is an impressively complicated office suite if it's not an error
<picklesworth> maybe he ran a build in there :/
<geofft> You say that like OOo can't be both an error and an impressively complicated office suite...
 * jdong wishes update-manager used PolicyKit...
<glatzor> jdong, https://edge.launchpad.net/aptdaemon
<jdong> ooh
<laszlok_> is it known that jockey-gtk doesn't work? maybe this is part of the python 2.6 thing in the title?
<laszlok_> that python bug is marked as fix released though...
<directhex> "doesn't work"? is claiming unemployment benefits?
<bryce> directhex: :-)
<clearscreen> directhex: i loled
<hyperair> say... can someone test what happens when you run this in a shell: notify-send title 'message&'
<hyperair> for some reason, the message gets substituted with something else
<hyperair> is that supposed to happen?
<james_w> no
<directhex> "&" generally stuffs it
<hyperair> yeah
<hyperair> but is this a bug in notify-osd or notification-daemon?
<directhex> using '&' in title means no message at all
<jdong> well you're not supposed to use unescaped HTML chars, right?
<hyperair> oh so it's supposed to be &amp;?
<directhex> seems so - but still broken in title
<directhex> hm, no, broken if &amp; is the ENTIRE title
<directhex> or... hm, it wasn't working, now it is
<directhex> bloody technology
<hyperair> no i think notify-osd might have crashed
<hyperair> remember that dbus automatically starts it again
<hyperair> [51462.618299] notify-osd[5512]: segfault at 18 ip b7698cc3 sp bf841a24 error 4 in libc-2.8.90.so[b7629000+158000]
<hyperair> [51787.162592] notify-osd[5960]: segfault at 121c61f8 ip b76e9cd9 sp bf992b74 error 4 in libc-2.8.90.so[b767a000+158000]
<hyperair> see.
<jdong> hyperair: holy crap. is that from an ampersand?
<hyperair> jdong: yes it is
<hyperair> jdong: unescaped
<jdong> hyperair: ok then you might be onto something more serious.
<jdong> hyperair: I'd file it as a potential security issue at this point.
<hyperair> hmm
<hyperair> wait, i can't reproduce it
<hyperair> it's not re-segfaulting
<jdong> hmm
<cjwatson> run it under valgrind
<hyperair> meh i can't reproduce it anymore
<hyperair> wonder what went on
<kees> hyperair: the body portion goes through pangomarkup, but I wasn't able to crash it...
<hyperair> hmm
<hyperair> so with regards to this whole pangomarkup thing... are the rules the same as html for symbols?
<kees> hyperair: it's a subset of html
<hyperair> subset?
<kees> hyperair: I was poking at it last week, but it seemed okay
<hyperair> hmm
<kees> http://library.gnome.org/devel/pango/unstable/PangoMarkupFormat.html
<hyperair> hmm i'm more interested in the symbols
 * hyperair now has a should-be-perfect irssi libnotify script =D
<jdong> hyperair: are ' you& su<a href=localhost>re</a>?"!;
<jdong> *ducks*
<cjwatson> I was thinking that irssi might be better hooked into libindicate
<cjwatson> although there don't seem to be shell bindings for that
<hyperair> jdong: sorry i didn't manage to see the notification. could you try again?
<hyperair> cjwatson: if there are perl bindings, it'll work.
<jdong> hyperair: test normal.....
<hyperair> cjwatson: but there aren't perl bindings either
<jdong> hyperair: test nasty are ' you& su<a href=localhost>re</a>?"!;
<hyperair> jdong: works perfectly =)
<jdong> hyperair: just making sure you wrote good perl :)
<hyperair> you wouldn't happen to be interested in the script would you?
<jdong> hyperair: some of the libnotify scripts floating out there are shell escapable.
<jdong> hyperair: putting the script up somewhere would be nice for the world, yeah :)
<hyperair> jdong: ah i used the multi-arg system() notation.
<cjwatson> I put mine up a while ago, BTW
<hyperair> cjwatson: where?
<hyperair> cjwatson: it isn't on scripts.irssi.org is it =p
<jdong> hyperair: good boy.
<cjwatson> http://www.chiark.greenend.org.uk/~cjwatson/code/notifications/
<hyperair> cjwatson: that requires a file
<cjwatson> yes, it does. deal.
<hyperair> hahah
<hyperair> and a daemon =p
<cjwatson> ditto
<jdong> wow. that's really good.
<jdong> I had a maildir-ish spool setup before I redid my shell server
<hyperair> +
<hyperair> also mine are based on the same script i think
<hyperair> heh
<jdong> yeah, fnotify was a good starting point for me too
<cjwatson> it's not really a proper daemon. I doubt you could do without something like that and still work over ssh, anyway.
<cjwatson> my laptop isn't necessarily on even remotely the same network as the server on which I run irssi
<jdong> my issue was I needed the notion of a notification being "acknowledged"
<hyperair> cjwatson: agreed. without ssh-ing back, there really isn't a way
<cjwatson> specifically the server can't necessarily open an ssh connection back to it
<jdong> much like how with an IMAP mailbox I know when I've read the message elsewhere
<hyperair> that's one of the reasons i'm running irssi locally
<cjwatson> I suppose I could do it with port forwarding
<jdong> I sometimes have 4 of 5 systems logged into IRC, some abandoned....
<hyperair> cjwatson: why not a fifo? eventually those hilights will build up you know
<cjwatson> which might be a bit simpler 'cos you wouldn't need the heartbeat
<cjwatson> hyperair: in practice it seems fine
<hyperair> hmm
<jdong> hyperair: it's gotta build up for years before that matters though
<cjwatson> I don't want to use a fifo because that might cause irssi to block if the server isn't running
<hyperair> jdong: good point =p
<hyperair> ah yes
<hyperair> fork! then you get a mini fork bomb =p
<cjwatson> the wrong solution to so many problems ;-)
<hyperair> =p
<hyperair> exec then.
<hyperair> Irssi::command("exec echo msg > fifo");
<cjwatson> doesn't interest me
<hyperair> hehe
<cjwatson> indeed, that'll just lead to a bunch of sh processes building up over time if the fifo is full
<cjwatson> don't see how that's an improvement really
<hyperair> fork bomb =p
<james_w> cjwatson: I was just thinking about how shell binding for libindicate would work, as it's not async like libnotify
<james_w> you have to maintain the dbus connection for the length of the indicator
<cjwatson> james_w: oh, interesting, you'd need a little session daemon to do it then
<james_w> yeah
<james_w> you could even do it over dbus
<cjwatson> slangasek: feel free to downgrade the universe test rebuild bugs I'm filing if you feel so inclined
<cjwatson> I didn't get much output from the test rebuild since it turned out to spam people by mail, but I'm filing what we got
#ubuntu-devel 2009-04-07
<scientes> how do i build nvidia driver for my specific kernel
<scientes> m-a is broken
<scientes> and i dont know to give dkms for version etc
<scientes> module=nvidia version=180 doesnt work
<TheMuso> scientes: What kernel are you running?
<scientes> 2.6.27.11-g
<TheMuso> scientes: you need linux-headers-generic installed
<scientes> have that
<scientes> the only way to get it to work is to restart but thats stupid
<scientes> you shouldnt break m-a
<TheMuso> scientes: the nvidia kernel driver in intrepid afaicr uses dkms.
<scientes> dkms build -m nvidia -v 180
<scientes> Error! DKMS tree does not contain: nvidia-180
<scientes> Build cannot continue without the proper tree.
<scientes> give me the command that occurs on startup for dkms
<TheMuso> scientes: I don't know enough about dkms to help any further sorry.
<scientes> bingo
<scientes> /etc/init.d/dkms_autoinstaller start
<cjwatson> robert_ancell: have you managed to get anywhere with bug 353090?
<ubottu> Launchpad bug 353090 in guadalinex "(jaunty) Text hidden on "Who are you?" step" [High,Confirmed] https://launchpad.net/bugs/353090
<cjwatson> robert_ancell: (I'm off to bed now, but will read messages)
<cjwatson> does anyone here suffer from bug 44194 (or, failing that, even just using WPA wireless networking would be somewhat interesting)? If so, could you please make sure you're up to date with jaunty and then upgrade to the wpasupplicant package in my PPA (https://launchpad.net/~cjwatson/+archive/ppa)?
<ubottu> Launchpad bug 44194 in openssl "wpasupplicant doesn't start when the network start" [High,Fix released] https://launchpad.net/bugs/44194
<cjwatson> I don't actually have a WPA network here so it's a bit tricky ...
<cjwatson> and I'd like a bit of testing from people who know what they're doing and how to recover from problems before unleashing it on the large number of subscribers to that bug
 * cjwatson goes to fall over for a bit
<TheMuso> cjwatson: I run a WPA wireless network here with a couple of Ubuntu WPA clients. I'll get latest updates and check that bug to see whether I suffer from it, and if so, will test your fix.
<slangasek> cjwatson: I do have separate /usr, so I could do some testing; would probably be another day or two before I get a chance though, with the rebooting & fiddling involved
<TheMuso> Oh, separate /usr, and static wpa config. I have neither configuration here. :)
<ikus060> May someone give me some clue, I'm looking for the source code that define the behaviour of Apple Keyboard
 * calc wonders if there is anything stopping us from flipping a bit to compressing all debs by default with lzma
<calc> aiui opensuse already does that for rpm's
<Keybuk> calc: isn't the reason we don't more to do with lzma's massively increased speed and memory requirements?
<calc> well it takes more on the compression side but takes less cpu time to decompress than even bz2
<calc> memory requirement was ~ 30MB iirc to decompress
<Keybuk> calc: but bz2 uses more cpu time to decompress than there are seconds left in the universe's life
<Keybuk> so that bar is so low, you practically trip over it on the way in
<calc> iirc it would save us ~ 200MB on the alternate cd when i tested it before
<Keybuk> the alternate CD is not the only problem space-wise
<Keybuk> and, pointedly, the alternate is the fallback in the low memory situations
<calc> yea, getting lzma onto the desktop cd would be more problematic :\
<Keybuk> I'd be interested to see benchmarks, but I'd be surprised if lzma performed anywhere near gzip
<Keybuk> obviously it can be enabled on a package-by-package basis like we do with bz2
<calc> hmm true
<Keybuk> we already use bz2 for mostly-text debs where we remember
<calc> how much ram does the alternate disk take by itself i would think we would still be well below the minimum install requirements even with lzma
<Keybuk> no idea
<calc> roughly 3x slower than gzip to decompress
<calc> with bzip being 8x slower than gzip
<Keybuk> what's the difference in compression like?
<calc> as of 7.10 gzip for a whole cd would be 708MB vs 500MB for lzma
<Keybuk> really?
<Keybuk> you tried it?
<calc> also reduces bandwidth requirements obviously for network updates, etc
<calc> https://wiki.ubuntu.com/dpkg-lzma
<calc> yea when i patched dpkg to support lzma
<calc> original was a mixture of bzip2 and gzip already on the cd, i recompressed it all with gzip, bzip2, and lzma to get numbers to see if everything was in one format
<Keybuk> I just picked on a random package
<Keybuk> -rw-r--r--  1 scott scott 170K 2008-09-29 18:04 upstart_0.3.9-8_i386.deb
<Keybuk> -rw-r--r--  1 scott scott 170K 2009-04-06 21:04 upstart_0.3.9-8_i386.deb_lzma
<Keybuk> zero difference
<Keybuk> well
<Keybuk> -rw-r--r-- 1 scott scott 173672 2008-09-29 18:04 upstart_0.3.9-8_i386.deb
<Keybuk> -rw-r--r-- 1 scott scott 173754 2009-04-06 21:04 upstart_0.3.9-8_i386.deb_lzma
<Keybuk> the lzma is, in fact, larger
<calc> the ods file on the wiki shows the all the packages on the cd as of 7.10
<Keybuk> I instantly disbelieve the wiki page
<calc> there were a small numbers of packages like that which grew very slightly
<Keybuk> 	
<Keybuk> original
<Keybuk> 	
<Keybuk> none
<Keybuk> 	
<Keybuk> gzip
<Keybuk> 	
<Keybuk> bzip2
<Keybuk> 	
<Keybuk> lzma
<robert_ancell> cjwatson: will update you when I can...
<Keybuk> 	
<Keybuk> lzma saves
<Keybuk> openoffice.org-core
<Keybuk> 	
<Keybuk> 37215228
<Keybuk> 	
<Keybuk> 112219498
<Keybuk> 	
<Keybuk> 38941278
<Keybuk> 	
<Keybuk> 37319546
<Keybuk> 	
<Keybuk> 27002374
<Keybuk> 	
<Keybuk> 10212854
<Keybuk> err
<Keybuk> BAD PASTE
<Keybuk> what I was trying to point out is that the original number doesn't match ANY of the other numbers!
<Keybuk> so, according to that wiki page, all of the packages are apparently compressed with fairyzip
<calc> for upstart as of 7.10 it was gzip 159454, bzip2 157482, lzma 138966, but of course has changed now
<calc> Keybuk: eh?
<Keybuk> upstart has not changed since 7.10
<calc> fairyzip?
<Keybuk> not majorly anyway
<Keybuk> calc: as in, the numbers do not match
<calc> compiler has
<Keybuk> calc: openoffice.org-core original should match bzip identically
<Keybuk> otherwise the test is not valid
<calc> well i was using the regular utils to compress not whatever dpkg does internally
<Keybuk> dpkg just uses them too
<calc> maybe it uses some different args to tar for older compatibility?
<Keybuk> not that I know of
<Keybuk> easiest way is just to extract and recompress the control.tar.gz
<Keybuk> gunzip && bzip2
<calc> the difference is on the order of 0.28%
<calc> thats what i did and it ended up with different sizes than dpkg
<Keybuk> you recompressed the entire cd?
<calc> i'm not sure if i still have the scripts but i used dpkg to pop out the control and the data and then recompressed the data and stuffed it back in
<calc> yes, and the ods shows all the packages
<Keybuk> cool
<Keybuk> I'm surprised it's honestly that much
<calc> a lot of the differences were in the range of .01% difference between original and the same compression type as original
<calc> but they look like they consistently ended up different sizes than the original packages compressed in at least supposed to be the same way
<Keybuk> we're already using lzma for things like openoffice now, right?
<calc> yea
<calc> it bought 14% over bzip2 on OOo source in a test i just did
<calc> not bad considering how big OOo is, heh
<Keybuk> the unlzma times seem quite reasonable here
<Keybuk> unlzma data.tar.lzma  7.85s user 0.53s system 96% cpu 8.670 total
<Keybuk> gunzip data.tar  2.86s user 0.46s system 99% cpu 3.331 total
<calc> yea
<Keybuk> it's the lzma times that really bite though
<calc> yea
<calc> but that is a one time cost... depends on if it is too high a one time cost i guess
<Amaranth> Keybuk: lzma fails even worse once your gzip implementation uses threads
<Amaranth> calc: that was the inflate time, not the deflate time
<Keybuk> once per upload/build cost
<calc> Amaranth: i was talking about deflate, yes
<calc> Amaranth: deflate takes much longer
<calc> Keybuk: we already have a huge cost by dpkg-shlibdeps, yuck
<Keybuk> not that huge
<Keybuk> lzma has been running for what seems like minutes so far...
<calc> Keybuk: for OOo it is like 50% of the build time for a cached build i think
<calc> on the order of 20min+
<Amaranth> eep
<calc> i need to dig into that later this week since i have my bugs under control
<Amaranth> calc: every time you talk about OOo building you make me less and less likely to ever even apt-get source it :P
<calc> i had talked to cjwatson about having a way to disable that option, heh
<calc> both the lzma and dpkg-shlibdeps could have flags to disable them for developer building and only enable them on buildds or something if needed
<calc> or so developers can disable them if they need to build quickly in any case :)
<Keybuk> lzma data.tar  206.26s user 0.53s system 99% cpu 3:27.41 total
<Keybuk> gzip data.tar  19.77s user 0.32s system 99% cpu 20.099 total
<calc> yea compression is yucky
<calc> hmm it was only 4x slower in my test back in 7.10 though, that is interesting
<calc> another place where lzma could help is in archive files like Contents, (amd64) gzip is 15759388, bzip2 is 12875965, and lzma is 10991062
<calc> currently we appear to only have gzip versions available
<calc> contents isn't grabbed all the time but packages file see similar percentage improvements
<Keybuk> yes
<Keybuk> because the publisher run needs to take longer ;)
<calc> lol :-)
<TheMuso> c
<bluefox_> Congratulations on Ubuntu Jaunty Beta for x86_64!
<bluefox_> You should add to your milestones, "Almost as stable as WindowsME!"
<JanC> <Amaranth> Keybuk: lzma fails even worse once your gzip implementation uses threads
<JanC> lzma2 should be much better with multiple cores...
<JanC> don't know if there is a linux port of that already?
<JanC> it divides the file in "blocks" that it can compress in parallel
<slangasek> bluefoxicy: trolling is inappropriate and unwelcome.
<jdong> slangasek: wrong bluefox :)
<jdong> friendly fire!!!!111
<jdong> wait...
<jdong> what the...
<jdong> you know what, I'm gonna go to bed now. Night :)
<slangasek> jdong: night :)
<Mithrandir> it's been entirely stable from me, apart from sometimes failing to power off properly.
<jdong> the OS itself has been great, but audio problems with proprietary crap has regressed
<jdong> high CPU usage, latency, and cutouts from Skype especially, also Flash.
<jdong> other than that, by far one of the cleanest upgrades I've done
<JanC> about lzma2: http://sourceforge.net/forum/forum.php?thread_id=2965956&forum_id=45797
<JanC> (appears it's still alpha or beta though)
<TheMuso> jdong: Sorry not much we can do re skype, other than you kill pulseaudio to use skype.
<TheMuso> jdong: Oh try also using direct hardware input for the microphone via skype, and only use pulse for output.
<slangasek> TheMuso: pulseaudio-module-x11 Recommends: gnome-audio | ubuntu-sounds, which confuses germinate; is there any reason not to reverse the order of these?
<TheMuso> slangasek: persia actually asked to have them turned around at one point, I can't remember his reasoning however. I think its in the changelog, let me look.
<hile> should it  be supported to change /usr/bin/python symlink to other supported versions than python2.6 in jaunty?
<slangasek> TheMuso: arguably the Recommends should be dropped entirely...
<slangasek> hile: no
<hile> ok
<persia> I asked to switch it around precisely because it confused germinate.  Dropping it would also meet my goals.
<slangasek> persia: you asked to have gnome-audio listed first because of germinate?
<persia> (or perhaps not "confuse" but rather "generated a behaviour I didn't want")
<slangasek> ah
<hile> fair enough, that would complicate things very much :)
<TheMuso> Yeah I think pitti dropped them, but somehow they were re-added. I'll remove them.
<slangasek> TheMuso: ok, cheers :)
<persia> slangasek, Yes.  I don't remember the specifics, but it was something about gnome-audio being installed when there was an ubuntu-sounds alternative available: perhaps related to universe flavours.
<persia> RIght.  That was it: for universe flavours, ubuntu-sounds wasn't getting installed because gnome-audio was available.
<slangasek> persia: ok.  the current formulation is going to prefer pulling in gnome-audio for universe flavors; it also causes germinate to want to pull gnome-audio into main.  All told, it results in rather a bit of inconsistency.
<hile> I just had some personal code using default python which did not work in 2.6 and I changed 'temporarily' the link, noticing upgrade failed horribly - if it were supposed to be supported to change default python, there would have been a couple of bug reports to be done
<persia> slangasek, I'd agree, especially because I think we'd generally prefer ubuntu-sounds anyway.
 * slangasek nods
<hile> anyway, just fixed my own code, that's the better solution anyway :)
<slangasek> hile: right - generally, packages are allowed to depend on a specific version of the 'python' package, and expect /usr/bin/python to be that version.
<slangasek> packages that need a version of python *other* than the current default can still invoke it as /usr/bin/python2.x
<persia> Note that packages that *do* use /usr/bin/python2.x need to be very careful about the libraries that may be available to that version of python.
<hile> yeah this was not packaged code anyway, just some local projects
 * StevenK sighs at libdvdread reporting itself as 0.9.4 in Jaunty
 * slangasek sighs at ogmrip having unreasonable requirements for libdvdread's version reporting
<slangasek> :)
<StevenK> slangasek: Ah, so you do know what is going on.
<StevenK> slangasek: I can patch libdvdread with a one-line patch and then ogmrip requires no changes.
<slangasek> StevenK: I got as far as the FTBFS and punted on it
<slangasek> I have no preference on how you fix it
<slangasek> well; if you change libdvdread, I prefer that it not make other packages FTBFS :)
 * StevenK sobs at the rdepends list.
<StevenK> slangasek: In other news, do you know about openoffice.org-qa-{api-test,tools} in NBS?
<StevenK> slangasek: They look to have circular Depends, too
<slangasek> StevenK: yeah - I actually removed those two just now
<robert_ancell> cjwatson: have workaround for bug 353090
<ubottu> Launchpad bug 353090 in ubiquity "(jaunty) Text hidden on "Who are you?" step" [High,In progress] https://launchpad.net/bugs/353090
<seb128> hey robert_ancell
<robert_ancell> seb128: morning seb
<davmor2> Guys I got an issue with samba.  I've got a share on my hardy server that works with vista, xp and intrepid but doesn't with jaunty.  I'm just looking through the bug report now to see if it's known but thought I'd better add it here too
<cjwatson> robert_ancell: cool, thanks! will look into that. presumably if the parent widgets aren't realized then .realize() just harmlessly does nothing?
<ogra> asac, do you have an idea about bug 356517
<ubottu> Launchpad bug 356517 in udev "udev does not detect eth0 on armel" [Undecided,Invalid] https://launchpad.net/bugs/356517
<mvo> could someone please eyeball http://launchpadlibrarian.net/24926831/debdiff ?
<cjwatson> mvo: looks ok to me
<mvo> thanks
<mvo> tests work fine too, I will upload
<asac> ogra: driver issue i would think
<asac> ogra: do you have a lshal from such a board for me?
<ogra> i can produce one
<asac> ogra: please do and attach to bug (i asked now)
<c_korn> hello. why is the number of processes not limited in /etc/security/limits to prevent fork bombs?
<mnemo> good question
<mnemo> it's insane that somebody can login to a non-root shell and disrupt the whole system
<c_korn> I read that debian is not affected
<seb128> by what?
<c_korn> <c_korn> hello. why is the number of processes not limited in /etc/security/limits to prevent fork bombs?
<seb128> oh, dunno about that one
<cjwatson> Debian does not set a maximum number of processes in /etc/security/limits.conf either, so I don't know where you read that. You can check the differences yourself: http://patches.ubuntu.com/p/pam/pam_1.0.1-9ubuntu1.patch
<cjwatson> I imagine the problem is that there is no sensible default. Any limit that will be high enough to avoid impeding legitimate work would also be high enough that a forkbomb would cause problems well before it ever reached the limit
<cjwatson> weren't there kernel scheduler changes to try to level out timeslices among users, so that even if one user had a zillion processes running, another user could still get their processes scheduled effectively?
<cjwatson> that's a much better approach to this kind of problem
<ogra> asac, attached
<c_korn> "I'll quickly mention here that Debian did not suffer the same fate as the others; congrats to the Debian development team." ( http://www.securityfocus.com/columnists/308 ) but in the comments someone said debian is affected
<c_korn> so the kernel scheduler has to be fixed instead of setting a maximum number of processes?
<c_korn> has to be hard because the problem still exists
<cjwatson> all approaches to this problem are hard; there is no easy answer (assuming you don't just ignore some of the constraints, as journalists are apt to do)
<mnemo> im a customer at a small shared web hosting where they give ssh access
<mnemo> they not big and professional but I really like the ssh access
<mnemo> I tried a fork bomb in that shell and their server got hosed
<mnemo> they run debian, but a really old version
<mnemo> i bet there is lots of ubuntu server installs like that, where a fairly large set of semi-untrusted people are given non-root accounts
<mnemo> i dont pretend to have a solution though..
<asac> ogra: that unfortunate. why does that driver need that parent?
<cjwatson> the general term for scheduler fixes that address this problem is "group scheduling"
<asac> ogra: udi = '/org/freedesktop/Hal/devices/net_00_00_45_67_89_ab'
<asac>  info.parent = '/org/freedesktop/Hal/devices/computer'  (string)
<cjwatson> you can google for it with site:lwn.net for a number of good explanations
<asac> ogra: is that kind of a special device?
<asac> e.g. not pci et al?
<asac> ogra: we opted out managing virtual devices
<asac> ogra:   linux.sysfs_path = '/sys/devices/virtual/net/eth0'  (string)
<c_korn> "if a user is running a fork bomb then other users are not affected at all [CPU scheduling wise], and the admin can log in and disable the user as well.)"
<cjwatson> I suspect that the problem is that we have cgroup scheduling enabled, but aren't properly setting up cgroups for tasks
<c_korn> as this seems to be a bigger problem I might open a question in launchpad for the ubuntu kernel
<asac> cjwatson: did your broadcom driver finally get a proper name or do you still see 'NULL(info.linux.driver)' in the syslog?
<cjwatson> /var/log/syslog.6.gz:Mar 31 21:00:08 sarantium NetworkManager: <info>  (wlan0): new 802.11 WiFi device (driver: 'NULL(info.linux.driver)')
<cjwatson> asac: ^-
<asac> sigh
<asac> ogra: ^^
<cjwatson> asac: that said it works fine ...
<asac> cjwatson: yes. we still carry a patch for that
<asac> i hoped we could drop it
<robert_ancell> cjwatson: yes, afaik realize() is not an issue for already realized widgets
<asac> ogra: can you drop the lp199140_dont_manage_virtual_devices.patch; that whould work; then i need the syslog while it works
<robert_ancell> cjwatson: re-read your question, yes it will realize any unrealized parents
<c_korn> I asked a question in launchpad about it: https://answers.launchpad.net/ubuntu/+question/66716
<c_korn> thanks for your answers (in this channel)
<Riddell> asac: how does firefox do its mimetype detection currently?
<ogra> asac, its ARM ...
<ogra> asac, there is no publically expo9sed PCI bus on any ARM devices
 * ogra twiddles thumbs installing the build deps ...
<KaiL> siretart, plans for xine-lib 1.1.16.3? It's a security update
<siretart`> KaiL: dtchen: I see that darren already has prepared an 1.1.16.3 upload. I'll check with him and merge that in the ubuntu hg branch
<KaiL> ah, ok
<RicardoPerez> seb128: hi, the fix for bug #352657 has a nasty side-effect. it's better to remove it or to code another variant of the same fix. I've posted the problem in the bugreport
<ubottu> Launchpad bug 352657 in evolution-indicator "All the strings from evolution-indicator shows untranslated" [Low,Confirmed] https://launchpad.net/bugs/352657
<seb128> RicardoPerez: hi, I've read your comment on the bug and I don't get the issue there, waiting on ted to be online
<RicardoPerez> seb128: OK. are you followed the steps to reproduce the new issue?
<seb128> no
<seb128> I've been too busy for that, I'm waiting for ted as said before
<RicardoPerez> seb128: ok, thanks for all
<seb128> you should relax a bit, the way you pressure one bugs nominating everything for jaunty etc is not helping there
<seb128> everybody is busy
<slytherin> I have a quick question. Rhythmbox has support for using brasero for CD writing. Considering that we have removed nautilus-cd-burner from default install and also totem is using brasero, shouldn't rhythmbox packaging be updated accordingly?
<seb128> slytherin: no, it's too late in the cycle for a such technology change
<RicardoPerez> seb128: yes, sorry about that. I'm not nominating anything since you told me about
<slytherin> seb128: thought so. Just wanted confirmation.
<slytherin> seb128: Oh, and I have another specific question related to gst-plugins-base package. How do I stop from i686 getting added to arch list in debian/control file everytime I do debuild -S (lintian gives error about i686)?
<seb128> slytherin: though it's easy to test and fedora is doing it already so we might want to consider it
<seb128> slytherin: I don't know, I've not been looking to that, we are on sync with debian for this one, does that create any issue?
<slytherin> seb128: the libasound2-dev build dependency has specific architectures. the list of arch is generated by using output of some command and I always get this problem. I believe the pbuilder will also fail building the package but I didn't try it yesterday. I will try today and let you know.
<seb128> slytherin: I doubt it's a stopping error
<slytherin> seb128: I will check again tonight.
<slytherin> Although why it should use any architecture list is beyond me.
<seb128> it's probably because some things are not available on bsd or hurd for example
<seb128> so they need to make a list not including those
<ogra> asac, ok, works with dropping the patch there are additional deriver issues though
<slytherin> seb128: but then doing [!bsd !hurd] is easier right?
<slytherin> anyway, i will check if it fails to build.
<seb128> slytherin: not sure why they don't exclude archs only, they use type-handling which does that listing
<asac> ogra: can you give me a syslog anyway?
<ogra> will do
<ogra> asac, attached
<lamont> Error org.freedesktop.DBus.Error.Failed: Element <syslog> not allowed inside <busconfig> in configuration file
<lamont> ^^ do we care that the jaunty upgrade from intrepid says that during hal install?
<lamont> I'm betting it's transient and because we're mid-upgrade
<cjwatson> mvo: doc-base aging period waived; copied to -updates
<cjwatson> slangasek: ^-
<mvo> cjwatson: thanks!
<ogra> asac, mind if i assign bug 356517 to NM and milestone it ?
<ubottu> Launchpad bug 356517 in udev "udev does not detect eth0 on armel" [Undecided,Invalid] https://launchpad.net/bugs/356517
<asac> ogra: not sure if its a NM issue.
<ogra> asac, its works fine if i drop your patch
<ogra> that will need special casing on arm
<asac> ogra: well. upstream wouldnt work
<asac> ogra: drop the NULL patch we also have
<ogra> as i said above, arm has no PCI bus
<asac> (which is actually causing the bug that makes the virtual patch fail)
<ogra> you mean drop both ?
<ogra> or only the NULL one ?
<asac> ogra: yes. try to drop both. if it still works that would be good to know
<ogra> ok, but i urgently need to milestone it else we wont get it past release managers
<asac> ogra: from what i see now what we need is a way to differentiate between the case we fixed by the virtual device bug and the armel valid virtual ethernet
<ogra> well, you know what arch youre on
<lamont> is there a nice little inotify app (or something) somewhere that will tell me who is modifying _that_ file?
<lamont> because having both domain and search directives in resolv.conf offends me
<lamont> mostly because it scares me to have such cluelessness displayed in such a critical file
<liw> lamont, oh, that's a clever idea: a generic inotify app to catch access to a specific file, I like that
<Mithrandir> you don't know who did it, though
<Mithrandir> ps ax in incron for /etc/resolv.conf, maybe
<lamont> Mithrandir: ew
<lamont> make it chattr -i resolv.conf and see who screams?
<lamont> well, +i
<lamont> mv: cannot move `/etc/resolv.conf.dhclient-new' to `/etc/resolv.conf': Operation not permitted
<lamont> ^^WINNAR
<ogra> asac, without NULL i dont see eth0 in the nm-applet anymore
<asac> yeah
<asac> so not supported upstream either
<ogra> well, all i can say is that it used to work until some days ago
<asac> i will talk to dan
<asac> ogra: right. because of the NULL patch which we have in ubuntu to support the broadcom thing
<asac> so mostly out of luck ;)
<ogra> can i assign it to NM and milestone ?
<asac> ogra: well. given that we want to support it, please do
<ogra> ok :)
<asac> ogra: please assign to me and set in progress
<jcastro> I am looking for some openweek volunteers: https://wiki.ubuntu.com/UbuntuOpenWeek/Prep
<jcastro> holler at me if you have questions
<ogra> evil Keybuk just left me with a homeless bug :P
<seb128> jcastro: when is it?
<jcastro> seb128: the week after release
<seb128> oh ok
<seb128> what about getting sleep etc ... ;-)
<Keybuk> ogra: ?
<jcastro> seb128: that's what the weekend is for!
<ogra> Keybuk, just joking, bug 356517
<ubottu> Error: Could not parse data returned by Launchpad: Unknown host. (https://launchpad.net/bugs/356517/+text)
<seb128> jcastro: DOH, I though those were to catch up on bug emails while IRC is not running ;-)
<jcastro> seb128: you can do that during the times when you are not doing a session, heh
<seb128> heh ;-)
<Keybuk> ogra: ah, iz HAL bug
<Keybuk> honestly, I suspect you're not going to get a HAL fix in time for jaunty
<ogra> Keybuk, hal ?
<Keybuk> I think so, HAL tends to get grumpy about devices hanging off /computer
<ogra> Keybuk, its a bunch of bugs ... one is that the driver doesnt detect plug events
<Keybuk> ICBW though
<ogra> one other is that NM ignores non PCI NICs
<Keybuk> is NM ignoring them or is HAL?
<ogra> lshal has it
<ogra> and it worked until last week
<Keybuk> ok
<Keybuk> I'll shut up then
<ogra> but indeed lshal has it under computer
<Keybuk> sure, it's a platform device
<ogra> since ARM has no publically exposed PCI bus
<Keybuk> in general, udev has little to do with network interfaces other than renaming them
<Keybuk> I didn't think ARM *had* a PCI bus
<ogra> yeah
<ogra> it does
<Keybuk> I thought the individual bits of the board were just hardwired into certain bits
<Keybuk> why don't they expose it then?
<ogra> but its not accessible from anywhere
<Keybuk> seems kinda silly
<ogra> tedg, once told me, i didnt really understand his explanation :)
<ogra> but apparently there is a PCI bus in the backend thats not exposed anywhere
<ogra> so you can add the cheap PCI components but hardwire them
<ogra> (he probably can elaborate on that :) )
<tedg> ogra: I was just saying that it could have an on-chip PCI bus.  That's relatively common for SoCs.  Not sure about those chips specifically.
<ogra> right
<ogra> on-chip PCI bus was the term i was missing :)
<tedg> I worked at Motorola, so we did mostly Motorola proprietary buses across the chips, but I would imagine someone that doesn't have that history would be better off using something they're more familiar with.
<tedg> You'd be amazed what we could do with a 68K bus :)
<ogra> well, doesnt gain us much if the HW doesnt expose it
<ogra> the thing is that nowadays every SW is written with the assumption that HW is PCI or USB ...
<ogra> and visible to the kernel
<ogra> through either of these busses
<agateau> I just figured out a bug in ubuntu installer: when installing from an usb hard drive, a cdrom entry is added to /etc/fstab for the drive, as a result one can't mount any usb harddrive after install has finished
<agateau> which package should this be reported to?
<agateau> ubiquity?
<cjwatson> agateau: no need to re-report it; bug 33512
<ubottu> Launchpad bug 33512 in partman-target "Removeable devices shouldn't be put into fstab" [Wishlist,New] https://launchpad.net/bugs/33512
<agateau> cjwatson: oh ok
<agateau> looks old according to bug id
<cjwatson> agateau: the reason we can't just remove it is that apt-cdrom depends on it (unless that's been fixed recently)
<cjwatson> it's a very long-standing issue indeed, known at least since hoary
<agateau> cjwatson: annoying, it really makes first boot experience not as smooth as it could be
<cjwatson> I know, but the alternative right now is a regression in other cases
<agateau> cjwatson: ok
<agateau> i am afraid this will become more common as more people install from usb (think netbook)
<cjwatson> agateau: I'm painfully aware of the problem
<agateau> cjwatson: isn't it possible to use "auto" for the filesystem?
 * agateau has not tried it
<cjwatson> agateau: um
<cjwatson> agateau: it's not the filesystem that changes, it's the device name
<cjwatson> agateau: the fix is for apt to find CD devices dynamically
<agateau> cjwatson: in my case: i had no cd device, but it tried to mount my usb stick as iso9660, if fs was set to auto, I guess it would have worked (mounted in /media/cdrom, but it's less naughty)
<cjwatson> mm, ISTR auto being problematic in some cases though
<cjwatson> anyway, would rather get it fixed properly
<agateau> sure, was just trying to figure a workaround for jaunty
<cjwatson> it's not a regression in jaunty; hardy was used on netbooks as well and has the same problem
<cjwatson> so given that I *know* that things like language pack installation are excruciatingly sensitive to changes in this area, I'd rather leave it alone for jaunty
<agateau> yes, but as time passes, more people try ubuntu on netbooks, especially with unr coming
<cjwatson> for now, I think it's still the case that more people require non-English systems than require netbooks :-)
<agateau> :)
<cjwatson> I'm not saying the bug is unimportant; just that incautious changes in this area have a high risk attached to them
<agateau> i understand
<agateau> at least i know this is a known bug, if i ever come up with a more clever idea, i'll comment the bug entry
<cjwatson> I'm sure there's a better bug about this, but I couldn't find it easily
<agateau> I assume using /dev/scd0 instead of /dev/sdb1 is not a good idea either
<ogra> isnt that whats currently used ?
<agateau> ogra: no, my machine had a /dev/sdb1 entry
<cjwatson> ogra: it's dynamic
<ogra> ah
<cjwatson> agateau: if the device had actually been /dev/scd0, I'm sure it would have used that ...
<cjwatson> bear in mind that device names can be different post-installation from during installation
<agateau> cjwatson: hmm, yes you are right, in my case I was using a usb stick so /dev/sdb1 was correct at install time
<ArneGoetje> cjwatson: about translations for the Live CD: do we download the new translations from Rosetta and put them into the packages? Who takes care of this?
<cjwatson> ArneGoetje: I do
<ArneGoetje> cjwatson: ok. do you have a list of source packages for which we are doing this?
<cjwatson> ArneGoetje: on the phone, will get back to you
<ArneGoetje> cjwatson: ok
<jdong> TheMuso: yeah, I figured Skype would be one of those things; Any particular reason you can think of that CPU usage has regressed significantly since Intrepid+pulse?
<ebroder> Do the buildds see packages that were just built? Or only packages that have been accepted into the archive?
<ebroder> (I'm wondering about the failed mpb 1.4.2-12ubuntu1 build - it should have used the libctl 3.0.3-1ubuntu1 that was uploaded shortly before)
<savvas> I think they have to be in the archive, but I'm generally wrong today so.. wait for another reply :)
<savvas> #launchpad or #ubuntu-motu people should probably know if no-one replies
<ebroder> Ok
<cjwatson> ebroder: build-dependencies have to be not only accepted into the archive, but published
<ebroder> cjwatson: Huh, ok
<cjwatson> ebroder: the only short-cut that buildds have is that they fetch files from the master archive, so they can get away with publication not quite being complete (germinate doesn't have to have run, and archive.ubuntu.com doesn't have to have been pulsed)
<cjwatson> ebroder: but trying to rely on this is difficult unless you have direct access to see exactly what state the system is in
<cjwatson> you can use versioned build-dependencies to force things
<ebroder> I did
<ebroder> "Build-Depends: ... libctl-dev (>= 3.0.3-1ubuntu1) ..."
<cjwatson> ebroder: in that case, no harm done, it can be retried later
<ebroder> Ok. Should I ping someone, or will it happen automatically?
<cjwatson> oh, that's why it failed rather than going to dep-wait as it normally would
<cjwatson>   libctl-dev: Depends: guile-1.6-dev but it is not going to be installed
<ebroder> Right - the new version changed that dependency
<cjwatson> ebroder: your sponsor has a retry button; ask whoever it was to poke it in (say) an hour's time
<ebroder> Thanks - will do
<cjwatson> actually give it a bit more than an hour, say 1.5 hours for luck
<ebroder> *nods*
<mok0> ebroder: I am responsible for that versioning
<ebroder> mok0: Oh, hi. Thanks for the sponsorship
<mok0> ebroder: I will make sure meep and mbp get built
<ebroder> Oh hmm...meep probably built successfully against the old libctl-dev. I bet that'll need another upload. Anyway, I'll let you take care of it. Thanks
<mok0> ebroder: It failed to build on my sbuilder because of a missing dep, so I assumed it was alright
<ArneGoetje> cjwatson: do you have a list of source packages, for which you are going to pull translations from Rosetta and put them into the packages directly? I would like to give our translators a notice to focus on those templates until the deadline on 9th.
<cjwatson> ArneGoetje: sorry for the delay. debian-installer/+pots/debian-installer, debian-installer/+pots/help, gfxboot-theme-ubuntu/+pots/bootloader
<ArneGoetje> cjwatson: that's all?
<cjwatson> ArneGoetje: with the usual caveat that I only consider those strings in debian-installer/+pots/debian-installer that are specific to Ubuntu - I don't import updates to strings already translated in Debian, since that's a hideous amount of work for me
<cjwatson> ArneGoetje: yes, that's all. debian-installer/+pots/debian-installer is an aggregated .pot file that gets spread out to lots of other packages
<cjwatson> and includes e.g. ubiquity
<ArneGoetje> cjwatson: ok... how about the desktop applications? they are only shipped with language packs?
<cjwatson> ArneGoetje: right
<ArneGoetje> cjwatson: ok, thanks
<cjwatson> technically apt debconf dpkg iso-codes language-selector also need manual updates, but we've never done those for the first four; I don't know if you do something for language-selector
<cjwatson> if you want me to do that, I have scripts to help me so I can do it if you like
<cjwatson> (language-selector only, I'd rather not introduce large diffs to the other four)
<ArneGoetje> cjwatson: hmm... I planned to do language-selector and iso-codes
<ArneGoetje> cjwatson: the language and country lists in language-selector are taken from iso-codes
<cjwatson> could you please not do iso-codes?
<cjwatson> I'm concerned that doing that will result in a vast unmergeable diff against Debian
<cjwatson> that's a case where we really, really need to get translations sent upstream
<ArneGoetje> cjwatson: okay... so rather push those to upstream?
<cjwatson> individual translators would need to do that
<cjwatson> IME if you try to do it centrally you end up trying to mediate disputes between translators in 60 languages you don't speak
<ArneGoetje> cjwatson: got it
<cjwatson> we've been synced with Debian on iso-codes for a while, btw
<cjwatson> I realise it's non-ideal in some ways, but would prefer not to rock that particular boat right before release; iso-codes is used by chunks of the installer too
<Keybuk> I love the smell of X lock-ups in the morning
<ArneGoetje> cjwatson: ok, I'll still ask the translation teams to submit their translations for iso-codes back to upstream (alioth), though we won't sync before release anymore
<lool> seb128: We just noticed that ubiquity was probably failing to reboot with gdm-signal as it used to (it seems it works with "reboot" at the moment); should it be ported to a ConsoleKit call?
 * jdong angrily kicks fglrx
<ArneGoetje> cjwatson: I will also put a note for translators into those templates on Rosetta explaining this.
<jdong> I'm sorry I didn't pay attention in art class when we talked about picasso, don't punish me for it NOW...
<lool> seb128: What would be the best way to reboot cleanly after an install?  Copy the logic in gnome-session for Restart?
<seb128> lool: no, the gdm-signal still works that's what update-notifier is using
<lool> seb128: It's not installed anymore, is it?
<seb128> lool: we didn't switch to the new gdm yet
<lool> powermanagement-interface ships the gdm-signal bianry
<ogra> seb128, pmi is gone
<seb128> use gdmflexiserver directly?
<lool> seb128: When I say "gdm-signal" I mean the gdm-signal command-line tool
<seb128> let me look at what mvo does in update-notifier
<lool> seb128: Here I'm using CK I think (I'm logging in with startx), and I think GPM starts the gnome-session dialog which calls into CK I think
<ArneGoetje> cjwatson: should we set a deadline when we will do the final translation sync from Debian for iso-codes?
<cjwatson> lool,seb128: sending a dbus call to consolekit looks like a sensible approach to me
<seb128> lool: you can do that, you will take the session down the same was than a xorg crash though
<cjwatson> ArneGoetje: it depends on when Debian chooses to do uploads
<seb128> if you use gnome-session you will get cleaner session closing
<seb128> and session saving if there is work open
<cjwatson> use gnome-session in what specific way?
<lool> seb128: There doesn't seem to be a gnome-session-save reboot option, you mean the gnome-session dbus api?
<seb128> there is no dbus api for that
<cjwatson> remember that ubiquity does not actually start a gnome session in its "Install Ubuntu" mode
<mvo> seb128: I use the source from gdm-signal in u-n
<ArneGoetje> cjwatson: well, I mean after what point in a release cycle we won't update that package anymore...
<lool> cjwatson: good point
<cjwatson> only when it's started from a full desktop
<seb128> right, in the installed context you can use the policykit dbus api
<lool> cjwatson: However you could try gnome-session and fallback on direct CK, if there's any benefit to that
<seb128> but gdm-signal should still be working
<cjwatson> ArneGoetje: I think, actually, translations would need to be sent upstream; but I'm not certain
<lool> seb128: it's not installed anymore
<seb128> that's what update-notifier uses
<lool> seb128: Then update-notifier is broken; nothing depends on powermanagement-interface anymore   :-/
<cjwatson> oh, upstream is pkg-isocodes.alioth.debian.org
<seb128> lool: well if it's not and update-notifier using it then we have an issue
<mvo> lool: u-n is shipping its own copy
<lool> seb128: Yeah
<lool> mvo: Oh
<cjwatson> ArneGoetje: non-language-pack translation deadline would seem sensible
<cjwatson> powermanagement-interface is in universe now, in fact
<ArneGoetje> cjwatson: that would be this Thursday.
<cjwatson> yes
<seb128> cjwatson, lool: if you don't care about the session state call the consolekit dbus api
<seb128> it's easy and do the job
<mvo> lool: well, not literatelly building the binary, but shipping the small source-file as part of the u-n source
<mvo> and calling from u-n into that
<cjwatson> seb128: certainly don't care about it in "Install Ubuntu" mode
<lool> I don't think we care about the session; we're rebooting into a pristine home dir in all cases; execpt when using casper persistence and rebooting into the live CD perhaps?
<cjwatson> seb128: $GNOME_DESKTOP_SESSION_ID says "this-is-deprecated". What's a modern way to tell whether gnome-session is in use?
<cjwatson> lool: persistence is a valid enough case
<lool> cjwatson: Can't you check for the dbus service being there?  (well call into CK if the gnome-session call fails)
<ogra_> why would the gnome-session call fail
<seb128> cjwatson: I would do what lool says, query for gnome-session over dbus
<cjwatson> YM if gnome-session-save --kill --silent returns non-zero?
<cjwatson> ogra_: if there's no GNOME session
<lool> ogra_: if it's not running
<ogra_> oh
<lool> cjwatson: I meant the gnome-session dbus call
<cjwatson> org.gnome.SessionManager.Shutdown or something?
<cjwatson> that doesn't seem to distinguish between shutdown and restart
<cjwatson> oh, I should use Logout with mode=2 by the looks of things
<lool> gsm_logout_supports_reboot() tries CK first and then falls back to GDM
<cjwatson> I need to set the response to the shutdown dialog up-front
<ogra_> what does fusa do btw ?
<lool> cjwatson: gnome-session should be future proof and backwards compatible: http://paste.ubuntu.com/146297/
<lool> This should work with new GDM and our old GDM, with or without CK
<ogra_> hmm, update-notifier just does "gdm_set_logout_action(GDM_LOGOUT_ACTION_REBOOT);"
<lool> That wont work with plain CK
<ogra_> no
<lool> ie next cycle
<ogra_> nor with python
 * ogra_ was under the wrong assumption u-n was python
<cjwatson> lool: right, how do I preset the shutdown dialog response though?
<seb128> see consolekit_action() in fusa 84_session_management.patch
<seb128> on how to use consolekit
<seb128> but right, fusa doesn't use the session dialogs
<seb128> they just connect the restart action to their own dialog
<seb128> you might want to do that
<lool> cjwatson: Right, it might be easier to talk to gdm or CK directly   :-/
<cjwatson> but that won't get us session saving
<lool> No  :-/
<cjwatson> this is obscenely convoluted :-/
<tedg> lool: cjwatson: My understanding is that gnome-session doesn't do session saving on it's own dialog for reboot :-/
<seb128> well you said that you don't care for the installer?
<lool> cjwatson: You could set the gdm logout action to reboot, then run gnome-session-save --force-logout
<lool> (if present)
<seb128> tedg: that's going to be fixed this week ;-)
<cjwatson> seb128: no, I didn't
<seb128> so just call the ck api
<davmor2> pitti: bug 357133
<cjwatson> seb128: I said I didn't care about it in "Install Ubuntu" mode (i.e. installer launched directly without a full desktop), but it's valid in the full-desktop case if you're running from a USB stick with persistence
<ubottu> Launchpad bug 357133 in jockey "Jaunty: Kubuntu jockey applet shouldn't call kdesudo" [Undecided,New] https://launchpad.net/bugs/357133
<cjwatson> lool: well, that's pretty much what I used to do
<cjwatson> but everyone is telling me I should be using dbus now ;-)
<seb128> the easier right now is probably what update-notifier does and what lool said
<pitti> davmor2: I thought I already fixed that
<cjwatson> clone the gdm-signal code?
<seb128> yes
<lool> cjwatson: Yeah, except it seems the dbus API doesn't seem to allow avoiding the dialogs
<cjwatson> ok, I can do that
<seb128> it's tested and known to work
<davmor2> pitti: it is if you call it from the menu this is from the panel applet
<seb128> we will work on a clean solution for gnome-session in karmic
<seb128> there has been discussion for adding dbus api for those actions
<cjwatson> though blimey, what a lot of code
<cjwatson> I think I'd want to convert it to Python and strip it down for convenience
<pitti> davmor2: oh argh
<lool> cjwatson: Just FTR, gnome-session talks to the gdm socket directly, it writes 'REBOOT' or something like that; you could either copy gdm-signal's code or do that in ubiquity
<davmor2> pitti: If you wait a short time after install you get the applet appear in the panel.  If you click on that kdesudo gets called up first
<cjwatson> yes, the protocol does not look difficult
<pitti> davmor2: yep, just spotted it in the code, thanks
<pitti> will care for it
<davmor2> 'nps
<cjwatson> except for having to mess about with authentication
<cjwatson> hmm, there are no python libxau bindings?
<lool> As long as we use old gdm, it's probably best to stick to telling it to reboot; so we need one implementation, we could either expose the gnome-session one or copy it in ubiquity; the gnome-session one is only available for live, not for pure install mode  :-/
<cjwatson> maybe I will have to do this in C then :-
<cjwatson> :-/
<ogra> python-dbus ?
<seb128> what did you to do until intrepid?
<cjwatson> seb128: called gdm-signal
<ogra> seb128, gdm-signal
<seb128> and why does it break now?
<lool> seb128: not included anymore
<seb128> can't we get gdm-signal back on the CD for jaunty?
<cjwatson> ogra: I'm getting a little tired of the circular conversation ...
<seb128> it's tiny
<cjwatson> it comes with the rest of powermanagement-interface
<ogra> it could be separated
<cjwatson> I thought we had tried rather hard to simplify that out
<seb128> ok, I think we discussed the options enough
<lool> Size: 10960
<seb128> my favority would be the update-notifier way
<cjwatson> ogra: (we'd already discussed the problems with the dbus api above)
<ogra> seb128, is there any similar python function to gdm_set_logout_action() ?
<seb128> anyway as said discussed enough, I think cjwatson knows the option and can decide which one he prefers next
<seb128> ogra: not that I know about no
<cjwatson> I'm happy enough to just clone the code for the moment, as update-notifier does
<cjwatson> it's not pretty, but will serve
<seb128> ok
<cjwatson> I already have a src/cut-and-paste/ directory for this kind of purpose ;-)
<mvo> it will all be good with gdm-new and dbus
<lool> cjwatson: plars opened a bug for the reboot issue we were seeing on babbage
<mvo> until then "copy-n-paste"
<lool> cjwatson: i told him to reassign to ubiquity
<cjwatson> lool: thanks
<pjwaffle> hi
<liw> hmph, I upgraded to the current intrepid, and now my wired network doesn't work
<pjwaffle> Hey I am curious why doesn't anyone setup a port for Linux to use the Minix or a BSD kernel... like Debian did
<seb128> liw: try jaunty?
<liw> seb128, the upgrade to current intrepid was in preparation for upgrading to jaunty; now I can't do that, until I fix the network
<pjwaffle> oops I mean for Ubuntu to use a BSD kernel or Minix
<liw> hm, looks like udev decide to rename my eth0 to eth1
<liw> er, no it didn't, that's my wireless, so that's ok
<liw> aha, I had 8139cp loaded, rmmod that and modprobe 8139too, and all is well (having both drivers is just silly)
<LaserJock> pjwaffle: not enough interest so far?
<alex-weej> asac: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/349663 - also the reason for the hinting choice not working?
<ubottu> Ubuntu bug 349663 in fontconfig "debconf options still present but not working" [Low,Triaged]
<asac> alex-weej: if you mean "debconf hintin choice not working", then yes.
<Chipzz> pjwaffle: because it REALLY is not as simple as "let's just set up a port. k done"
<pjwaffle> chipzz: I know but debian did it
<Chipzz> aside from a different kernel it also involves a different libc. and then incomatibilities ensue
<Chipzz> *incompatibilities
<pjwaffle> true
<Chipzz> you obviously have no idea what you're talking about :)
<pjwaffle> I know I am still an intermediate user so your right... I was just curious
<Chipzz> also, what advantage would it have?
<Chipzz> I doubt anyone would really care for ubuntu running on a freebsd kernel
<pjwaffle> people who have more experience on BSD or with minix a smaller disc
<pjwaffle> cover more users
<Chipzz> no we wouldn't
<pjwaffle> ive used bsd and there's vast differences
<Chipzz> people who have more experience with BSD would just... run BSD?
<pjwaffle> true but Ubuntu has a big repo and is easy to use
<Chipzz> it's a niche market
<Chipzz> and the very small advantage very likely would be no means justify the effort
<pjwaffle> i guess
<Chipzz> pjwaffle: for debian it may make more sense because debian has more "power-users" anyway
<Chipzz> but that's hardly the audience ubuntu is targetting
<broonie> Well, it's more about people being interested enough to volunteer as anything else.
<broonie> than, rather
<liw> sysklogd looks for a symbol matching Version_[0-9]+ in System.map, but Ubuntu (intrepid, jaunty) doesn't seem to include one; Debian (lenny) does; anyone know what's up?
<LordKow> ugh great, i take it removed symbols from a dependency upgrade is quite likely to break reverse depends. vlc 1.0 in jaunty might become impossible unless some changes get reversed
<LordKow> and im not about to have my ppa bloated with all of these reverse-depends being rebuilt against a new dep
<calc> LordKow: removing symbols from a library without bumping its soname is a critical bug i think
<calc> LordKow: what library removed symbols without bumping soname?
<LordKow> calc, the schroedinger lib has all kinds of symbol issues going on. however, i dont think this applies to the jaunty repos. im trying to bump schroedinger to 1.0.6 (currently at 1.0.5). i'll pastebin the portion of the symbols diff i have right now... i forgot to log the pbuilder output
<calc> oh i was just wondering if it affected other packages
<LordKow> calc, what im doing will most definitely but http://pastebin.com/m4615e8aa still seems weird
<calc> LordKow: if it just affects vlc then someone needs to remind them that library sonames exist for a reason
<LordKow> i've done lib upgrades before that remove and add symbols but the #MISSING concerns me
<LordKow> that occurs when rebuilding the current jaunty schroedinger lib (based on 1.0.5) using the 1.0.6 source
 * calc doesn't know what missing means as opposed to removed
<LordKow> exactly, neither do i.
<LordKow> oh well, maybe it's the same as - without a +... just emphasizing the fact that the symbol is no longer there.
<LordKow> obviously, any deps that utilize that removed symbol will be broken.
<calc> yea
<LordKow> i guess i'll go back to the vlc source and see if they had a particular reason for bumping the min version of schroedinger to 1.0.6. if they didn't i'll simply reverse it.
<LordKow> anyways, i think reversing those changes is the only viable option right now to keep vlc 1.0 snapshots usable in jaunty. unless i disable building vlc against the schroedinger lib. dont think i want to do the latter though.
<kees> asac: can you take a look my patch for bug 352779?  this duplicates for n-m the logic in dhcp3's dhclient scripts for MTU handling.
<ubottu> Launchpad bug 352779 in dhcp3 "Bad MTU for eth0 in 9.04 amd64" [High,In progress] https://launchpad.net/bugs/352779
<asac> kees: where did you get that magic barrier from?
<asac> e.g. 576
<kees> asac: it was long-long discussed for the dhcp3 changes
<kees> asac: basically, 64 is never right, and 576 is only done on locally configured PPP connections where the user wants lower latency over potentially broken networking
<kees> asac: ultimately, 576 and lower is never right when sent over DHCP
<kees> asac: the addition of "interface-mtu" to /etc/dhcp3/dhclient.conf (which n-m uses) introduces this issue
<kees> asac: many weird edge network devices misbehave (sending 64 and 576) when asked for interface mtu
<kees> asac: especially true, it seems, for ComCast in the US.
<infinity> kees: Oh, eww, n-m is honoring MTU from DHCP now?
<kees> infinity: yeah, it seems that way.
 * infinity is so glad he runs his own DHCP servers most places he connects...
<kees> infinity: it's certainly the right thing to do for PPPoE and other stuff, but unfortunately, tons of devices are monsterously stupid.
<infinity> kees: I'll admit that for PPPoE, I've always just set my own MTU.
<infinity> kees: And for both PPPoE and PPPoA, I think I've had exactly one provider out of 6 or 7 that actually set a correct MTU via DHCP anyway. :/
<kees> infinity: heh
<slangasek> infinity: "oh eww, n-m is bypassing the dhclient script which handles this and many other things"
<infinity> slangasek: Heh.
<asac> kees: committed upstream. thanks!
<kees> asac: great, thanks!
<slangasek> darn; I guess that means n-m is still duplicating logic w/ dhcp3-client, and we still don't get samba integration back
<sabdfl> debian_defaults not up to date?
<sabdfl> is there a hotlist of "top issues known in the archive"?
<directhex> coo, a sabdfl
<sabdfl> one of the many ;-)
<directhex> not many have gold-plated rocket ships, though
<jdong> sabdfl: directhex is trying to rewrite the kernel in mono!
<jdong> *ducks*
<sabdfl> genius
<sabdfl> will it run on windows, finally?
<cody-somerville> I get something like that after the installation of a number of python packages - "INFO: using unknown version '/usr/bin/python3.0' (debian_defaults not up-to-date?)"
<savvas> jdong: you should direct that to linus :)
<cody-somerville> I hope that doesn't mean things will start trying to run with python 3.0
<jdong> apparently, someone did a CoLinux port of Ubuntu.
<sabdfl> cody-somerville: yes, i just saw that here too
<jdong> it'd be better if they published the sources but meh, GPL details ;-)
<directhex> jdong, why else do you think i'm being shipped to UDS? gotta discuss the port with the kernel people!
<savvas> cody-somerville: just remove python3.0 :P
<jdong> directhex: thanks on monodevelop awesomeness btw, is this the first time we've released with an up to date MD stack? :)
<directhex> jdong, it's not 100% up to date - monodevelop-vala and monodevelop-debugger-* need updating. but they're on git.debian.org and git hates my guts
<directhex> jdong, thing is, until 2.0 appeared, 1.0 was the most recent stable release. and releasing svn snapshots is a bit :/
<mvo> sabdfl: the message is harmless (but anonying) - i will talk to doko what we can do about it
<jdong> directhex: indeed
<sabdfl> thanks mvo
<slangasek> mvo: how can I diagnose why update-manager doesn't want to remove packages to allow ekiga to upgrade?
<hyperair> directhex: git loves you if you read the manpage ;)
<slangasek> (apt-get dist-upgrade is perfectly happy doing so)
<infinity> slangasek: Does apt-get give similar results?
<infinity> Jinx.
<mvo> currently, python3.0 is neither in supported nor unsupported nor old current in this debian_defaults file, this is why the message appears.
<mvo> slangasek: I uploaded a new ekiga with a transitional package that should fix it, probably waiting in binary-NEW ?
<slangasek> mvo: oh, let me check :)
<directhex> hyperair, manpages plural. every git command has its own, and those commands have intentionally unhelpful names, to ensure you don't know which manpage to read
<slangasek> mvo: still, my question was "how can I diagnose" :)
<mvo> slangasek: hm, but I had the held-back thing for apt-get dist-upgrade too
<hyperair> directhex: righ right
<hyperair> directhex: tab completion ftw
<slangasek> mvo: I see ptlib in NEW, is that what you mean?
<mvo> slangasek: yes
<directhex> hyperair, and, of course, doing a simple thing requires multiple commands and multiple manpages
<hyperair> directhex: well ask hanska, he's our git dictionary
<slangasek> libpt2.4.2 as a transitional package?  that concerns me a bit...
<hyperair> directhex: depends on how complex you're donig
<mvo> slangasek: apt-get dist-upgrade should come to the same results, that is the easiest diagnose
<infinity> Just a bit...
<hyperair> doing*
<directhex> hyperair, he's generally only online at weekends during term time. and i don't know where in italy he is - hopefully he hasn't had a house fall on him
<slangasek> mvo: oh, you're right, it does hold it back, hmm
<mvo> slangasek: it affects only users running the devel release, we could skip the package or I can try to come up with something else
<slangasek> mvo: ok, how about 'gnome-keyring', which is the other package I have being held back by update-manager but that apt-get dist-upgrade *will* upgrade?
<hyperair> directhex: well then you can ask me =D
<infinity> mvo: That's a pretty ugly-looking transitional package...
<hyperair> directhex: i'm... less of a dictionary, but i've picked up a fair few things from #git
<mvo> it is :/
<savvas> go on now, git! :p
<directhex> hyperair, Laney accidentally imported a bz2 as orig for monodevelop-vala. is this an issue?
<mvo> slangasek: give me a minute, I need to check the source (for the held-back)
<infinity> mvo: Why is it required, exactly?
<mvo> slangasek: if the transtional package is too ugly, feel free to reject and we must think of something else
<hyperair> directhex: no it isn't.
<hyperair> directhex: just make sure to import the gz
<slangasek> mvo: well, it is technically incorrect since this transitional package won't provide any of the functionality of libpt2.4.2
<hyperair> directhex: if it bothers you much, you can switch to the pristine-tar branch and remove the bz2 files
<slangasek> and there wasn't even a libpt2.4.2 binary package prior to jaunty, so I wouldn't want to ship with it
<mvo> infinity: apts scoring algorithm is confused and thinks its better to keep the libpt2.4.2 and hold back ekiga than to go for the new libpt2.6.1 - the root of the problem is that it does not properly consider conflicts/replaces when it calcualtes that score. something I'ma bit hesitant to fix at this point
<infinity> mvo: Ahh, so it's pretty much that nr_removed == nr_added, and it balks at that?
<mvo> infinity: yes
<infinity> mvo: So, artificially lowering the removed count by one (with the transitional package) "fixes" it?
<infinity> mvo: Ew? :)
<slangasek> mvo: was the new ekiga in before beta?
<savvas> anyone taking care of packagekit?
<slangasek> seems not, binaries were all published Mar 27 or later :(
<infinity> slangasek: Short of fixing apt, I'm not seeing a way around this.  You?
<directhex> hyperair, i just want monodevelop-vala and monodevelop-debugger-* 2.0 in the archive before jaunty releases. and a beer. i don't really care about the fine detail
<infinity> slangasek: (I'm still with you on the "ew", though)
<slangasek> mvo: ah, gnome-keyring is held back only because of gnome-keyring-dbgsym installed here, so please ignore that one
<mvo> we could add some magic to update-manager to kick it, but it would leave the apt-get users out
<mvo> slangasek: aha, ok. I think I should still add a --debug option or something to it, just in case
<hyperair> directhex: what are the outstanding issues?
<slangasek> infinity, mvo: could the horrible names of the libpt plugins packages be fixed instead?
<mvo> slangasek: I can look for alternative solutions tomorrow, today I'm not in shape anymore :)
<slangasek> ok :)
<slangasek> I'll meditate on this one a bit yet today
<slangasek> but I've always thought those plugin package names were gratuitously ugly, so maybe we can make the ugliness cancel out
<infinity> slangasek: While making them unversioned (but with versioned depends) might fix future upgrade issues, I don't see how it would help the current issue. :/
<mvo> sure, if you fix it while I'm asleep I send you a virtual cup of finest japanese tea
<slangasek> infinity: because if we agree the versioned package names are gratuitous, it's not harmful to provide the old package names as transitional packages
<directhex> hyperair, monodevelop-debugger-gdb: simply needs a new orig, and pushing to the archive
<infinity> slangasek: Oh, lollerskates, thus satisfying the need to have "extra packages", but doing it with the plugins instead of the library?
<slangasek> yep
<infinity> slangasek: Still vile, but agreed that it's slightly less so.
<ikus060> Hi, is there any channel for linux developper. I need to do some modification the kernel to have a better support of my keyboard
<ikus060> Any suggestion where I should go for help ?
<directhex> hyperair, monodevelop-debugger-mdb: simply needs a new orig, and pushing to the archive
<james_w> savvas: I keep an eye on them, what's up?
<directhex> hyperair, monodevelop-vala: upstream was updated to 2.0 using a bz2 orig - in theory ready to go, as long as we can get a gzip orig from pristine-tar somehow (e.g. revert & re-do using gzipped orig)
<directhex> hyperair, those are the outstanding issues. no actual work - simply requires "proper" updating rather than me attaching orig/diff to an ubuntu bug & ignoring debian
<hyperair> directhex: pristine-tar commit /path/to/orig.tar.gz
<hyperair> directhex: make sure you name your .orig.tar.gz correctly
<savvas> james_w: sorry for the delay, my mouse broke :) could someone take a look at bug 347327 ? packagekit can't handle unicode folder (and perhaps file?) names when a user tries to install .deb files
<ubottu> Launchpad bug 347327 in packagekit "crashes when installing packages from non ascii folders" [Medium,Confirmed] https://launchpad.net/bugs/347327
<james_w> savvas: yeah, I saw it
<directhex> hyperair, okay, and next?
<hyperair> directhex: that should be it. try git buildpackage
<savvas> james_w: it's really not that super-important, but Desktops are allowed to be localized with unicode, would be nice to get it fixed :)
<james_w> savvas: sure, would be nice
<hyperair> directhex: if you've import-orig'd before, it won't import again because there are no changes, so basically you have to pristine-tar commit it manually.
<james_w> savvas: it's not on my list to try and fix for jaunty. I would happily sponsor a fix though
<savvas> james_w: ok, I'll check it out during the weekend, maybe I still have some luck left after python transition :)
<james_w> heh :-)
<directhex> hyperair, and the cure for "fatal: The remote end hung up unexpectedly"?
<hyperair> directhex: the cure is to fix the server.
<hyperair> there should be another message before that
<directhex> o_o
<directhex> directhex@desire:~/Projects/pkg-mono-git/monodevelop-vala$ git push
<directhex> fatal: The remote end hung up unexpectedly
<hyperair> directhex: git remote
<directhex> directhex@desire:~/Projects/pkg-mono-git/monodevelop-vala$ git remote
<directhex> origin
<hyperair> git config remote.origin.url
<hyperair> are you sure it's right?
<hyperair> directhex: ^
<savvas> is there a way to see the type of character codec for python text strings? to show if it's ascii or utf-8?
<directhex> git://git.debian.org/pkg-cli-apps/packages/monodevelop-vala.git
<hyperair> directhex: i don't think you can push to that.
<hyperair> directhex: you need to push through ssh.
<directhex> sigh. GIT IS CONVENIENT AND EASY!
 * directhex mails cake to Keybuk 
<hyperair> directhex: yeah it is, if you know how to use it.
<hyperair> no wait, noone said it's easy.
<hyperair> it's got a hell of a learning curve
<hyperair> kinda like gnu screen and vim
<hyperair> they're awesome stuff but you need to figure them out first
<iulian> You need to write good configs.
<savvas> ..and until you do, some other guy is using gedit and happily creates 100 lines of working, tested code :P
<hyperair> directhex: if you checked out using svn:// you wouldn't be able to commit would you?
<hyperair> lol
<hyperair> savvas: you never know when you have to edit some config files on some random remote server =)
<directhex> hyperair, and because you use debian on them, you have nano!
<savvas> ah that
<cody-somerville> I love gedit :)
<iulian> vim ftw.
<hyperair> i love geany.
<savvas> hyperair: I think I can still open it with gedit using gnome's backend for sftp/ftp :)
<directhex> ed. the one true editor
<hyperair> directhex: sed.
<hyperair> better yet, cat.
<hyperair> cat is the ultimate editor.
<hyperair> savvas: that's assuming the remote ssh server supports sftp
<hyperair> savvas: my router doesn't have sftp though it has ssh
<directhex> butterflies!
<hyperair> wut
<savvas> scp then :p
<savvas> or I'll eventually stop giving ideas and use pico lol
<hyperair> hahah
<hyperair> there isn't a nano on my router ;)
<savvas> you and your router
<hyperair> yes, me and my router =p
<savvas> you know where you can put it - on the shelf for "lost and never meant to be found" :P
<hyperair> physically never be found ;)
<hyperair> i'll leave it connected
<hyperair> my internet connection is on the line here!
 * savvas inverts the hacker symbol and cracks the router with vim.. and a hammer
<hyperair> read-only filesystem.
<hyperair> =D
<hyperair> vim can't damage a router
<savvas> hammers are always handy!
<hyperair> not if you can't find it physically
<savvas> what's your address again? :p
<hyperair> my ip address? whois me and find out =p
<ion_> hyperair: Who stole your reverse?
<hyperair> ion_: reverse?
<ion_> The hostname an IP address maps to
<hyperair> ask the network admins in my uni =p
<seb128> does anybody knows how to easily recreate a stock grub menu.list configuration?
<mkrufky> make distclean
<mkrufky> make menuconfig
<seb128> no, the grub menu that you get after installation
<seb128> ie make it look at the available linux image and list those and other installs which are detected on other disks too
<mkrufky> im sorry, you said GRUB menu
<mkrufky> my bad
<mkrufky> lol
<hyperair> lol
<hyperair> update-grub.
<mkrufky> its my fault -- i thought this was #linuxtv ....
 * mkrufky hides
<hyperair> seb128: ^
<seb128> upgrade-grub will keep your local changes
<hyperair> seb128: delete it first
<seb128> I want to wipe it for a clean version
<seb128> ok, easy enough
<hyperair> mmhmm
<hyperair> then update-grub gives you a stock one
<seb128> it seems to not list other installs
<seb128> only linux images on the current distro
<seb128> I've an intrepid install on an another disk and it's not there from a quick glance
<hyperair> you have to share the /boot i think.
<seb128> there is no way to do whatever the installer do?
<hyperair> no wait that is a bad idea
<hyperair> hmm
<hyperair> i'd just add an entry manually.
<hyperair> like chainloader +1 kinda thing
<slangasek> seb128: detecting foreign OSes is done via udebs in the installer, so no, no easy way to reproduce that from an installed system; OTOH, there are various bugs that result from trying to incorporate those boot entries directly, instead of just chainloading as hyperair mentions
<seb128> slangasek: ok thanks
<RAOF> seb128: And grub2 uses the output of os-prober to automatically generate those items, but that's obviously not terribly useful if you're not using grub2.
<Keybuk> directhex: cake is bad
<directhex> Keybuk, even if it's delicious & moist & not git?
<Keybuk> especially then
 * Keybuk does not want to become a tubbers
<cody-somerville> I'll eat the cake.
<ion_> The cake is a lie.
<cody-somerville> I was afraid of that.
<slangasek> mmm, lye cake
<slangasek> infinity: or, we could just remove libpt2.6.1's Conflicts: on libpt2.4.2, which is incorrect
<infinity> slangasek: Oh, they have no file conflicts?
<slangasek> nope
<infinity> slangasek: In that case, the old lib just ends up orphaned, autocleaned, and problem solved...
<slangasek> yep
<infinity> slangasek: Why was mvo trying to force the removal, I wonder?
<slangasek> it wasn't his idea :)
<slangasek> he was just trying to clean up the update-manager problem
<infinity> slangasek: Oh, inherited from upstream maintainer?
<slangasek> no, inherited from the person who packaged the new upstream version of ptlib
<slangasek>         cp debian/in/$(PACKAGE)-00list debian/patches/00list
 * slangasek swears at the octave3.0 maintainer
<slangasek> as if using dpatch wasn't annoying enough to begin with
<slangasek> let's just clobber the changes on every rebuild, hurray
<LordKow> so how easy/not easy is it to fork a lib and allow it to co-exist with the one in the jaunty repos? I remember a ppa doing it with the kde libs for amarok2 in intrepid. the key would be making sure the rev deps that should use the one in the jaunty repos continue to do so while only a specific package utilizes the forked-libs
<larsivi> I get version conflicts for OOo in jaunty - is that something that is well known and scheduled for fixing?
<seb128> is xvfb-run known to be broken?
<seb128> $ xvfb-run ls
<seb128> [: 182: Illegal number:
<seb128> xvfb-run: error: display :99 already in use
<Laney> At the risk of being rude, can someone look at bug 356612? It fixes a regression in automake and blocks an upload I need to make
<ubottu> Launchpad bug 356612 in automake1.10 "Regression vs 1.10.1: depfiles problem causes some source packages to ftbfs now" [Undecided,Confirmed] https://launchpad.net/bugs/356612
<hyperair> why risk of being rude?
<Laney> prodding sponsors
<seb128> Laney: I would but I've no enough clue about automake to review that
<Laney> well it's just a backport from upstream but yeah, fair enough
<seb128> try to get Keybuk or slangasek to look at it
<Laney> that should have hilighted them ;)
 * Keybuk is a conference this week
<Keybuk> AT a conference
<ion_> ATH0 a conference
<slangasek> calc: any more interesting bugs on OOo?
<calc> slangasek: not yet, it looks like OOo might be safe to upload RSN :)
<slangasek> how soon is that?
<calc> and no response from the catalan people about their buggy file
<calc> either later tonight or tomorrow morning (is that ok?)
<slangasek> yeah, that works
<calc> ok
<seb128> slangasek: does "xvfb-run ls" works for you?
<seb128> Keybuk: if you can write on IRC you can probably have a quick look to a sponsoring request and ack an upstream backport too ;-)
<slangasek> calc: did you see that sparc failed with a different compiler error this time?
<slangasek> calc: might be advantageous to get OOo uploaded right now, if we're having a carnival of build failures
<slangasek> otherwise, you should plan to just drop sparc completely in the next upload so that it's not hanging over our heads
<slangasek> seb128: don't have it installed; I can have a look
<calc> yea seems sparc fails differently each time but works fine for debian :-\
<seb128> slangasek: would be nice, I want somebody to confirm if it's broken or if I've a local issue
<slangasek> calc: well we clearly don't have an identical source package and we know we don't have the same default compiler options on the buildd; so the fact that it works fine for Debian doesn't mean there aren't OOo bugs here...
<slangasek> seb128: confirmed the failure here
<Keybuk> seb128: no, because that involves getting to launchpad
<Keybuk> which has so far timed out three times in a row for me ;)
<seb128> slangasek: I've opened bug #357338 if you want to milestone it
<ubottu> Launchpad bug 357338 in xorg-server "xvfb-run broken in jaunty using dash" [High,New] https://launchpad.net/bugs/357338
<seb128> slangasek: it breaks builds using xvfb-run
<seb128> or rather target it for jaunty
 * slangasek nods
<seb128> thanks
<Ampelbein> hi there! could someone look at bug 352653 . It's a minor packaging issue and I wonder if the information provided is enough for a FreezeException?
<ubottu> Launchpad bug 352653 in coherence "python-coherence: /usr/share/dbus-1/services/org.Coherence.service should be included" [Low,Triaged] https://launchpad.net/bugs/352653
<calc> ugh i'm still getting new bugs on gutsy
 * calc told the users to just test out jaunty and upgrade if it works, heh
<ScottK> Ampelbein: There was a new coherence upload in Debian today.  Did that (by chance) fix this bug?
<Ampelbein> ScottK: I'll check that, thanks for the pointer.
<ScottK> No problem.
<directhex> calc, tell them to try karmic!
<slangasek> ArneGoetje: there are a number of new gnome-user-guide-$ll packages added in the latest upload; could those get added to the dependencies of language-pack-gnome-*?
<Ampelbein> ScottK: no, this did not get fixed. the services-file is still not provided. should i file a bug in debian, too and link it?
<seb128> the debian maintainers know about that
<seb128> I mailed him a week ago and he replied that somebody else was looking at the issue
<seb128> I will try pinging him again, you don't need a freeze exception for bug fixes yet though, just subscribe sponsors
<Ampelbein> ok, done that already. thanks.
<slangasek> "Grep'ing the whole file is not good either: AIX grep has a line limit of 2048"
<slangasek> >_<
<ion_> The following people find AIX grep relevant:
<sladen> cjwatson: what's the status of debs with a .tar.lzma ?  Are they allowed in the archive/soyuz (lintian is complaining)
<seb128> slangasek: ok, your new comment is sort of what I suggested in the bug description ;-)
<slangasek> seb128: yeah. :)
<seb128> slangasek: that's not the only issue though, I've changed it to use bash just to try and it still breaks on "display already used"
<seb128> when called several times
<slangasek> doh
<seb128> I would suggest just dropping the change from the previous upload for jaunty
<slangasek> that's fair
<slangasek> Laney: automake sponsored
<Laney> slangasek: woo! Thanks a bunch
<seb128> I will wait for bryce to comment on the bug though maybe he can fix it easily
<bryce> seb128: already dropped
<seb128> bryce: thanks
<bryce> seb128: I don't care enough about xvfb to try fixing it
<seb128> bryce: I don't care either as long as I can still build pygtk ;-)
<bryce> besides I'd probably just break it some other way in the process (it's not my patch originally, just sponsored from a contributor) ;-)
<seb128> right, let's go back to a known situation for jaunty
#ubuntu-devel 2009-04-08
<cjwatson> sladen: they are not allowed. use .tar.gz
<sladen> cjwatson: this is for the .deb, not the .orig  Using dh_builddeb -- -Z lzma  is saving ~50%
<sladen> cjwatson: or is it just  gz and bzip2  allowed for .debs in the archive
<RAOF> sladen: I'm pretty sure mesa is already lzma compressed, which would suggest that it's OK.  Check it out?
<cjwatson> sladen: oh, well then those have been allowed for ages with a suitable Pre-Depends
<cjwatson> namely dpkg (>= 1.14.12ubuntu3)
<calc> cjwatson: pre-depends not needed anymore as of lp 2.2.3
<cjwatson> ok
<calc> sladen: you should be able to just upload lzma compressed debs without doing anything else special now
<calc> sladen: up until ~ april 1 you had to have a pre-depends
<hyperair> lzma compressed debs? as in data.tar.gz replaced with data.tar.lzma or something?
<cjwatson> yes.
<cjwatson> it makes sense for some particularly large packages
<calc> hyperair: its been supported since gutsy (iirc)
<hyperair> i see.
<hyperair> so how come it never really took off?
<calc> or maybe it was hardy, i can't recall
<calc> hyperair: big things use it already such as OOo
<hyperair> i see
<sladen> cjwatson: ta.  (And I'm a great fan of Pre-Dpedns for funky compression methods, so I'll add it ;-)
<hyperair> but how do you trigger it building as lzma instead of gz?
<calc> i was discussing with Keybuk about potentially making it the default for dpkg for karmic, but not sure that it is that helpful without also having lzma for squashfs
<cjwatson> dh_builddeb -- -Zlzma
<cjwatson> calc: I don't think that's suitable
<hyperair> aah
<cjwatson> I would advise against such a change
<calc> cjwatson: too slow for desktop cd or something else?
<calc> aiui novell already does it by default for rpm (not saying that it is a reason to do it though)
<cjwatson> I'm very concerned about the behaviour on low-memory systems
<cjwatson> and am strongly inclined to veto this
<calc> ok
<calc> how low do we support as far as low-mem is concerned?
<cjwatson> for installation, at least down as far as 64MB; lower is manageable but it gets slow due to localedef
<calc> iirc it uses ~ 30MB to decompress, so it is valid if we support very low-mem situations i suppose
<calc> wow i didn't realize we supported that low
<cjwatson> obviously you can't run a standard Ubuntu desktop on that (hence why I'm not worried about OOo using data.tar.lzma) but there are other valid use cases using the Ubuntu archive that aren't a full desktop
<calc> yea
<cjwatson> I'm pretty sure I raised the same concern a while back
<cjwatson> I do think lzma has been great for getting us some much-needed space on the alternate CD in particular targeted areas, and I'm very grateful for that
<calc> i think in the past when i had talked to you it was more an issue of low-mem ~ 256MB machines installing via the desktop cd, or something to that effect
<cjwatson> but I think we should leave it at that rather than pushing it too far
<calc> yea thats fine
<cjwatson> memory is an issue on desktop CD installs too, certainly
<cjwatson> we've found it difficult to hold it to 256MB
<calc> luckily we have the install without booting into desktop option as well
<calc> which i imagine takes a lot less than 256MB
<cjwatson> the desktop CD is a situation where noticeably more memory can be used during installation than is required for the installed system, which I regard as a fairly major problem
<cjwatson> it's not that much less, unfortunately
<cjwatson> I think it's still clear, but not comfortably so
<calc> cjwatson: someone had requested an option for a gui netinst, would that lower the requirements without having to fall all the way back to ncurses?
<cjwatson> yes, to some extent
<calc> cjwatson: from what i can see debian has that and it only takes ~ 15MB for a netinst cd with gui
<cjwatson> we will be doing that once a current version of GTK gets fixed to be able to support the directfb backend again
<cjwatson> (Debian unstable has run into the exact same problem; it isn't just us)
<TheMuso> /c/c
<calc> of course it takes more than that in ram to run it, but probably less than the current desktop cd direct install method
<calc> cjwatson: ah i see :)
<cjwatson> it's not a replacement for ubiquity; it's (largely) a straight translation of the current d-i dialogs into GTK
<infinity> cjwatson: Another ubuntu-autotest run is in progress, BTW (just kicked off), if you want to watch the list.
<cjwatson> which is serviceable, but it isn't a by-hand designed interface. I expect we'll need to put quite a bit of work into some areas
<infinity> cjwatson: Seeing as how the attempt to do the same with soyuz seemed to go unpleasantly.
<cjwatson> calc: (I was one of the developers who put a lot of time into the GTK installer in Debian, so I'm reasonably familiar with it ;-) )
<calc> cjwatson: isn't the alternate cd d-i also?
<cjwatson> though I didn't do the final stretch, just a good deal of the early underpinnings - there was a time when I was about the only person working on it
<cjwatson> calc: yes
<cjwatson> infinity: ok
<calc> cjwatson: so its different than the current desktop installer but a nicer looking version of what we currently use in the alternate cd
<cjwatson> calc: it's just dropping in a different debconf frontend, basically
<calc> hmm we'd have to put that on the alternate cd as a gui installer then, since the desktop cd isn't done in a manner that d-i knows how to install from, aiui?
<cjwatson> that's correct. More realistically, the server CD
<calc> ok
<cjwatson> (since the server CD has quite a bit of spare space but the alternate is usually kind of tight)
<calc> ok
<calc> or just lzma a package or two and then we have space on the alternate cd again ;-)
<cjwatson> also, the corporate services guys are actually pushing for this
 * calc has to run buy groceries but will be back ~ 1hr
<TheMuso> Some of the other UbuntuStudio devs have also expressed an interest in using the GTK d-i for the studio disks.
<cjwatson> right
<cjwatson> I did try to do it for jaunty but the aforementioned GTK problems shot it down
<TheMuso> Yep
<TheMuso> A11y wise, I don't care about GTK d-i, since the Ubuntu desktop CD's installer is accessible enough to be usable now.
<ikus060> I made a modification in the kernel source code. Now I wan to test this modification but before I need to compile the kernel
<ikus060> Can someone refer me so some documentation ?
<sladen> cjwatson: I'm a believer in sticking to .gz for base packages.   But what's your view on alternate compressors ("advancecomp" et al) that can get another 15% out of the deflate stream by trying harder
<ikus060> In fact, I thikn I only need to compile one part of the kernel : hid
<cjwatson> sladen: IME we are at the point where other strategies for saving space, such as working on more efficient representations and shipping of translated documentation, represent much better bang for our buck
<infinity> cjwatson: I say we just remove libx11 and anything that depends on it, and see how that works out.
<bryce> infinity: wow, that could save me a lot of work
<infinity> bryce: See?  I'm a giver.
<cjwatson> kees: do you know what happened to the sudo patch I'm sure we used to have that passed through all environment variables if sudoers says you can run whatever command you like?
<cjwatson> kees: are we supposed to just use sudo -E now? (This comes up because libgksu never passes sudo -E.)
<kb9vqf> I'm working on remastering a LiveCD, and I have a CD that works with i386 but when I generate the amd64 version it fails right as the graphical boot menu is displayed.  Any ideas why this happens?
<kb9vqf> Or who might know? ;-)
<ArneGoetje> slangasek: hmm.. I thought pitti fixed that already... will check.
<slangasek> ArneGoetje: ah; the new ones still show up in component-mismatches
<javito> hi
<javito> i am reading in debian-policy website that the latest version is 3.8.1.0.... but what should i use in my debian/control file  3.8.1.0  or 3.8.1 ??
<cjwatson> javito: you should read the part of the policy manual that covers the Standards-Version field
<cjwatson> javito: section 5.6.11
<javito> cjwatson: thanks
<javito> is very clear here
<tedg> Heh, the Debian Policy manual is so complete that the answer to the question "I'm reading the manual and don't understand, what do I do?" is "Read the manual" :)
<cjwatson> it's comprehensive enough that it's understandable for people to get lost until they've made enough use of it to have a general feel for where to find things
<calc> iirc one of the first things you are supposed to do before applying as a DD is to read the entire policy manual :)
<calc> and be able to recite the dfsg backwards ;-)
 * tedg tried to be in AA but couldn't remember all 12 steps ;)
<jmillikin> If "Sebastien Bacher" is present: Can you take a quick peek at <https://bugs.launchpad.net/nautilus/+bug/357438>? It's a small bug with a simple fix, but would be great to get into one of the -ubuntuX patchsets for Nautilus before Jaunty final. Apologies in advance for the drive-by patch/question, but my connection time is limited.
<ubottu> Ubuntu bug 357438 in nautilus "Always show "backup" directories." [Undecided,New]
<jmillikin> If you see this, thanks!
<jdong> quick drive-by :)
<javito> when will be allow upload bugfix to karmic?
<sladen> well, you can upload bugfixes to jaunty
<javito> including minor bugs?
<sladen> but new versions, and new packages, and new features need to wait until karmic opens (~6 weeks)
<sladen> javito: if it helps the quality of the release, yes
<javito> but a bugfix impleis increase the version
<sladen> javito: increasing the -0ubuntuX package version, yes
<javito> ok then thanks
<sladen> javito: to get a new upstream release in, it has to be a bugfix only release
<javito> sorry for my stupid questions i'm really newbie here :D
<sladen> javito: yeah, if nobody was allowed to fix bugs and nobody allowed to upload, we might as well have released a month ago... :)
<javito> sladen: maybe only for critical bugs, like in stable debian
<javito> since frozen
<javito> it just why i asked
<sladen> javito: post-release, you need a stable-release-update exception (eg. a security issue)
<kees> cjwatson: I think pitti removed most of it, but kept a whitelist for things like http_proxy, but beyond that I don't remember.
<kees> cjwatson: though, recently, I was pretty sure that environment was passed unfiltered if one was in sudoers with an "ALL".
<Hobbsee> hrm.  How does one not use these new notifications for just pidgin...
<sladen> Hobbsee: irssi :)
<Hobbsee> i do like it for things that are actual "doesn't matter if you miss them" notifications, but for pidgin, it means that i miss the notifications, and there's absolutely *no* indication that someone's sent me a reply to a message.  And i'm not convinced that the notifications actually fire every time, at all.  Fail.
<Hobbsee> sladen: i guess I could use bitlbee and konversation, yes.
<Hobbsee> sladen: irssi, if i use the notifier, is goign to have exactly the same problem, on a bigger scale?
<TheMuso> Hobbsee: there was discussion about irssi and notifications here yesterday, I can't remember the result of that conversation however.
<sladen> Hobbsee: somebody (look for the logs) was discussing something similar earlier.   Ah, TheMuso has beaten me to it
<sladen> s/look/lookings/
<Hobbsee> TheMuso: i get the feeling that the more i send thru the notifier, the more messages i'll only see hours later when i happen to manually open up the window again, though
<TheMuso> Hobbsee: I don't know how the notification works, since I don't use it.
<Hobbsee> TheMuso: ah
<Hobbsee> sladen: i'll do that, but i suspect that'd make my problem worse again
<sladen> Hobbsee: IIRC, libnotify is "replaced" by the new back end so everything is gets diverted to /dev/null (well, a 3 second pop-up, then /dev/null)
<Hobbsee> sladen: damn.  that's *exactly* what i'm trying to avoid.
<Hobbsee> sladen: and i'm really not convinced that the popups work all the time, either
<sladen> Hobbsee: probably what will happen is that the pidgin authors will get pissed off, and switch to their own internal notification system, skipping the "standard" as it doesn't do what they want
<Hobbsee> sladen: heh. That sounds about right.
<Hobbsee> hrm, I guess i could switch to kopete or something
<Hobbsee> which should bypass the new notifier stuff
<sladen> you can do other mad setups, like irssi-proxy  (irssi, but it also listens on a port and passes everything through so that you can daisy chain to another IRC client)
<Hobbsee> that's true.  I'm already doing funky things with proxies.
<Hobbsee> but that's not a bad idea
<sladen> if daisy chaining worked /really well/ you could have a IRC "client" that did nothing but display flashing notifications
<sladen> I don't really have a solution (as it's not a use-case I've hit and had to work around yet)
<Hobbsee> the irc isn't really the problem - konversation doesn't (and probably won't) use the new notifications for this release.  It's only the other protocols.
<sladen> perhaps the long term key is to modify the funky new libnotify backend, to be ware of state
<Hobbsee> mmm
<sladen> eg. is the screen-saver running, is there keyboard/mouse activity, is there a full screen movie
<sladen> what's that four-quardrant system for prioritising?    There's two axis, one is urgency and the other is importance
<sladen> so it could be less urgent than watching the full screen movie, but important enough to save until later
<Hobbsee> true
<sladen> Hobbsee: anyway, we probably know who to blame for the new design if it gets panned post-release ;-)
<Hobbsee> sladen: hmmm?
<sladen> Hobbsee: the same person who brought us nekkid desktop wallpaper!
<sladen> I suspect the new notifier will end up covering 90% of use-cases better than it did before, but leave an empty space for the other 10%
<Hobbsee> ah, right
<Hobbsee> indeed.
<Hobbsee> although I personally think "give me some obvious notification that i've received a message over msn / jabber / etc via pidgin, after the fact" would be a fairly large use case for pidgin...
<Hobbsee> Ah well.  I'm sure the notification team will decide how to do it best, and if they don't, debian will get a lot more people.
 * Hobbsee goes off to research how to make pidgin behave more sensible
<Hobbsee> er, sensibly
<jcastro> Hobbsee: the messaging-indicator is where the missed notifications get queued up
<Hobbsee> jcastro: except that it doesn't work.
<Hobbsee> jcastro: they never show up there
<jcastro> that's a bug then
<Hobbsee> sorry, the ones about the fact that someone's signed in do, but not the ones that say i've received a message.
<jcastro> only the messages are supposed to queue up in there
<jcastro> not like, when people sign in and stuff
<Hobbsee> and speaking of that, i'm not so crash hot on having to have *two* icons on my panel about it, or having to keep pidgin open, because otherwise pidgin quits.
<Hobbsee> if only it worked...When's the ETA on getting a fix?
<jcastro> there should just be one icon, the little envelope for the messaging indicator
<jcastro> dunno, mine works, maybe ask in #dx?
<Hobbsee> hmmm.  might have to ask later when they're awake
<sladen> jcastro: so unread IM/email messages are hiding until the envelope, until you click it, and then they /are/ being shown?
<jcastro> right
<Hobbsee> sladen: that would make sense.
<jcastro> when there are new ones in there there's a green dot on the envelope
<jcastro> so basically, instead of a pidgin icon, a new evo mail icon, etc. you just have them all under one icon
<jcastro> which also btw brings the contact list up for pidgin
<Amaranth> I thought empathy got ported as well
<jcastro> right
<Amaranth> I never thought notifications would be the reason Ubuntu started maintaining a large number of deltas from upstream
<jcastro> alot are accepting them
<jcastro> though I don't have statistics on that
<Amaranth> Sure, if it's just "cleanup your usage to check for features" and stuff like that
<Amaranth> or "use append mode"
<sladen> yeah, it missed the first /msg  but saw the second and third
<sladen> and gives me an exploding envelope
<sladen> well, that'd be pidgin crashing
<sladen> Hmm, the option is called "Shutdown..." but the action is immediate (so should not have the ...)
<calc> is there a reason that arrow keys don't work in insert mode in vim, i seem to recall this used to work at some point
<calc> but not i just inserts a new line with eg "B:
<calc> er "B"
<Hobbsee> jcastro: hrm.  It appears that my existing config was making it not behave properly.  Has the dx team tested with previous release configs, instead of clean slates?
<jcastro> Hobbsee: not sure, that is a good point though
<Hobbsee> ah, but the minimise to tray functionality isn't there.  dammit.
<Hobbsee> or the minimise to anything, really
<Hobbsee> jcastro: did you find a way around that?
<Hobbsee> at least i get the right things in the envelope now!
<spm> calc: wfm. my fading memory suggests that tends to be caused by a zotted or simply wrong TERM - eg should be xtermc, is set to sun-console :-/ I think terminals can also get into a gaga state as well, and need resetting.
<Hobbsee> ah, that would be https://bugs.edge.launchpad.net/ubuntu/+source/pidgin/+bug/295713
<ubottu> Ubuntu bug 295713 in pidgin "pidgin ends (instead of minimizing) when closing buddy list" [Undecided,Incomplete]
<Hobbsee> hrm.  can one assign things to the dx team, i wonder....
<Hobbsee> sladen: out of curiousity, which gnome theme are you using?
<calc> spm: hmm gnome-terminal sets it to xterm, if i change it to linux it seems to work
<calc> actually no i just tested in the wrong spot
<calc> it seems the place it is happening is set to TERM="screen"
<calc> for screen console program
<infinity> calc: Under screen, it's "TERM=screen" for you?
<infinity> calc: I get "TERM=screen.linux"...
<calc> infinity: yea
<calc> infinity: shows up as just TERM=screen for me
<TomJaeger> Any chance someone can commit the .debdiff attached to bug #311732?
<ubottu> Launchpad bug 311732 in linux "2.6.28-4 breaks thinkfinger" [Undecided,Fix released] https://launchpad.net/bugs/311732
<TomJaeger> Thinkfinger is completely broken atm
<sladen> Hobbsee: *boggle*.  Human, I guess.  I try and stick with the defaults (assuming the default theme hasn't changed)
<Hobbsee> sladen: hm, OK
<sladen> Hobbsee: I did have some problem recently whereby all the fonts were too big, until you went System->Settings->Appearance.  Didn't have to click anything but that was enough to fix the fonts to the correct size
 * Hobbsee nods
<ajmitch> gnome-settings-daemon not being started properly on login?
<TomJaeger> Keybuk, do you think you could have a look at the patch?
<maxb> sladen: I have noticed this immediate shutdown thing too - *intermittently* !
<htrejh> hi
<htrejh> i tried to create a deb package and it worked, but my program doesn't have any files in /bin for example and it created and packaged empty directories, how can i remove thatN
<directhex> fix your package's .install file?
<directhex> also, packages don't go into /bin they go into /usr/bin
<htrejh> .install file?
<highvoltage> dade
<htrejh> i do not have any .install file
<highvoltage> he probably meant debian/install file
<htrejh> emacsen-install?
<directhex> htrejh, in your debian/ folder in your source package, the install file (or pkgname.install for multi-package source packages) lists the actual files to include in the package
<htrejh> strange i do not have this file
<highvoltage> you have to create it
<htrejh> k
<directhex> and you have no files either. go figure
<htrejh> are there any sample files?
<directhex> which packaging helper does your package use?
<htrejh> dh_make
<htrejh> but i found, there were plenty ex files generated :)
<directhex> so plain dh.
<directhex> which compat version?
<htrejh> 7
<directhex> are you using minimal-style rules?
<htrejh> hm
<htrejh> dunno
<directhex> does your rules file contain a bunch of dh_this dh_that dh_other, or a couple of "dh $@"?
<directhex> http://svn.debian.org/viewsvn/pkg-cli-libs/packages/gtk-sharp2/trunk/debian/rules?revision=3937&view=markup is old-style full rules, http://svn.debian.org/viewsvn/pkg-cli-libs/packages/smartirc4net/trunk/debian/rules?revision=4049&view=markup is dh7 minimal rules
<htrejh> a bunch of...
<htrejh> it's the first one
<directhex> right. is dh_install called in your binary(arch|indep) rule?
<htrejh> hm no, it is commented
<directhex> dh_install is the rule that actually, well, installs files generated by the build into a deb. it uses the debian/install file as a manifest
<directhex> http://svn.debian.org/viewsvn/pkg-cli-libs/packages/smartirc4net/trunk/debian/libsmartirc4net0.4-cil.install?revision=3806&view=markup is a little example
<htrejh> euhm
<htrejh> so i must uncomment it right?
<directhex> right.
<htrejh> ok, thanks
<htrejh> but i still have the empty dirs :s
<lyhana8> hi, how could I change the mysql user ID correctly ?
<lyhana8> actually I change it manually in /etc/passwd and /etc/group and now the server refuse to start
<Hobbsee> lyhana8: #ubuntu for support please.
<lyhana8> Hobbsee: I come from there, they have no idea. Plus it's a high config issue
<lyhana8> I'm trying to share a mysql DB among a gentoo and an ubunutu. User ID change and file permissions change work fine on gentoo, but not on ubuntu
<Nafallo> lyhana8: no it isn't. and that doesn't make this channel a good forum for support. you could try #ubuntu-server or any of the local community channels please.
<Hobbsee> -server's not a support channel either for non-server stuff, actually.
<Hobbsee> lyhana8: a simple google search finds http://ubuntuforums.org/showthread.php?t=109752 which appears to be appropriate.
<Hobbsee> But please note, this really isn't the appropriate channel.
<Nafallo> Hobbsee: well, I found running mysqld as a user a bit strange ;-)
<lyhana8> Hobbsee: thanks
<Hobbsee> Nafallo: it does?
<Nafallo> Hobbsee: I meant. mysqld on a non-server. sorry :-)
<Hobbsee> oh, right
<Nafallo> Hobbsee: but yea. you're right. I was jumping to conclusions :-)
<htrejh> can someone explain why i get those empty dirs packaged?
<kb9vqf> htrejh: do you have a dirs file in your debian/ folder
<htrejh> yes, i just removed it, will try again :)
<kb9vqf> htrejh: that was most likely your problem.  I ran into this once or twice myself :)
<kb9vqf> good luck!
<htrejh> ok thanks :)
<siretart`> persia: are you still working on bug #349458?
<ubottu> Launchpad bug 349458 in ffmpeg-debian "Please provide a VFP-optimised build for ffmpeg-debian" [Medium,In progress] https://launchpad.net/bugs/349458
<mvo> Riddell: is the disappearing dbus/mainloop/qt.so still a issue with current intrepid->jaunty upgrades? I just ran anohter test upgrade and its still there, I suspect its a particular package that triggers it (and that I do not have installed)
<Nafallo> damn :-/
<Nafallo> my X just crashed after a VT switch again
<mnemo> nafallo: which chipset? any stacktrace at the end of xorg.log.old?
<Nafallo> /var/log/gdm/\:0.log.1
<Nafallo> will put it on a pastebin.
<Nafallo> once my firefox stop crashing...
<Nafallo> http://paste.ubuntu.com/146805/ <-- 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
<savvas> Nafallo: for firefox crashes, try to create a new user - this will definitely sort it if it's a local /home/ problem in the configuration :)
<Nafallo> savvas: yeah. I know. I reckon it's one of the newly updated plugins. just hard to catch.
<Nafallo> also, a new user won't have my stored passwords, so a no go.
<savvas> there's a plugin for that
<savvas> password exporter
 * Nafallo shrugs.
<Nafallo> still not the issue :-)
<savvas> :P
<Nafallo> I'm pretty sure it's a plugin considering it started happening right after I upgraded vimperator ;-)
<Ng> safe mode
<savvas> well, if you ever consider on recreating a new .mozilla directory: https://addons.mozilla.org/en-US/firefox/addon/2848
<Nafallo> anyway. my bigger issue is X ;-)
<cjwatson> mvo,seb128: does the libgksu patch I attached to bug 357101 look OK to you?
<ubottu> Launchpad bug 357101 in ubiquity "GUI does not exit on reboot after install on armel" [High,Triaged] https://launchpad.net/bugs/357101
<tjaalton> is anyone going through sync requests anymore?
<seb128> tjaalton: yes, archive admins
<tjaalton> seb128: ok, good
<kwwii> evand: it seems we need to work on the time zone map some more...two problems: 1) the pics are scaled up during a "real" install and 2) the text is black and the background too dark for that
<evand1> kwwii: by being scaled up do you mean that they're scaled to be greater than their original resolution?  If so I believe cjwatson fixed that.
<evand1> and indeed on the text.  Did you have a better color in mind?  It's quite easy to change.
<kwwii> evand1: yes, exactly...the pics show up blurry because of it
<kwwii> evand1: yeah, I'm talking to others about it and I'll get back to you
<kwwii> evand1: thanks
<evand1> kwwii: sure thing
<cjwatson> evand: I didn't do anything about that
<cjwatson> evand,kwwii: the change I made (relatively recently) was to prevent the images being unnecessarily scaled down from their original resolution when the screen is big enough to comfortably accommodate the full sizes
<cjwatson> the map is fiddly to use when scaled down; that's acceptable when we have to do it to make it fit on the screen, but IMO we should make use of bigger screen sizes when we have them
<evand> oh, my mistake.  I misread the changelog entry then.
<kwwii> cjwatson, evand: the problem I am seeing is that the pics are being scaled up larger than the original size and therefore have blurry edges
<evand> kwwii: I'll take care of that
<kwwii> cool :-)
<cjwatson> that's very odd. what size of screen?
<cjwatson> evand: is this something you can reproduce?
<kwwii> cjwatson: 1920x1440 or such
<cjwatson> the code just says "if screen big enough: use normal images; else: use half-size images
<cjwatson> "
<kwwii> cjwatson: it seems to be normal sized when I install from the live CD but when I click on install ubuntu directly it scales them up it seems
<cjwatson> aha
<cjwatson> that'll be the full-screening
<cjwatson> I bet that the map widget is set to expand
<cjwatson> or fill, or some combination of those
<evand> cjwatson:  ah actually, probably not given my low resolution, but I can roll debs for kwwii to test
<kwwii> right, that is how it looks
<evand> ah
<cjwatson> (I can never remember the difference and always have to look it up ...)
<lool> cjwatson: Could we get a debian-installer upload (I can do one if you like) today?  I'd like to test updated hd-media kernel built by d-i for https://bugs.launchpad.net/ubuntu/+bug/354226
<ubottu> Ubuntu bug 354226 in ubuntu "Jaunty lpia installer fails with hd-media kernel on dell mini 9" [Undecided,Confirmed]
<lool> if a kernel config is missing on lpia, we might still have a change to fix that one
<cjwatson> lool: ok, I can do one later; I'd like to get a bit further with diagnosing bug 341928 first though, if that's OK, since that may well require a d-i upload anyway
<ubottu> Launchpad bug 341928 in lvm2 "Consistently reproducible "device or resource busy" error on partitioning" [High,Triaged] https://launchpad.net/bugs/341928
<lool> cjwatson: That's fine; thanks
<ogra> if i do a while statement in shell like: while read moo;do echo $moo;done < $multiline_string ... is there any way to avoid using a fifo (read wants to open something, is there any replacement i can use to parse teh string directly ?)
<kwwii> evand: how much can we change the wy the text looks? ie can we add a background color or a line around the outside? Can we change the X to a dot or such?
<kwwii> s/wy/way
<evand> kwwii: it's done in cairo, so we can add a different color line around the text or a solid background quite easily
<evand> and yes, we can change the x to a dot
<kwwii> evand: cool, once I have an idea of what to change I will get back to you...thanks again
<evand> kwwii: great, thanks!
<ogra> bah, i'm dense today
<cjwatson> ogra: you mean you're trying to split up $multiline_string into lines?
<ogra> cjwatson, no, i'm trying to change one line in a multiline string while keeping the order of the lines intact ...
<cjwatson> ogra: why not just use sed then?
<ogra> but i just noticed i'm silly and use: echo "$string"|while ...
<cjwatson> foo | while read has some very odd semantics that are likely to bite you if you aren't careful
<cjwatson> the while loop turns into a subshell so any variables set in there will be lost
<javito> hi
<cjwatson> I'd recommend using sed if you can
<asac> ogra: can you join #nm for a moment?
<ogra> hmm, sed is tricky here since the lines can vary and i dont know all possibilities
<javito> what status should be assigned to a bug if you are attached the debdiff and subcribed motu for get sponsoring?  confirmed? in progress?
<ogra> asac, i'm there
<mvo> cjwatson: patch looks good
<cjwatson> hah
 * cjwatson cracks bug 341928
<ubottu> Launchpad bug 341928 in lvm2 "Consistently reproducible "device or resource busy" error on partitioning" [High,Triaged] https://launchpad.net/bugs/341928
<elmo> cjwatson: what was it?
<fader_> cjwatson: \o/
<elmo> (oh, nm, it's in the bug)
<cjwatson> elmo: lvm2 scans all devices in /dev and didn't know that it should prefer, well, just about any other name over /dev/block/
<cjwatson> I haven't actually tested the fix yet, that's in progress
<cjwatson> fader_: thanks for those instructions, very helpful
<fader_> cjwatson: No problem, glad to help :)
<fader_> cjwatson: (especially with this bug as it's been hitting me on a daily basis ;) )
<cjwatson> fader_: sorry it took a while; lvm2 and devmapper are twisty as hell and it was tricky to find the exact bit at fault
<cjwatson> I never knew devmapper included a regex library ...
<fader_> cjwatson: I can imagine... I don't envy you the task of tracing through all that
<fader_> Heh
<fader_> Now you just need to add the ability for it to read email and it will be a complete program.
<Hobbsee> fader_: it does irc already?
<fader_> Hobbsee: Heh, probably not, but I'm counting on there being an SMTP->IRC gateway out there somewhere ;)
<Hobbsee> haha :)
<StevenK> fader_: I think that can be done in about 5 lines of Perl
<fader_> If it were a week ago I'd be sorely tempted to file a bug on this.
<BUGabundo> anybody knows when pitti will be around? I have a GPM question
<seb128> BUGabundo: he's at the linux foundation summit for the week
<BUGabundo> seb128: thanks
<BUGabundo> forgot about that
<seb128> you can ask your question on the channel
<BUGabundo> anyone else in charge of GPM?
<seb128> some other people might know
<BUGabundo> gonna file a wishbug against it
<seb128> what do you call gpm exactly?
<BUGabundo> to save profiles
<BUGabundo> Gnome Power Manager
<BUGabundo> even Win95 did that
<seb128> you should open wishlist bug upstream rather
<BUGabundo> and current version of GPM doesn't
<BUGabundo> I will
<seb128> nobody is actively working on new feature in an ubuntu specific way
<BUGabundo> and track it in LP too
<BUGabundo> I know
<seb128> but I think the no profile is a choice
<BUGabundo> just wanted to know if anyone knew anyother way to manage power profiles
<seb128> it should be doing the right things, profile are sort of the wrong solution
<BUGabundo> well I wish for Home, Office, On The Road profiles
<BUGabundo> some can and should suspend, others always Onlin
<seb128> what would be the difference?
<BUGabundo> Screen bright, etc
<seb128> I'm busy with jaunty work now and don't want to start a discussion
<seb128> but that's of the wrong approch
<seb128> you want to have settings changing when docked or on battery
<BUGabundo> no not really
<seb128> it doesn't really depends of if you are sitting in a train station or an airport
<directhex> i ought to file a bug about getting ubuntu to be aware when my laptop's backlight changes brightness by itself (i.e. so it doesn't still show as 100% brightness when it's not)
<BUGabundo> seb128: I'll start a discussion devel-discu ML
<cjwatson> fader_: I'd like to fetch an updated lvm2-udeb into the running installer on berkelium, but it apparently doesn't let me fetch from either ppa.launchpad.net or people.ubuntu.com. Do you know what else I could try?
<seb128> BUGabundo: right
<BUGabundo> filing now bugs on both BTS and search for dupes
<seb128> I would be surprised if there was not a bug about that already open
<kwwii> query evand
<kwwii> oops
<evand> heh
<cjwatson> fader_: never mind, I got it working by fetching the file to nickel first
<fader_> cjwatson: You will probably need to copy it to nickel and then grab it from nickel on the target machine... they are firewalled down pretty hard
<fader_> cjwatson: Heh, one step ahead of me :)
<cjwatson> seems to DTRT, I'll upload that
<cjwatson> couldn't quite test it all the way through, but lvm2 is now using the right device names
<BUGabundo> seb128:" Query timeout of 60 seconds hit - killing the running query" that makes it hard to look for a dupe
<seb128> BUGabundo: try less hard queries
<seb128> BUGabundo: ie limit the importance to normal so you filter out all the crashers
<seb128> or set a title keyword
<BUGabundo> seb128: I limited to GPM and keyword "profile"
<seb128> weird
<BUGabundo> http://bugzilla.gnome.org/buglist.cgi?query=gnome+power+manager+profiles
<BUGabundo> and simple one timeout too
<seb128> you should select the product in the list
<azeem> maybee try gnome-power-manager
<seb128> rather than searchin in the whole bugzilla this way
<azeem> otherwise you might get all the hits with "gnome"
<BUGabundo> there's nothing tagged "future"
<BUGabundo> seb128: that was what I did! I limited to GPM
<seb128> no it's not
<seb128> the url has no product keyword
<seb128> http://bugzilla.gnome.org/query.cgi
<cjwatson> mvo: thanks for the libgksu review; uploaded
<cjwatson> lool: see my comment in bug 357101 - I think you may have missed the context of my patch
<ubottu> Launchpad bug 357101 in ubiquity "GUI does not exit on reboot after install on armel" [High,Triaged] https://launchpad.net/bugs/357101
<lool> cjwatson: Indeed, I missed gksudo had this
<lool> cjwatson: Looks absolutely fine then
<cjwatson> though I agree it should go upstream
<BUGabundo> seb128: bug 357719
<ubottu> Launchpad bug 357719 in gnome-power-manager "GPM should have user profiles" [Undecided,New] https://launchpad.net/bugs/357719
<cjwatson> you can't really talk to dbus when gksudo'd unless you preserve environment variables, anyway
<cjwatson> not the session bus anyway
<BUGabundo> linked upstream too
<seb128> BUGabundo: ok
<BUGabundo> seb128: sending now to devel discuss
<tseliot> seb128: any ideas as to why my partitions are mounted with "%" instead of "/" in their labels? http://www.albertomilone.com/ubuntu/gnome/problem.png
<tseliot> seb128: any ideas as to why my partitions are mounted with "%" instead of "/" in their labels? http://www.albertomilone.com/ubuntu/gnome/problem.png  They are reported correctly by vol_id: http://pastebin.ubuntu.com/146969/
<lool> cjwatson: Oh right, it's not the session bus anyway
<seb128> tseliot: is that new?
<lool> cjwatson: But these vars should be enough for the session bus I think
<cjwatson> lool: for ubiquity, there's no problem with just taking the lot
<tseliot> seb128: yes
<cjwatson> lool: so I don't want to get into any unnecessary complexity
<cjwatson> "preserve whole environment" is just fine for me
<tseliot> seb128: what package should I have a look at to fix it?
<BUGabundo> tseliot: never saw nothing like that
<seb128> tseliot: I would say to look at the recent upload on https://edge.launchpad.net/ubuntu/+source/gnome-mount
<lool> cjwatson: sure
<lool> cjwatson: It was in case we wanted to avoid copying the whole env
<james_w> tseliot: http://lists.freedesktop.org/archives/hal/2009-April/013158.html may be related
<seb128> tseliot: hum, though that's using _ ... not sure then
<tseliot> BUGabundo: maybe it's because your partitions don't have a label?
<BUGabundo> most don't, yes
<tseliot> james_w: /media/hdb5 is being translated into %media%hdb5 which involves more mangling than what it's described there
<BUGabundo> seb128: email sent.
<lool> cjwatson: 16:02 < kov> lool: just saw it, yeah, I'll just finish something and do some  more thinking about that, but I see no problem in principle
<cjwatson> lool: great, please pass on my thanks - I had been planning to send it to him once Ubuntu people had checked it was OK but don't mind being preempted ;-)
<lool> (done)
<jcastro> kirkland: I added the time grid here so people can pencil in what time they want sessions: https://wiki.ubuntu.com/UbuntuOpenWeek/Prep
<jcastro> also, anyone else interested in an openweek session please ping me!
<cjwatson> fader_: is it just me or is it odd that berkelium isn't back in the PPA pool? I did run make_ppa - or did you steal it again for enablement?
<fader_> cjwatson: I didn't grab it but it is possible that it got hit automatically... let me check
<cjwatson> fader_: I wasn't sure how to tell - make_ppa didn't seem to obviously cause anything to be added to launchpad.net/builders/ even when I checked right afterwards
<fader_> cjwatson: It takes a bit of time as it needs to rebuild the machine.  I'm not sure when it shows up on launchpad though... maybe once it's finished building and ready for work...
<fader_> I kicked off make_ppa again on it just to see.  It doesn't look like certify-web was doing anything with it
<elmo> cjwatson: make_ppa takes a long time (it's a from-scratch reinstall) and sometimes fails
<elmo> cjwatson: don't worry about it too much; we get alerted when machines fail to make the transition
<cjwatson> elmo: ok, fair enough, thanks
<cjwatson> I didn't realise it was a full reinstall, thought it was just untar or similar
<elmo> it probably should be, and we may move towards something lighterweight now that the enablement machines are being more actively used
<elmo> but right now, it's a pre-seeded from-scratch install
<elmo> (including guest creation \o/)
<BUGabundo> cjwatson: do you know about http://xpud.org/ ?
<BUGabundo> they boot linux in 10 secs
<infinity> BUGabundo: My experience with most "we boot Linux in under 10 seconds" systems is that they tend to not have an init system, and frequently don't use X.
<infinity> BUGabundo: Neither of those are particularly viable for us.
<BUGabundo> infinity: yeah... just learned about that via Âµblog. reading more
<cjwatson> BUGabundo: as infinity says. The trick is booting quickly while also doing the things that Ubuntu does.
<cjwatson> BUGabundo: besides, I don't see any source code there?
<cjwatson> BUGabundo: I imagine they just took out a bunch of stuff
<BUGabundo> I think I already asked this, but my memory is worse by the day, how can I make bootchart messure past GDM ?
<BUGabundo> cjwatson: no mention of code on the ML either
<hyperair> BUGabundo: look for S99stop-bootchart or something in /etc/rc2.d and rename it to K99blah
<infinity> cjwatson: http://github.com/penk/mkxpud/tree/master
<BUGabundo> hyperair: thanks... the scripted changed so much in jaunty
<hyperair> BUGabundo: um that was in intrepid.
<hyperair> BUGabundo: i don't know about jaunty.
<BUGabundo> hyperair: ahh ok then
<infinity> cjwatson: They basically just tear chunks out of Debian-like systems to make cut-down bootable images.
<hyperair> i don't think it should have changed much though
<BUGabundo> hyperair: http://paste.ubuntu.com/146993/
<BUGabundo> here is mine
<hyperair> BUGabundo: i didn't modify my initscript, i just renamed it to K99stop-bootchart.
<hyperair> BUGabundo: then it won't get called when init finishes
<hyperair> i mean when the whole set of rc2.d scripts finish
<cjwatson> BUGabundo: right. doesn't sound too interesting with regard to our boot speed work, from what infinity says
<BUGabundo> ok nice to know
<savvas> where's the icon size set for .desktop files? I mean when you stretch the icon of a .desktop files, where's the value saved?
<kirkland> jcastro: cool, i'll grab a slot
<ubuntunewkid> hello
<ubuntunewkid> is anyone experienced with testing python
<ubuntunewkid> i am getting syntax errors in the terminal when i try to test my python code
<ubuntunewkid> i am using python 3.0
<cjwatson> ubuntunewkid: Python 3.0 involves significant language changes from previous versions of Python. Have you read the documentation on porting from previous versions?
<cjwatson> bah
<jdstrand> mvo: hi! when you can spare a couple minutes, can you review bug #354793 and my proposed fix? I'd like push this out as an SRU, or possibly a security update.
<ubottu> Launchpad bug 354793 in apt "date error on saving time starting day" [High,In progress] https://launchpad.net/bugs/354793
<mvo> jdstrand: thanks, doing that now
<elmo> mvo: ekiga can't be upgraded by update-manager; I think I saw you discussing this with mdz the other day - is this a known bug?
<mdz> elmo: yes, I filed it
<elmo> mdz: ok, ta
<mdz> elmo: https://bugs.edge.launchpad.net/ubuntu/+source/ekiga/+bug/353768
<ubottu> Ubuntu bug 353768 in ekiga "Upgrade from 3.0.1-1ubuntu2 to 3.2.0-0ubuntu1 held back" [Medium,In progress]
<mvo> elmo: yes, there was a fix tossed around, but it was no good, so its still being worked on
<tseliot> slangasek: (just asking, it's not a request) would it be a problem to include qt4 in Ubuntu's cd (e.g. in Jaunty+1) in terms of space?
<mdz> kirkland: are you sure you want to attach *full* dpkg -l output to every kvm bug report?
<kirkland> mdz: seemed like a good idea at the time, is that ill-advised?
<kirkland> mdz: the virt stack is many and varied
<mdz> kirkland: it's an extra 200k of data for every report
<mdz> kirkland: it would be better to limit it to relevant packages
<mdz> we could probably use a general mechanism for noting versions of related packages (other than dependencies)
<kirkland> mdz: can i compress it?
<mdz> kirkland: yes, it compresses down to 50 or so
<kirkland> mdz: yeah, totally, the dependencies isn't as interesting as its cousins
<mdz> before the base64 bloat
<mdz> kirkland: maybe you could add something to hookutils for that
<kirkland> mdz: on the other hand ... i don't know that i've gotten a kvm bug report yet
<kirkland> mdz: via apport
<kirkland> mdz: or at least not piles of them
<kirkland> i was bracing for the worst :-)
<pwnguin> how many people are using kvm AND jaunty?
<mdz> kirkland: adding a hook won't cause you to get any more bug reports than you otherwise would
<mdz> it just makes them more useful when the user uses the tool
<kirkland> pwnguin: at least 1
<pwnguin> if the report takes longer as a result of the hook, you might argue you'll get less apport bugs from impatient users
<kirkland> mdz: okay.  is this something I need to pull immediately?
<mdz> kirkland: no
<kirkland> mdz: i did poke around a little for an existing function to get a list of packages installed, didn't find one, lazily dpkg -l'd it
<kirkland> mdz: that 200K number is considerably smaller on servers :-)
<kirkland> mdz: which is where I tested it
<kirkland> mdz: and I could trim it down to just the first 3 fields of output
<kirkland> mdz: obviously, i don't actually care about package descriptions, can look that up later
<mdz> kirkland: I'll work on a hookutils function which takes a list of package names and DTRT
<kirkland> mdz: just need the state, pkgname, and pkgver
<mdz> kirkland: do you really need the state?  I'd think just name and version for installed packages, and ignore uninstalled packages
<kirkland> mdz: dpkg -l | awk '{printf "%s\t%s\t%s\n", $1, $2, $3}'
<kirkland> mdz: that's down from 200K on my desktop to 48K
<mdz> kirkland: dpkg-query --show --showformat '${Package} ${Version}\n'
<kirkland> mdz: yours works for me
<kirkland> mdz: i'm happy with that
<mdz> kirkland: as I said, I'll add something to hookutils to make this simple
<mdz> it's already duplicated in several hooks
<kirkland> mdz: nice, thanks
<mdz> kirkland: Committed revision 1379.
<mdz> kirkland: once that's in the archive, you can just do attach_relevant_packages(report, ['package1', 'package2', ...])
 * ogra wonders why he doesnt see any "running scripts casper..." messages on a livefs boot if quiet is omitted ... 
<kirkland> mdz: okay, you're opposed to attaching the whole list?  or can you expose a method to take the whole list?
<ogra> i see them in casper.log but not on the screen
 * Riddell throws a paper aeroplans at doko with "commit changes to cdbs to bzr" written on it
<mdz> kirkland: honestly, I think attaching the whole list is not very useful
<mdz> kirkland: surely you have to look through that whole list to find the handful of packages which are relevant
<mdz> kirkland: the virt stack can't be that much worse than the printing stack, and they list 32 packages in a nice compact and readable attachment
<sbeattie> mdz: hrm, I wonder if it'd be useful to support regex matching there; think of all the apache2-* packages.
<sbeattie> sorry, libapache2
<mdz> sbeattie: that's a good point
<mdz> sbeattie: bzr commit -m 'apport/hookutils.py: Add glob matching to package_versions()'
<mdz> sbeattie: done
<sbeattie> mdz: thanks!
<mdz> sbeattie: so now you can do package_versions('libapache2*')
<mdz> it uses shell-style glob matching rather than a regex, which is a bit simpler
<TheMuso> mdz: I see the apport utils alsa hook retrieves pci information about audio hardware. Does this also retrieve the vendor and device IDs as well, since these are often needed for hda hardware enablement/debugging.
<slangasek> tseliot: not at all
<slangasek> tseliot: er, I mean, yes it would be a big problem
<slangasek> tseliot: "not at all" to "would it be possible", which is what I read first :)
<mdz> TheMuso: it does lspci -vvmmnn
<tseliot> slangasek: oh, even if it allowed access to some very interesting technology?
<TheMuso> mdz: ah ok.
<ogra> tseliot, called kubuntu ?
<tseliot> ogra: not, it's not exactly what I meant :-P
<tseliot> s/not/no/
<ogra> :)
<slangasek> tseliot: doesn't matter, there's no room.
<tseliot> slangasek: ok, thanks
<bencrisford> Hi everyone
<bencrisford> If anyone gets any free time, spux project (ventrilo client for linu) needs developers :S, we're over on #spux on irc.freenode.net
<bencrisford> so if u do have some free time...
<bencrisford> cheers, bye
<picklesworth> Err, what is spux? :/
<mcas> can anyone tell me the time for the final translation export?
<ebroder> Will it still be possible to upgrade, e.g., gutsy -> hardy after the 18th? I'm sending a reminder message to some of my users, and I'm wondering how emphatic I need to be about needing to upgrade
<mdke> ebroder: yes. Try #ubuntu in future for support requests
<atari2600a> hey
<atari2600a> I'm using your 9.04 beta
<atari2600a> I thought I'd just let you know
<atari2600a> firefox didn't & still will not retain my preferences
<atari2600a> I see this as a GIANT FREAKING SECURITY HOLE!
<mdke> atari2600a: if you are able to search for a bug about this, that is more helpful than reporting it here. If there is already a bug, you can subscribe; if not, you can file one
<atari2600a> meh
<mdke> mcas: 9 April for translations outside language-packs; and 16 April for those in them (https://wiki.ubuntu.com/JauntyReleaseSchedule)
<mcas> mdke: but which time? 00:00 UTC ?
<mdke> mcas: in theory yes (see the top of the page I linked above)
<mcas> oh sorry
<mcas> my mistake
<ikus060> I ask the question on kernel channel, but there isn't any activity, so I give a try here. I compile the kernel with CONFIG_HID_DEBUG=y but I don't get any debug info in syslog
<walrus17> hello
<walrus17> how yo udoin people
<ikus060> fine, and you ?
<walrus17> not bad
<ikus060> Every time I come here, people seams to be death ...
<walrus17> they are waiting for help
<javito> hi
<walrus17> hello
<walrus17> wow you doni?
<walrus17> * doin
<lamont> so when I dist-upgrade and it gives me a new kernel and a new firefox, so I reboot the machine, then launch firefox... why is it that firefox immediately says 'zomg we need to restart...'?
<slangasek> because there's a bug in something? :)
<javito> lamont all firefox updates do it since firefox v3, including firefox over windows
<slangasek> javito: no, you shouldn't get that behavior on a newly-launched firefox
<lamont> javito: yeah, but rebooting the machine, uh, kinda necessarily is a restart of firefox...
<lamont> slangasek: I guess I should file a bug, eh?
<slangasek> yes please :)
<lamont> feels like development, though. :-)
 * jdong glares at pidgin for segfaulting on iconv
<jdong> err icon-theme.cache rather.
<seb128> jdong: get the libxml update I uploaded 15 minutes when it's built
<jdong> seb128: cool, awesome :)
<seb128> you can disable your jabber accounts as a workaround too
<jdong> thanks
<javito> i have a doub with a bug i'm working on
<javito> i sent a debdiff for fix LP: 356918
<javito> but there a a motu devel that deassigned me to the bug
<javito> and wrote "this bug was fixed in the latest debian package" and linked to a sync request
<javito> so... we are in Feature Frozen and this Sync implies a new feature
<maxb> do you doubt it is fixed in the latest debian package?
<maxb> bug 356918
<ubottu> Launchpad bug 356918 in rocksndiamonds "rocksndiamonds: directory "downloads" is not created automatically (dup-of: 353144)" [Medium,Confirmed] https://launchpad.net/bugs/356918
<ubottu> Launchpad bug 353144 in rocksndiamonds "package rocksndiamonds 3.2.6.0+dfsg-3 failed to install/upgrade: subprocess post-installation script returned error exit status 2" [Medium,Confirmed] https://launchpad.net/bugs/353144
<maxb> javito: the changelogs provided in the sync request look pretty non-feature to me
<javito> Added Galician translations for debconf
<cjwatson> that's not a feature
<cjwatson> anyway this is moot because seb128 has done the sync
<slangasek> :)
<javito> but i think frozen implies dont include new think could create new bugs... a new translation may have new bugs
<javito> but i am maybe wrong
<cjwatson> javito: we don't count translation updates as features
<javito> ok then, i'll take note for the future, sorry for the mistake
<cjwatson> yes, it is possible for them to create new bugs, but they will be very localised, and for the most part (not always in the case of translations of C programs, but always in the case of debconf translations) cosmetic
<cellofellow> Will Jaunty have the new GTK version of Aptitude (0.5.0). I checked and currently it only has 0.4.1.
<maxb> As there are only hours to go until FinalFreeze, I think "no" is a safe bet
<cellofellow> Oh, really only hours?
<maxb> ~ 2h40m
<cellofellow> well, yeah No will be the right answer.
 * cellofellow wonders if Aptitude GTK will overtake Synaptic as the favorite GTK APT frontend.
<mvo> cellofellow: not for jaunty ;)
<lamont> slangasek: there.  #358014
<cellofellow> obviously. :)
<cellofellow> But, in the next year or two. What if it's the default manager for Ubuntu in, say, Karmic+1?
<slangasek> lamont: thanks, I'll leave you in asac's capable hands for that one then
<cellofellow> (Or is Synaptic too ingrained into Ubuntu to leave?)
<asac> bug #358014
<ubottu> Launchpad bug 358014 in firefox-3.0 "rebooting does not clear firefox's "restart required" status" [Undecided,New] https://launchpad.net/bugs/358014
<Adri2000> slangasek: is final freeze really beginning at the start of the utc day as maxb said?
<mvo> cellofellow: synaptic is pretty integrated and some people are quite fond of it, but that does not mean its there forever
<mvo> cellofellow: we will talk about it at uds and decide
<cellofellow> Ok then. :) So, we've had this discussion before I take it?
<slangasek> Adri2000: that's the official deadline; the actual freeze may happen any time after that (it requires coordinating multiple people in order to get the button pushed)
<Adri2000> ok
<mvo> cellofellow: you take it in what sense?
<cellofellow> mvo: oh, just how you said it would be discussed at UDS made me think this had been discussed before and it was decided to discuss it more then.
<mvo> cellofellow: sorry, I did not express myself clearly then. I meant to say "we will discuss about it at the next UDS"
<cellofellow> ok
<mvo> cellofellow: for jaunty it was not clear if the gtk frontend would make it out of experimental or not
<cellofellow> It's still there, hasn't hit Sid yet.
<cellofellow> I thought Ubuntu pulled from Experimental though, not Sid.
<mvo> cellofellow: only for selected packages
<cellofellow> oh, ok
<cellofellow> and it pulls straight from upstream for some things like Firefox, right?
<mvo> yes
<slangasek> hmm.  for the life of me, I cannot figure out why intrepid had python-xmpp 0.3.1-1.2 instead of 0.4.1-cvs20080505.2.
<cjwatson> cellofellow: pulling from experimental across the board would be pretty, er, hardcore ;-)
<cellofellow> gotcha
<slangasek> in the "putting lots of metal through newfound holes in your skull" sense
<cellofellow> when was the experimental branch started? I seem to remember once upon a time there only being stable, testing, and unstable.
<maxb> experimental isn't a full branch, more of an overlay on unstable
<maxb> A question about FinalFreeze: are Python 2.6 DeprecationWarnings from console apps still worth fixing, or are they too cosmetic to be worth the overhead of freeze exception processing?
<cellofellow> According to Wikipedia it says that stuff in Experimental is stuff that isn't considered stable upstream, whilst if it is stable upstream it gets put in unstable.
<slangasek> ...
<slangasek> I think that section should be removed from the wikipedia article. :)
<slangasek> maxb: universe is still fairly open to bug fixes with a minimum of overhead, I would say they're still worth fixing
 * maxb should get debdiffing then :-)
<cjwatson> cellofellow: experimental has been there for eons
<cellofellow> ok
<cjwatson> cellofellow: http://www.debian.org/doc/FAQ/ch-ftparchives.en.html might be a touch more authoritative than Wikipedia
<cjwatson> which in this respect is indeed spouting nonsense
 * calc doing test build for OOo then upload in ~ 1hr :)
<lamont> so HTF do I tell vim to override the global setting for syntax on, globally for myself, in and out of chroots, I wonder.
<cjwatson> echo 'syntax off' >> ~/.vimrc
<lamont> ta
<lamont> I wouldn't mind it so much if (1) I'd ever started using it, and (2) it was actually readable on the window
<calc> lamont: you can also set your background color light or dark to make it more readable if that is the issue
<calc> lamont: eg set bg=dark
<lamont> calc: I prefer the backgrounds I have, thank you.  syntax highlighting has never been of any signifcant use to me
<calc> lamont: er no the set bg=dark makes it change the highlighting colors (aiui anyway) so it shows up better on light or dark backgrounds
<calc> lamont: but yea if you don't need it just turn it off
<lamont> bg is either grey or black or a dark purple for most of my windows
<lamont> then again, when I fire up a terminal, it's an xterm...
<lamont> sorry seb
<calc> well in that case setting bg=dark should change the colors to be readable, at least for the dark cases
<calc> i always set my xterms to be white on black like console so i just have mine set to bg=dark in vimrc
 * calc doesn't like the black on white in default gnome-terminal
<Adri2000> speaking of vim, is it just me or vim stopped wrapping debian/changelog lines to 80 characters in jaunty?
<slangasek> kees: could you have a look at bug #358051? (component-mismatches cleanup)
<ubottu> Launchpad bug 358051 in dnspython "Main inclusion request for dnspython" [Undecided,New] https://launchpad.net/bugs/358051
<lamont> slangasek: I'm a big fan of shiny dnspython
<lamont> OTOH, that has nothing to do with release critera
<TheMuso> calc: re gnome-terminal, me neither, which is why I change it to white on black. :p
<calc> TheMuso: yea me too
<calc> TheMuso: i rarely use real xterms, usually just a g-t 'xterm'
 * calc wonders if black on white is a mac'ism
<TheMuso> calc: gnome-terminal all the time for me here, due to a11y requirement.
<TheMuso> calc: Not sure, but I know its quite difficult, at least so far as I've tried, to switch the OS X terminal to black on white.
<LaserJock_> bryce: about? I got an interestingly locked up X
<LaserJock_> relatedly, does anybody know the best way to restart X from ssh?
<bryce> /etc/init.d/gdm restart
<hyperair> could i persuade anyone to look at bug #202089?
<ubottu> Launchpad bug 202089 in pulseaudio "Pulseaudio is blocking normal sound after resume" [Low,Confirmed] https://launchpad.net/bugs/202089
<LaserJock_> bryce: what if that doesn't work?
<TheMuso> hyperair: Just have, please read my comment.
<hyperair> it was fixed, but some users complained it didn't work for them, so i've revised the pm-utils hook in pulseaudio
<bryce> LaserJock, then your GPU is probably locked up and you'll have to powercycle
<LaserJock_> bryce: it says it shut down but fails to restart. however I see all my desktop processes still around so I don't know how it could have successfully shut down
<bryce> ps aux | grep X ?
<hyperair> TheMuso: are you luke yelavich?
<TheMuso> hyperair: Yes.
<hyperair> TheMuso: i've fixed that already, see my latest comment =)
<TheMuso> hyperair: Thanks.
<LaserJock_> bryce: I still have an X process
<LaserJock_> let me kill that
<hyperair> TheMuso: actually i'm wondering if suspend-source is also needed
<TheMuso> hyperair: Hrm, you may have a point.
<hyperair> TheMuso: perhaps it owuld be safe to just add it anyway
<TheMuso> However, who would be using a mic/line-in when they suspend?
<hyperair> TheMuso: good point, but if anyone is crazy enough to do that, it would be nice to not have it break ;)
<LaserJock_> bryce: hmm, killing X hosed the whole thing, can't even ssh anymore, off to powercycle :-)
<LaserJock_> this is sort of disturbing
<LaserJock_> I was in the middle of my dissertation :-)
<hyperair> TheMuso: i'll update the debdiff then.
<dtchen> hyperair: i'm already fixing it in my bzr branch
<hyperair> dtchen: ah, i see. okay =)
<hyperair> dtchen: weren't you crimsun?
<dtchen> i still am.
<hyperair> dtchen: i thought you weren't around =p
<LaserJock_> bryce: would x86 vs x86_64 make a difference, I just started using amd64 around the time this started happening
<bryce> laserJock, seems plausible
#ubuntu-devel 2009-04-09
<dtchen> hyperair: / TheMuso: all set
<dtchen> tested with two devices, does the right thing
<TheMuso> dtchen: ok cool.
 * mneptok punches directhex in the face
<mneptok> YOU ARE GREEN DRAZI!
 * slangasek scratches his head
<mneptok> slangasek: http://doctormo.wordpress.com/2009/04/08/foss-tribalism-in-the-community/
<mneptok> slangasek: directhex earns the comment win :)
<TheMuso> slangasek: Since I'm almost done for my working day here, and since I'm away for the easter weekend, and since kernel freeze is tomorrow, I'll need exceptions for linux-ports and linux-rt, which will only be rebases. Shall I file a bug to make it formal?
<slangasek> I see. :)
<slangasek> TheMuso: hmm, how long after kernel freeze are the rebases expected to get done?
<TheMuso> slangasek: not till next monday evening my time at the absolute earliest
<slangasek> TheMuso: are those packages up-to-date with the linux package currently in the archive?
<TheMuso> slangasek: yes they are
<slangasek> ok
<slangasek> on the bright side, your Monday evening is early
<slangasek> yes, please file a bug to remind us that it's coming
<TheMuso> Ok will do.
<directhex> mneptok, i'd hope slangasek of all people would get an obscure babylon 5 reference
<slangasek> Yes.
<directhex> especially since i was out-obscured last time :/
<mneptok> directhex: between slangasek and myself, it's a tight net to slip through :)
<TheMuso> dtchen: I'm going to upload that suspend/resume change for pulse now, since I am about to head off for the easter weekend, unless you want me to hold off, and you get someone else to sponsor the uploads.
<dtchen> TheMuso: it's set for upload
<TheMuso> dtchen: ok thanks.
<dtchen> hyperair: thanks for being on top of it. unfortunately editing files using my phone is somewhat subpar ;)
<TheMuso> dtchen: is there a problem with the file?
<dtchen> TheMuso: no, my bzr branch is fine.
<TheMuso> dtchen: ah ok I just thought there was an error you found relating to use of your phone or some such. :)
 * TheMuso does a quick test build.
<slangasek> mneptok: I don't think I contribute much there, as I wouldn't have seen the comment at all without being pointed to it... :)
<TheMuso> slangasek: ok bug filed, ubuntu-release subscribed.
<slangasek> TheMuso: saw it, thanks :)
<TheMuso> Ok pulse uploaded, I'm outa here. Happy easter all
<slangasek> have a good weekend!
<TheMuso> Will do, checking out plenty of live music.
<slangasek> kirkland: do you recall why python-moinmoin was among the packages dropped when you cleaned up the server seed?
<slangasek> kirkland: asking because it's not seeded anywhere else under Ubuntu, it's currently in main only because kubuntu has not yet merged that change
<slangasek> (also because python-moinmoin serecommends: fckeditor from universe, so I need to know which side of that to clean up)
<cjwatson> slangasek: oh, I think that recommendation was new in the merge I sponsored recently; if you need to, it probably wouldn't be disastrous to drop it to a suggests
<cjwatson> it makes the moin GUI editor work
<slangasek> yeah, it looked wrong to me as a Recommends
<slangasek> then I went to look at the seed to see in what circumstances python-moinmoin is pulled in, and became Confused
<slangasek> cjwatson: should we poke python-moinmoin back into the ubuntu seeds somewhere?
<maxb> moinmoin was using an embedded copy of fckeditor until recently. Personally I hate the GUI editor, but some people might see it as a standard part of a Moin install?
<slangasek> ah
<cjwatson> wasn't it disabled?
<slangasek> in 1.6.2-1 it was
<cjwatson> one reason I can think of to keep it is that we almost certainly run it on some of our own servers
<cjwatson> IIRC including the GUI editor
<slangasek> well, first of all, having moin in main only because of the accident that the kubuntu seed hasn't merged that change isn't good - this should be seeded in the dvd seed?
<cjwatson> maybe better one of the platform supported-server seeds
<slangasek> supported-misc-servers, then?
<cjwatson> sounds plausible
<slangasek> ok; that leaves fckditor as an open question
<slangasek> e
<savvas> just so I don't have a guilt for 6 months, do you think I made the right decision to set bug 356935 as invalid? it's too late for such changes right?
<ubottu> Launchpad bug 356935 in sqlite3 "FFe: Please sync sqlite3 3.6.12-1 from Debian testing" [Undecided,Invalid] https://launchpad.net/bugs/356935
<slangasek> savvas: barring major bugs in the version we currently have in jaunty, yes
<savvas> no bugs whatsoever unfortunately, that little application is damn good, and getting better every time :)
<savvas> I guess the live backup can wait for 6 months hehe
<LaserJock_> dang, Ubuntu just keeps getting easier and easier to install
<slangasek> sorry, we'll try harder for karmic
<LaserJock_> :)
<savvas> does anyone happen to know which application configuration the installer asks you to import?
<savvas> is there a list of these apps?
<LaserJock_> it just did firefox, evolution, and pidgin for me
<savvas> same :\
<savvas> imagine going through the whole 500-600 application configuration folders in my home I gathered this past few years :P
<savvas> *these
<slangasek> cjwatson: so with that decided, we still need to figure out whether we want fckeditor by default (MIR) or not (upload).
<cjwatson> security review might take a while, I guess
<cjwatson> I'm happy to have it out given the lateness
<cjwatson> want me to upload that?
<slangasek> I can
<slangasek> I already have it here
<cjwatson> ok
<cjwatson> beware debian/control.in
<slangasek> noted :)
<cjwatson> slangasek: my fix for 44194 hasn't had any confirmation that it actually fixes the bug yet, but Lars reckons it doesn't break anything. Do you think I should go ahead and upload what I have?
<slangasek> cjwatson: yeah
<slangasek> calc: did the OOo upload happen?
<slangasek> calc: doesn't appear to have - it's now late, 2 hours past the official deadline?
 * slangasek afks for dinner
<calc> slangasek: i ran into git eating my brain issue, i am ready to upload now
<calc> i'll stage it all on chinstrap and then get into the archive in ~ 2hr (need both packages)
<calc> slangasek: around 1hr left until its uploaded to the archive itself
<tedg> Is it worth working on some final bugs (not crashers) or is it time to give up?
<calc> slangasek: i also disabled sparc in the build (at least afaict), so we probably should remove the sparc binaries from the archive after it is done building
<calc> slangasek: done
<slangasek> calc: ok; in that case we could drop the sparc binaries immediately anyway
<calc> slangasek: ok
<calc> they both just got accepted
<calc> so if you want to nuke the jaunty sparc binaries go ahead :)
<calc> slangasek: could i get you to accept ooo-thumbnailer into universe? :)
<calc> slangasek: it closes bug 25827 but I managed to forget to mention it in the changelog :(
<ubottu> Launchpad bug 25827 in openoffice.org "Thumbnails for Openoffice.org documents" [Medium,Fix committed] https://launchpad.net/bugs/25827
<ScottK> slangasek: Any ideas on why we stopped building usplash for ia64 last year?
<ScottK> I don't see anything in debian/changelog
<ScottK> Currently all of Kubuntu except kubuntu-meta is built on IA64, so the completionist in me is a bit frustrated.
<slangasek> ScottK: no idea on that one, no
<slangasek> calc: does ooo-thumbnailer have an ack from motu-release?
<slangasek> actually... either way, I'm not going to get to it tonight
<calc> slangasek: ok, i'll ping motu-release
<slangasek> ok
<slangasek> calc: btw, there are a number of reverse-build-deps of libitext-java that don't seem to have gotten MIRs yet; do you have any information about bouncycastle, libpdfrenderer-java, junitperf, or should I write up the MIRs from scratch?
<calc> reverse-build-deps? i must be confused or something
<calc> why would reverse-build-deps (things that use a library) need to be moved into main
<slangasek> calc: er, I mean build-deps
<calc> but no i didn't know anything about its changing, it has been in main for a while now and didn't realize it grew new build-deps
<slangasek> I'm not sure they're new
<calc> oh
<calc> hmm either their new or someone demoted them after it built for intrepid i suppose
<slangasek> or libitext-java never had to be rebuilt after being promoted
<slangasek> actually, libitext-java was uploaded once since promotion... and is dep-wait.
<calc> oh hmm i forgot about that
<calc> yea so it either had things demoted or it grew new build-deps
<slangasek> no, the package has *never* built successfully in main
<slangasek> the binary that's in main is the same version that was originally promoted
<calc> hmm how did it get in the archive at all, since the previous upload was a ubuntu change
<slangasek> it was built in universe
<slangasek> *before* it was promoted
<calc> er 1.4.5-3 was promoted
<slangasek> oh
<slangasek> ok, then they are new build-deps
<slangasek> sorry; I was trying to go by debian/changelog, which says nothing about the new deps at all
<calc> then 1.4.5-3ubuntu1 was uploaded 6 months later
<calc> ok
<slangasek> heh, ok :)
<slangasek> in that case, I can probably cull these build-deps for jaunty
<calc> so whoever requested sync should have written the MIRs
<calc> because it would have required an override of the ubuntu changes to have been synced
<slangasek> yes, quite
<calc> bug 299000
<ubottu> Launchpad bug 299000 in libitext-java "sync-request" [Wishlist,Fix released] https://launchpad.net/bugs/299000
<calc> it was matthias
<calc> lol
<slangasek> yep
<slangasek> well, he was right that the Ubuntu change was integrated in the Debian package :)
<slangasek> I'll write up the MIRs
<calc> ok
<calc> i could do it tomorrow, but i'm about to head to bed for tonight
<slangasek> that's fine; these are high on my list of things to kill off for release, I'll take care of it before bed
<calc> ok
<slangasek> that, or kill off the build-deps if I determine they're expendable :)
<StevenK> Mmmm. Red-shirt Build-Depends
<slangasek> absolutely!
<hyperair> dtchen: regarding the pulseaudio hook, the get_pulse_users i wrote that time misses out of a few pulseaudio instances, especially if you've killed pulseaudio before and don't prepend /usr/bin to it.
<hyperair> dtchen: could you take the current get_pulse_users() function from the debdiff i proposed?
<hyperair> dtchen: to summarize, get_pulse_users() { ps -C pulseaudio -o user=; }
<hyperair> dtchen: i think that works much better than using awk
<slangasek> soren: dendrobates mentioned last week you would be providing the fix for bug #347622; is that done now, or is the bug still outstanding?
<ubottu> Launchpad bug 347622 in eucalyptus "in SYSTEM mode, VM ips are not automatically discovered by CC or NC on switched networks" [Critical,Confirmed] https://launchpad.net/bugs/347622
<seb128> DOH
<seb128> slangasek: already frozen?!?
<slangasek> seb128: yep - but if you need something pushed in, we'll do the usual dance of course
<slangasek> fusa, then?
<seb128> slangasek: please accept fusa, it undo the string freeze breakage of the previous upload
<slangasek> sure
<seb128> thanks
<seb128> I was sort of expect to get work done today
<seb128> ie upload quite a lot
<seb128> you are just putting extra review load on your shoulder but if you are fine with that ;-)
<slangasek> yep, that's the routine
<slangasek> the alternative is that everyone makes "one last upload" with "just a small change that can't hurt"
<bryce> so nice having the release manager in my time zone :-)
<slangasek> heh
<slangasek> that's UTC-10, right?
<liw> bryce, no no, it's so nice having a release manager who never sleeps
<liw> we should have more vampires develop Ubuntu
<liw> "Ubuntu: Linux not just for human beings"
<slangasek> tseliot: do you agree with pitti's proposal in bug #351394?
<ubottu> Launchpad bug 351394 in nvidia-common "nvidia -177 needs to be transitioned to -180 on upgrade" [High,Triaged] https://launchpad.net/bugs/351394
<tseliot> let me check
<tseliot> slangasek: I think I can migrate users without transitional packages when they do the upgrade through Update Manager and bug them to death with debconf if they upgrade from the command line
<tseliot> which is what nvidia-common should do
<slangasek> oh, nvidia-common already does this?
<tseliot> slangasek: yes but it doesn't migrate users with the 177 driver yet though. It should be a trivial change
<slangasek> ok
<tseliot> slangasek: no, wait it should already do that (since revision 9): https://code.launchpad.net/~albertomilone/nvidia-common/main
<bryce> is kde using Qt4.4 or 4.5 in jaunty?
<slangasek> bryce: 4.5
<bryce> hrm
<bryce> https://bugs.kde.org/show_bug.cgi?id=187356#c21 (in ref to our bug #350120)
<ubottu> Launchpad bug 350120 in xserver-xorg-video-ati "painting artifacts with qt4.5 on radeon chipset" [Medium,Confirmed] https://launchpad.net/bugs/350120
<ubottu> KDE bug 187356 in qt "graphical corruption in multiple applications with qt-4 5" [Normal,New]
* slangasek changed the topic of #ubuntu-devel to: Python 2.6 issue #349467 | Archive: release freeze | Ubuntu 9.04 Beta released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
* slangasek changed the topic of #ubuntu-devel to: Archive: release freeze | Ubuntu 9.04 Beta released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<nixternal> bryce: there is no easy way of fixing the issues due to Kubuntu deciding to use Qt 4.5 (imho it was a bad decision)
<nixternal> I would have to say that 350120 is more than likely a Qt/Kubuntu bug more so than an x bug...we knew the warning of using Qt4.5 with KDE <4.3
<bryce> nixternal: thanks, that's what I was wondering
<bryce> nixternal: what package should this be filed against?
<nixternal> qt
<savvas> does anyone know the answer to bug 358271? is it actually a bug?
<ubottu> Launchpad bug 358271 in console-setup "Unsupported settings in configuration file /etc/default/console-setup" [Undecided,New] https://launchpad.net/bugs/358271
<nixternal> woo, kubuntu isn't the only ones to make that mistake of using 4.5, I see gentoo did too :)
<bryce> nixternal: hmm no such package 'qt'.  'qt4-x11'?
<nixternal> ya, that's it
<bryce> awesome thanks
<nixternal> np
<savvas> cjwatson: I'd like your comment for b ug 358271 when you find some time (since you were the last person that changed console-setup)
<tkamppeter> slangasek, hi
<tkamppeter> slangasek: I have uploaded HPLIP 3.9.2-3ubuntu4 and as it finished uploading I saw your e-mail that you have frozen the RC. So it missed the freeze for seconds. Can you pass it through?
<slangasek> tkamppeter: it will be reviewed by the release team; there are no free passes for "almost" making the freeze cutoff, given that the official freeze deadline was several hours ago :)
<tkamppeter> slangasek: sorry, if someone reports a problem I will put out a SRU.
<ogra> slangasek, could you do me a favour and trigger a ports-live build (none of our fixes from yesterday seems to have made it on the 09 image)
<ogra> *seem
<slangasek> lool: ^^ could you do that, maybe? I'm trying to find my bed
<seb128> 'night slangasek
<lool> slangasek: Happy to
<lool> slangasek: Have a good night
<slangasek> "trying" is still the operative word ;)
<ogra> slangasek, i can do it myself, i just dont like to do it without asking during freezes ;) sleep tight
 * lool throws a bed on slangasek 
<slangasek> ogra: oh; "can you" vs. "can I" :-)
<ogra> slangasek, yeah, sorry, you were still up ... GO TO BED NOW !!!
<ogra> ;)
<lool> slangasek, ogra: Kicking an ubuntu live build for armel
<ogra> thanks
<lool> (I verified the proper versions of casper, flash-kernel, and gnome-keyring are on the cdimage mirror; however I can't check on the buildds)
<lool> cjwatson: ogra reminded me that we shouldn't run for armel alone; will finish this run though, and I don't intend to run another full ports_daily-live build unless you say otherwise
<tseliot> doko: any ideas as to why this happens when dist-upgrading to Jaunty (the program works well in Jaunty)? https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/346099
<ubottu> Error: This bug is private
<tseliot> it's no longer private now
<cjwatson> slangasek: ooh, confirmation of 44194
 * cjwatson offers up a quick prayer of thanks
<cjwatson> savvas: eek; will look, thanks
<cjwatson> debian/changelog:284:  * Removed debconf support for grp:alts_toggle, grp:ctrls_toggle,
<StevenK> root@mangled:~# deluser ...
<StevenK> Warning: Removing group `users', since no other user is part of it.
 * StevenK gives adduser a penalty card for 'lying'
<savvas> cjwatson: thanks :)
<IntuitiveNipple> Do we have anyone to push an openjdk bug-fix? archive freeze is upon us and I haven't had a response from doko
<doko> tseliot: this should be gone, afaik
<doko> IntuitiveNipple: which one
<IntuitiveNipple> doko: oh, you're there :) I emailed you and subscribed you to bug #344705
<ubottu> Launchpad bug 344705 in openjdk-6 "IcedTea Plugin Doesnt Work" [High,In progress] https://launchpad.net/bugs/344705
<IntuitiveNipple> doko: thought you may be on vacation
<tseliot> doko: ok, thanks
<doko> IntuitiveNipple: ok, looking
<IntuitiveNipple> doko: thanks :)
<ogra> seb128, why is gnome-keyring started in two places ?
<ogra> (pam starts it from gdm and xdg has an autostart file)
<seb128> not sure, they have different purpose
<seb128> the pam thing allows to automatically unlock it
<seb128> when entering your password on the login screen
<ogra> we're trying to track down the 100% CPU usage on arm atm
<ogra> and were wondering if a race could happen here
<seb128> the autostart is because you need to get it started when doing autologin or not using gdm too
<ogra> its also confusing that we see it running with different options on different systems
<seb128> open upstream bugs
<ogra> lool sees --start if not using gdm
<seb128> I don't know the details
<ogra> i see --daemonize --login on my laptop
<lool> Hmm I wonder why printf '%c' 0xff doesn't output the same as printf '\xff'
<BUGabundo> seb128 is not here?
<BUGabundo> is update to pidgin is crashing XMPP and SSL
<BUGabundo> pidgin (1:2.5.5-1ubuntu7)   * debian/patches/71_upstream_change_fix_ssl_crasher.patch:
<calc> BUGabundo: file a bug with apport crash information :)
<BUGabundo> doing so
<BUGabundo> I have the .crash for it
<BUGabundo> just don't have dbg symbols
<BUGabundo> UM is running so I have to way to install it
<BUGabundo> seb128: ping
<BUGabundo> (02:46:31 PM) freenode: is update to pidgin is crashing XMPP and SSL
<BUGabundo> (02:46:47 PM) freenode: pidgin (1:2.5.5-1ubuntu7)   * debian/patches/71_upstream_change_fix_ssl_crasher.patch:
<seb128> BUGabundo: contextless ping warning
<BUGabundo> sorry for the noise
<seb128> ?
<IntuitiveNipple> lool: shell doesn't support leading 0x ?
<IntuitiveNipple> lool: correction, %c only consumes first character, so you get the 0
<ogra> yeah, doesnt that need to be %s ?
<seb128> BUGabundo: did you have question or ...?
<BUGabundo> seb128: its just that patch is making pidgin crash
<BUGabundo> I just got the .crash and bt full
<BUGabundo> reporning now on LP
<seb128> BUGabundo: are you sure you don't have bug #357949 rather?
<ubottu> Launchpad bug 357949 in pidgin "Pidgin crashes when trying to connect to jabber" [High,Confirmed] https://launchpad.net/bugs/357949
 * BUGabundo looks
<BUGabundo> that's what happens
<BUGabundo> but I just got it before lunch!
 * seb128 grrr at user filing ton of duplicates
<BUGabundo> it was fine until then
<BUGabundo> this bug is 18h old
<lool> IntuitiveNipple: Indeed; quite counter-intuitive when compared to printf '%i' 0xff
<lool> IntuitiveNipple: thanks
<seb128> BUGabundo: and you did restart pidgin after upgrade since yesterday before that?
<IntuitiveNipple> printf '\xXX' prints the single character with code 0xXX, whereas '%c' prints the ASCII char at index 0 of the relevant argument
<BUGabundo> of course
<lool> ogra: I wanted to output a byte with the value 0xff, %s would have output "0xff"
<IntuitiveNipple> lool: Yeah, that could get confusing!
<BUGabundo> just added my bt full to that bug
<ogra> lool, ah
<lool> IntuitiveNipple: I think %c in C is just like %i or %d, not like %s -- which is why i was confused
<lool> Anyway \xff works fine
<IntuitiveNipple> lool: convoluted but this works: printf "\x$(printf '%x' 0xff)"
 * lool fails to see the point :)
<IntuitiveNipple> lool: just because it can :p
<IntuitiveNipple> lool: might be useful in some weird string-processing scenario :)
<lool> I would just find %c much easier if it wasn't %.1s
<IntuitiveNipple> lool: yeah, that'd have to guess the argument type was a hex-expressed byte
<BUGabundo> seb128: renaming ~/.purple/icons/ seems to work
<lool> (It does for %i and %d!)
<IntuitiveNipple> yeah, that is almost looking like a bug
<seb128> BUGabundo: I told you that's the same bug ;-)
<IntuitiveNipple> since it says 'printf uses the C format specifiers'
<BUGabundo> thanks for the tip seb128
<lool> I guess it wont every be changed for compatibility purposes
<IntuitiveNipple> possibly not, but... "...all C format specifications ending with one of diouxXfeEgGcs, with ARGUMENTs converted to proper type first..."
<seb128> BUGabundo: you're welcome
<IntuitiveNipple> lool: Is it bash you're working with?
<IntuitiveNipple> lool: bug #225637
<ubottu> Launchpad bug 225637 in coreutils "printf(1) %c doesn't work as expected, instead like %.1s." [Wishlist,Confirmed] https://launchpad.net/bugs/225637
<lool> Eh
<IntuitiveNipple> "POSIX requires the current behavior"
<lool> IntuitiveNipple: It's zsh
<IntuitiveNipple> lool: http://www.zsh.org/mla/workers/2004/msg00356.html
 * Hobbsee mourns the loss of working pidgin
<ogra> use drums
<BUGabundo> Hobbsee: it is workable
<BUGabundo> if you like to loose all your old avatars
<Hobbsee> BUGabundo: how does one fix it so it doens't segfault when it's trying to connect?
<lool> right
<seb128> Hobbsee: https://bugs.edge.launchpad.net/ubuntu/+source/pidgin/+bug/357949
<ubottu> Ubuntu bug 357949 in pidgin "Pidgin crashes when trying to connect to jabber" [High,Confirmed]
<BUGabundo> Hobbsee: rename ~/.purple/icons/
<seb128> or remove the gst plugin which lead to the crash
<Hobbsee> ah, lovely.
 * BUGabundo rather rename... hope I can get it back later.... I love too much my avatar cache
<seb128> BUGabundo: just rremove /usr/lib/gstreamer-0.10/libgstladspa.so
<ogra> tedg, should pidgins contact list minimize into the notifier applet ?
<Hobbsee> ogra: I wish!
 * ogra never uses pidgin ... 
<tedg> ogra, into the messaging menu?  Yes, it should.  Assuming you have the plugin enabled of course.
<ogra_babbage> only here on the test machine for IRC
<tedg> Hobbsee: That got fixed with the 0.1.5 upload of indicator-applet and libindicate.
<ogra_babbage> tedg: well, thats a fresh jaunty install, shouldnt it be enabled by default ?
<Hobbsee> ah ha.  excellent.
<ogra_babbage> the buddy list definately minimizes to teh windowlist here
<tedg> ogra_babbage: Yes.  Is it up to date?
<ogra_babbage> built this afternoon (UTC)
<tedg> ogra_babbage: Oh, minimizes?  It'll minimize to the window list, if you close it, it'll go into the menu.
<ogra_babbage> if i close it it shuts down pidgin
<ogra_babbage> it only minimizes to the applet if i click on the submenu in the applet
<ogra_babbage> oh, now it doesnt
<ogra_babbage> weird
<ogra_babbage> tedg: ignore me, seems it does what it should, though i'm sure it just closed when i tried that before
 * tedg hacked into ogra_babbage's machine and fixed it ;)
<ogra_babbage> might that have to do with the fact that i wasnt connected before ?
<tedg> You should really change that password...
<ogra_babbage> damned ... i shouldnt have blogged it :)
<tedg> ogra_babbage: Yes, I think that Pidgin does take that into account.  If you're completely offline it closes.
<ogra_babbage> ah, ok then it DTRT
<cr3> anyone happen to know since when apt-transport-https has been in ubuntu-standard?
<cr3> err, "in" as in a dependency of the ubuntu-standard meta package :)
<james_w> just this release
<cody-somerville> Earlier this release cycle I believe
<cr3> james_w: excellent, that saved me quite a bit of searching :)
<cjwatson> cr3: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.jaunty/revision/1296
<plars> pitti_: awake?
<Ampelbein> hmm. apport on intrepid states: "upload() got an unexpected keyword argument 'staging'"
<james_w> do you have a backtrace?
<dendrobates> slangasek: we have a problem with the upload of eucalyptus soren made yesterday.
<dendrobates> slangasek: he introduced a critical bug.
<slangasek> dendrobates: I saw a new bug opened, yes
<dendrobates> slangasek: this basically completely breaks eucalyptus.  Is there any way I can get this in?
<slangasek> dendrobates: yes, please get the fix uploaded
<dendrobates> it is uploaded.
<Ampelbein> james_w: no. http://paste.ubuntu.com/147778/ is all i get.
<dendrobates> slangasek: ^^^
<Ampelbein> states network error, but i can connect to launchpad without problems.
<slangasek> dendrobates: ok, then I'll review it as soon as I can
<dendrobates> slangasek: thanks much.
<kees> james_w: excellent reply to the PolicyKit design "bug".  we'll have to use that as a FAQ if it comes up again.
<Ng> asac: I'm going a bit crazy here... thunderbird should be able to see gnome-vfs shares, right?
<ion_> kees: URL please.
<kees> ion_: https://bugs.edge.launchpad.net/bugs/358086
<ubottu> Ubuntu bug 358086 in policykit-gnome "Exploitable to gain root access with non-priveleged user" [Undecided,Invalid]
<ion_> Thanks
<kees> slangasek: which MIRs are critical to release still?
<slangasek> kees: the ones that show up with 'Ubuntu Jaunty' on https://bugs.launchpad.net/~ubuntu-mir/+subscribedbugs
<slangasek> (I'm not done filing all the ones that apply, unfortunately)
 * kees face-palms
<IntuitiveNipple> I've just helped a user solve a fail-at-initrd stage bug with jaunty. It was failing to find the root partition. Eventually we worked out that udev wasn't building its db. Then the user recalled seeing a message scroll past during boot "udevadm trigger is not premitted while udev is unconfigured" and it turned out that dpkg hasn't completed configuring before the system was rebooted.
<IntuitiveNipple> Where precisely should that be posted against?
<ion_> Oh noes, the fonts are blurry again. I wonder which package caused it? I have installed many sets of upgrades since the previous reboot/login. Setting lcdfilter as lcdlegacy doesnât work anymore.
<kees> IntuitiveNipple: sounds like the install/upgrade didn't finish before you rebooted.
<IntuitiveNipple> kees: not me; the user. apparently the system restart icon came up and so he rebooted
<kees> IntuitiveNipple: ah, so "please reboot" happened even though a package failed to install?
<kees> IntuitiveNipple: check the dpkg logs and figure out if it was udev or linux that failed, and open it against that package.
<kees> it does seem that the update-notifier file should only be put in place if the postinst finishes successfully.  :(
<IntuitiveNipple> kees: apparently so. Took a while to diagnose it because he was stuck in the initrd busybox, but the fix was a live-CD env, chroot to the install, and "dpkg --configure -a"
<slangasek> does the notification icon know not to launch if dpkg is still running?
<IntuitiveNipple> I'm wanting to post a bug but not sure which package to put it against. I found another report of the same issue in forums
<kees> slangasek: not sure
<kees> IntuitiveNipple: you could open it against both udev and linux :)
<IntuitiveNipple> kees: I'm sure Scott would love that!
<kees> IntuitiveNipple: heh, well both of those packages drop the "please reboot" file, so they likely both need to be fixed.
<IntuitiveNipple> I'll quote you in the bug report then!
<kees> IntuitiveNipple: well, please include the logs of the failure too. :)
<IntuitiveNipple> kees: there's not much of those since it was initrd, but I've got something from a forum post.
<kees> IntuitiveNipple: the package update logs, I mean
<kees> IntuitiveNipple: i.e. figure out what state the system was in prior to rebooting
<IntuitiveNipple> kees: ah ok... the user reported he updates every day, so the diff was between yesterday and today
<kees> IntuitiveNipple: have them include /var/log/dpkg.log
<IntuitiveNipple> kees: too late unfortunately - the user had to go to 'karate' ... I suspect he'll be taking out some frustration for the bug :)
<slangasek> kees: mumble
<slangasek> kees: ok, I guess I'll hack the crap out of libitext to disable libpdfrenderer?
<kees> slangasek: I'm really really against libpdfrenderer.  fixing PDF vulnerabilities is hugely time-consuming.  :(
<slangasek> ok
<Keybuk> IntuitiveNipple, kees: definitely not a bug in udev or linux
<Keybuk> well, maybe linux
<Keybuk> but not udev
<IntuitiveNipple> Keybuk: ok, I didn't think so... what would you suggest?
<Keybuk> if you get "udevadm not permitted" inside your initramfs, something called update-initramfs without depending on initramfs-tools!
<kees> Keybuk: ah-ha
<Keybuk> (initramfs-tools depends on udev obv.)
<IntuitiveNipple> hmmm, so maybe initramfs-tools then? My main aim is to keep this on the radar in case others hit it, since it looks like a rare corner-case
<Keybuk> no, not initramfs-tools
<Keybuk> initramfs-tools is fine
<IntuitiveNipple> and the explanation isn't obvious
<Keybuk> it's a bug on whatever package *called* initramfs-tools from its postinst
<Keybuk> without depending on initramfs-tools
<IntuitiveNipple> I think i'll assign it to "Ubuntu" :0
<Keybuk> that would be unhelpful
<Keybuk> please don't do that
<Keybuk> instead grep /var/lib/dpkg/info/*.postinst and look for calls to update-initramfs
<Keybuk> and check each of the packages to make sure they have Depends: initramfs-tools
<Keybuk> if you find some which don't, file bugs on them
<IntuitiveNipple> I'll need the user to return to be able to do that/
<james_w> kees: thanks
<IntuitiveNipple> Keybuk: what source/script issues that "... not permitted...' text - I couldn't find it grep-ing the initrd or the udev package, but the user may not have reported it correctly
<kees> Keybuk: ntfs-3g
<kees> for i in $(grep update-initramfs *.{post,pre}{rm,inst} | cut -d: -f1 | perl -pe 's/\.(post|pre)(inst|rm)//' | sort -u); do apt-cache depends --recurse $i | grep Depends | grep -q initramfs-tools || echo $i; done
<slangasek> kees: pdfrenderer build-dep axed
 * kees hugs slangasek
<Keybuk> kees: can you fix it?
<kees> Keybuk: we're in freeze, but if slangasek says "yes"
<slangasek> yes
<jcole> fyi guys, installing flashplugin-nonfree on jaunty 64bit installs the 32bit plugin
<kees> jcole: by design
<LordKow> yes it does
<jcole> kees: why
<LordKow> adobe's 64-bit version is still in development and is unstable.
<kees> jcole: because the 64bit plugin is still in beta.
<jcole> kees: hmm, its always worked fine for me
<LordKow> but not everyone, and it's not something ubuntu can maintain/fix
<jcole> kees: is there a 64 bit package in ubuntu?
<jcole> kees: its not like other beta software doesnt exist in the repos ;)
<kees> jcole: there is no officially supported 64bit flash plugin.
<kees> in ubuntu
<kees> jcole: I wish it did, though :)
<kees> jcole: I've been running the 64bit plugin for a few months now, and it's rock-solid for me.
<LaserJock> bryce: I just had another lockup, this time on i386. I think maybe I'm going to go back to the -intel assumption
<jcole> kees: same here... who says its unstable? or does unstable=beta
<kees> jcole: the problem is that Adobe hasn't officially released it, so tracking it as it updates is harder.
<kees> Keybuk: just to be sure I understand, this is the only thing that needs changing, right?
<kees> -Depends: ${shlibs:Depends}
<kees> +Depends: ${shlibs:Depends}, initramfs-tools
<james_w> Ampelbein: is your python-launchpad-bugs package at 0.3.5?
<bryce> LaserJock: bug #?
<LaserJock> bryce: don't have one as of yet, I don't know what the heck to even write
<Keybuk> kees:
<Keybuk> kees: yup
<Keybuk> it's a simple dependency issue
<jcole> kees: i have problems with the 32 bit plugin... for example, when i close firefox, i will still hear sound and see a bunch of nspluginwrapper processes that i have to kill manually... ive never had that problem after switching to the 64bit version
<LaserJock> bryce: it just seems to lock up when I do too many things at once
<Keybuk> because of the move of udev from /etc/udev/rules.d to /lib/udev/rules.d it became important that things don't muck around with udevadm while udev is mid-air
<slangasek> kees: ok, how's odt2txt look to you for a MIR candidate?  (would like to know if it has a shot before writing up the MIR)
<kees> jcole: agreed.
<jcole> kees: if you ask me, the 32bit plugin is unstable
<Keybuk> ie. Depend on udev if you use it
<kees> jcole: I blame nspluginwrapper :)
<jcole> kees: it also locks up my sound card
<Keybuk> and as a result, Depend on initramfs-tools too
<kees> slangasek: one sec
<kees> jcole: that I blame on pulseaudio.  ;)
<jcole> kees: even though the 64bit version is "beta", its more stable than the 32bit version... so why not put a more stable version in the repos for 64 bit users?
<slangasek> because we're releasing in three weeks and are not going to rearrange the package based on one anecdotal report that the 64-bit version is more stable
<slangasek> sorry, two weeks
<kees> slangasek: ntfs-3g uploaded
<slangasek> ok, will snag it
<kees> jcole: asac is the best person to answer that; he has a plan for what will be happening in karmic
<kees> slangasek: odt2txt looks probably okay, though I'm cringing at the embedded zip processor...
<jcole> slangasek: understood, and another name could be ia64-flashplugin-nonfree... the reason of it not being in repos because its "beta" doesnt make sense to ,e when we have lots of other experimental software in the repos (ie: samba4)
<jcole> s/,e/me
<kees> (jcole: ia64 != x86_64)
<jcole> kees: heh, sorry
<jcole> kees: i didnt mean itanium
<kees> jcole: anyway, the issue is that no one stepped up to handle it in jaunty
<kees> jcole: asac has plans for doing it karmic though
<IntuitiveNipple> kees: looks like fuse-utils is affected too
<slangasek> right; samba4 is there because there's a Debian maintainer for it, whereas for flash we have a hard enough time getting one package maintained sensibly
<Stskeeps> http://s41.radikal.ru/i094/0904/90/4db739743759.jpg
<Stskeeps> err. sorry, ignore that
<Keybuk> pretty
<kees> IntuitiveNipple: I see initramfs-tools in the depends for fuse-utils
<Keybuk> kees: weird, I don't
<kees> Keybuk: fuse-utils -> udev -> initramfs-tools
<IntuitiveNipple> kees: hmmm, strange
<Keybuk> ah, good point
<Keybuk> yes, it's fine to depend on udev or initramfs-tools
<alex-weej_> is Hibernate supposed to use a normal file if no swap partition is enabled?
<Keybuk> alex-weej_: no
<kees> Keybuk: so you're saying a package must declare its own Depend on udev/initramfs-tools if it uses it, not just via a recursive depend?
<alex-weej_> Keybuk: ok, critical bug in jaunty then
<Keybuk> alex-weej_: which is critical?
<Keybuk> kees: recursive is fine
<Keybuk> kees: dpkg postinst ordering reasons, not esoteric
<kees> Keybuk: okay, then I think my cmdline above should find them all, and only ntfs-3g popped out
<slangasek> it's not "fine", it's brittle; it works as long as the recursive depends is there
<Keybuk> alex-weej_: are you saying that hibernate is creating a file for you?
<slangasek> and starts failing as soon as the thing you were relying on to do the depending for you no longer does
<alex-weej_> Keybuk: i accidentally hit Hibernate instead of Suspend in FUSA menu, something printed on the console "no swap partition enabled, try swapon -a" but the disk just churned away for > 10 minutes before i gave up and forced a reboot
<alex-weej_>  = lost data
<Keybuk> alex-weej_: that doesn't sound that Critical to me
<alex-weej_> data loss = critical
<Keybuk> it sounds like "don't do that then" with a low or medium bug
<Keybuk> then it's a critical bug that Ubuntu loses data if I hit my computer with a lump-hammer?
<Keybuk> *you* powered off your computer
<Keybuk> if you'd left it alone, it might have recovered
<Keybuk> and I'd be surprised if it lost data in the process, hibernate usually involves a sync
<kees> slangasek: if that's so, then these need something: watershed cryptsetup dmsetup kbd linux-ubuntu-modules-*
<slangasek> kees: those all invoke update-initramfs but don't depend on initramfs-tools?
<alex-weej_> Keybuk: what on EARTH could it be doing to my disk for 10 minutes? i was more worried that it was writing RAM to my data partitions than anything else
<kees> $ grep update-initramfs cryptsetup.*
<kees> cryptsetup.postinst:	if [ -x /usr/sbin/update-initramfs ]; then
<kees> cryptsetup.postinst:		update-initramfs -u
<kees> $ apt-cache show cryptsetup | grep Depends
<kees> Depends: libc6 (>= 2.8), libdevmapper1.02.1 (>= 2:1.02.20), libgcrypt11 (>= 1.4.0), libgpg-error0 (>= 1.4), libpopt0 (>= 1.14), libuuid1 (>= 1.05), dmsetup
<Keybuk> alex-weej_: it wouldn't have done that, it's more likely it was simply paging
<slangasek> linux-ubuntu-modules-* no longer exists
<alex-weej_> i don't have a swap partition
<alex-weej_> how could it page?
<IntuitiveNipple> It's bug #358654
<ubottu> Launchpad bug 358654 in ntfs-3g "udevadm trigger is not permitted while udev is unconfigured" [Undecided,New] https://launchpad.net/bugs/358654
<Keybuk> alex-weej_: it can still flush the cache and then have to reload everything file-backed from disk
<slangasek> kees: dmsetup doesn't appear to even recursively depend on initramfs-tools?
<alex-weej_> it doesn't take 10 minutes to bring my system up from cold
<kees> slangasek: odd, my lum is purged, but I still have dpkg info files for it.
<Keybuk> alex-weej_: by all means file a bug
<Keybuk> but please realise that it's *NOT* critical
<cody-somerville> Does amd64 use the generic kernel?
<Keybuk> cody-somerville: amd64 has its own kernel
<slangasek> it has its own kernel, which is called "-generic"
<kees> slangasek: ah! apt-cache depends is following Breaks
<slangasek> kees: right :)
<Keybuk> alex-weej_: you powered off your own machine - so at best, you could file a critical bug on yourself ;)
<cody-somerville> Keybuk, whats it called?
<cody-somerville> linux-amd64 doesn't seem to exist
<Keybuk> cody-somerville: generic iirc
<kees> cody-somerville: linux-generic
<slangasek> Keybuk: how long should one sit in front of a hung machine before it's reasonable to conclude it's not coming back, then?
<alex-weej_> Keybuk: by that logic any bug that causes a system hang but doesn't kill the power is not critical
<IntuitiveNipple> cody-somerville: it's a different arch; same package names
<Keybuk> alex-weej_: you said the disk was active
<Keybuk> doesn't sound like a hang, simply sounds like it was busy
<Keybuk> it's certainly a bug
<alex-weej_> Keybuk: and in a normal "hang" situation, it's difficult to tell whether anything is "active"
<alex-weej_> well the keyboard fails to respond
<kees> Keybuk, slangasek: list seems to include: dmsetup cryptsetup kbd watershed.  shall I shove each of those?
<IntuitiveNipple> kees: do you want to add them to the bug report, or shall I? They're currently in a comment
<kees> IntuitiveNipple: I can add them
<IntuitiveNipple> kees: ok
<IntuitiveNipple> Do we have a way to search the archive to identify other packages that we may not have installed that also need patching?
<kees> Keybuk: watershed only Recommends udev -- was there a reason to try to keep its Depends light?
<kees> Keybuk: and cryptsetup has initramfs-tools as a Suggests
<kees> slangasek: let me know what you think; I'm nervous to make these changes post-freeze for the less-obvious cases.
<slangasek> kees: Depends is the only way to enforce package configuration prior to the postinst being run, which is what we're trying to achieve; I think these are all "obvious" cases
<kees> slangasek: okay
<kees> slangasek: and you think I should even add it for those that Depend on udev already?
<slangasek> kees: I think those are not worth bothering with right now because the transitive dep does take care of it
<slangasek> but we should eventually fix those rather than relying on another package to guarantee us something we should be depending on directly
<dendrobates> slangasek: soren did not actually up load eucalyptus, he wanted approval first.  it is on chinstrap chinstrap:~soren/upload/  and in his ppa.
<dendrobates> slangasek: sorry for the bad information.
<slangasek> is it signed?
<dendrobates> slangasek: yes.
<slangasek> dendrobates: could you throw it at the queue for me? :)
<dendrobates> slangasek: yes.
<kees> slangasek: cryptsetup, devmapper, kbd, watershed all uploaded.
<dendrobates> slangasek: uploaded
<IntuitiveNipple> kees: looks like just in time another user is reporting it too
<IntuitiveNipple> and there were two others that came and went before we could investigate this afternoon, too
<geser> anyone here using (g)vim and bicyclerepair?
<gopogo> ubuntu jaunty is  not detecting windows during installation
<gopogo> why its nort detecting windwows during installation
<hyperair> gopogo: dunno, but this isn't the right place. head to #ubuntu.
<hyperair> gopogo: sorry i meant #ubuntu+1
<hyperair> you might like to file a bug too
<dtchen> hyperair: yes, i'll queue it, thanks
<hyperair> dtchen: alright thanks
<DBO> bryce, do you mind talking a bit of intel xorg with me?
<DBO> erm, actually I'll take this to #ubuntu-x
<ScottK> cprov: Would you please tell me why usplash no longer gets built on ia64?
<pwnguin> itanium?
<ScottK> Yep.
<cprov> ScottK, I don't know, but i can quickly check for you.
<ScottK> cprov: Thanks.
<kirkland> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/nut/+bug/357583
<ubottu> Ubuntu bug 357583 in nut "missing the last bit for powering off the system" [High,In progress]
<kirkland> slangasek: trivial debdiff attached, ubuntu-release subscribed
<cprov> ScottK: pas-ed -> %usplash: amd64 armel i386 lpia powerpc sparc
<slangasek> dendrobates: oh, in fact, eucalyptus was uploaded already
<dendrobates> slangasek: yeah, I misuderstood sorens message.
<slangasek> well, I'll just review the one of them. :)
<ScottK> cprov: Thanks.
<slangasek> kirkland: ack
<cprov> ScottK: usplash was recently enabled for lpia, last time it was allowed to build in ia64 was in hardy
<cprov> https://edge.launchpad.net/ubuntu/hardy/+source/usplash/0.5.19
<ScottK> cprov: We've got the same problem on ia64.
<kirkland> slangasek: ack = message received, or go ahead with upload?
<slangasek> kirkland: well, both; no reason to wait for review prior to uploading to the queue
<kirkland> slangasek: synack
<dtchen> hyperair: i'll just reopen 202089 and sub the relevant parties
<hyperair> dtchen: okay
<dtchen> slangasek: do you prefer that i subscribe ubuntu-main-sponsors for https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/202089/comments/127 ?
<ubottu> Ubuntu bug 202089 in pulseaudio "Pulseaudio is blocking normal sound after resume" [Low,Fix committed]
<slangasek> lool, persia: the VFP-optimized libs are still 'in progress'?
<lool> slangasek: 2 are in the canonical-arm-dev PPA, but gtk+ doesn't want to complete building
<persia> slangasek, I'm hoping to pass the other two to lool today for testing there as well.
<slangasek> which 2 are in the PPA right now?
<slangasek> more to the point, why are they not uploaded to jaunty?
<slangasek> dtchen: prefer relative to what?
<persia> slangasek, pango and gtk+, and because they might break something.
<dtchen> slangasek: simply finding a sponsor
<lool> slangasek: Actually gtk+ just built an hour ago
<slangasek> persia: but, er, of course they might break something; if they're going to be uploaded to jaunty at all, it should be sooner rather than later?
<slangasek> dtchen: ah; then I have no preference at all, unless you're trying to tag me to be a sponsor ;)
<persia> slangasek, OK.  I'll just seek sponsorship for the other two, rather than passing them through lool.
<lool> slangasek: I wanted to run them before pushing to the archive and perhaps breaking builds etc.
<slangasek> lool: if you're specifically concerned that the new packages are going to break arm itself, then that's fine, do what you need to in order to QA them - if it was a question of general breakage, though, better to get more eyeballs on the packages
<slangasek> but in any case, they need to get to the archive soon
<radix> slangasek: hi, I have (sad to say) some changes that I'd like to nominate for jaunty for landscape-client. they're bugfix-only. I've prepared everything: should I subscribe ubuntu-release to the bug?
<lool> slangasek: My plan was to upload them to PPA, run them, push to archive; cdimage/debian-cd kept me busy and gtk took longer to build than expected, so it's not done yet, sorry
<slangasek> radix: if they're bugfix-only, please get the package uploaded to jaunty and it can be reviewed from there in the unapproved queue
<radix> slangasek: oh, okay, so I'll get a regular main uploader to do that?
<slangasek> lool: sounds like things are on track from here, so no worries
<slangasek> radix: yes
<radix> sorry for the distraction. thanks very much
<Keybuk_> I like hard locks just before RC
<radix> are there any main sponsors that could take a look at bug #358744 for me?
<ubottu> Launchpad bug 358744 in landscape-client "Update to landscape-client 1.0.29, which is a bugfix-only release" [Undecided,New] https://launchpad.net/bugs/358744
<lool> slangasek: Pushed pango; gtk failed QA (missing one substitution, so I've pushed it again)
<slangasek> ok
#ubuntu-devel 2009-04-10
<ScottK> slangasek: Since usplash is no longer built on ia64, what would you think of removing all the binaries on ia64.  Then I can do a new kubuntu kubuntu-meta update and germinate won't try to put usplash on ia64?
<slangasek> ScottK: acceptable
<ScottK> slangasek: Do you want a bug for the usplach binary removal?
<ScottK> ch/sh
<slangasek> I don't think so
<ScottK> slangasek: OK.  Just let me know when it's done and I'll give it a couple of publisher cycles.
<slangasek> will do
<slangasek> ScottK: done
<ScottK> slangasek: Thanks.
<slangasek> ArneGoetje: translation full export for RC starts tomorrow(today), right?
<ArneGoetje> slangasek: Friday 22:00 UTC
<ArneGoetje> slangasek: export will take about 24 hours, the langpack prep another 5 hours or so.
<ice-nine> Is there a website / bug tracker listing current bugs in 9.04, and possibly status of bugs?  Reason being, I'd like to take a look at what requires fixing, and may be lend a helping hand....
<slangasek> ArneGoetje: ok
<slangasek> ice-nine: the list of bugs that are known targets for Ubuntu 9.04 are found at https://launchpad.net/ubuntu/jaunty/+bugs
<ice-nine> thanks slangasek.  I'll check out that url.  Is it possible for just anyone getting involved in committing bug fixes in common apps?
<slangasek> ice-nine: to commit fixes, you generally have to be a member of ubuntu-dev already; but we happily accept patches via Launchpad
<persia> ice-nine, You might find https://wiki.ubuntu.com/SponsorshipProcess useful
<ice-nine> Thanks.  I'll look into this.
<gopogo> ubuntu jaunty jackass is  not detecting windows during installation
<gopogo> it says no windows instaled
<Hobbsee> gopogo: and again, #ubuntu+1
<jdong> wow...
<gopogo> http://www.linuxloop.com/news/2009/04/08/why-virtualbox-should-be-included-in-ubuntu/
<persia> apt-cache show virtualbox-ose ?
<gopogo> Jaunty -> its saying connected to wifi netework but not pigging default gateway
<slangasek> gopogo: this is not a support channel.  I gather that you've already been directed to #ubuntu+1 several times already.
<YokoZar> A user submitted a bug report with this failure on Wine's --configure step: Error: contents of '/etc/mailcap.new' do not match what was written -- abort
<YokoZar> Could this possibly be the package's fault, or is something else going on here?
<gopogo> slangasek: no body is answering ubuntu +1
<Hobbsee> gopogo: then perhaps you shouldn't ask when it's the European & US night, and a public holiday in a lot of countries.
<gopogo> Ohk
<Hobbsee> channels are always quieter then ;)
<gopogo> is there any issue in wep in jaunty jackass ?
<gopogo> opps jackolope
<Hobbsee> ...but the bit about support not being here still applies, i'm afraid...
<infinity> gopogo: Rephrasing the question doesn't make it any less a support question.
<gopogo> WEP IS NOT WORKING LOOKS LIKE BUG
<gopogo> ;-)
<gopogo> its was working in 8.04
<infinity> gopogo: If you need answers RIGHT NOW, Canonical (among other companies) offer paid support.  Otherwise, please respect the (rather small set of) rules that our community support runs by, and ask in the proper channel, browse bugs to see if you find something similar, check forums, etc.
<gopogo> i cant pay connanical
<gopogo> i am a student
<infinity> gopogo: Then feel free to make use of the free support that the community offers.  Just keep in mind that said free support doesn't happen here.  Please.
<gopogo> oks
<gopogo> where should i report this bug
<YokoZar> ubuntu-bug (packagename) on a terminal is best
<slangasek> superm1: is /etc/apache2/sites-available/default-mythbuntu not a conffile?  you shouldn't need to rm -f it in the maintainer script, should you?
<superm1> slangasek, it's not a conffile, it's generated by the postinst
<slangasek> ok
<dschulz> hi
<dschulz> anyone bitten by #358915  "init crashed with SIGSEGV in event_poll()"   ?
<dschulz> running jaunty/amd64
<dschulz> i'm looking for clues on this
<slangasek> not that I'm aware of
<slangasek> I'm way impressed with apport now, though
<dschulz> slangasek: i thought the same when I first saw the bug report finished
<deepspring> I found a bug in Python 2.6 on Ubuntu 9.04... do I discuss it here?
<deepspring> http://ubuntuforums.org/showthread.php?p=7046504
<persia> deepspring, #ubuntu-bugs is a better place for discussion of bugs.
<deepspring> ok
<deepspring> gone
<bigon> hi, is reloading dbus after installing a .service file still necessairy in the postinst script?
<t325> Hello, is OpenSSL considered a part of Ubuntu? If it is, where are its linkable libraries installed?
<t325> (coming from a FreeBSD perspective -> don't know very well the "separation of powers" here)
<persia> t325, Do you have libssl-dev installed?  dpkg -L libssl-dev would show you the relevant files in this case.
<persia> But this isn't a support channel: for asking about aspects of packaging (like that), #ubutnu-motu is better.  For asking more general questions about Ubuntu, #ubuntu is better.
<t325> it wasn't installed, thanks!
<lool> slangasek: Bug #359049 > could you have a RM look and comment?  cjwatson mentionned consistency between subarches is desirable
<ubottu> Launchpad bug 359049 in linux "imx51 udeb hardcodes linux version in vmlinuz binary name" [Undecided,New] https://launchpad.net/bugs/359049
<lifeless> pop quiz; is there a C url library (and not 'libcurl, its an http library, not a  URL library)
<lifeless> I want something with urljoin, urlparse etc
<lifeless> clearly mozilla etc etc etc have to _do_ this, but I don't want to even think about linking in those monsters
<elmo> lifeless: I think the gnome folks have a library that does that, but I forget it's name
<lifeless> jamesh: ^
<elmo> lifeless: oh, maybe neon?
<elmo> lifeless: and libsoup is the gnome one
<lifeless> ah, blink, I remmeber that from tla; libneon changed api more often than... /me stops
<persia> And it also is an http library, rather than a URL/URI library.
<lifeless> yah
<lifeless> I don't mind that so much, but the focus leads to some odd apis
<elmo> persia: well, i assumed a http library would have URL/URI functions
<lifeless> elmo: libcurl has exactly one - 'escape' :P
<persia> elmo, It does: it's just that the form of the request disqualified something else for supporting http :)
<lifeless> persia: not strictly; libcurl I've already ruled out but neon may have what I want
<lifeless> I don't want to start a liburl project for the hell of it
 * persia finds annoying unlicensed public code that implements URL parsing functions
<lifeless> the ne_uri_* functions are what I need. Thanks elmo, I really should have remembered this
<lifeless> though dragging in a full http library to get it - fail
<lifeless> bah actually no
 * lifeless implements
<jamesh> lifeless: there is some basic URL parsing functions in glib, but they are really basic.
<tedg> jamesh: Is there more in gio?
<jamesh> tedg: perhaps.  I haven't explored it much.
<jamesh> maybe in the GFile interface
<lifeless> tedg: I saw that it uses dbus to access backends and cried while running
<tedg> I figured there'd have to be, but I haven't played with it either.
 * tedg thinks bazaar should use dbus for backed support.
<lifeless> tedg: heh. no
<lifeless> its not that I don't like DBus, I like it fine
<lifeless> but its IPC/RPC.
<lifeless> not everything needs to be hit with that particular hammer.
<tedg> lifeless: Yes, choosing the right tool for the job.
<tedg> lifeless: BTW, were you able to get the appropriately corrupt repository downloading it from LP?
<lifeless> now, if you have a core implementation that allows a backend to be 'I get stuff from dbus', then you can mix and match
<tedg> lifeless: Or should I start a tarball upload for the next couple days :)
<lifeless> tedg: To make sure I don't waste time debugging something differnet I really want a tarball of what you have on your disk
<tedg> lifeless: Okay, do you know if there is an attachment limit in LP?  Perhaps it should go on people.u.c
<lifeless> past midnight here, gnight
<lifeless> whereever is fine
<tedg> Cool, will do.  Thanks lifeless
<crik91> hi
<bluefoxicy> anyone know why trackerd constantly uses 100% CPU?
<bluefoxicy> actually you know what.
<bluefoxicy> I can find out why it uses so much CPU.
 * bluefoxicy bash script.
<jdong> bluefoxicy: for me right after the upgrade it required a complete rebuild of the DB which was pretty thrashy and spinny at times, after that initial chug things settled down for the most part....
<bluefoxicy> jdong this has been happening since I upgraded, 3 days before beta.
<bluefoxicy> and it's not playing with my hard disk a lot.
<bluefoxicy> % time     seconds  usecs/call     calls      function
<bluefoxicy> ------ ----------- ----------- --------- --------------------
<bluefoxicy>  60.34   80.164781         672    119149 g_main_context_iteration
<bluefoxicy>  24.21   32.168548         269    119150 g_main_context_pending
<jdong> odd; sounds like an indexer is getting stuck on some sort of file type then
<bluefoxicy> this is where most of the work is occurring but this is pretty useless
<jdong> lol that sounds like a main event loop or something
<bluefoxicy> yeah.
<jdong> hmm a profiler, then?
<bluefoxicy> what I need is an encapsulated graph
<bluefoxicy> like, g_main_context_iteration() takes 60%.  45% of its time is in function call to some_other_function(), which spend 80% of its time in yet_another_function()...
<bluefoxicy> and draw pretty, space-filling boxes
<jdong> lol is it technically feasible for strace to do that?
<bluefoxicy> (actually ltrace could be modified to do this)
<jdong> well it probably can
<bluefoxicy> yes, because it can say "You are in function X" "function call to Y... we were in function X.  X called Y."
<bluefoxicy> and trace the return path.
<jdong> well when A() waits 1s, calls B() which takes 1s, what does strace report as the time for A(), 1s or 2s?
<bluefoxicy> it's also feasible to output a trace to a log and write a parser to process it
<bluefoxicy> that's a good question
<bluefoxicy> as main() doesn't encapsulate the entire life of the program, and all times add up to 100%, I'd say it counts only the time literally spent in the function body and not in sub-calls
<sbeattie> strace is strictly syscalls, ltrace might do it, oprofile might be useful here as well.
<jdong> yeah it makes more sense from a "useful output" point of view if it does not double-count time in encapsulated calls
<bluefoxicy> well, regardless
<bluefoxicy> this is a lot of useless.
<cjwatson> robbiew,slangasek: 339898 is actually fixed, evand just forgot to close the bug
<cjwatson> I'll close it out
<robbiew> cjwatson: ah, ok
<robbiew> thnx
<davmor2> robbiew: I can confirm it is fixed :)
<robbiew> :D
<davmor2> robbiew: infact only outstanding obvious bug is bug 358519
<ubottu> Launchpad bug 358519 in ubiquity "Jaunty: Ubiquity-frontend-kde step 4 should display bars for partitioning" [Undecided,New] https://launchpad.net/bugs/358519
<robbiew> davmor2: ok, thanks
<cjwatson> I'll target that, but I'm not sure we have time to fix it for jaunty
<robbiew> agreed
<davmor2> cjwatson: weird thing is it was working and now isn't
<cjwatson> davmor2: in that case, it might help a bit if you could give a rough estimate of when it last worked
<cjwatson> but I'm not working until Tuesday, so it's a bit of a stretch
<cjwatson> (nor, I think, is Evan)
<davmor2> cjwatson: It didn't appear in beta so after that I think I check on Monday and it was in so maybe the week before
<davmor2> I really should learn to use grammar
<cjwatson> punctuation too
<davmor2> cjwatson: I am dyslexic it's hard enough to spell with out remembering other things :)
<cjwatson> hmm, so we're talking somewhere between 26th and 30th March?
<cjwatson> if you could put that in the bug that'd be good
<cjwatson> davmor2: ah, fair enough :)
<davmor2> cjwatson: will do
 * cjwatson eyes the enormous changelog for 1.12.0, uploaded on Mon 30th Mar
<cjwatson> sigh
<cjwatson> could lose a goat in there, no trouble
<davmor2> cjwatson: it would of happened before monday as it was on monday's cd
<davmor2> ah sorry 30th
<cjwatson> davmor2: but there were no changes between 26th and 30th
<davmor2> just saw mon and not the 30th
<cjwatson> I think 1.12.0 is a good guess for the version that introduced this, as that included a merge of a branch that made reasonably non-trivial changes to the KDE partitioning page
<cjwatson> shtylman: ^- don't suppose you could look into this, as it was your branch? see bug 358519
<ubottu> Launchpad bug 358519 in ubiquity "Jaunty: Ubiquity-frontend-kde step 4 should display bars for partitioning" [Undecided,New] https://launchpad.net/bugs/358519
<davmor2> cjwatson: can you set a status on the bug so it doesn't get missed,  because currently you can't change the partition size in side by side install.
<cjwatson> it's targeted, it won't get forgotten
<davmor2> ah cool :)
<ion_> All udevâs changelog entry says is âNew upstream release.  LP: #358013â. It would be interesting to see that bug report, since it appears to be closed. :-)
<jdong> haha magic words of doom :)
<davmor2> cjwatson: I'm going to grab a copy of beta just to confirm that it wasn't in then.  I'm pretty certain I would of logged it though. But that will at least mean that you can definitely rule out pre-beta
<shtylman> cjwatson: will do
<cjwatson> shtylman: thanks, give me a shout if/when you have a branch for us to merge
<jcole> didrocks: as you already may know, calendar still doesnt work in evolution-mapi and the Authentication button still crashes evo even after your latest patch...
<jcole> didrocks: i compiled the latest openchange, samba4 and evolution-mapi from svn and everything works :)
<didrocks> jcole: I tried to contact you
<didrocks> jcole: evolution-mapi is the last version, contrary to what you told previously
<jcole> didrocks: oh, im sorry, i get busy here at work sometimes
<didrocks> I followed upstream who told me to package the last version :)
<jcole> didrocks: you have an old libmapi0 in jaunty
<didrocks> jcole: yes, comming from openchange
<didrocks> not evolution-mapi :)
<jcole> didrocks: the libmapi0 in jaunty doesnt work with the calendar
<didrocks> jcole: as I said in the bug report, we are waiting for debian upstream packager who is working on the update and then sync
<didrocks> jcole: I already know that ^^
<jcole> didrocks: oh ok
<didrocks> jcole: that's why we wait for openchange ^^
<jcole> didrocks: do you think it will be ready before jaunty release?
<didrocks> jcole: if it's not packaged Tuesday, can you ping me please ?
<jcole> didrocks: you bet :)
<didrocks> jcole: Tuesday is the deadline seb128 and I convinced to wait for debian :)
<didrocks> (I didn't check today if they have the new version)
<jcole> didrocks: remind you, it takes the latest samba4 to compile the latest openchange.. the samba4 currently in jaunty wont work
<didrocks> jcole: do you have the version for the 2 packages?
<jcole> didrocks: thanks alot for all the hard work on this, its very appreciated
<didrocks> it will be quicker for me to check on debian ^^
<didrocks> jcole: I know it's a waited feature, try to have it for jaunty :)
<didrocks> s/waited/wanted
 * jcole looks
<jcole> didrocks: for openchange -> http://websvn.openchange.org/filedetails.php?repname=openchange&path=%2Ftrunk%2FChangeLog
<jcole> didrocks: yesterday was last update
<didrocks> jcole: ok, I just wondered about last official released
<jcole> didrocks: i think they are planning to have an official release very soon
 * jcole pings the evo devs
<didrocks> jcole: openchange and evolution dev are the same people?
<davmor2> cjwatson: definitely not happening in beta
<jcole> didrocks: the openchange devs hang out in #evolution on irc gnome
<didrocks> jcole: ok, and if you downgrade to last samba4 version, it doesn't work. Did you test it?
<didrocks> jcole: just give a look there
<jcole> didrocks: ill try to downgrade and see what happens
<didrocks> jcole: thanks a lot :)
 * didrocks hopes that jcole used /usr/local so that it will not be an headake :)
<jcole> didrocks: /usr/local/samba
<didrocks> jcole: perfect :)
<lamont> gah.  how in the hell do I get firefox to STOP stealing focus when it thinks it's a good idea?
<ion_> A window manager shouldnât permit such behavior.
<lamont> ion_: yeah, and then there is metacity.
<lamont> and compiz
<davmor2> lamont: use epiphany
<lamont> davmor2: and this will help me how?
<davmor2> firefox won't steal anything any more :D
<jcole> lamont: compiz has a "Utility" called "Windows Rules" that lets you manage annoyances like that... look in compiz settings manager and scroll to the bottom
<lamont> jcole: true.  OTOH, metacity has focus-policy == strict, which I'd really like to migrate into compiz but haven't managed to locate where, in the 10 minutes I've spent researching it over the last year
<jcole> lamont: looks like its called "No focus"
<lamont> srsly?
<lamont> because upstream was completely against == strict... which has been there since I, um, coaxed.  yeah lets use that word, seb128 into adding it for me
<jcole> lamont: http://wiki.compiz-fusion.org/WindowMatching#Window_Rules
<jcole> lamont: heh, looks like a firefox example there
<lamont> huh.  what do you know.  this machine actually does have an nVidia display
<lamont> 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0640 (rev a1)
<lamont> though it'd be nicer if it knew what it had
<jcole> lamont: System->Administration->Hardware Drivers
<jcole> lamont: ubuntu auto installs the nvidia driver :)
<lamont> yeah
<lamont> but only if you let it
<lamont> "no proprietary drivers are in use on this system"
<jcole> lamont: i think your modaliases might be out of date
<jcole> $ apt-cache show nvidia-180-modaliases | grep -E '^D|^ '
<jcole> Description: Modaliases for the NVIDIA binary X.Org driver
<jcole>  The modaliases provide a list of pci id's which makes it possible to
<jcole>  detect the model of a graphic card.
<lamont> W: Unable to locate package nvidia-180-modaliases
<lamont> so that'd be a "yes"
<lamont> though to be fair, the machine is stuck on hardy for other reasons
<jcole> lamont: install envy and get the latest then
<jcole> lamont: https://wiki.edubuntu.org/EnvyNG
<lamont> jcole: I'm still working on figuring out why I even care if I have the latest restricted driver
<lamont> since I'm, you know, not using it.
<ion_> keybuk: Since you wrote the udev changelog entry âNew upstream release.  LP: #358013â, perhaps you could consider making LP: #358013 open for the curious public (since the bug appears to be fixed). :-)
<jdstrand> slangasek: fyi-- uploaded new vm-builder to fix bug #342359 and bug #354849
<ubottu> Launchpad bug 342359 in vm-builder "[jaunty] ubuntu-vm-builder crashed with ioctl in create()" [Medium,Fix committed] https://launchpad.net/bugs/342359
<ubottu> Launchpad bug 354849 in vm-builder "vm-builder FTBFS under python2.6" [High,Fix committed] https://launchpad.net/bugs/354849
<calc> anyone know what happened to the coreutils info pages?
<calc> eg info cut just gives me the manpage that has no information and tells me to use info cut for more information
<calc> hmm info coreutils works but not info cut
 * calc was just made aware the dictionary issue was much bigger than he thought :\
<calc> every dictionary package has to be manually checked and updated if out of date for new OOo (gag)
 * calc kicks OOo hard
<calc> i thought it was a short list of ~ 5 packages i had already fixed from reading the debian bug report
<calc> i guess i know what i will be doing this weekend :\
<Milosz> hey people, I am packaging an application that I want to submit and I have a question regarding the control file
<Milosz> for libcurl, there exist 2 different -dev packages, one with openssl and one with gnutls
<Milosz> how can I specify in the control file that either is fine?
<geofft> put a | between them
<geofft> but it looks like both of those Provide: libcurl-dev
<slangasek> jdstrand: "to give the loopback a devices a chance to settle down" - why is this not a call to udevadm settle?
<jdstrand> slangasek: I was not aware of that command
<slangasek> ah; I don't have enough context from the diff to know if it's appropriate here, but the comment suggests it might be the Right Thing
<ScottK-palm> slangasek: I just read the release team meeting logs. AFAIK, all the Python 2.6 bugs from last week's list are still open.
<jdstrand> slangasek: this is a simple workaround the fact that kpartx sometimes dies. it doesn't seem to with the sleep(3), and the extra tries are just to give a sporting chance at it working
<jdstrand> slangasek: bottom line, this was a workaround that I was told to upload until soren works out the problem and the correct solution
<slangasek> hmm, ok
<Keybuk> settle sounds like the right workaround
<Keybuk> "wait for /dev to catch up"
<ScottK-palm> jdstrand: cemc found a new apparmor issue with clamav 0.95.1. I asked him to get a hold of you. It is probably the long pole in the tent for having 0.95.1 ready to upload.
<jdstrand> ScottK-palm: yeah, already talked to him
<ScottK-palm> jdstrand: Great. Thanks.
<Keybuk> he eventual plan, of course, is just to have these ioctl()s block in the kernel until /dev has caught up
<directhex> hm. /me prepares some notes on a topic he expects to hear mentioned at UDS
 * ScottK-palm remembers he didn't say he was going yet and goes off to write a mail ...
<jdstrand> Keybuk: your saying 'udevadm settle' is the correct thing to do for bug #342359?
<ubottu> Launchpad bug 342359 in vm-builder "[jaunty] ubuntu-vm-builder crashed with ioctl in create()" [Medium,Fix committed] https://launchpad.net/bugs/342359
<jdstrand> Keybuk: this is the relevant errorL:
<jdstrand> VMBuilder.exception.VMBuilderException: Process (['kpartx', '-d', '/tmp/vmbuilderID1u60/disk0.img']) returned 1. stdout: , stderr: device-mapper: remove ioctl failed: Device or resource busy
<jdstrand> ioctl: LOOP_CLR_FD: Device or resource busy
<Keybuk> I can't read the bug
<Keybuk> but if you get EBUSY, that sounds like you need a settle
<jdstrand> slangasek: honestly I'm not sure what to do wrt the bug. vm-builder is not my code and I don't know what soren wants to do long-term (ie, maybe he wants to run it on systems without udev... I have no idea)
<slangasek> there are no Ubuntu systems without udevz
<jdstrand> of course, but python-vm-builder is an upstream
<jdstrand> uhhh, vm-builder
<slangasek> fine, but the package should still be properly integrated in Ubuntu :)
<jdstrand> I am not arguing with that :)
<slangasek> anyway, the diff here is, I think, wrong, but it mostly addresses the symptom and shouldn't cause regressions (aside from slowing down the process), so I'll accept it
<slangasek> please follow up with soren about doing this with udevadm settle in the future, though
<jdstrand> ok
<jdstrand> btw, that is 3 seconds on an (at least) 5 minute long command
<jdstrand> but I'll follow up with him
<slangasek> ogra: if/when you're around, I think you should go ahead with an upload for bug #358762
<ubottu> Launchpad bug 358762 in initramfs-tools "update-initramfs trigger should run flash-kernel" [High,New] https://launchpad.net/bugs/358762
<Keybuk> DRAIIIIEEEEEE
<jdstrand> ScottK: fyi the klamav apparmor fix is in bug #359301
<ubottu> Launchpad bug 359301 in clamav "klamav can't download virus database on jaunty" [High,In progress] https://launchpad.net/bugs/359301
<jdstrand> ScottK: due t the pending 0.95.1 upload, I have assigned it to you
<aaronator_>  ./fwupdate.ini: line 1: syntax error near unexpected token `newline'
<aaronator_>  ./fwupdate.ini: line 1: `<?xml version="1.0" encoding="ISO-8859-1"?>'
<aaronator_> what is the error?
<slangasek> aaronator_: this isn't a support channel; please see #ubuntu
<aaronator_> thanks
<dcomxx> hi! is it possible to somehow add the current date to the ping result and also print the errors on timeouts or not reachables to a different text file ?
<savvas> dcomxx: date; ping www.example.com | grep -i 'string to match here'
<savvas> dcomxx: but you might want to ask that or future questions at #ubuntu :)
<dcomxx> what is string to match ? the error ?
<dcomxx> and i need it to print the date for every ping not only once
<dcomxx> or only for the errors .. so that i know when the error happened
<dcomxx> oh yea .. grep .. but how i know what error it will be ...
<dcomxx> can i write like this -> ping ip | grep 'error msg' | date > file.txt
<dcomxx> ?
#ubuntu-devel 2009-04-11
<ScottK> jdstrand: Sounds good.  Got it.
<gopogo> jaunty has same look and feel as the 10 ubuntu before it :-(
<gopogo> makes it boring
<Milosz> it's in the details
<directhex> gopogo, all three new themes are the same as Human?
<directhex> http://webupd8.blogspot.com/2009/03/new-themes-in-ubuntu-904-jaunty.html
<Milosz> also consistency is better than useless change (where something can still change and be consistent, but you don't want to reinvent the entire thing each time)
<gopogo> specially when mark said that OS X usability was the gold standard
<gopogo> i dont like the dark themes makes it difficult to read menu items
<gopogo> new notification system is really great congrats guys !
<jdong> yeah, it's pretty :)
<jdong> and I like the idea of the "notification center" too for messaging
<ScottK> jdong: How are you on not getting notified for up to a week about new updates?
<gopogo> is it inspired by Growl in Os X
<Milosz> It seems like an own invention to me and it's great
<gopogo> only thing I not found working was wep support in wifi
<jdong> gopogo: by "inspired" you mean a clone of, right? ;-)
<jdong> but yeah Growl is the first thing that came to mind.
<Milosz> Can't be praised enough that they did this, maybe you can argue whether the system itself as it turned out is good or not (I think it is, but just as not to take a stance here), but the fact they did it based on an own idea is fantastic
<jdong> ScottK: I don't like it; that's definitely going to get some reworking here locally....
<ScottK> jdong: Yes.  Fortunately it's just a gconf change.
<jdong> ScottK: I'm still disappointed that unlike Kubuntu, the GNOME stack still doesn't use packagekit for updating
<jdong> primarily I'm interested in PolicyKit
<jdong> being able to preauthorize users to do system updates
<ScottK> I'd prefer something more mature myself, but none of the KDE options were particularly appealing.
<ScottK> Neither Adept (the other choice) nor Kpackagekit complain about unverified packages which IMO makes them unsuitable for actual use, but I got outvoted.
<jdong> that's disappointing.
<jdong> I guess we NEED someone to launch a package poisoning attack before people get the point...
<ScottK> The KDE3 version of Adept did, so it's a significant regression in my opinion.
<ScottK> Agreed.
<jdong> considering that deb packages are instant root access, I would expect that to be considered a pretty serious problem
<Amaranth> Remember the wallpaper change?
<Amaranth> I thought people would get the message then
<Snova> Hmm?
<gopogo> i think altest the icons should be changed in default theme
<directhex> gopogo, are you volunteering to make replacement icons for everything in tango?
<gopogo> yeah why not
<Amaranth> Someone made this big list of repositories to get interesting unofficial packages and one of the guys included in the list didn't want his packages used by such people. He made a package that forced the GNOME wallpaper to be set to a skull and crossbones
<gopogo> nice ;-)
<ScottK> That's a warning about random third party repositories.
<ScottK> Cryptographic package verificatio wouldn't help that one.
<Amaranth> People apparently didn't realize a package for something like your panel could change other things on your system at the same time
<Amaranth> ScottK: Still, it's the general "packages from other places can harm you" thing
<ScottK> Sure.  The problem with the lack of cryptographic verification is packages you think are from places you trust can harm you.
 * Amaranth wonders wtf happened to his IO performance
<gopogo> this ico n set looks great -> http://www.gnome-look.org/content/preview.php?preview=2&id=32146&file1=32146-1.jpg&file2=32146-2.jpg&file3=32146-3.jpg&name=Glass+Icons+Theme
<Amaranth> eep, no way
<Amaranth> Human looks so much better
<Milosz> yeah I give it a -- too
<Milosz> the details are not right
<gopogo> 326990 users like ......its one of the most downloaded in gnome look :-;
<Milosz> well they have no taste :P
<Milosz> it's quite surprising btw how many people think mediocre stuff is good
<pwnguin> this the tyrrany of "no" ;)
<Milosz> hence you can not really let the majority take a decision when it's about style.. it sounds a little harsh but is IMO the reality
<Milosz> s/take/make/
<pwnguin> Milosz: so what you're saying is that style is making a decision that the majority of people will disagree with
<gopogo> there should be public voting about themes/ icon and users should be allowed to contribute ..........some kind competintion
<Milosz> but it works the other way around - when someone who's proven of himself to have an eye for style decides something for most people and they "just" use it because it's let's say the default, it will be better for them even on a usability level (when it comes to Human for example usability and style are both a concern pertaining to the same thing), even if they don't notice it consciously
<Milosz> pwnguin, not really ^
<gopogo> ~ competition
<Milosz> they will not disasgree if you give them something that is in the end effect better
<Milosz> but they are to say it carefully possibly unable to make that decision in the first place
<gopogo> who made human theme any way  some guy  in canonical ?
<Milosz> i.e. something better will have a better effect on them but they're not able to choose it for themselves (sometimes, with some things)
<Milosz> it's style dictatorship and it's generally good
<pwnguin> Milosz: and how do you reach this conclusion, that the general population cannot find good "optimimum" designs?
<Milosz> pwnguin, usability studies
<gopogo> well Human theme sucks .........its dull and boring ..........i rather use os x icons
<pwnguin> Milosz: like the Wichita State studies?
<gopogo> hahaha
<Milosz> it's superficially boring but it has properties that make it good for a default theme
<Milosz> pwnguin, I don't know these
<pwnguin> Milosz: they're the only ones i know of.
<Milosz> pwnguin, I worked at a company who devised its own studies
<Milosz> partially ordered by clients, partially in the FLOSS usability work we've been doing
<gopogo> what happened to that company
<Milosz> nothing, but I don't work there anymore
<gopogo> oks is it still there
<pwnguin> oh, i guess there's the nielsen group studies
<pwnguin> but they generally trust users
<gopogo> as developer you might to use VIM or editor , w3m for browsing web  mutt for checking email but general users may not
<Milosz> just got to be observant
<Milosz> and somewhat merciless
<Milosz> if a user does not accomplish the task, then the interface or design has failed
<calc> slangasek: ping, ispell-uk
<pwnguin> Milosz: if that's the objective metric, where's it published?
<gopogo> i am testing jaunty on my Dad .........who is Phd with 5 degrees ....Sr fellowship ....... who finds using checking his mail etc to be some kind of regrious routine  ......... he had tried 3 systems (windows xp -> moved bcos too many virus attacks ,  kde 3,59 and yesterday i installed jaunty for him)
<Milosz> pwnguin, what is an objective metric?
<pwnguin> Milosz: something used to settle disputes, mainly
<Milosz> no
<gopogo> he immediately asked me change ubuntu background ...wall paper etc
<Milosz> that was not what I meant to ask
<Milosz> I meant what in this context are you calling an "objective metric"?
<Milosz> and by this context I mean the current discussion
<pwnguin> broadly, usability
<pwnguin> specifically you mentioned accomplishing a task or not
<Milosz> Then I don't understand to what exactly that I've said you're referring
<Milosz> And it certainly doesn't make sense to me to ask where "it" is published because usability is being published everywher
<Milosz> where*
<pwnguin> "if a user does not accomplish the task, then the interface or  design has failed"
<Milosz> pwnguin, that's usability testing 1-0-1
<Milosz> that's nothing specific to any specific company, specific way of proceedings or specific type of test  (if anything, than that, but even that not really because it generally applies to all usability tests, just that the definition of 'failed' may differ from the usual meaning)
<pwnguin> im not under the impression that any testing guides decision making
<gopogo> yeah some kind Human Interface Guide line by apple
<Milosz> no, but you're understanding accomplishment in a task-focused sense, and by task you understand a process that you do from start to completion with a goal in mind
<gopogo> if dont have it why not follow apple's
<Milosz> but this is not how you read these terms in a usability testing context
<gopogo> whats test group ?
<Milosz> what a test group is?
<gopogo> whats test group for usability testing for ubuntu ?
<Amaranth> gopogo: We have a HIG
<Amaranth> Well, GNOME does
<gopogo> ubuntu HIG == Gnome HIG ?
<pwnguin> well, probably not
<pwnguin> firstly because KDE is in "ubuntu"
<ScottK> Xubuntu too
<pwnguin> yes, apologies
<gopogo> kde 4 ...ithink they got there own guidlines
<pwnguin> secondly because Canonical's been developing some new GNOME tech
<pwnguin> that might redo some of the guidelines if successful
<gopogo> like ?
<pwnguin> notifications
<gopogo> is different from kde 4 notifications
<Milosz> I worked on the KDE 4 HIG in that company incidentally
<Milosz> But I code myself using Gtk+ :)
<ScottK> Yes and the Canonical stuff is very unlikley to get accepted by KDE, so even if they do produce a KDE version, it will be Kubuntu specific.
<gopogo> i was always liked KDE ...its much much flexible and feature rich
<pwnguin> in fact, i dont see anything in the GNOME HID a all about notifications
<Amaranth> pwnguin: long standing bug
<pwnguin> all of which supports my statement that ubuntu's acting guidelines are not == GNOME's published HIG :)
 * ScottK suspects this would be a much better discussion for #ubuntu-offtopic
<gopogo> maybe a minor difference
<calc> gar i have to fix 7 dictionary source packages :\
<calc> at least that was all that was buggy out of ~ 50
<calc> hmm is requestsync broken?
<calc> hmm i just dropped the -d sid from it and it worked
<savvas> can you disable the packagekit error notification that another package manager is using apt?
<savvas> or is that deliberately shown?
<cjwatson> kirkland: you assigned bug 236640 to me for jaunty, but I'm not sure there's much more I can do with it at this point beyond what I've already uploaded ...
<ubottu> Launchpad bug 236640 in open-iscsi "iSCSI install fails under hardy" [High,In progress] https://launchpad.net/bugs/236640
<cjwatson> I guess I can ask for testing
<pochu> slangasek: hi, bug #354475 should be fixed before Jaunty IMHO, could you look at the debdiff I've attached and maybe approve it?
<ubottu> Launchpad bug 354475 in libproxy "Ubuntu patch breaks libproxy" [High,In progress] https://launchpad.net/bugs/354475
<jtisme> cjwatson, how would i go about downloading the  kde_ui.py code that R. Shtylman modified  for side by side fix, so i can test it
<cjwatson> jtholmes: http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/3210 - but if you don't know how to apply that by hand, just wait until we upload it and a daily build is available
<RicardoPerez> asac: Hi. I'm online, if you need me.
<asac> RicardoPerez: hi. could you try to add some debug printf's in gdm code to see the font it actually uses?
<RicardoPerez> asac: Mmhm... I can try it, but I'm not a developer, so I don't know if I'll be able to do that :)
<asac> RicardoPerez: do you know how to rebuild deb/ubuntu packages?
<RicardoPerez> asac: I'm using "dpkg-source -x" & "fakeroot debian/rules binary" in the past
<RicardoPerez> s/I'm using/I used/g
<asac> RicardoPerez: ok. wait a bit please
<RicardoPerez> asac: sure
<asac> RicardoPerez: hmm. seems i didnt put the debug output to the right code paths ... will check after dinner. if you are gone i will ask on the bug
<RicardoPerez> asac: right! see you soon, then :)
<RicardoPerez> asac: and thanks a lot
<RicardoPerez> asac: BTW, what is suppossed to be the right default font? Bitstream Vera or DejaVu?
<jtholmes> cjwatson, thanks i had to go away for a few hours, i think i know how to apply will try any way
<philsf> hi, I need help debugging jaunty's python packages. I can't open many GUI packages (jockey, apport, ubuntu-bug, software properties). I was thinking maybe I could reinstall some key packages, but don't know where to begin
<philsf> I was directed in #ubuntu+1 to ask here
<slangasek> calc: what about ispell-uk?
<siretart> yay! the intel 2.7 driver fixes resume in UXA on my 945GM hardware!
<ScottK> siretart: How about crashiness?
<siretart> ScottK: I've just installed it in /opt/somewhere and rebooted. uptime ~10 mins, but it already survived the first resume
<siretart> performance is way better than UXA in pure jaunty, but still not at EXA in intrepid. but its getting closer
<ScottK> siretart: I see.  Jaunty is pretty unuable for me as is (with 945GM), so it wouldn't take much for me to think we should update.
<ScottK> unuable/unusable
<siretart> well, planet-penguin-racer is still unplayable for me
<siretart> let's try another suspend/resume
<siretart> yay, survived again
<siretart> ScottK: btw, this upgrade required a newer libdrm as well
<siretart> so it is of course a nogo for jaunty, IMO
<ScottK> We did a new libdrm like a week ago ...
<siretart> well, jaunty has libdrm 2.4.5
<siretart> the intel 2.7 driver requires 2.4.6
<siretart> at some point, they seem to have botched with the version numbers, I think yesterday they released 2.4.9
<siretart> that's what I compiled for my laptop
<ScottK> For me the downside risk seems nil.  Once Jaunty is released and I don't need it for testing anymore, I'm dumping it as it is.
<siretart> for karmic or intrepid?
<ScottK> Probably Debian, but I'm not for sure yet.
<siretart> I see
<ScottK> Intrepid kernel is very problematic for me.
<jdong> siretart: does 945GM crash X on resume from suspend for you?
<siretart> jdong: it did in jaunty. it doesn't anymore with intel 2.7 for me
<jdong> ah; what does getting 2.7 consist of?
<jdong> (it's driving me nuts in Jaunty right now)
<siretart> getting libdrm 2.4.9 and intel sources, installing build-dependencies, installing it to /opt/somewhere, add ModulePath directive to your /etc/X11/xorg.conf
<siretart> luckily, I didn't need to touch any kernel modules..
<jdong> okay, I was primarily worried about kernel land; that sounds straightforward
<jdong> I'll have to put that on my TODO list
<siretart> for intel the kernel parts are in the kernel tree.
<siretart> for other drivers (radeon, etc) you need to build from the libdrm tree
<jdong> cool; I was just worried the jaunty versions wouldn't suffice
<calc> slangasek: er can it get approved?
<calc> slangasek: you asked me about the changes a week or two ago so i had documented them
<slangasek> calc: approved where?  I don't see a bug that ubuntu-release is subscribed to, nor an upload in the queue?
<calc> hmm i thought it had been
<calc> perhaps you unsubcribed it when you asked for more details?
<calc> it just needs sync not uploading
<slangasek> oh, you subscribed ubuntu-archive for the sync
<calc> ah so i need to subscribe ubuntu-release as well?
<slangasek> no
<slangasek> you need to subscribe ubuntu-release if you want an exception, but you said it doesn't need an exception
<calc> well it esentially isn't a big change even though it is a new upstream
<slangasek> hmm, did you actually look at the diff for those bits that aren't just data?
<calc> yes, they seemed to be fine
<slangasek> ok
<calc> the ooo xcu for example is just for building OOo extension with it
<slangasek> then yeah, it's fine to sync (though you should also set the bug back to 'confirmed' :)
<calc> ok
<calc> i also need syncs for espa-nol and ipolish (already filed bugs for them as well)
<calc> i found out just yesterday that the dictionary issue affected more packages than i thought, rene had just filed bugs on a few that he felt like doing
<calc> so last night i went through all the dictionary packages in ubuntu (afaik anyway) and found the ones affected, only 7 packages total, the other 4 i still need to fix in debian first then sync
<calc> i'll try to get those done monday morning
<calc> not too bad out of ~ 50 source though
<slangasek> I still think this should have been fixed in OOo.
<slangasek> having to provide exhaustive country maps in order to use a dictionary for a language is wrong
<calc> slangasek: agreed... however as upstream doesn't use system dictionaries at all it won't get fixed quickly, and i don't understand what is it doing since it is convoluted between their extensions and system support :\
<slangasek> heh
<calc> it might have a chance at getting fixed due to some other bugs in the dictionary support for multiple dictionaries of the same language
<calc> eg if you have a medical dictionary as an extension it currently completely overrides the system dictionary for the language
<calc> so the only correct spelled words are the medical dictionary ones :\
<calc> erm the only ones it thinks are correct
 * calc bbl, gone to easter stuff
<philsf>  hi, I need help debugging jaunty's python packages. I can't open many GUI packages (jockey, apport, ubuntu-bug, software properties). I hope I could reinstall or reconfigure some key packages, but don't know where to begin
<philsf> software-properties-gtk error http://paste.ubuntu.com/149125/
<philsf> jockey-gtk error http://paste.ubuntu.com/149126/
<philsf> apport ubuntu-bug error http://paste.ubuntu.com/149127/
 * Snova is looking at the software-properties-gtk one
<philsf> thanks
<Snova> And... I have no idea, I just try not to let people feel they're ignored. :)
<philsf> I have just uninstalled python2.4 and python2.5
<Snova> Looking at the package files, the files are there...
<philsf> Snova: this is the result of a bad upgrade, but I hope to save it without re-installing
<Snova> Oh dear... check that this file exists: /usr/share/pyshared/softwareproperties/gtk/SoftwarePropertiesGtk.py
<philsf> I don't believe they are really bugs in the packages, but maybe someone here understands what's going on, and has some spare time to help me
<Nafallo> considering it's not only a weekend, but also the easter holiday...
<philsf> Snova: it exists
<philsf> Nafallo: you're right, bad timing
<Snova> Open a Python interpreter and paste the output of this:
<Snova> import sys
<Snova> print sys.path
<philsf> ['', '/usr/lib/python2.6', '/usr/lib/python2.6/plat-linux2', '/usr/lib/python2.6/lib-tk', '/usr/lib/python2.6/lib-old', '/usr/lib/python2.6/lib-dynload', '/usr/lib/python2.6/dist-packages', '/usr/lib/python2.6/dist-packages/PIL', '/usr/lib/python2.6/dist-packages/gst-0.10', '/var/lib/python-support/python2.6', '/usr/lib/python2.6/dist-packages/gtk-2.0', '/var/lib/python-support/python2.6/gtk-2.0', '/usr/local/lib/python2.6/dist-packages']
<Snova> Not to mention I'm not running on Jaunty...
<philsf> Snova: http://paste.ubuntu.com/149136/ I just tried the following: force-remove python26 (and -minimal, and libpython26), and reinstall them
<philsf> ImportError: No module named shutil
<philsf> this should be simple, now, right :)
<Snova> Er, not so much.
<Snova> That's supposed to be included with the standard install... if even *that* won't work, there are problems.
<savvas> philsf: is it a desktop install or a server?
<philsf> savvas: desktop
<savvas> jaunty right?
<philsf> I can install python2.4 and 2.5 without a problem
<philsf> jaunty, yes
<savvas> philsf: can you send this to pastebin: apt-cache policy python python2.6 python2.6-minimal
<savvas> philsf: also this, sorry: apt-cache policy ubuntu-desktop
<philsf> savvas: http://paste.ubuntu.com/149138/
<savvas> ok try: sudo aptitude reinstall                 if not self.arguments['mode'] == 'file':dpkg-reconfigure
<savvas>                     self.usage("ERROR: -i should be used with -f <filename>")
<savvas>                 self.arguments['in-place'] = True
<savvas> oops
<savvas> wait :)
<Milosz> When will my sources show up in the PPA?
<Milosz> I thought I can at least see immediately that they were uploaded correctly
<savvas> Milosz: try #launchpad - I think it takes about 15 minutes
<philsf> maybe if I remove or purge all python packages that depend on py2.6, reinstall py2.6, then reinstall the deps from ubuntu-dekstop
<Milosz> ok that's good because I thought already something's wrong
<Milosz> and, switching to #launchpad, thanks
<savvas> philsf: try this: sudo aptitude reinstall python2.6; sudo dpkg-reconfigure python2.6
<savvas> philsf: anything?
<philsf> savvas: just a sec, I made things worse. trying to get back to the point where I had python-support installed :)
<savvas> ok :p
<philsf> savvas: will you be here in 30-60 min from now. I have to leave for now
<savvas> philsf: no idea, but try to reinstall everything if you know how to do it :)
<philsf> savvas: I will, thanks anyway
#ubuntu-devel 2009-04-12
<Milosz> What's Ipia?
<azeem> Milosz: why do you ask?
<Milosz> azeem, adding packages to my PPA
<azeem> do you mean LPIA?
<Milosz> LPIA
<Milosz> sorry I wasn't sure if it's an uppercase i or a lowercase L
<Milosz> I would google it but there is no information about it
<Milosz> anyway if this is not the right place to ask...
<jdong> Low Power Intel Architecture
<jdong> (i.e. Atom)
<Milosz> thanks jdong
<Milosz> ok it's Atom, I see
<jdong> although Atom is more or less x86 compatible, an Atom-aware compiler can generate code that executes more efficiently on the Atom
<Milosz> I know
<jdong> primarily due to in-order vs out of order execution; as I understand
<Milosz> I've only never heard the term LPIA before really
<jdong> interestingly, the patches for that may or may not be in our GCC :)
<Milosz> heh
<Milosz> I'd think you can optimize a great deal for Atom's in-order execution
<Milosz> I mean optimize the asm by knowing it's an Atom CPU it will run on
<jdong> I'd expect so, too
<geofft> #ubuntu-devel
<geofft> I don't suppose anyone online is familiar with AppArmor?
<geofft> specifically, how to deal with the possibility of /etc/krb5.conf being a symlink
<ScottK> geofft: https://wiki.ubuntu.com/DebuggingApparmor
<geofft> ScottK: Hm, that doesn't help me a whole lot. I can just add the target of the symlink to the apparmor profile
<geofft> but what I'm really trying to ask is, can I make AppArmor follow symlinks?
<ScottK> OK.  No idea about that.  jdstrand would be the one to ask.
<geofft> It looks like bug 132468 was kinda about this, and the profile just picked up the target of the symlink
<ubottu> Launchpad bug 132468 in apparmor "Nameservice abstraction should also include /var/run/resolvconf/resolv.conf" [Low,Fix released] https://launchpad.net/bugs/132468
<geofft> and so was 203898, and the program just stopped making symlinks. So maybe you can't do this?
<dtchen> apparmor does not, no.
<dtchen> it's one of the things i'm looking at for LTS
<geofft> so there's no existing functionality for saying "it's safe to follow /etc/krb5.conf being a symlink"
<geofft> any idea if upstream or ubuntu would be interested in a patch to add this support?
<kb9vqf> Any idea why a program would SIGSEGV with a fileno.c: No such file or directory.  ?
<kb9vqf> I can't find this fileno.c in any ubuntu packages; nearest I can tell it is part of the gnu c library
<geofft> is it reproducible, and if so, can you get a backtrace out of gdb or something?
<kb9vqf> geofft: very, and that is the GDB output when the crash occurs
<kb9vqf> geofft: well, actually, there are a couple more lines, see here https://bugs.launchpad.net/ubuntu/+source/xscreensaver/+bug/357556/comments/5
<ubottu> Error: This bug is private
<kb9vqf> Let's try that again.... https://bugs.launchpad.net/ubuntu/+source/xscreensaver/+bug/357556/comments/5
<ubottu> Ubuntu bug 357556 in xscreensaver "phosphor crashed with SIGSEGV in fileno_unlocked()" [Medium,New]
<kb9vqf> Trying to get an actual backtrace now (sorry, haven't used GDB before, still learning :-) )
<geofft> type "bt"
<geofft> (or "backtrace")
<geofft> I believe libc6-dbg will get you the debugging symbols to make GDB happy? Dunno if they'd help much
<kb9vqf> geofft: OK, just waiting for it to crash again.  It usually crashes between 5 and 45 minutes after starting
<kb9vqf> geofft: Not sure if you're still there, but it finally crashed again on two machines, and I uploaded the backtraces here: https://bugs.launchpad.net/ubuntu/+source/xscreensaver/+bug/357556/comments/7
<ubottu> Ubuntu bug 357556 in xscreensaver "phosphor crashed with SIGSEGV in fileno_unlocked()" [Medium,New]
<kb9vqf> geofft: It's not much more information to go on, unfortunately
<kb9vqf> geofft: The funny thing is GDB claimed it found all the needed debugging symbols when I attached to the running phosphor process, but there are still unresolved functions
<geofft> kb9vqf: The unresolved ones look like invalid addresses. From that backtrace, I can't tell anything...
<kb9vqf> geofft: me either :/
<kb9vqf> geofft: there are only four instances of fileno() in the program
<kb9vqf> geofft: I am wondering if the problem is more severe, and possibly lurking somewhere in glibc or the X server, as phosphor is not the only screensaver to crash after a certain amount of time
<kb9vqf> geofft: I have had almost all of the opengl xsavers I have tried crash in this manner (dunno yet if all are crashing on fileno_unlocked or not)
<jpds> Latest upload of adobe-flashplugin to partner breaks flash everywhere.
<jpds> (in jaunty).
<cjwatson> kwwii_: any luck on the ubiquity changes?
 * maxb blinks at the ftbfs report and wonders why linux-ports and linux-ports-meta tried to build on amd64
<cjwatson> maxb: they aren't in P-a-s
<cjwatson> therefore they try to build and immediately fail
<maxb> worth adding, now there is an Ubuntu-specific P-a-s ?
<cjwatson> although we have the capability now, I'd explicitly prefer to keep them in sync (and so would the Debian maintainer)
<cjwatson> you could file a bug on buildd.debian.org asking for Ubuntu-specific entries, since there's no linux-ports package in Debian
<maxb> right
<cjwatson> err, on bugs.debian.org, but with "Package: buildd.debian.org", I mean
 * calc is getting tornadoes for easter :\
<hyperair> tornadoes?
<hyperair> as in those swirly windy things?
<calc> yea tornado watch for my area all day i think
<calc> really bad thunderstorms, etc
<hyperair> ouch
<hyperair> =(
<calc> 60mph wind, ~ 2cm hail, etc
<hyperair> sounds very bad
<calc> its luckily not hailing here at least at the moment, but the wind sounds pretty high
<calc> the hail was spotted around 10km away i think
<calc> but the storm is moving this way, heh
<kees> slangasek: so, what's the policy for packages that have ftbfs since Nov?  do we leave them that way since fixing them would essentially break feature freeze?
<IntuitiveNipple> I've updated the orbit2 package to create a -dbg symbol package. Currently it has always been a direct sync from Debian with no Ubuntu changes. I've added an Ubuntu version suffix but I'm not sure where/what to set the debian/control Maintainer to since it currently points to the Debian maintainer. Do we have a team that it should be set to?
<cjwatson> IntuitiveNipple: why does it need a -dbg package, as opposed to the -dbgsym package on ddebs.ubuntu.com? Does it need a separate build pass with different compiler options?
<cjwatson> IntuitiveNipple: the general answer to your question is that running 'update-maintainer' from ubuntu-dev-tools will sort it out for you, but ...
<IntuitiveNipple> Hmmm... we have two debug symbol systems?
<cjwatson> -dbg is for (a) packages that already had it in Debian, where it isn't worth diverging to remove it (b) cases where it needs a separate build pass
<cjwatson> -dbgsym handles cases where the debug symbols can be extracted entirely automatically
<IntuitiveNipple> Oh! that explains alot! I am debugging a complex AT-SPI > java > eclipse issue and almost all other packages had -dbg packages so I *assumed* in view of bug #29294 that it was 'missing'
<ubottu> Launchpad bug 29294 in orbit2 "please provide a liborbit2-dbg debug package" [Wishlist,Confirmed] https://launchpad.net/bugs/29294
<IntuitiveNipple> This is what happens when constantly testing new installs... this one didn't have the ddebs repo added to apt sources !
<cjwatson> it's possible that 29294 predates ddebs
<cjwatson> or at least predates them being widely known and used
<cjwatson> I'll close that bug with an explanation
<IntuitiveNipple> Yes, although alter comments fooled me too... from late last year. I'll update with a comment to where they are :D
<IntuitiveNipple> i'm already doing it... you want me to stop?
<cjwatson> I'm happy to do it since I have authoritative and helpful links to hand
<IntuitiveNipple> Thanks
<IntuitiveNipple> I was referring to pitti's email of Novmeber 2007 on devel-discuss announcing it
<cjwatson> there's a wiki page with up-to-date information and help
<IntuitiveNipple> Good... Google didn't find that for me so far
<cjwatson> DebuggingProgramCrash
<IntuitiveNipple> I looked at all the other Debug* pages except that one earlier!
<IntuitiveNipple> could have saved myself 1/2 hour
<cjwatson> bug updated
<IntuitiveNipple> I only got onto that because I've finalyl pinned down why the Gnome at-spi/gail/atk-bridge causes problems for eclipse (got a decent backtrace from one of the threads) and wanted to see if there was more debug info for gdb... turns out there isn't after all :s
<lfaraone> Hi, it seems that bug 235105 isn't properly fixed for me; I'm running stock jaunty and my harddisk spins down on *AC* as well as on batt often. (a about once every 5 minutes or so) Should I comment on the bug?
<ubottu> Launchpad bug 235105 in pm-utils "scripts in /etc/pm/power.d should be called after resuming/ thawing" [Undecided,New] https://launchpad.net/bugs/235105
<lfaraone> * bug 59695
<ubottu> Launchpad bug 59695 in pm-utils "High frequency of load/unload cycles on some hard disks may shorten lifetime" [Critical,Fix committed] https://launchpad.net/bugs/59695
<BUGabundo> guud eater afternoon
<BUGabundo> is pitti back?
<BUGabundo> is it known that apport / ubuntu-bug won't work with proxy?
<lfaraone> BUGabundo: https://bugs.edge.launchpad.net/ubuntu/+source/python2.5/+bug/94130
<ubottu> Ubuntu bug 94130 in apport "HTTPS over proxy fails" [Undecided,Confirmed]
<BUGabundo> lfaraone: thanks
<slangasek> kees: eh, we generally want them fixed, since otherwise they're hardly security-supportable... which package are you looking at?
<kb9vqf> I'm having some major problems with my Jaunty KDE3.5 torrent tracker...which tracker does Ubuntu use?
<kb9vqf> Ah, never mind, found it on the main tracker page.  BitTornado.
 * kb9vqf feels kinda stupid
<kees> slangasek: linux86. i can upload the fix shortly.
<kwwii_> cjwatson: almost done, I had the family at my house this afternoon/evening...I plan on finishing things up tomorrow, is that ok?
<kwwii_> cjwatson: I still haven't recieved a green light from mark, but I am doing all this hoping that it will come...I know he wants a change and everyone has responded well to the new version
<cjwatson> kwwii_: I'll be away all day tomorrow, unfortunately, so I hope Evan is around ...
<ash3> #ubuntu-wisconsin
<kwwii_> cjwatson: I've snet him an email. I'll just have to see how this plays out. Mark might request changes anyway
<ion_> What changes are you talking about, btw?
<kwwii_> ion_: are you talking to me? (with my best DeNiro accent)
<ion_> kwwii: Well, youâre the only one here.
<kwwii_> ion_: http://sinecera.de/time_zones.png
<kwwii_> and soon I am gone as well :p
<ion_> Neat
<ni|> hello, how do i get a package in the "partner/web" category in the ubuntu repositories
<ni|> i'm a programmer for a IM archival company in massachusetts
<ni|> and I've crafted a debian file for each system {hardy,intrepid,jaunty}
<Chipzz> ni|: I don't think that's the point of the partner repo
<Chipzz> I think the most logical thing for you to do would be to set up your own repo
<Chipzz> for further assistance, use #ubuntu-motu though
<ni|> Chipzz: thanks
<cjwatson> kwwii_: I think I'm going to have to go ahead and upload ubiquity; we need to get the other changes tested in a definite timeframe
<cjwatson> kwwii_: we'll just have to consider the map changes separately
#ubuntu-devel 2010-04-12
<micahg> Amaranth: is compiz required for proper notify-osd now?
<Amaranth> micahg: A compositor of some kind is needed for the fade part, yes
<Amaranth> Always has been
<micahg> Amaranth: ok, but that shouldn't make duplicates happen, right?
<Amaranth> duplicates?
<micahg> not duplicates, multiples on either side
<Amaranth> Oh, I don't know
<micahg> bug 559109
<ubottu> Launchpad bug 559109 in notify-osd "Two notification bubbles at the same time" [Undecided,New] https://launchpad.net/bugs/559109
<Amaranth> compiz doesn't have any effect on notify-osd
<Amaranth> and macslow is the author of notify-osd, not me :)
<micahg> k, someone mentioned compiz fixed it, so I figured I'd ask you Amaranth, thanks
<Amaranth> Well, he probably only tests with compiz so it's possible notify-osd is taking advantage of something we handle differently compared to metacity
<ArneGoetje> slangasek: the final LanguagePackTranslationDeadline is set to 22nd. (Thu). I will ask the Launchpad Translation team for the final export on 23rd. (Fri), which will then be available for langpack-o-matic on 24th (Sat.)building all the langpacks will take around 2 days, depending on how busy the buildds are... So, by Monday, 26th we should have everything ready. Is that too late for you? BTW: since last week, every language-pack update is a full updat
<RAOF> So, why is libglib2.0 failing to build on sparc, with the buildd log ending with âno really, you do not get to build glib2.0 here.â?
<RAOF> http://launchpadlibrarian.net/43173338/buildlog_ubuntu-lucid-sparc.glib2.0_2.24.0-0ubuntu1_FAILEDTOBUILD.txt.gz
<slangasek> ArneGoetje: hi, you got cut off at "full update"
<slangasek> ArneGoetje: 23rd your time, or UTC? :)
<ScottK> RAOF: Because that build was taking down the buildds.
<lifeless> RAOF: manual policy override :> aka lamontd
<ScottK> RAOF: glib2.0 and sparc are not on speaking terms at the moment.
<slangasek> rpc.lamontd, I think
<RAOF> Ok.  That archive skew causes anything which b-ds on mono-devel to fail to build :(
<ScottK> Yep.
<lifeless> on all arches ?
<RAOF> No, just on sparc.
<RAOF> We could probably work around it by explicitly giving mono-devel an option dependency on an older libglib on sparc; then it'd be installable and should work.
<ScottK> Sparc: Now that hppa can't be complete crap anymore, someone has to do it.
<lifeless> RAOF: given that this cropped up early last week, I'd do it.
<lifeless> that or fix the glib issue on sparc
<RAOF> We have a sparc porter box, don't we?
<ScottK> Where we == Canonical, yes.
<persia> There's probably one in the DC: I know that at least one Sparc user has been reporting that the lucid kernel still can't boot.
<ArneGoetje> slangasek: So, we won't have any delta  updates until final release.
<persia> NCommander: Any chance you got your sparc booting to help RAOF look at libglib?
<ArneGoetje> slangasek: 23rd UTC
<ArneGoetje> slangasek: so that the UTC-n timezoners have a chance to get updates in until 22nd their time.
<persia> Does anyone happen to know the name of the script that checks packageset permissions in LP, or what access level is required to set permissions?
<JontheEchidna> persia: edit_acl.py from ubuntu-archive-tools?
<persia> That's likely it.  Thanks.
<persia> RIght.  I seem to be good at crashing that :)  Time to find another class of solution :)
<slangasek> ArneGoetje: well, final ISO mastering should start on Monday so that we have the full three days for validation; I think having the deadline prior to end-of-day 22nd would benefit us
<slangasek> ArneGoetje: and of course since this is an LTS, there will be future point releases that can incorporate any translations that miss .0
<ArneGoetje> slangasek: sure... so, pull the deadline in front? Like 20th (Tue) and export the translations on 21st, like it would do by cron job?
<ArneGoetje> dpm: ^^
<dpm> good morning and thanks for the heads up, ArneGoetje. I think by "having the deadline prior to end-of-day 22nd" slangasek meant having the deadline a bit earlier during the day (didn't you?). I believe otherwise translators would not be happy with the idea of moving it to the 20th at this point and loosing 2 full days of time for translation
<ArneGoetje> dpm: should we just say we export the translations at 22:00 UTC on 22nd?
<slangasek> ArneGoetje, dpm: yes, I just mean having it a little earlier in the day on the 22nd
<dpm> ArneGoetje, that sounds good to me, if 22:00 UTC is early enough for the release team. slangasek, what do you think the best time would be?
<slangasek> ArneGoetje: is 22:00 early enough that it's available to langpack-o-matic before Saturday?
<ArneGoetje> slangasek: well, the export takes 10 hours to finish, lp-o-matic build takes about 2 hours, the buildds chew on them for about 2 days (700+ packages)
 * slangasek nods
<slangasek> and there's a manual upload step that you have to do between lp-o-matic building the source, and the buildds starting to chew?
<ArneGoetje> slangasek: yes, including review the logs if anything failed...
<ArneGoetje> slangasek: so, if you want to have them before Saturday (UTC, I assume), then exporting them on Wednesday would be necessary, I guess.
<slangasek> 22nd @22:00UTC export, + 12h, +1h padding for log review, takes us to 18:00 your time on Friday, right?
<ArneGoetje> slangasek: 19:00
<slangasek> ok
<slangasek> so a few hours earlier is better?
<slangasek> I don't want to move the deadline back any further than we have to, but I'd like us to have the langpack build start before the weekend (UTC)
<slangasek> especially since I'll be in the air that weekend
<ArneGoetje> slangasek: the time for uploading them at 19:00 is OK for me, I can arrange that.
<slangasek> ok
<dholbach> good morning
<RAOF> Good morning!
<dholbach> RAOF: HAPPY BIRTHDAY! :-)
<RAOF> dholbach: Thanks!
<micahg> RAOF: dholbach +1 :)
<pitti> Good morning
<pitti> apw: WI tracker> no, you still have to do that manually; that's bug 509806
<ubottu> Launchpad bug 509806 in launchpad-work-items-tracker "Alllow postponing to a different milestone" [Wishlist,Triaged] https://launchpad.net/bugs/509806
<tkamppeter> pitti, hi
<pitti> hi tkamppeter; how's the LF summit?
<tkamppeter> pitti, starts on Wednesday, flight tomorrow at noon time
<tkamppeter> pitti, there are people still complaining that CUPS does not start on boot, on bug 554172
<ubottu> Launchpad bug 554172 in cups "cups not starting at boot" [Undecided,New] https://launchpad.net/bugs/554172
<tkamppeter> pitti, was this not an ifupdown problem (do not know bug number) which is already fixed?
<pitti> tkamppeter: no idea; this bug does not have any data, such as whether the rc2.d/S50cups link exists, etc.
<pitti> tkamppeter: /var/log/boot.log might be useful as well
<tkamppeter> pitti, thanks, I asked the user.
<al-maisan> A laptop of mine (running lucid) gets stuck after a post-boot file system check, I don't see any hard disk activity (the hard disk LED is not lighting up) and typing 'C' will not abort the fsck; I have to hold the power button to turn off the machine.
<al-maisan> A part of the drive is encrypted FWIW
<al-maisan> Is this a known issue?
<mdke> how does one get the ability to accept bug nominations for particular releases?
<tkamppeter> pitti, found the bug, it was 497299.
<mdke> the ubuntu-docs team would quite like the ability to do this so that we can target bugs for SRUs, but at the moment I seem to be the only person able to do it
<tkamppeter> bug 497299
<ubottu> Launchpad bug 497299 in ifupdown "upstart not starting init-scripts (event net-device-up IFACE=lo missing)" [High,Fix committed] https://launchpad.net/bugs/497299
<tkamppeter> pitti, by the way, a user has confirmed on April 1 that the Karmic SRU in this bug works for him, so you can push it to -updates on your next SRU run.
<slangasek> al-maisan: have seen bug reports describing this, but they're as-yet-untriaged - can you try a few things for me?
<al-maisan> slangasek: yes, of course.
<pitti> tkamppeter: can he please say so in that bug?
<slangasek> al-maisan: 1) are the dots under the logo still scrolling, or have they stopped?
<slangasek> (tells us whether plymouth is still running)
<pitti> tkamppeter: oh, there is a confirmation already
<al-maisan> slangasek: I believe they have stopped.
<slangasek> al-maisan: ok - Alt+F1 doesn't switch VTs?
<al-maisan> slangasek: nope, I tried that.
<slangasek> al-maisan: Alt+SysRq+K?
<al-maisan> didn't try that
<al-maisan> how can I mark a partition to be fsck'ed?
<al-maisan> I'd like to do that and reboot in order to try Alt+SysRq+K
<tkamppeter> pitti, I changed the tag to verification-done now, so that this bug should get into your SRU queue.
<pitti> tkamppeter: yes, so did I
 * al-maisan looks for a 'SysRq' key on his keyboard
<slangasek> al-maisan: you can set the mount count manually on the filesystem with tune2fs -C <device>; or to force a rootfs check, touch /forcefsck
<slangasek> SysRq is the printscreen key
<al-maisan> slangasek: right
<mvo> al-maisan: probably not helpful for your use-case, but the recovery mode has a filesystemcheck option too
<al-maisan> mvo: just did a "sudo tune2fs -l /dev/mapper/ul-h"
<al-maisan> rebooting..
<tkamppeter> pitti, do you know what goes wrong at bug 559676?
<ubottu> Launchpad bug 559676 in hplip "package hplip-data 3.10.2-1ubuntu5 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/559676
<tkamppeter> pitti, it gives the error: update-python-modules: error: hplip-data.private is not a recognized python-support module.
<tkamppeter> pitti, issued by update-python-modules
<pitti> tkamppeter: perhaps it's trying to install that into a public module dir?
<tkamppeter> pitti, hplip-date contains a file /usr/share/python-support/hplip-data.private
<mdke> alternatively, is it possible to do a query that shows bugs in a particular package that have been nominated for a release?
<tkamppeter> pitti, /usr/share/python-support/hplip-data.private contains a list of all.py files in /usr/share/hplip/ and subdirectories, but I am not Python expert enough to know whether this is really needed and for what.
<pitti> this isn't really python itself; it's python-support, which is a Debian-ish way of packaging them; I'm afraid I can only refer you to http://www.debian.org/doc/packaging-manuals/python-policy/ at this point, to check whether there's something wrong with the packging
<slangasek> mdke: https://bugs.launchpad.net/ubuntu/lucid/+nominations?field.searchtext=foo?  may have false-positives since it's not keyed on the package field, but is close
<slangasek> mdke: in theory, accepting nominations is tied to upload privs; anywhere you find this to not be true is a bug AIUI
<slangasek> mdke: oh, you want it for other people that aren't uploaders, though - hmm
<mdke> slangasek: right
<mdke> slangasek: that url is helpful though, thanks
<nigelb> didrocks, got a minute about bug 542091?
<ubottu> Launchpad bug 542091 in cheese "Add apport hook for cheese" [Wishlist,Triaged] https://launchpad.net/bugs/542091
<didrocks> nigelb: sure, did you post the latest version of the patch?
<nigelb> didrocks, I wanted to run by you the latest version of the hook before I made a debdiff
<didrocks> nigelb: ok :)
<nigelb> http://pastebin.com/DMpQ0KDA
<nigelb> is the prompt too confusing?
<nigelb> "If Cheese is running, please close Cheese. Cheese will run again in debug mode. Please wait till you see a video or an error message before closing cheese"
<lifeless> nigelb: how can the user tell if cheese is running ?
<nigelb> lifeless, well, I suppose user could see it in the taskbar?
<didrocks> nigelb: right, if it crashes, not sure it's still displayed
<nigelb> didrocks, if cheese crashes, doesn't apport deal with it differently?
<nigelb> i.e., not via the hook
<al-maisan> slangasek: so, here's the data you asked for: 1 - the dots under the logo are not scrolling, 2 - Alt-F1 does not switch VTs, 3 - Alt+SysRq+K gets me out of there and the boot process continues successfully.
<didrocks> nigelb: it launches the hook when it crashesâ¦ but that's still better than "killall" which was present in the previous version. I guess we can go on with it for the moment. I'll just change "please close Cheese" by "please close it"
<al-maisan> slangasek: after pressing Alt+SysRq+K I see a black screen for a second, there was an error message related to getpwuid or something similar bit I do not know whether it's pertinent to the fsck problem
<nigelb> didrocks, ok.  will get you a debdiff in a few :)
<slangasek> al-maisan: do you have an external monitor plugged in?
<didrocks> nigelb: sweet :)
<al-maisan> slangasek: sorry, I don't.
<slangasek> al-maisan: darn, was hoping this was bug #533135 again - that would've made things simpler
<ubottu> Launchpad bug 533135 in plymouth "System fails to boot with plymouth installed (nouveau driver with >1 display)" [Medium,Triaged] https://launchpad.net/bugs/533135
<slangasek> al-maisan: ok, next question is whether it's reproducible when booting without 'splash'
<al-maisan> slangasek: I will try that.
<agateau> Hi,
<agateau> I am having a grub problem with Lucid:
<agateau> On boot I get this message: http://pastey.net/135171
<agateau> Pressing a key just prints the message again :/
<agateau> Any idea?
<cjwatson> agateau: wow, I've never seen that before.  could you mail that to bug-grub@gnu.org?
<agateau> cjwatson: will do
<al-maisan> slangasek: booting w/o splash makes no difference i.e. the file system is checked and the boot-strapping is stuck
<cjwatson> agateau: what system is this?
<agateau> cjwatson: googling for the message I found people having a similar issue with memtest86 on asus bios (the machine is an asus), do you think it could be related?
<slangasek> al-maisan: excellent, that makes it much easier to debug ;-)  Try booting without quiet, without splash, and with --verbose
<cjwatson> yes, I just found the same thing
<cjwatson> it probably is indeed related
<agateau> it's a brand new asus laptop p81ij
<al-maisan> slangasek: will do.
<agateau> cjwatson: I assume you found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549429
<ubottu> Debian bug 549429 in memtest86+ "error: too small lower memory (0x99100 > 0x96000)" [Important,Open]
<cjwatson> yes
<agateau> cjwatson: I am not familiar with memtest86, do you think I can try the binaries they suggest in this report?
<cjwatson> you aren't trying to boot memtest86+, are you?
<agateau> cjwatson: no
<cjwatson> then those binaries won't help
<agateau> ok
<agateau> I tried to reach grub interactive mode, but could not
<agateau> wait, just got it
<agateau> mmm
<agateau> There are only Memory test entries
<agateau> I miss a kernel here!
<cjwatson> hah
 * agateau boots on a usb key
<cjwatson> so you *are* booting memtest86+
<cjwatson> what language are you using?
<slangasek> bryceh: there's something very strange with the xserver-xorg-video-displaylink package in the NEW queue; it seems to contain two copies of the upstream source, one in a subdir
<agateau> french
<agateau> some kind of locale issue with the boot loader?
<al-maisan> slangasek: hmm .. ok .. I have a console full of log statements, is there anything in particular you'd like to know?
<agateau> don't know if it's important, but I actually translated the last line of the message I pasted from french to english, the rest was in english
<nigelb> So, um, will all the bugs in the archive queue be processed before release?  Any way I can expedite a bug in that queue?
<al-maisan> slangasek: btw, the last line reads: "plymouth-log state changed from pre-start to spawned"
<slangasek> al-maisan: the last four or five lines are probably the place to start; maybe easier to take a photo?
<cjwatson> agateau: there was a particular bug I was thinking of, but doesn't seem to be that.  nevertheless, I'd like to see your /boot/grub/grub.cfg
<al-maisan> slangasek: let me do that .. just a minute
<slangasek> al-maisan: ah, that job only runs once the 'filesystem' event is emitted
<slangasek> so that tells us something
<agateau> cjwatson: sure
<agateau> just a minute
<al-maisan> aha
<slangasek> tsk, plymouth-log.conf calls a plymouth command not documented in plymouth --help
<agateau> cjwatson: http://pastey.net/135172
<agateau> mmm the BEGIN END 10_linux does not sound very good
<agateau> mmm, I have no linux-image-generic installed :/
<agateau> cjwatson: ^ no wonder it does not boot
<agateau> cjwatson: I think that's my mystake
<cjwatson> agateau: that would do it, yes ...
<agateau> cjwatson: I moved the package selection from old laptop to new laptop with a combination of dpkg --get-selections, dpkg --clear-selections, dpkg --set-selections
<agateau> cjwatson: and I guess I somehow uninstalled the kernel :/
<tkamppeter> pitti, the HPLIP problem I mentioned earlier I cannot reproduce, probably the user has a broken file somewhere, but I have a more important problem, bug 530327.
<ubottu> Launchpad bug 530327 in hplip "hplip has dependency on libcups2-dev (for cups-config cmd)" [High,New] https://launchpad.net/bugs/530327
<tkamppeter> pitti, should we move cups-config to a non-dev package or what should we do?
<slangasek> bryceh: it pains me to see a package that was successfully using dh 7 switch to xsfbs :(
<mvo> cjwatson: hi, I have a odd issue with ssh, I have a running ssh connection on the client but the command that was run has exited and on the server I see no sshd running anymore for the connection. the client still does not timeout (I use --batch-mode, this is the auto-ugprade tester). any idea? do I miss another config option for this ?
<al-maisan> slangasek: here's the screen shot: https://devpad.canonical.com/~muharem/IMG_4284.JPG
<cjwatson> mvo: is there still a port-forward open or something?  running the client with -vvv might help
<cjwatson> ssh should automatically exit when all its channels are closed, without the need for any options
<slangasek> al-maisan: very odd; I don't see anything here that tells me why it stopped where it did
<al-maisan> hmm..
<mvo> cjwatson: thanks! I run with -vvv now (will take a bit, it only hangs at the end of the lts-mythbuntu upgrade test.
<slangasek> al-maisan: I guess it's most likely to be a bug in plymouth, then
<slangasek> al-maisan: since plymouth is responsible for console redirection at boot time
<al-maisan> aha
<al-maisan> slangasek: yeah .. I was scrolling up a bit and did not see any error message that would stand out either
<pitti> tkamppeter: we could theoretically move it to the cups binary package, but why does hplip even need that? we do not need any runtime detection in hplip, we know where cups lives..
<al-maisan> slangasek: so, after pressing Alt+SysRq+K I see one more error message, it reads: "General error mounting filesystems."
<al-maisan> "A maintenance shell will now be started."
<al-maisan> "Control-D will terminate this shell and reboot the system"
<tkamppeter> pitti, only the debug tool hp-check needs it, for normal printing with HPLIP cups-config is not needed.
<al-maisan> slangasek: the boot continues and gdm comes up, after "sudo /etc/init.d/gdm stop" I can do Ctrl+Alt+F7 and the maintenance shell still seems to be there
<pitti> tkamppeter: ah, do we ship this in hplip itself?
<tkamppeter> pitti, yes
<tkamppeter> pitti, should it go into hplip-dbg?
<pitti> tkamppeter: not sure how useful it is; but if you don't normally need it, you might move it to there, and have -dbg depend on libcups-dev perhaps?
<hunger> Since beta2 I had * the netbook progra chooser thing break, then gdm started to freeze the system und now the whole thing stopped booting:-(
<slangasek> al-maisan: ok, so mountall was still running when you hit Alt+SysRq+K, probably waiting for the processing of the 'filesystem' signal to finish; that gives us a small clue, but I still don't know where the bug lies.  Can you file a bug on the plymouth package with this information?  It's best if Keybuk can take a look at it
<al-maisan> slangasek: will do.
<tseliot> mvo: any ideas about what's going on in bug #559587 ? xorg-driver-fglrx is now a transitional package and we do this in the preinst of fglrx: pastebin.ubuntu.com/413010/
<ubottu> Launchpad bug 559587 in fglrx-installer "package fglrx (not installed) failed to install/upgrade: trying to overwrite '/etc/ati/signature', which is also in package xorg-driver-fglrx 2:8.721-0ubuntu8" [High,Triaged] https://launchpad.net/bugs/559587
<slangasek> tseliot: yes, you have files in /etc/ that aren't marked as conffiles...
<slangasek> tseliot: you should ship these files under /usr/share instead since they aren't really conffiles, declare Conflicts: on the old version of xorg-driver-fglrx that contained them, and in the fglrx preinst, make either the directory, or the individual files, symlinks to the real files in /usr/share
<chrisccoulson> slangasek - for bug 469752 - that's being backported upstream btw
<ubottu> Launchpad bug 469752 in firefox "firefox,3.5/3.6 startup-notification bug" [Unknown,Fix released] https://launchpad.net/bugs/469752
<chrisccoulson> so i will defer that to lucid-updates
<slangasek> chrisccoulson: ok
<al-maisan> slangasek: bug #561312
<ubottu> Launchpad bug 561312 in plymouth "fcsk hangs up the boot-strapping process" [Undecided,New] https://launchpad.net/bugs/561312
<tseliot> slangasek: ah, so this is why they're not removed. Wouldn't a "Conflicts" defeat the purpose of transitional packages?
<slangasek> tseliot: Conflicts on the *old version*; you don't want to conflict with the transitional package, only with the previous versions of the package that weren't transitional
<slangasek> so Conflicts: xorg-driver-fglrx (<< 2:8.721-0ubuntu1), I guess?
<tseliot> slangasek: ok, it makes sense now. Another thing: I think /etc/ati/amdpcsdb.default is supposed to be modified by amd's control panel
<tseliot> which is why we make a backup of configuration files
<dholbach> can everybody please have a look at http://qa.ubuntu.com/reports/sponsoring/ and see what should go in as last minute fixes?
<slangasek> tseliot: but despite making a backup, you always put the new one from the package in place, with the comment in the script that it's required to be updated when the driver is updated?
<tseliot> slangasek: yes that is correct. I think superm1 implemented this
<slangasek> tseliot: well, I do think that if we're always going to ignore changes from the control panel, then we shouldn't put them in /etc/ at all since that gives people the wrong impression
<slangasek> tseliot: (and makes the package itself confusing and complicated in ways it doesn't need to be)
<tseliot> slangasek: in the light of what I know about this, I agree
<directhex> as long as it causes fewer drops into "Low graphics mode", which tend to make a grumpy directhex
<tseliot> slangasek: I'll send an email to superm1 and to upstream just to be sure that what we do is correct
<tseliot> directhex: oh, but that's a feature :-P
<directhex> tseliot, a driver which supports my new radeon is a feature. x not starting due to missing amdpcsdb.default is a bug
<tseliot> directhex: a driver which makes you grumpy is a feature :-P
<tseliot> jokes aside, I'll fix this soon
<slangasek> zul: your latest seed change to server-ship wants to drop these five packages out of main.  If they're supposed to be in main (as implied by server-lucid-canonical-application-support), they need to be seeded *somewhere*; currently they aren't
<mdz> lool, I would be happy to test your bogofilter package
<ogra> sigh, why do we only get big packages on the armel buildds today ...
<lool> mdz: it's in my PPA
<lool> mdz: thanks for your help
<Tm_T> ogra: someone tries to make you cry
<lool> mdz: the main code change is to fix parsing of the first line of the body
<ogra> Tm_T, definately ... gcc, kdeedu, kdebase and tons of haskell
<Tm_T> ogra: muhahahaha
<bdrung> can a member of ubuntu-release review bug #516249?
<ubottu> Launchpad bug 516249 in hdparm "FFe: Please merge hdparm 9.27-2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/516249
<simon-o> Hi, what's the most helpful thing to do for Lucid this late in the cycle? Fix FTBFS?
<doko__> it's at least useful
<simon-o> doko__: any better idea?
<cjwatson> tackle unassigned bugs on https://bugs.launchpad.net/ubuntu/lucid/+bugs
<simon-o> cjwatson: thanks, I'll have a look
<bdrung> simon-o: are
<bdrung> usp
<bdrung> ignore that
<bdrung> james_w: you are doing the archive-admin work today?
<james_w> yes
<bdrung> james_w: can you release pwdhash from the NEW queue?
<bdrung> (let it in)
<james_w> in a bit
<bdrung> thanks
<mvo> superm1: http://people.canonical.com/~mvo/automatic-upgrade-testing/current/ has mythbuntu profiles now  and the first bug is discovered (#560691) (just fyi)
<Daviey> mvo: that is great, thanks
<mvo> yw
<ScottK> mvo: Did you see the bug I filed on update-manager about the package removal list being incorrect?  Now that I look for that, it seems quite common.  Am I misunderstanding what that list is supposed to cover?
<bdrung> didrocks: can you merge vala from debian?
<mdz> any archive admins around?
<didrocks> bdrung: sure, I only uploaded today after having it handy for a week (but I wasn't fancy to upload that before the week-end). Didn't noticed that debian had it uploaded. I add this on my TODO, thanks!
<ScottK> mdz: If it's something doable from the web U/I, yes.
<mdz> ScottK, I need an API operation
<mdz> or rather, I may
<bdrung> didrocks: btw, you broke abraca ;)
<mdz> ScottK, does that count or not? or should I bug someone else?
<ScottK> mdz: I'm not sure.
<mdz> cjwatson, I may need somebody with privileges to run lp-remove-package.py per DWC
<mdz> james_w, pitti, Keybuk ^^
<cjwatson> mdz: here
<didrocks> bdrung: I don't see it as a rdep of vala or valac? (in any case, upstream should ship .c file during build)
<cjwatson> mdz: what's the crisis?
<ogra> can some archive admin bump casper to something very high ?
 * ogra wants to chatch the one free armel buildd
<seb128> ogra: no, you need buildds admin for build scores
<pitti> mdz: DWC?
<ogra> *catch
<mdz> cjwatson, kernel 2.6.32-20.29 contains a serious-looking regression, #-kernel is responding, IS has made a chmod quick fix
<cjwatson> ogra: it's already building
<ogra> seb128, err, indeed
<ogra> cjohnston, oh
<pitti> mdz: I can help out with archive bits if necessary
<mdz> DWC calls for the package to be removed next, though I'm open to discussion as to whether that's appropriate in this case
<ogra> grmbl, cjwatson indeed
<bdrung> didrocks: it FTBFS. upstream will release a vala 0.8 compatible version soon.
<persia> What's the bug number?  I've been running that kernel for a while now.
<mdz> cjwatson, it's only lucid
<mdz> ("only")
<ogra> cjwatson, it refreshed on the webpage the second you said that :)
<pitti> -20 runs fine here..
<ogra> thanks anyway
<mdz> persia, I'm in mitigation mode right now
<cjwatson> mdz: do you have a bug reference?
<cjwatson> oh
<cjwatson> persia asked that
<didrocks> bdrung: sweet. But can you convince them to ship .c generated files in their release too? (it's just an additional line in autotools if they need help)
<bdrung> didrocks: why?
<ScottK> mdz: I can't do that one.
<mdz> the issue is believed to affect ThinkPads
<mdz> (a few, some, all - I don't know)
<cjwatson> mdz: so, is it more serious to render lucid entirely uninstallable for everyone, or to permit ThinkPad users to continue installing this kernel?
<cjwatson> pitti: DealingWithCrisis
<didrocks> bdrung: it avoids building thing needed to build (like the fact we don't run autoreconf during build). It makes life for package maintainers easier and more and more upstream are adopting this for vala
<mdz> cjwatson, already made the call (based on input from apw) that we should block further distribution of the packages
<mdz> #ubuntu-kernel is still isolating the root cause from the looks of it
<cjwatson> the one awkward bit about removing it is that it will mean the kernel-overrides script won't work next time, and we'll have to reapply kernel overrides by hand, which is actually non-trivial
<bdrung> didrocks: abraca uses scons
<dholbach> 561151
<cjwatson> or at least potentially non-trivial - I haven't validated recently that the kernel packages precisely match the overrides in the archive
<dholbach> persia: ^
<pitti> cjwatson: shouldn't be that bad, though; these days, binaries are all in main, so it's easy with the +queue page
<cjwatson> pitti: section/priority mismatches can cause problems
<cjwatson> I don't recommend that people use +queue for the kernel at the moment
<didrocks> bdrung: ah ok, doesn't know very well scons, maybe no vala integration for autogenerating .c file during release so :(
<cjwatson> unless you've personally validated that all the section/priority fields match
<mdz> cjwatson, is it a lesser evil to leave the packages 403?
<cjwatson> mind you, kernel-overrides doesn't actually seem to do anything with priority, which is the significant one for d-i, so if this is a problem then it's already been broken
<cjwatson> mdz: I think pitti's right and they can be removed with minimal knock-on effects
<pitti> -19 is already gone, so -20 is our only kernel right now
<cjwatson> though I'm not wild about the precedent here; kernel regressions are far from unheard of and if we removed them all the time it would be very hard to get anything done
<pitti> cjwatson: the main difference that I see is that with removing the next version would need to be NEWed again, while with 403 it should just work
<cjwatson> still, as you say, you've already agreed to 403
<pitti> but 403 seems good enough to me, TBH
<cjwatson> pitti,mdz: I'm available by SMS all today for NEW processing
<cjwatson> let's not flood mvo with a new batch of update-manager bugs due to the 403 at this point
<persia> Just as a note, the kernels have been published for three days according to LP: do we expect most active lucid testers have not yet upgraded?
<cjwatson> bad enough that I'm going to be flooded with installer bugs
<mdz> cjwatson, thanks
<cjwatson> mdz: is this certain to be fixed today?
<cjwatson> because once I lp-remove-package this, I can't easily undo it
<mdz> cjwatson, we have a known good state to roll back to, so I'm optimistic, yes
<cjwatson> specifically which binary package(s) have been 403ed?
<mdz> if we don't find a good fix, we should be able to back out the change at least
<mdz> cjwatson,
<mdz> linux-image-2.6.32-20-generic_2.6.32-20.29_amd64.deb (29.5 MiB)
<mdz>   linux-image-2.6.32-20-preempt_2.6.32-20.29_amd64.deb (29.9 MiB)
<mdz>   linux-image-2.6.32-20-server_2.6.32-20.29_amd64.deb (29.5 MiB)
<mdz>   linux-image-2.6.32-20-386_2.6.32-20.29_i386.deb (29.5 MiB)
<mdz>   linux-image-2.6.32-20-generic_2.6.32-20.29_i386.deb (29.5 MiB)
<mdz>   linux-image-2.6.32-20-generic-pae_2.6.32-20.29_i386.deb (29.6 MiB)
<pitti> cjwatson: well, upgrades will be broken either way :)
<pitti> (wrt. update-manager bug reports)
<elmo> so the packages are actually 404 right
<elmo> + now
<elmo> as in, we chmod-ed on cocoplum and rm-ed everywhere else
<elmo> I don't know if 404 is any better or worse than 403 from an update-manager POV
<cjwatson> mdz: this is bug 561151?
<ubottu> Launchpad bug 561151 in linux "reproducible oops at startup on thinkpad x61s in acpi_ex_read_data_from_field" [High,In progress] https://launchpad.net/bugs/561151
<cjwatson> oh yes, dholbach said
<mdz> cjwatson, yes, that's the master bug now
<cjwatson> damnit, I can't remove just single binaries
<cjwatson> wait, what's going on, I should be able to
<pitti> -b ?
<cjwatson> never mind, I was saying -a amd64 -a i386 when I didn't need to
<cjwatson> mdz: http://paste.ubuntu.com/413135/
<mvo> ScottK: I saw it, I check it out today, I'm working on u-m currently anyway
<mvo> ScottK: (and thanks :)
<ScottK> mvo: OK.  Let me know if you need anything.
<mdz> cjwatson, I've notified NG that you've removed the packages, in case he needs to do any further cleanup
<mdz> s/NG/Ng/
<cjwatson> mdz: at some point we should post-mortem whether this was really necessary - it's a trade-off between users affected by a bug, and developers unable to do certain types of work just before final freeze
<mdz> cjwatson, feel free to make a note on the incident report for the retrospective
<mdz> cjwatson, robbiew is relieving me wrt the kernel incident in progress
<cjwatson> mdz: note> done
<bdrung> sistpoty|work: can you have a look at bug #516249, too?
<ubottu> Launchpad bug 516249 in hdparm "FFe: Please merge hdparm 9.27-2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/516249
<sistpoty|work> bdrung: I must admit that I'd prefer someone else handling hdparm than me
<bdrung> sistpoty|work: can you ping someone?
<bdrung> i would like to have a yes or no soon.
<sistpoty|work> pitti: ^^
<bdrung> sistpoty|work: another thing: audacious 2.3
<pitti> sistpoty|work: by default, "no"
<pitti> given how much trouble it sometimes causes, I wouldn't change critical pieces like this at this point
<sistpoty|work> bdrung: got a FFe for audacious filed already? (the list is just too long :/)
<bdrung> sistpoty|work: no. i have prapared a package based on debian's git repo and uploaded into my ppa. it's tested by some people. i have to convert the package to debian merges and then it's ready for the FFe.
<sistpoty|work> bdrung: straight from what I recall about audacious: shouldn't be really a problem imho, as long as you make sure it's well tested
<sistpoty|work> bdrung: just read your comment about autotools-dev, I'll mark that won't fix then, ok?
<bdrung> sistpoty|work: k
<bdrung> pitti: the newer hdparm version is required by SSD owners (-> TRIM)
<pitti> in which way?
<pitti> bdrung: does hdparm issue those commands by itself?
<bdrung> pitti: the wiper script that cleans the SSD required the new hdparm version
<mdz> cjwatson, <apw> robbiew, mdz, i have three reliable confirmations that a single patch revert will resolve the thinkpad issues
<pitti> but we have tested lucid for 5 months on SSDs without it
<pitti> bdrung: I really want to avoid yet another issue like bug 515023
<ubottu> Launchpad bug 515023 in hdparm "ATA pass-through commands preventing external HDD to be mounted" [High,Confirmed] https://launchpad.net/bugs/515023
<bdrung> pitti: the wiper script uses  --trim-sector-ranges-stdin
<pitti> bdrung: how is the wiper script called?
<bdrung> wiper /dev/sdXY
<bdrung> and wiper /dev/sdXY --commit for actual doing the clean
<pitti> bdrung: I mean, is it cron'ed, or otherwise integrated?
<bdrung> pitti: manually run by the user
<superm1> tseliot, slangasek I think we'll have to defer to what AMD says is the best POR for that file to prevent these upgrade problems
<pitti> bdrung: but who will actually do that?
<bdrung> the best solution would be that the kernel supports TRIM
<pitti> bdrung: we might provide a newer version in lucid-backports for the adventurous folks perhaps?
<pitti> but few, if any users will even know about stuff like that
<pitti> (not that I do..)
 * pitti reads http://en.wikipedia.org/wiki/TRIM
<tseliot> superm1: yes, let's see what they say
<bdrung> pitti: http://ubuntuforums.org/showthread.php?t=1272893 http://www.ocztechnologyforum.com/forum/showthread.php?60882-wiper.sh-discussion-thread-%28Linux-TRIM-tool%29
<pitti> bdrung: to me this sounds utterly scary, nothign like we should rush into lucid without ever having tested it on a large scale
<pitti> other opinions appreciated, though
<pitti> but a bug in this could potentially wipe your entire disk
<bdrung> pitti: in the prepared package, the wiper script will not be installed
<m_anish> Hi I am facing a peculiar problem.. I have just installed ubuntu-lucid-beta2 and installed the sugar-emulator-0.88 package (there is some bug in karmic that doesn't allow sugar-emulator/xephyr to work)... anyways sugar-emulator is now working in lucid but it seems to have screwed up my touchpad settings. When I left-click instead of performing the normal left-click operation it turns the normal pointer to a hand... I have to use CTRL+Left click t
<m_anish> o make left click work. Any ideas how to fix this?
<ScottK> m_anish: Help for Lucid is in #ubuntu+1
<m_anish> ScottK, Ok thanks!
<apw> cjwatson, robbiew, unless anyone objects I will upload this kernel fix now
<robbiew> apw: fine by me...you should probably update bug 526354...so those affected by that issue know
<ubottu> Launchpad bug 526354 in linux "[Dell Studio 1537] temperature sensors and fan stop working following suspend/resume" [High,Fix released] https://launchpad.net/bugs/526354
<apw> robbiew, done
<robbiew> thnx
<apw> cjwatson, if i upload a non-ABI bumper will things be ok following the deletion?
<cjwatson> please do it
<cjwatson> it'll probably require binary NEW but that's OK
<cjwatson> (SMS me if necessary)
<apw> cjwatson, ack
 * mdz wonders why the git-core package contains multiple copies of some fairly chunky (1M) binaries
<cjwatson> mdz: aren't those hardlinks?
<mdz> cjwatson, not on my system
<cjwatson> 1283400 -rwxr-xr-x 103 root root 984888 2010-02-18 07:36 git
<cjwatson> 1283400 -rwxr-xr-x 103 root root 984888 2010-02-18 07:36 git-add
<cjwatson> for example
<mdz> -rwxr-xr-x 1 root root 984888 2010-02-18 07:36 /usr/bin/git
<mdz> -rwxr-xr-x 1 root root 984888 2010-02-18 07:36 /usr/bin/git-receive-pack
<mdz> -rwxr-xr-x 1 root root 984888 2010-02-18 07:36 /usr/bin/git-upload-archive
<cjwatson> those are hardlinks here, according to ls -li
<Chipzz> mdz: have you stat'ed them?
<cjwatson> 1283400 -rwxr-xr-x 103 root root 984888 2010-02-18 07:36 git-receive-pack
<mdz> Chipzz, they have different inode numbers
<cjwatson> 1283400 -rwxr-xr-x 103 root root 984888 2010-02-18 07:36 git-upload-archive
<cjwatson> same inode number
<mdz> they were put there by dpkg on an ext3 filesystem
<mdz> I looked because I was curious why the .deb was so big
<cjwatson> the .deb is only 5.5MB
<mdz> cjwatson, which seemed like a lot to me for what it is
<cjwatson> oh, you mean the ones in /usr/bin, sorry
<cjwatson> those aren't hardlinks, indeed, I was looking in /usr/lib/git-core/
<cjwatson> seems like a straightforward bug
<seb128> does anybody know how is the default dictionnary language set?
<seb128> empathy and evolution default to english on a lucid beta2 french install there with french listed as available too
<nigelb> asac, you were looking for problems with ssl on firefox?
<nigelb> asac, someone in #launchpad has trouble with logging in.  could be part of the problem
<persia> hyperair: So I'm thinking about a compcache spec for UDS: is there a writeup of the requirements LTSP has related to compcache?
<hyperair> persia: er.. my experiences with compcache have been bad. did you highlight the wrong person?
<persia> Yes, actually.  Sorry :)
<hyperair> =)
<hyperair> persia: are you sure compcache is stable enough, though? my experiences with compcache forced me to reboot to reclaim the lost memory compcache took
<persia> It's being used currently.  It was also merged upstream.  I think we'd benefit from a review of it for maverick.
<asac> nigelb: all updates should be fine
<asac> e.g. run dist-upgarde
<nigelb> asac, oh ok.  I've asked him to try with another browser for now.
<asac> nigelb: tell him to upgrade everything
<asac> thats really important
<nigelb> asac, will do
<souffledev> hi guys. i am having segfaults - ff 3.5.9 on 9.10.
<souffledev> updated, re-installed multiple times with no success
<souffledev> deleted ~/.mozilla
<souffledev> i can't find anything about this on LP
<souffledev> wait. i think the /usr/lib/firefox-3.5.9/firefox.sh is going into an infinite loop
<souffledev> hahaha
<souffledev> lmfao
<ari-tczew> please move package to jaunty-updates bug 249104
<ubottu> Launchpad bug 249104 in packagekit-gnome "FTBFS on sparc, armel, hppa, ia64 due to false positive warning and -Wcast-align" [Undecided,Fix committed] https://launchpad.net/bugs/249104
<cody-somerville> How interesting. I have a random GTK text input field hovering in the lower right of my screen.
<persia> And which process owns it?
<persia> (you ought be able to determine this with the X utilities, but it's long enough since I played screen wars that I don't remember which)
<cody-somerville> persia, I tried xwininfo but the trouble is that I click right through it.
<persia> That's annoying
<zul> slangasek: when you get a chance can you have a look at #392759 its a ffe exception for apache2
<zul> slangasek: also 533029, thanks
<hunger_> Could somebody please fix opensync-plugin-syncml, please? It is not installable in lucid:-/
<geser> hunger_: see bug 524938
<ubottu> Launchpad bug 524938 in libopensync-plugin-syncml "Remove binary "opensync-plugin-syncml" from lucid" [Undecided,New] https://launchpad.net/bugs/524938
<ramvi> /boot/vmlinuz* doesn't exist on my system. Can I regenerate it some how?
<kklimonda> install kernel package
<hyperair> linux-image-`uname -r`
<cjwatson> he left
<hyperair> oh whoops
<cjwatson> speaking of which, amd64 kernel NEW-processed, i386 still building
<cjwatson> though nearly done, I notice
 * hyperair compiles his own kernels
<cjwatson> that's nice
<hyperair> mmhmm
<hyperair> it has things that upstream does not like
<hyperair> stuff like BFS, linux-phc
<cjwatson> (my comment was relevant because the kernel had to be temporarily removed from the archive today, and this constitutes putting it back; it wasn't an invitation for general "I don't need the archive kernel" :-) )
<hyperair> aah i see.
<hyperair> why was the kernel removed from the archive?
<cjwatson> bug 561151
<ubottu> Launchpad bug 561151 in linux "2.6.32.30 reproducible oops at startup in acpi_ex_read_data_from_field" [High,Fix released] https://launchpad.net/bugs/561151
<persia> Apparently it didn't boot for some thinkpads.
<hyperair> i see.
<hyperair> that sucks.
<hyperair> well at least it's fixed.
<JamieBennett> Any core-dev around to upload me a patch, https://bugs.edge.launchpad.net/ubuntu/+source/webservice-office-zoho/+bug/561836 ?
<ubottu> Launchpad bug 561836 in webservice-office-zoho "debian/control missing build depend" [Undecided,New]
<ajmitch> JamieBennett: looks like you modified Depends rather than Build-Depends in that debdiff
<JamieBennett> ajmitch: ah, sorry, silly mistake
 * JamieBennett goes to fix
<jpds> Can an archive admin please pass https://launchpad.net/ubuntu/+source/linux/2.6.32-20.30/+build/1687719 through NEW?
<jpds> cjwatson / slangasek ^
<slangasek> looking
<ccheney> NCommander: how far do you think we are away from having a new arm patch?
<ajmitch> JamieBennett: fwiw, from looking at setup.py I think you need the python-distutils-extra package, best to do a test build in pbuilder or similar to check it
<JamieBennett> ajmitch: just building it in pbuilder now, thanks for the heads-up
<slangasek> jpds: accepted
<mathiaz> slangasek: about bug 552786
<ubottu> Launchpad bug 552786 in upstart "initctl: lacks proper exit codes" [Medium,Invalid] https://launchpad.net/bugs/552786
<mathiaz> slangasek: what would be the next step?
<mathiaz> slangasek: it seems that Scott doesn't plan to fix it in time for lucid
<jdong> *criiiinge* I just saw http://www.exploit-db.com/exploits/12130
<jdong> looks like user_xattrs is all tht's needed for this to work
<JamieBennett> ajmitch: moved the depend to Build-Depends and tested in pbuilder if you have time to have a look again
<ajmitch> ok
<slangasek> zul: done
<slangasek> zul: did you see my earlier comment about your unseeding of packages that AIUI are supposed to be in main?
<ajmitch> JamieBennett: I've unsubscribed -sponsors & will upload in a minute once I've testbuilt it myself
<JamieBennett> ajmitch: Thanks !
<slangasek> mathiaz: well, I've followed up in the bug; since we're all agreed that the real bug is in upstart, I'd like to still get it fixed there
<slangasek> mathiaz: barring that, workarounds in puppet will be considered
<mathiaz> slangasek: ok - thanks for the follow up
<mathiaz> slangasek: so I'll wait for Scott's reply
#ubuntu-devel 2010-04-13
<slangasek> kirkland: your base-files upload doesn't modify debian/links?
<kirkland> slangasek: it wasn't actually created
<kirkland> slangasek: i backed it out
<slangasek> $ dpkg -L base-files|grep etc/motd
<slangasek> /etc/motd
<kirkland> slangasek: i couldn't actually figure out who's creating that link at this point ... any hints ?
<slangasek> the file is listed as belonging to the package
<kirkland> slangasek: debian/rules:         ln -sf /var/run/motd debian/tmp/etc/motd
<kirkland> slangasek: i'll prune that line
<kirkland> slangasek: sorry
<kirkland> slangasek: thanks for the sanity check
<slangasek> kirkland: sure thing
<slangasek> kirkland: since it's no longer in the package, that also means the symlink will disappear on upgrade - so the version check in the postinst needs to be dpkg --compare-versions "$2" lt 5.0.0ubuntu17, not just -z "$2"
<kirkland> slacker_nl: http://paste.ubuntu.com/413371/
<slangasek> kirkland: why was the 'rm -f' line there?  hopefully that was redundant :)
<kirkland> slangasek: yeah, redundant
<zul> slangasek: thanks...i saw your earlier comment but havent gotten to it yet
<slangasek> zul: well, can you confirm that these packages are supposed to be in main?  I can fix up the seeds quickly for that
<zul> slangasek: yeah they are
<slangasek> ok
<slangasek> I'll follow through then
<kirkland> slangasek: http://paste.ubuntu.com/413375/
<kirkland> slangasek: can you give that a once-over?
<slangasek> kirkland: looks good; please do an upgrade test before upload, to confirm
<kirkland> slangasek: ack
<kirkland> slangasek: that rm -f debian/tmp/etc/motd was not in vain
<kirkland> slangasek: some other part of the packaging was putting something there
<kirkland> slangasek: http://paste.ubuntu.com/413388/ appears to be doing the right thing
<slangasek> ok
<kirkland> slangasek: http://pastebin.ubuntu.com/413396/
<slangasek> kirkland: looks good
<kirkland> slangasek: cheers, thanks, uploading
<FeasibilityStudy> I keep getting kernel failure messages on boot, and when apport runs, it cannot show me the details because I get a permissions error
<FeasibilityStudy> IOError(13, 'Permission denied')
<psusi> hoo rah!  e2defrag now works with uninit_bg, crc checksumed block group descriptors and all!
<robertzaccour> i reported a bug a while back, it seems to have been forgotten about
<robertzaccour> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/555503
<ubottu> Launchpad bug 555503 in xorg-server "screen flickers at least once every few minutes" [Undecided,Confirmed]
<robertzaccour> is there any possibility it will be fixed before the final release?
<robertzaccour> anyone here?
<RAOF> robertzaccour: THat's likely to be fixed by booting with the powersave=0 option; have you tried that (as requested in the bug)?
<genii> robertzaccour: 279 give or take
<robertzaccour> RAOF, i tried that, didn't work
<robertzaccour> genii, whats that mean?
<robertzaccour> i reported it and the info was incomplete, then i included the needed info, then it was confirmed and seems to be forgotten about. wish there was somethin i could do. i do what i can to help when possible
<genii> robertzaccour: This channel has currently about 279 people in it. So the question "anyone here" has the answer of 279.
<robertzaccour> genii, oh i see haha just wan't sure who was awake thanks
<robertzaccour> is it likely to be fixed before the release? i'm hoping so. all thats happened in the report is confirmed
<soren> nixternal: Still awake?
<soren> nixternal: When did we decide tomorrow's DMB meeting was going to be?
<robertzaccour> did i ask a bad question?
<persia> soren: Isn't it 15:00 as always?
<soren> persia: It may be.
<genii> robertzaccour: There are no bad questions. There are questions to which there are no immediate answer.
<persia> That's when I'm planning to be paying attention, if that matters :)
<nixternal> soren: 15:00, my alarm on my cell phone just went off 15 minutes ago letting me know to wake up for it :)
<soren> Fair enough. I Google'd it, got UWN which said 1400 UTC.
<robertzaccour> if the bug has been confirmed and no other action, should i assume its gonna be fixed well after the release if it is?
<robertzaccour> wish there was something else i could do
<soren> persia, nixternal: Thanks. I'll try to make it. I'm holidaying with the family, so it may not work out.
<persia> Best of luck on finding the opportunity to be present :)
<persia> (and have fun otherwise)
<soren> Thanks, and will do.
<RAOF> Yeah.  For what it's worth, other people with what sound like a similar bug have found that i915.powersave=0 fixed it for them.  One thing you could try would be using the drivers from the xorg-edgers PPA; they're newer and might already have a fix for you.
<nixternal> i have been on holiday for the past year
<robertzaccour> RAOF, you talkin to me?
<RAOF> Yes.
<ajmitch> nixternal: I'm sure I can beat that :)
<robertzaccour> RAOF, i915powersave=0 didn't work for me. where can i get xorg-edgers PPA?
<soren> Whoever reviewed python-cloudservers source and binary: Big thanks!
<soren> I wished we kept track of that.
<soren> s/wished/wish/
<nixternal> ajmitch: how much longer for you?
<RAOF> robertzaccour: launchpad.net/~xorg-edgers/ppa/+archive.  Bear in mind that those are unsupported drivers.  If they work for you, it's possible that we could isolate what's fixed it and backport to Lucid.
<robertzaccour> RAOF, should i try the pre-released and unsupported updates in software souces option also?
<ajmitch> nixternal: who knows, I occasionally do a few uploads, like today
<RAOF> robertzaccour: There's nothing in there at the moment; that will start to be populated once Lucid is released.
<robertzaccour> RAOF, it said page not found
<RAOF> Sorry; http://launchpad.net/~xorg-edgers/+archive
<robertzaccour> RAOF, thanks. which link do i select?
<RAOF> There's a section âAdding this PPA to your systemâ with details.
<robertzaccour> oh i got it thanks
<robertzaccour> i'm gonna update and then restart thanks
<robertzaccour> brb
<robertzaccour> back
<robertzaccour> RAOF, thanks again. i'll keep an eye on it for a few minutes and let ya know what happens
<robertzaccour> RAOF, it didn't seem to work, just did it again
<slangasek> chrisccoulson: seen that xulrunner-1.9.2 still FTBFS on ia64?
<slangasek> chrisccoulson: ah, yes you have because you've commented on the bug :-)
<slangasek> chrisccoulson: in the meantime, I'm nuking the out-of-date couchdb-bin binary on ia64, so we can get component-mismatches cleaned up
<robertzaccour> RAOF, it didn't work and I posted a comment on the launchpad log file. thanks anyhow
<robertzaccour> any other ideas?
<robertzaccour> did i make someone mad?
<RAOF> boot, adding the âdrm.debug=0x06â kernel parameter to the boot line.  Wait until you've reproduced the bug, then run âdmesg > dmesg.logâ and attach both dmesg.log and /var/log/Xorg.0.log to the bug.
<RAOF> That will cause all sorts of debugging information to be attached to those logs, and we can send it upstream.
<robertzaccour> RAOF, is that in the grub you're talking about next to the end of the text?
<RAOF> Yup.  In the same place as you'd put the âi915.powersave=0â bit; just after âquiet splashâ
<robertzaccour> RAOF, whats /car/log/Xorg.0.log?
<RAOF>  /var/log/Xorg.0.log is your X log file.
<robertzaccour> RAOF, oops i meant /var/log/Xorg.0.log
<robertzaccour> do i type that in the terminal too?
<RAOF> No, you attach it to the bug.
<robertzaccour> how do i attatch it? just type it in the comments?
<RAOF> There's an âadd attachment or patchâ button at the bottom of the bug page, just after the âadd commentâ box.
<robertzaccour> oh ok thanks
<robertzaccour> i'll try that brb
<robert__> RAOF, in the drm.debug=0X06 i capitalized the x. was i wrong?
<robert__> huh?
<RAOF> robert__: I'm not sure; I think you should...
<robertzaccour> RAOF, was i supposed to capitalize that x or does it matter?
<RAOF> I don't know if it matters or not.  It would probably be best to not capitalise it, though.
<robertzaccour> RAOF, ok i'll try it again then brb
<robertzaccour> back
<robertzaccour> RAOF, what you told me to run didn't do anything
<RAOF> What do you mean by âdidn't do anythingâ
<robertzaccour> RAOF, dmesg > dmesg.log
<RAOF> dmesg > dmesg.log will create a file called âdmesg.logâ in your home directory.
<robertzaccour> i did it right that time and thats what it said
<robertzaccour> robert@robert-laptop:~$ dmesg . dmesg.log
<robertzaccour> Usage: dmesg [-c] [-n level] [-r] [-s bufsize]
<robertzaccour> thats what it said when i typed it right this time
<RAOF> Um, that's not the same as âdmesg > dmesg.logâ
<RAOF> . is not the same as > :)
<robertzaccour> http://pastebin.com/HEkQe7Bm
<robertzaccour> thats whats in the folder
<robertzaccour> does that look right?
<RAOF> That looks right, but you didn't boot with drm.debug=0x06
<robertzaccour> RAOF, i did
<robertzaccour> at the end of all the text i put a space between that last word and what you said to put
<robertzaccour> did i insert it wrong? i thought it was correct
<RAOF> I think you've inserted it wrong.  Which is good!  Because that means you probably inserted the i915.powersave=0 wrong too, which means it might fix your bug.
<robertzaccour> how was i supposed to insert it? at the grub menu i pressed e. went to the end of all that text, added a space, then inserted what you said
<RAOF> Ok.  So, rather than the end of all that text, you want to go next to the âquiet splashâ bit, hit space, and then add i915.powersave=0.  This should be on the *same line* as âquiet splashâ.
<robertzaccour> RAOF, i didn't see anything about quiet splash, but i'll check again brb
<robertzaccour> RAOF, to the right of that line?
<RAOF> I'm taking a photo of what it should look like.
<robertzaccour> and should i delete the repos from earlier?
<robertzaccour> oh ok
<robertzaccour> should i delete those x repos i added earlier?
<RAOF> That's probably a good idea.
<RAOF> You should follow the instructions from the xorg-edgers site - use âppa-purgeâ
<robertzaccour> RAOF, i just deleted those repos
<robertzaccour> i'm gonna restart and look for "quiet splash"
<robertzaccour> brb
<robertzaccour> RAOF, i'm back
<robertzaccour> the line ends like this now quiet splash i915.powersave=0
<robertzaccour> is that correct?
<RAOF> That sounds correct, yes.
<robertzaccour> oh i didn't use ppa purge? i just deleted those repos via gui
<robertzaccour> RAOF, so i should just wait a few minutes and see if the bug is still there?
<RAOF> That won't have removed the packages.  You probably want to re-add the PPA and then use ppa-purge.
<RAOF> Yes.  Wait a while and see if that's fixed it first :)
<robertzaccour> how do i do ppa purge?
<RAOF> It's a package in the xorg-edgers PPA.  You run âsudo ppa-purge ppa:xorg-edgersâ and it removes the ppa packages, installs the ubuntu ones, and then disables the PPA repository.
<robertzaccour> its a quick blink so i'll try not to blink lol
<robertzaccour> should i reinstall them before doin that or go ahead and purge?
<RAOF> You haven't removed the packages.  Removing the repository just means you won't be getting any updates - the packages that you already had installed will remain.
<robertzaccour> RAOF, oh ok installing now
<robertzaccour> RAOF, it says command not found
<RAOF> You'll need to install the ppa-purge package first.
<robertzaccour> i did
<robertzaccour> RAOF, http://pastebin.com/bYfXGRSG
<robertzaccour> thats what the update says
<robertzaccour> sudo-apt-get update
<robertzaccour> RAOF, robert@robert-laptop:~$ sudo ppa-purge ppa:xorg-edgers
<robertzaccour> sudo: ppa-purge: command not found
<robertzaccour> robert@robert-laptop:~$
<RAOF> You now also need to run âsudo apt-get install ppa-purgeâ.  That installs the ppa-purge package.
<robertzaccour> RAOF, oh i did the ppa but forgot to install them lol sorry
<robertzaccour> robert@robert-laptop:~$ sudo apt-get install ppa-purge
<robertzaccour> Reading package lists... Done
<robertzaccour> Building dependency tree
<robertzaccour> Reading state information... Done
<robertzaccour> E: Couldn't find package ppa-purge
<RAOF> Then you'll need to re-add the xorg-edgers PPA; that means that you don't have the right PPA added.
<RAOF> Incidentally, have the flashes been occuring?
<robertzaccour> RAOF, no not since the i915.powersave=0
<robertzaccour> RAOF, i see xorg in synaptic
<robertzaccour> lucid wasn't listed in the sources so i just changed the word karmic to lucid
<robertzaccour> i did it again and still can't find it
<robertzaccour> well, i guess if it can't find it maybe i can just delete it from the repos
<RAOF> Ok.  Run âsudo add-apt-repository ppa:xorg-edgersâ from a terminal.  That will definitely add the right repository.  Then run âsudo apt-get updateâ, then âsudo apt-get install ppa-purgeâ
<robertzaccour> ok
<robertzaccour> RAOF, i did those commands. is it ok to delete it from software sources now? its still there
<robertzaccour> RAOF, i guess i purged it
<RAOF> If you run âsudo ppa-purge ppa:xorg-edgersâ the repository will automatically get removed.
<robertzaccour> i know i did that and the terminal did its thing, but in the software sources gui i see the 2 i added plus the one i added in the terminal
<robertzaccour> robert@robert-laptop:~$ sudo ppa-purge ppa:xorg-edgers
<robertzaccour> PPA to be removed: ppa:xorg-edgers ppa:xorg-edgers
<robertzaccour> Warning:  Could not find package list for PPA: ppa:xorg-edgers ppa:xorg-edgers
<robertzaccour> robert@robert-laptop:~$
<robertzaccour> haven't noticed any more screen blinking
<robertzaccour> RAOF, is this gonna be a problem? the ppa i mean
<robertzaccour> RAOF, brb i'll read when i get back if you type anything
<RAOF> Try running âsudo apt-get update && sudo ppa-purge xorg-edgersâ.  The PPA is not necessarily a problem, but it will mean that you don't get updates or support, and there are almost certainly bugs in those drivers which are not in the Ubuntu packages (and visa versa, obviously).
<robertzaccour> back
<robertzaccour> RAOF, http://pastebin.com/SFA5q72j
<robertzaccour> but look at this
<RAOF> Good, that seems to have worked.
<robertzaccour> wait brb
<robertzaccour> http://i455.photobucket.com/albums/qq274/Knuckle_Brawler/Screenshot-1-2.png?t=1271136148
<robertzaccour> thats what i meant by still in the software sources gui
<robertzaccour> oh and still haven't seen any screen blinking :)
<robertzaccour> RAOF, hey you still there?
<RAOF> That's fine; that's the other PPAs that you have enabled.
<robertzaccour> RAOF, oh ok i'll just delete those
<robertzaccour> RAOF, how do i make this permanent?
<robertzaccour> and how should i post this on launchpad?
<robertzaccour> RAOF, you still there?
<robertzaccour> a lot of quit text along the screen there, did i lose ya in the text? lol
<robertzaccour> RAOF, are you there?
<robertzaccour> i need to submit a confirmed bug fix. can someone help me do it properly?
<robertzaccour> RAOF_, hey you there?
<robertzaccour> can anyone help me with this confirmed bug fix?
<robertzaccour> I need to make sure i posted it right on the log or at least know how to make it a permanent fix on my system
<robertzaccour> please someone that can help me please respond
<persia> What's the bug number?
<robertzaccour> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/555503
<ubottu> Launchpad bug 555503 in xserver-xorg-video-intel "screen flickers at least once every few minutes" [Medium,Confirmed]
<robertzaccour> persia, the update worked. now i just gotta make it a permanent boot up from my end and make sure i posted it correctly at the very end of the log
<RAOF_> I've already updated the launchpad bug; to make this permanent you can edit /etc/default/grub, and add i915.powersave=0 next to quiet splash.
<persia> Yeah, the bug state looks great.
<robertzaccour> RAOF_, what do i do now?
<robertzaccour> RAOF_, is there any way i can make it permanent on my end or just wait for the updates?
<robertzaccour> are yall awake? anything else i can do? can i make it a permanent change from my end?
<robertzaccour> did i add i915 powersave correctly? http://pastebin.com/REXnmmUw
<robertzaccour> RAOF_,  persia did i add i915 powersave correctly? http://pastebin.com/REXnmmUw
<persia> You're at least missing a close-double-quites
<robertzaccour> persia, whats that mean?
<persia> On line 9, you want to add stuff *inside* the quotes.
<robertzaccour> persia, thats what it brought up when i ran /etc/default/grub
<robertzaccour> persia, with other people's help we found a bug fix, reported it, and now just gotta get it set to the grub defaults on my end
<persia> Right.  On line 9, you want to add the extra bits inside the quotation marks.
<robertzaccour> the i915.powersave=0 i added myself, wanted to make sure i did i right before i save it and have a kernel panic
<robertzaccour> persia, what do i add?
<RAOF_> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" i915.powersave=0 should be GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.powersave=0"
<RAOF_> Note the position of the double-quotes.
<robertzaccour> ok thanks. what about the line below that one?
<robertzaccour> line 9
<RAOF_> That is line 9
<robertzaccour> oh yeah one line is blank. what about line 10?
<robertzaccour> should i just erase line 10?
<persia> Just leave the rest of the file as it was before you edited.  you just have to change the one line.
<robertzaccour> i'm gonna pastebin what i got now brb
<robertzaccour> http://pastebin.com/Qz6LnbGa
<robertzaccour> thats what it looks like now. is that right for saving?
<persia> No.
<robertzaccour> persia, what do i need to do now?
<robertzaccour> the first part of line 9 is there twice. is that what i need to delete?
<persia> delete everything on line 9 up to the second 'G' character.
<RAOF_> As in: line 9 should be exactly:
<RAOF_> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.powersave=0"
<persia> and see the /topic : this used to be on-topic, but I fear we're drifint :)
<robertzaccour> persia, RAOF_ http://pastebin.com/U2YeMbUf
<robertzaccour> i really appreciate yall helping me
<robertzaccour> are yall still awake?
<robertzaccour> i need to save this correctly, gettin up real early in the morning all i need to know is if i got it right please help me
<robertzaccour> are yall still awake? please help me
<robertzaccour> anyone else??
<robertzaccour> yall please help me i gotta get up in a few hours
<robertzaccour> please please help is there anyone else here?
<robertzaccour> :( maybe Linux isn't for me
<RAOF_> You've replaced that with the original.
<RAOF_> You'll probably get better support in #ubuntu+1
<robertzaccour> RAOF_, i replaced what with the original?
<robertzaccour> ok thanks yall
<robertzaccour> here's what it says now http://pastebin.com/cRdCHdxb
<RAOF_> That looks good.
<robertzaccour> RAOF_, thanks. what do i save as? grub?
<robertzaccour> oh everytime something is successfully fixed in ubuntu i email it to myself. i have a bit list of ubuntu emails i emailed myself lol
<pitti> Good morning
<robertzaccour> good mornin
<dholbach> good morning
<RAOF_> Good morning :)
<robertzaccour> the Ubuntu community is wonderful
<robertzaccour> wouldn't trade it for any distro in the world :)
<dholbach> hey RAOF_
<dholbach> hey seb128
<seb128> hey dholbach
<seb128> how are you?
<RAOF_> Morning seb128
<dholbach> seb128: getting better :)
<dholbach> thanks
<robertzaccour> ok time to restart with the bug fix :)
<seb128> hey RAOF_
<seb128> dholbach, good!
<robertzaccour> man if i didn't bring up the bug i'm not sure if anyone else would have before the release. there was only one other person affected by it on launchpad
 * dholbach hugs seb128
<robertzaccour> it was accomplished with other people's knowledge and not my own, however i still fill like i contributed by telling the right people about the bug
 * seb128  hugs  dholbach
<robertzaccour> i'm goin to sleep for a few hours, yall have a great day thanks and God bless
<dholbach> zul: does bug 557110 need to get reopened?
<ubottu> Launchpad bug 557110 in mysql-cluster-7.0 "Dependency mismatch for mysql-cluster-*" [High,Fix released] https://launchpad.net/bugs/557110
<tseliot> slangasek: still around?
<Damascene> hello, any one care https://bugs.launchpad.net/vte/+bug/263822 ?
<ubottu> Launchpad bug 263822 in vte "RTL (right to left) support in terminal (BiDi)" [Low,Triaged]
<wgrant> mvo: Hi.
<joaopinto> Damascene, I am not sure you get much attention on a non critical bug wich requires a complex resolution at this time :P
<Damascene> not so complex
<Damascene> only add mlterm when installing rtl support
<Damascene> is it too complex?
<joaopinto> Damascene, first it needs to be decided whether that's the proper fix :)
<joaopinto> and I believe mlterm would also need to be moved to main
<Damascene> I don't know what to do. I've sent to ubuntu-desktop ubuntu-devel talked in the channel of both
<Damascene> who can really help? Mark?
<joaopinto> Damascene, I don't think Mark is doing bug fixing lately :P
<Damascene> :)
<lifeless> Damascene: mark could make it critical priority if you convince him its critical. So can any other bug triager though.
<lifeless> Damascene: are you claiming that its a critical bug ?
<Damascene> will not critical but a bug that could be fixed by using mlterm which is ready to fix it
<Damascene> it will not fix vte or gnome-terminal but it will give you a working terminal for rtl
<lifeless> so joaopinto says that its not clear that that is the fix.
<lifeless> Damascene: have you proposed a merge making the change you think will fix it ?
<cjwatson> I don't think it's appropriate to pull in a completely different terminal emulation program, personally
<cjwatson> certainly not at this point in the cycle, we don't have time to discover new bugs when it's installed by default
<joaopinto> Damascene, to be honest what you are requesting should be recored on a different bug report, one thing is the lack of RTL on VTE, another thing is the lack of an usable terminal for RTL languages (by default)
<Damascene> :S
<Damascene> I
<Damascene> I'm not asking to replace vte. just installing mlterm with rtl support
<Damascene> not for every ubuntu user
<Damascene> joaopinto, are you sure I should open another bug?
<slangasek> tseliot: hi
<tseliot> slangasek: hey, are you ok with what I wrote in my last email?
<tseliot> (on escaping the percent sign)
<joaopinto> Damascene, I think you should, the proper fix for VTE would be to have the RTL support, that take ages or never be fixed, on the other hand if you have a specific bug to include mlterm with a good ration it may be considered and fixed on Lucid+1
<mvo> hi wgrant
<slangasek> heh, mlterm certainly has plenty of its own bugs
<slangasek> tseliot: uhm, you shouldn't have to escape the percent sign
<slangasek> tseliot: if you're having to escape the percent sign, you're passing it in the wrong place :)
<joaopinto> erm, I am eating letters
<Damascene> joaopinto, I've spent much time heating that bug :)
<joaopinto> Damascene, If I were using a language with a default broken terminal I would also be ;)
<Damascene> should I use ubuntu-bug?
<wgrant> mvo: Why was it chosen to use the /changelogs/pool hierarchy rather than something like SOURCE_VERSION.changelog in the normal pool?
<slangasek> tseliot: ply_boot_client_update_daemon() takes a static string; unless you need to do percent substitution in *both* mountall and the theme, you shouldn't have to escape anything
<wgrant> (I'm looking at the Soyuz implementation of this.)
<Damascene> and what do you suggest as title please
<joaopinto> Damascene, "Selecting an RTL language should install and RTL capable terminal emulator"
<joaopinto> the package is language-selector
<Damascene> thanks
<tseliot> slangasek: but I have to create the string first, right? I think nih_sprintf will complain if I don't escape %
<tseliot> as printf would do
<slangasek> tseliot: why do you need nih_sprintf() to create the string?
<mvo> wgrant, no specific reason, it could as well be this. it was simply modeled after the current way of storing them
<slangasek> tseliot: if you mean composing the "fsck:%s:%d", only the first argument will have %s interpreted
<slangasek> tseliot: a subsequent argument that contains %s is just treated as a literal string
<wgrant> mvo: It seems a little awkward to have two pools if they're in the same place.
<wgrant> (and it's more than a little awkward for Soyuz)
<mvo> wgrant, that is true
<tseliot> slangasek: something like nih_sprintf (NULL, _("Checking disk %1$d of %2$d (%d %% complete)"), progress));
<mvo> wgrant, if joaopinto (he was doing the patch) does not mind we can easily change it at this point
<persia> What are the mirroring implications of the change?  My memory is that the changelogs collection is fairly large.
<wgrant> mvo: So he has the only server-side implementation at the moment?
<mvo> wgrant, AFAIK
<tseliot> slangasek: but I guess I can solve it with string concatenation
<joaopinto> mvo, it's ok for me, that will allow also to use the mirrors for changelogs
<persia> And my understanding of the default mirroring is that it would pull anything in /pool/
<mvo> wgrant, I would suggest to put the changelog alongside each binary package (or symlink from source changelog)
<slangasek> tseliot: right, that wouldn't work so well.  But this would: nih_sprintf (NULL, _("fsck:%s:%d", _("Checking disk %1$d of %2$d (%3$d %% complete)"), progress));
<joaopinto> mvo, but aren't other files on /changelogs/.. I noted some *copyright on some random packages ?
<mvo> wgrant, this make it more robust in the client implementation if e.g. no deb-src line is avaialble
<wgrant> persia: I've no plans to use this for the primary archive yet. u-m is already specially hardcoded for the primary archive.
<slangasek> tseliot: ... except with right syntax
<mvo> joaopinto, yes, but those are not fetched currently, they are just there for information
<slangasek> (i.e., no stray '_(" in front of the format string...)
<wgrant> mvo: Right, we should be able to easily do the symlink dance in Soyuz.
<mvo> wgrant, ok, cool. give me some minutes to update the code, I have another u-m bugfix pending anyway
<joaopinto> symlinks from each binary package to the source changelog ?
<wgrant> mvo: I guess this will even fix the differing source/binary version issue.
<mvo> wgrant, exactly
<mvo> wgrant, on changelogs.ubuntu.com there is a crawler that does fixup (via symlinks) like this as well
<persia> wgrant: Cool.  Just wanted to make sure :)
<wgrant> (conveniently enough, we have raw changelogs available in Soyuz as of a couple of weeks ago)
<tseliot> slangasek: ok, I see what you mean now. Thanks
<Damascene> joaopinto, https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/562130
<ubottu> Launchpad bug 562130 in language-selector "Selecting an RTL language should install and RTL capable terminal emulator" [Undecided,New]
<Damascene> please adjust the description as you want
<wgrant> joaopinto: How easy would it be for you to adapt to this change?
<mvo> wgrant, joaopinto: to properly fix the src-version != binary-version (a good example is gcc-defaults with gcc-defaults != gcc) we would have to add a .changelog alonside earch foo_$arch.deb that reads "foo_$arch.changelog" (via symlink or file)
<cjwatson> that's a lot of extra files in the mirror :-/
<cjwatson> (may be unavoidable)
<mvo> cjwatson, yeah, but we will not do it on the default archive
<wgrant> cjwatson: Right, this probably won't work for the primary archive.
<mvo> cjwatson, at least now :) only third-parties
<cjwatson> oh, this is for PPAs?
<mvo> cjwatson, yes, PPAs plus archives like getdeb
<cjwatson> fair enough!
<joaopinto> mvo, ok
<wgrant> mvo: That was exactly the binary I was thinking of...
<wgrant> So, yes, I guess we just need a foo_1.0.changelog, and foo_1.0_i386.changelog etc. symlinks.
<mvo> wgrant, yes
<mvo> foo-src_1.0.changelog
<mvo> foo_2.0_i386.changelog
<wgrant> Right.
<joaopinto> hum, I will need to move the changelog extraction to the build process, or just assume it was built for every arch
<mvo> wgrant, so that does mean we have a good change to get it for PPAs relatively soon :) ?
<wgrant> That's pretty easy to do on my end.
<wgrant> Much easier than the separate pool.
<wgrant> And it will be more reliable too.
 * mvo nods
<persia> wgrant: Did the importer job run already, so that it's time for the UI exposure?
<persia> (re: changelogs)
<wgrant> persia: The importer doesn't exist yet.
<persia> Aha!  I thought that was still missing :)  I'll poke some more to see if it gets created.
<wgrant> I'm not sure how NCommander's going with that, or whether someone else needs to pick it up.
<mvo> joaopinto, you could just opportunisticly assume its build for each arch (or test if foo_$arch.deb exists). I hope it does not cause too much trouble, but I think its a better schema in the longer run
<joaopinto> mvo, I will create the links, on my case is only i386/amd64, will work just fine
<mvo> joaopinto, cool
<wgrant> joaopinto: OOI, which archive software does GetDeb use?
<joaopinto> wgrant, custom build system, bzr branch lp:debfactory
<joaopinto> it was prior to PPAs implementation :P
<wgrant> Ah, right, I remember that vaguely.
<joaopinto> and there are other technical reasons to not use PPAs, more flexibility to plugin our own features, license issues, mirror size, etc etc
<wgrant> Yep.
<directhex> bugger, apt in hardy doesn't support http 301 redirects - only in jaunty+.
<mvo> wgrant, the code in u-m is updated now, would you mind updating the bugreport against soyuz so that it reflects the new schema too? I will upload the new u-m today
<wgrant> mvo: Will do. Thanks for being so swiftly adaptable!
<didrocks> cjwatson: do you have a minute to discuss about the long standing bug #221112? (it's even worse now that ubuntu one music store is available)
<ubottu> Launchpad bug 221112 in quodlibet "Can't use space bar in search bar when using french alternative keyboard" [Undecided,Confirmed] https://launchpad.net/bugs/221112
<wgrant> mvo: So it's now binary_version_arch.changelog, in the same directory as the binary itself?
 * wgrant checks the branch.
<mvo> wgrant, yes
<cjwatson> didrocks: well, we switched to the oss variant at the specific request (indeed, quite loud demand IIRC) of the French community
<cjwatson> what does the option people are talking about correspond to in XKB-speak?
<Damascene> joaopinto, I've opened a bug as you said. what should I do now please?
<didrocks> cjwatson: right, I think we can fix/workaround the oss variant. The bug was introduced by fixing bug #198759. after debugging a little bit, in the oss variant, Ctrl + space and space return the same XLookupString
<ubottu> Launchpad bug 198759 in xkeyboard-config "Right CTRL don't work" [Medium,Fix released] https://launchpad.net/bugs/198759
<didrocks> I guess gtk_action_group_add_toggle_actions use a lookup to set up accelerator
<joaopinto> Damascene, the best place to get help with bugs is #ubuntu-bugs ;)
<wgrant> mvo: Heh, that code's a bit simpler now.
<didrocks> one fix is to use in /usr/share/X11/xkb/symbols/fr include "nbsp(level4n)" instead of include "nbsp(level4nl)" in the oss variant
<mvo> wgrant, yes, its a nice change :)
<mvo> wgrant, if the diff has more "-" than "+" while keeping or extending functionality I'm happy
<didrocks> we lost the "without forcing the use of level5 for mostly four-level layouts". Upstream responded a little bit to that: https://bugs.freedesktop.org/show_bug.cgi?id=15804 stating that no option there will fit everyone
<joaopinto> Damascene, and keep in mind that your bug is very unlikely to be fixed at this  time, IMHO it's not a critical bug
<ubottu> Freedesktop bug 15804 in General "Layout "fr" Variant "oss" not working as desired" [Normal,Resolved: notourbug]
<Damascene> joaopinto, if someone can't use apt-get it is non critical?
<Damascene> all apt-get messages are not readable
<joaopinto> Damascene, there is an easy work around
<Damascene> but there is a workaround. 1. don't use your language 2. use LC_ALL=C apt-get
<joaopinto> and software center works just fine
<cjwatson> didrocks: so we definitely shouldn't force the use of level-5 modifiers for fr(oss), but beyond that it's been years since I touched this stuff
<didrocks> cjwatson: I have no real clue about the pros and the cons of those 2 layout (the level4nl definition is in /usr/share/X11/xkb/symbols/nbsp) as I don't have this background. But the fact that with level4n, we don't loose unbreakable space in for instance OOo as they use Ctrl + Shift + space) and that people can enter a space character in rhythmbox then seems better
<joaopinto> Damascene, the work around is to manually install mlterm and use it
<joaopinto> any way, this is something you need to discuss with bug triagers, I am not one ;)
<awilkins> Is this the right place to mention that Eclipse seems to have been right proper broken by the last update?
<cjwatson> isn't level4n the one that hijacks right-ctrl again?
<didrocks> do you have good pointers as the docs seems sparse in that area and I don't think I have enough background, even reading the 5 related bug reported (upstream and in different distros) to take that decision?
<Damascene> may I ask in which team you are? joaopinto
<cjwatson> I don't any more, like I say it's been years
<didrocks> cjwatson: from what I understand no, the change in the first bug report (the initial change in 2008) was another setup
<joaopinto> Damascene, and like it was already mentioned, introducing mlterm could bring a new bunch of other unknown/untested issues
<cjwatson> I think if you can simultaneously fix the rhythmbox bug and avoid regressing that right-ctrl bug, you should go ahead
<cjwatson> it shouldn't need any installer changes - it's just in xkeyboard-config
<Damascene> right, but even kernels have this
<joaopinto> Damascene, kernels have a team handling them, mlterm does not
<Damascene> who said that?
<didrocks> right, I saw that. but I don't want to make a bad change there, hence the fact I asked this to you as you should have better knowledge than I :)
<seb128> didrocks, if you need details on those keyboard changes talk to svu
<Damascene> mlterm 3.0.0 released a days ago
<seb128> he does IRC on irc.gnome.org and is nice to questions usually
<seb128> didrocks, try on #control-center
<didrocks> enforcing the level5 was in including "level5(rctrl_switch)"
<didrocks> seb128: thanks, doing it now. Just wanted all available inputs first :)
<cjwatson> didrocks: you want a time machine plus me a couple of years ago, unfortunately, I think :)
<didrocks> cjwatson: so hard to find nowdays ;)
<cjwatson> it took me about a day to cram all this stuff into my head and I think it's fallen out again
<joaopinto> Damascene,  I am dropping the debate, I can't help you and I don't want you to be more frustrated than you already are :P
<Damascene> oh, thanks
<apachelogger> mvo: ping.. is there a way to do-release-upgrade without having 3rd party repos disabled?
<apachelogger> mvo: nvm, already found it :)
<sebner> apachelogger: 3rd party repos are evil :P
<ajmitch> sebner: not when the 3rd party repository is your local mirror of packages
<sebner> ajmitch: local mirrors are evil :P
<ajmitch> says you who wasn't trying to grab lucid packages at ~8k/sec earlier today :P
<sebner> ajmitch: /me grabs with ~600kb/s anytime. Well except the first few days after a stable release
<apachelogger> 600 Oo
<apachelogger> who can you work like that?
<ajmitch> yeah, this is because I was trying to fetch from archive.ubuntu.com
<ajmitch> it's not always fast fetching from there to NZ
 * apachelogger gets already majorly annoyed with 2000
<sebner> apachelogger: 600kb/s = 6Mbit, you have 20 Mbit?
<apachelogger> sebner: at times we get there ^^
<apachelogger> average is around 1200 though
<sebner> apachelogger: pffffff, at home (carinthia) I have 16Mbit
<ajmitch> I'd probably get up to about that from a NZ mirror
<apachelogger> sebner: like a friend who apparently has 16, in fact I never saw it go beyond 200 ;)
<apachelogger> err
<apachelogger> 2
<sebner> apachelogger: not true, Carinthia is different *hahahahaha*
<apachelogger> no argument there :P
<sebner> apachelogger: we get ~1450 maximum, average is between 1200 -1400
<ev> is it just my machine, or are dbgsym packages broken?
<seb128> ev: how broken?
<ev> seb128: http://paste.ubuntu.com/413583/
<seb128> ev: seems about right?
<seb128> "Reading symbols from /usr/bin/cheese...Reading symbols from /usr/lib/debug/usr/bin/cheese...done."
<ev> right, but no source code listing
<seb128> we don't embed source code in the dbg or dbgsym the way rpm distro are doing
<seb128> you need to apt-get source cheese
<ev> oh?  Weird, I thought we did.
<seb128> cd in the source
<seb128> and run gdb there
<seb128> no we don't ;-)
<ev> fair enough, thanks!
<seb128> you're welcome
<baptistemm> StevenK, could you approve me as member on ~bluetooth? I'd like a to give a hand there
<lamont> mvo: bug 559194 also needs a fix in update-manager, thanks
<ubottu> Launchpad bug 559194 in update-notifier "update-motd.d symlinks are not listed as conffiles" [Wishlist,Fix released] https://launchpad.net/bugs/559194
<mvo> lamont: could you elaborate a bit please? the update-notifier change is uploaded
<nosse1> Do you know of a good guide of how to create a company internal apt-source repo? (With tools to rebuild Packages, etc.)
<Riddell> persia, bryceh: xserver-xorg-video-displaylink seems to ignore the source code in the .orig.tar.gz and add it through the .diff.gz , why is that?
<Riddell> W: xserver-xorg-video-displaylink source: patch-system-but-direct-changes-in-diff COPYING and 10 more
<persia> Um, if it does that, I made a mistake.
<persia> I'll go fix that now.
<Riddell> persia: ok I'll reject for now
<jpds> nosse1: https://wiki.ubuntu.com/Mirrors
<jibel> mvo: hey, I ported the "3rd party changelog" fix to synaptic.
<jibel> mvo: I'm wondering how the change of this morning to u-m will work with 3rd party repos other than ppa like e.g medibuntu.
<persia> Reject it?  From where?
<jpds> nosse1: #ubuntu-mirrors is a better place to ask.
<mvo> jibel: woah, thanks!
<jibel> mvo: they use the format base_uri+"/changelogs/pool/%s/%s/%s/%s_%s/%s"
<jibel> mvo: Do they need to change the way they provide the changelog or must we try different format depending on the repo ?
<jibel> mvo: joaopinto's fix was working well with this format.
<mvo> jibel: they already have this? I was not aware of that. easiest is probably to ask them if they can provide symlinks
<jibel> mvo: e.g http://packages.medibuntu.org/changelogs/pool/non-free/g/googleearth/current.lucid/changelog
<nosse1> jpds, well thanks. But I'm not looking for a mirror. I'm looking for a description of how to build repo of custom, non-official packages
<mvo> jibel: joaopinto from getdebs is fine with the change, I hope they will be too. maybe they can even share the code
<lamont> mvo: update-manager-common delivers /etc/update-motd.d/91-release-upgrade as a symlink, rather than a file (which makes it not a conffile, and therefore it keeps coming back).  Same bug, different package doing the delivery
<mvo> jibel: lets ask them first if they can adept before adding compat code
<jibel> mvo, ok, I'll ask them. thanks.
<mvo> jibel: great, thanks
<persia> Oh, yeah.  That's a mess :)
 * persia fixes
<mvo> jibel: just for reference, the reason to do it like this was to avoid problems with src-version != binary-version (like gcc-defaults)
<mvo> lamont: thanks
<jibel> mvo, yes, I've read the irc log.
<persia> bryceh: Remind me: what benefit do we get from not using the tiny debian/rules again?
<jpds> nosse1: Oh, sorry then.
<jibel> mvo, can you join us on #medibuntu to talk about the changelog
<directhex> slangasek, as requested (well, noticed - we just forgot), banshee-coverwallpaper just yanked from sid
<Laney> did i forget to do that one :(
<bdrung> how can i test an apport hook?
<Riddell> doko_: do you have any comment on bug 492139 ?
<ubottu> Launchpad bug 492139 in glassfish "Sync glassfish 1:2ur2-b04-3 (universe) from Debian testing (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/492139
<persia> bdrung: kill -1 the program?
<persia> bdrung: Or kill -11 if you want a specific sort of kill (that would be segfault)
<bdrung> persia: can i see what apports wants to send?
<persia> Yep.  Just choose "View the Report", and (optionally) don't actually submit to LP.
<persia> Works for CLI and GUI variants.
<james_w> you should be able to write a test case that calls the hook with a dummy report and checks the output
<Riddell> doko_: how about bug 523910 ?
<ubottu> Launchpad bug 523910 in python-reportlab "sync request (unstable -> lucid/main)" [Undecided,New] https://launchpad.net/bugs/523910
<doko_> Riddell: there was a glassfish package before, packaged by sun, but I can't find it now, neither in universe, nor multiverse. ahh, I see, filed the removal request myself ... in 449905. yes, I think that is ok
<doko_> Riddell: about 523910: it's fixing the PIL bug, yeah, have to be more verbose for the FFe
<Riddell> doko_: ok I'll remove the blacklist for glassfish and sync that
<Riddell> doko_: what's to be done with bug 535386 ?
<ubottu> Launchpad bug 535386 in gnat-4.4 "FFEs for ada packages in lucid / arm builds" [Undecided,Confirmed] https://launchpad.net/bugs/535386
<doko_> Riddell: could you sync the four remaining packages?
<Riddell> doko_: the outdated ones on http://people.canonical.com/~doko/ubuntu-diff/status/ada.html ?
<doko_> Riddell: yes
<doko_> just updated this page
<doko_> and then closing the report
<Ryan1> Is there any chance bug #554432 will be fixed before Lucid is released?
<ubottu> Launchpad bug 554432 in linux "kernel BUG at /build/buildd/linux-2.6.32/drivers/gpu/drm/i915/intel_display.c:1917!" [Undecided,Confirmed] https://launchpad.net/bugs/554432
<dmart> Does anyone know how to encrypt the whole rootfs when installing using ubiquity?
<ogra> i think thats only possible with d-i
<ogra> unless that changed
<cjwatson> correct
<dmart> ogra, can I chat to you later about that?
<ogra> dmart, i havent done any encrypted root installs in my life but indeed you can :)
<dmart> cjwatson: have you done this?
<cjwatson> I just port that stuff over from Debian and make sure it doesn't break too badly :-)
<dmart> ok, I'll chat to ogra later and see if we get anywhere.  Thanks
<cjwatson> there should be an "encrypted LVM" choice in d-i's autopartitioner, though
<cjwatson> which with any luck should just DTRT on arm too
<persia> Riddell: xsever-xorg-video-displaylink back in NEW for your reviewing pleasure: should be *much* cleaner now.
<Riddell> Daviey: what's the status of bug 555111 ?
<ubottu> Launchpad bug 555111 in xmltv "Sync xmltv 0.5.56+cvs20100328-1 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/555111
<tseliot> Riddell: is kubuntu-default-settings maintained in a bzr branch? I might have to upload a fix for the bootsplash (bug #553954)
<ubottu> Launchpad bug 553954 in plymouth "[Lucid Beta 1] plymouth has a non translatable string coming up on screen" [Medium,In progress] https://launchpad.net/bugs/553954
<Riddell> tseliot: yes lp:~kubuntu-members/kubuntu-default-settings/ubuntu
<Riddell> persia: nothing there yet
 * persia goes to hunt
<tseliot> Riddell: ok, so what shall I do when my fix is ready? Upload and make a bzr merge request?
<Riddell> tseliot: yes please
<tseliot> Riddell: ok, thanks
<persia> Riddell: Really there this time, including round-trip download test
<Riddell> persia: accepted
<persia> Riddell: Thanks.
<joaopinto> where can I find the reason for the libuser1 removal ?
 * persia files the corresponding removal bug
<joaopinto> shouldn't the reverse depends be also removed ?
<james_w> joaopinto: I don't see it removed
<joaopinto> it's no longer available on the lucid repository
<joaopinto> usermode which depends on it was not
<james_w> ah, probably unbuildable binaries spec
<joaopinto> hum, there was a mail about checking such packages right ?
<james_w> yes
<joaopinto> if I can fix it at this time would it still be included on the archive ?
<james_w> http://people.ubuntuwire.org/~lucas/ubuntu-nbs/32/libuser_1:0.56.9.dfsg.1-1ubuntu2_llucid32.buildlog
<james_w> yes
<NCommander> ccheney: ping?
<james_w> joaopinto: the problem is that the upstream build system installs in to site-packages, and then the packaging tries to copy from dist-packages
<joaopinto> james_w, ok, i will atempt to fix it, thanks
<cjwatson> apw: you had a machine that exhibited ridiculous slowness with dpkg when installing linux-headers, I recall, before we worked around it in dpkg.  Would you be up for trying a different workaround for me?  I'd like to sync to upstream if possible
<apw> cjwatson, don't think it was me
<apw> i do remember it though
<cjwatson> hm, at this point I don't want to upload it without advance testing
<apw> cjwatson, though any machine should show it, it being the size of the kernel headers which are the issue
<apw> so if you want me to try it i think reinstalling a kernel headers package should trigger it
<apw> and if it does not with your dpkg would that do for testing?
<cjwatson> that ought to do, I just don't have a system with ext4 right here
 * apw cirtaonly has those
<deryck> pitti, I'm starting work on bug 556499 which is for launchpad bugs team from the last UDS...
<ubottu> Launchpad bug 556499 in malone "Set user expectations for Ubuntu bugs after user reports a bug" [High,In progress] https://launchpad.net/bugs/556499
<apw> cjwatson, i have a 32 and a 64 bit i could test that on
<nemo> Say, this may be incredibly obvious, but I was wondering as I watched downloads scroll by (slowly)
<nemo> Does Ubuntu use / has considered  binary diffs?
<nemo> From last updated version of the package, if the user has it cached?
<nemo> Or perhaps partial updates.
<deryck> pitti, as I understand this, the idea is to have an aleart on the page after a user files a bug letting them know what they can expect, i.e. you should be able to reproduce this, etc.  sound right?
<jpds> nemo: Yes.
<nemo> jpds: yes to use or considered?
<nemo> :)
<jpds> nemo: https://wiki.ubuntu.com/AptSyncInKarmicSpec
<pitti> deryck: so, some things that come to my mind which we should point out, are: providing a good description and reproducer; most bugs aren't looked at quickly, and they might stay around for some time; checking for duplicates yourself helps a lot (although at this time it's a bit late, and we have a dupe detector now)
<joaopinto> james_w, the proper fix would be regenerate the autoconf* stuff, would a small patch directly on configure be prefered ?
<pitti> deryck: and of course that everyone, including the reporter, is encouraged to help with debugging and fixing
<deryck> pitti, right.  seems good.  I'm wondering, too, about making this generic.  Would it be ok to add a field to a project/distro in lp akin to the bug reporting guidelines, and then you guys could put whatever text you like to show up there after someone files a bug?
<pitti> rickspencer3: ^ you might have some thoughts about it as well?
<james_w> joaopinto: really? why does that fix it?
<pitti> deryck: that's a good idea indeed, so that we can adapt it over time without needing to change LP itself again
<deryck> pitti, ok, that makes sense to me too.  In a perfect world, we would prompt better according to the state of the bug, but as a first step, this seems useful, IMHO.
<pitti> deryck: perfect world> "Success probability: 0.3%" :)
<deryck> heh, exactly. :-)
<pitti> deryck: it would be useful to warn about bugs wit low gravity
<joaopinto> james_w, hum, I had the idea that the sites-packages dir was defined on the configure script
<pitti> i. e. short description, no attachments, no apport data, etc.
<deryck> pitti, right, and if we do that, that's a good bit more involved then a simple message alert.
<nemo> jpds: cool.
<pitti> deryck: oh, another thing comes to my mind: there are certainly a lot of packages with no package bug contact; could we do the text based on that?
<deryck> pitti, yes, that would be reasonable.
<pitti> deryck: I'm not sure whether it'd be easier to do with macros and just one complex notice, or different notices for the two cases
<deryck> pitti, so as a first cut, a base message that is configurable per project but if it's Ubuntu with no package specified, an additional message appears?
<pitti> deryck: "no package" is another interesting (and rather hopeless) case indeed
<pitti> deryck: I actually meant "no package bug contact", but both are indeed different cases
<deryck> pitti, oh, sorry I misread the scrollback, sorry.  right
<deryck> pitti, I think we could handle both cases there.
<ccheney> NCommander: I was wanting to find out the status of the arm patch
<NCommander> ccheney: we're going to force building for ARM mode. (-marm)
<james_w> joaopinto: if you can confirm that a patch to configure.ac and configure will fix it then that's great
<joaopinto> actually the path comes from aclocal.m4
<ccheney> NCommander: that needs a patch for the part of the build you need to force it on, right?
<NCommander> ccheney: no, we're going to force the entire build, just not some bits
<deryck> pitti, I'm worried that a dynamic solution based on gravity or heat is a bit much for a first cut.  Does the variable message option mentioned above sound useful?
<pitti> deryck: yes, definitively; we can include all those cases in text form, too
<pitti> deryck: like "if this has no package, you lose"
<ccheney> NCommander: oh ok, do i need a patch of some sort to do that in OOo, or is it going to be forced at the buildd level?
<NCommander> ccheney: got a debdiff coming for you
<ccheney> NCommander: ok thanks
<deryck> pitti, ok, great.  I'm curious like you if others agree, but if so, I can start work on this.
<NCommander> ccheney: http://paste.ubuntu.com/413678/ - how's that look? (I'm doing a partial test build to make sure -marm sticks, but other then that ...)
<pitti> deryck: there certainly will be some debate about the particular text still :)
<deryck> pitti, of course. :-)
<ccheney> NCommander: looks simple enough :)
<pwk> hi I have two build boxes freshly installed from 9.10. when they compile my c++ project using g++-4.1 the x86 build box adds symbols that require GLIBCXX_3.4.11 (and GLIBCXX_3.4.9). The amd64 build box does no such thing and just requires any GLIBCXX_3.4...I am unclear why this is, but would appreciate any insight...since I distribute the binary I need to get rid of those dependencies on x865
<pwk> here are the symbols that x86 build box adds that are the problem: http://pastebin.org/149195
<pwk> I compile using g++-4.1 to make sure my application runs on as many systems as possible, and yet it punishes me with that 3.4.11 dependency which was introduced in 9.10
<Riddell> cjwatson: for bug 557220 where is the image file?
<ubottu> Launchpad bug 557220 in gfxboot-theme-ubuntu "kubuntu splash using old logo" [Undecided,New] https://launchpad.net/bugs/557220
<NCommander> ccheney: do you want me to upload it directly when ready?
<ccheney> NCommander: no i have lots of patches already in queue
<ccheney> NCommander: i added your patch from the pastebin to my set
<NCommander> ccheney: alright
<NCommander> ccheney: I'll make sure I can test build it
<ccheney> ok
<ccheney> i'll be ready to upload as soon as i finish copying over a bunch of updated copyright strings :-\
<joaopinto> does anyone know the equivalent to  sysconfig.get_python_lib(0,0) to get the dist-packages path ?
<james_w> python -c "from distutils import sysconfig; print sysconfig.get_python_lib()"
<james_w> /usr/lib/python2.6/dist-packages
<james_w> joaopinto: ^
<joaopinto> hum
<joaopinto> sorry, it returns the proper value, I am going crazy :P
<mathiaz> slangasek: hi - what's your opinion on creating the openldap user with a home directory set to /nonexistent instead of /var/lib/ldap?
<ScottK> joaopinto: libuser1, IIRC, had it's binaries removed because it didn't build.  It just needs the FTBFS fixed and uploaded to get back in.
<joaopinto> ScottK, I am working on it, thanks
<ScottK> joaopinto: OK.
<joaopinto> I had to remove the prefix parameter on the get_python_lib, I believe there is a bug with get_python_lib() but this is not the best time to file a bug for distutils :P
<james_w> pitti: when do you normally disable apport? Can you please ping me when you do so?
<pitti> james_w: usually right after the RC release, but seb128 asked me to do it a bit earlier this time; probably for RC
<pitti> james_w: yes, I can do that; for disabling kerneloops?
<james_w> exactly, thanks
<james_w> or feel free to do it yourself if you find uploads easier than IRC pings ;-)
<tseliot> slangasek: I fixed #553954. Shall I proceed with the upload and update some bzr branch?
<bdrung> sistpoty|work: i don't understand point 1 of your comment in bug #494604.
<ubottu> Launchpad bug 494604 in audacious "Please package audacious 2.3 for lucid" [Wishlist,Confirmed] https://launchpad.net/bugs/494604
<sistpoty|work> bdrung: in the patch you add dependencies against audacious-dev, right?
<kwwii> Keybuk: hey, did you get the images I sent for the low-colour boot?
<sistpoty|work> bdrung: audacious-dev should have any dependencies that are needed to develop using the shipped headers
<Keybuk> kwwii: I've been travelling over the weekend
<kwwii> Keybuk: ok, just wanted to make sure the email made it to your inbox :-)
<Keybuk> I've no idea yet ;)
<kwwii> :P
<kwwii> lucky you
<kwwii> I'll bug you tomorrow then
<Keybuk> that might not scale
<bdrung> sistpoty|work: aha, ok. this needs to be fixed in debian
<Keybuk> slangasek: so I think I've figured out with Plymouth SEGVs inside ply_process_pending_events() all the time
<sistpoty|work> bdrung: wait a second, let me take a look again, maybe I'm confused with what patch I looked at
<bdrung> sistpoty|work: audacious-dev depends on (nearly) everything from B-D
<sistpoty|work> bdrung: ah, now I'm back on track, yes
<sistpoty|work> bdrung: actually audacious-dev as seen in experimental seems to be more or less sane (e.g. there's an include that requires libmowgli-dev), at least after taking a short look
<sistpoty|work> bdrung: actually I did confuse your audacious-plugins patch with one for audacious (there are depends added there as well), let me take another look
<sistpoty|work> bdrung: I think the same logic should apply for the -plugins-dev
<sistpoty|work> bdrung: however it's not too much of a problem, so if you want, feel free to leave it as is
<sistpoty|work> bdrung: just saw another thing: how is the upgrade path handled if you've got plugins-extra installed?
<bdrung> sistpoty|work: the question is: do we really need a -plugins-dev package
<bdrung> ?
<bdrung> plugins-extra will be removed
<sistpoty|work> bdrung: aha, audacious-plugins-dev is a meta package, so *shrug*, not too sure if it's needed or not
<bdrung> it does the same as "sudo apt-get build-dep audacious-plugins"
<sistpoty|work> yeah, might make sense to just drop it then...
<ion> keybuk: A random thought: implementing the last-good-boot stuff not in boot time, but by running something like update-last-good-boot in the preinst of all packages that change relevant files, and having update-last-good-boot exit if /var/run/updated-last-good-boot exists, create a new updated-last-good-boot snapshot and create the /var/run stamp so that subsequent updates during the current OS runtime donât change the last-good-boot (since the one weâre ...
<ion> ... about to unpack changes the files not to match with what weâre running).
<ion> s/new updated-/new /
<sistpoty|work> bdrung: anyway, as I tried to express, the dependencies of the -dev package aren't really too much of a problem, feel free to leave them as is for this upload (I doubt anyone will complain about dependency bloat of -dev packages)
<ion> keybuk: If the system manages to get into a state thatâs running a preinst of a package, the boot is *probably* âgoodâ.
<bdrung> sistpoty|work: i will fix it in debian. then it gets fixed by the next sync/merge
<sistpoty|work> bdrung: excellent, thanks!
<Keybuk> ion: that's how I keep telling people to implement it ;-)
<Keybuk> at least, roughly
<ogra> Keybuk, wasnt the "mountall goes into an endless loop if the clock is wrong" bug supposed to be fixed ?
<ogra> i thought we should end up in a maintanace shell now
<Keybuk> ogra: yes, it's fixed
<Keybuk> no, you end up with a plymouth prompt
<Keybuk> "fsck failed, what you want to do?"
<ogra> hmm, and if you dont have plymouth ?
<lamont> why doesn't my SD card show up anymore?
<ogra> i know that amitk saw the issue today on a beagleboard
<Keybuk> ogra: mountall Depends: plymouth
<ogra> and he definately didnt get any prompt
<ogra> ah, good
<ogra> he went into an endless loop
<ogra> the bad thing is that we support the beagle now but it doesnt have a battery at all to keep the clock
<Keybuk> it sounds like he was using an old version
<ogra> well, whatever was in the archive today
 * ogra would really love to just drop the pass 1 from /dev/root in /lib/init/fstab by default ... but i suspect several people would attempt to kill me then :)
<tseliot> Keybuk: I've fixed bug #553954 by modifying mountall, plymouth and other themes. How shall I proceed with the upload (e.g. bzr branches, etc.) for these 2 packages?
<ubottu> Launchpad bug 553954 in plymouth "[Lucid Beta 1] plymouth has a non translatable string coming up on screen" [Medium,In progress] https://launchpad.net/bugs/553954
<Keybuk> I'd like to review your patches first
<Keybuk> could you e-mail me the URLs to the relevant commits
<Keybuk> this is something that has a large breakage potential right before release
<Keybuk> so I think "additional eyes" review is worthwhile
<tseliot> Keybuk: absolutely, I'll send you an email
<sabdfl> rickspencer3: please can i ask for a late sync of the schroedinger package?
<sabdfl> to get 1.0.9
<sabdfl> i don't think there are any critical deps, but it's worth chacking in case that's a bad req
<rickspencer3> sabdfl, in team meeting atm
<rickspencer3> will ping back soon
<sabdfl> danke
<seb128> sabdfl, I was pondering syncing it while I did some GNOME sync before meeting but there was no bug open about it, any bug fixed or new feature we want in the update?
<tseliot> Keybuk: ok, email sent. Let me know if/when I can upload.
<tseliot> slangasek will get an email too
<Keybuk> tseliot: will review today
<tseliot> thanks
<deryck> ttx, ping
<Keybuk> bug #558865 is clearly a DFSG violation (restriction of endeavour)
<ubottu> Launchpad bug 558865 in bzr "crash on conquering military building" [Undecided,Invalid] https://launchpad.net/bugs/558865
<mathiaz> Keybuk: what's your plan for bug 552786?
<ubottu> Launchpad bug 552786 in upstart "initctl: lacks proper exit codes" [Medium,Invalid] https://launchpad.net/bugs/552786
<Keybuk> mathiaz: I don't have a specific plan
<Keybuk> I agree it's a bug, and that it should have proper exit codes
<Keybuk> but I have REAL BUGS to fix between now and release
<Keybuk> so I'm very unlikely to do it
<Keybuk> I will more than happily review patches though and provide all necessary advice
<maco> as opposed to....heisenbugs?
<Keybuk> mathiaz: the "open question" is, what are the exit codes when the job is starting and stopping? :)
<Keybuk> ie. if the job is start/pre-start ... it's not running, so should not exit 0
<Keybuk> but it's not "not running", so should not exit 1
<Keybuk> and stop/running is obviously running right now, but very soon won't be, so should not exit 0 probably
<Keybuk> I guess 0 := goal = start & state = running
<Keybuk> anything else can be 1
<Keybuk> (the states change for 1.0 anyway, so too much thought at this point is only going to be thrown away soon enough)
<mathiaz> Keybuk: right - I agree that returns 0 only if the process is running is enough
<james_w> kenvandine: which package for a music store bug?
<kenvandine> james_w, most likely libubuntuone
<kenvandine> or rhythmbox-ubuntuone-music-store
<kenvandine> but most of the functionality is in libubuntuone
<james_w> hmm, it's via banshee
<kenvandine> ok
<james_w> I'll test in rhythmbox
<kenvandine> libubuntuone
<kenvandine> :)
<james_w> yep, libubuntuone, thanks
<kenvandine> james_w, np
<seb128> sabdfl, new schroedinger synced
<sabdfl> thanks seb128
<zyga> mvo: hi
<zyga> mvo: did you manage to merge the other software-center branch?
<slangasek> mathiaz: /nonexistent> I think that's pretty ugly :)
<ccheney> NCommander: about to upload the new OOo with your change, did it seem to work so far?
<NCommander> ccheney: I didn't get a chance to try it
 * NCommander is not having the best day
<NCommander> ccheney: I just kicked a build, if you can wait 45 minuts for patch+configure, I can tell you to if it works
<ccheney> NCommander: ok
<ccheney> NCommander: ping me when you verify it works and i will upload it
 * ccheney is going to do a ooo-l10n test build before uploading
<NCommander> ccheney: thanks. The patch looks correct to you, right?
<ccheney> NCommander: it looks sane to me, whether it will actually work i don't know :)
<NCommander> ccheney: well, building to the point of failure takes two hours
<zul> slangasek: i updated the autofs5 upstart script fyi
<ccheney> NCommander: oh thats not bad, if you are going to be around long enough to see if it passe that point then just ping me then
<ccheney> NCommander: i'm always around on irc :)
<NCommander> ccheney: yeah, I'll be around. Its just waiting for OOo to configure takes eternity
<NCommander> ccheney: 'CFLAGS=-g -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions' 'CPPFLAGS='
<NCommander> didn't work
<NCommander> ugh
 * YokoZar waits for his package to be built...Launchpad first says build starts in 15 minutes.  Then 1 hour.  Then 30 minutes.  Now 5 hours.
<NCommander> ccheney: oh, I put ifneq versus ifeq (note to self: don't patch OOo at 8am in the morning)
<ccheney> NCommander: should be ifeq?
<NCommander> ccheney: if arch == armel, then pass -marm
<NCommander> the code as written is arch != armel :-)
<seb128> bug #554478
<ubottu> Launchpad bug 554478 in mountall "power g5 does not boot lucid beta" [Undecided,New] https://launchpad.net/bugs/554478
<seb128> does somebody known about this issue?
<ccheney> NCommander: ah heh
<NCommander> seb128: ENOG5 :-/
<seb128> (just asking because I've a GNOME upstream who is running into the issue)
<seb128> oh, Keybuk!
<seb128> Keybuk, you wouldn't have a clue of what issue could create bug #554478 or what info would be useful there?
<ubottu> Launchpad bug 554478 in mountall "power g5 does not boot lucid beta" [Undecided,New] https://launchpad.net/bugs/554478
<seb128> Keybuk, just trying to be nice to an GNOME upstream who is using ubuntu ;-)
<seb128> Keybuk, workarounds hints are welcome if you have some too
<Keybuk> if it's suspected to be a mountall bug, add --debug and capture that output
<chrisccoulson> is svu the only gnome upstream using ubuntu? ;)
<Keybuk> though by the looks of it, it's not a mountall bug
<Keybuk> it looks like it's passed that
<seb128> chrisccoulson, no, but still he's nice with us ;-)
<seb128> Keybuk, any idea what could be to blame rather?
<Keybuk> no, none
<chrisccoulson> seb128 - he is, but i think i scare him away ;)
<sabdfl> pgraner: who's a good person to chat with regarding a USB issue?
<Keybuk> oh, wait, "it reports failed mount"
<Keybuk> no idea on that
<Keybuk> The /dev/mapper/control file is the only file in /dev/mapper. Nothing else in that dir.
<Keybuk> seb128: ^ sounds like an LVM issue
<ccheney> NCommander: ifneq is right changing that causes it to be used on not arm
<ccheney> NCommander: and causes build to fail on amd64
<NCommander> ccheney: oops :-)
<NCommander> ccheney: I think I also need to set ARCH_CXXFLAGS
<seb128> hey svu
<seb128> Keybuk, thanks, I copied what you said to svu
<svu> seb128: hey
<Keybuk> I also copied it to the bug ;)
<svu> Keybuk: I was told it would be useful to capture --debug, right?
<seb128> svu, do you know what you upgraded just before getting the bug?
<Keybuk> svu: yes, that's always useful
<svu> Keybuk: is there anything I could check in dmesg?
<Keybuk> dmesg is unlikely to be helpful
<ccheney> NCommander: ok, well let me know once you get a working patch :)
<Keybuk> it looks, to me, like you're missing LVM device nodes
<svu> seb128: I think I upgraded both kernel and mountall - but not 100% sure
<Keybuk> you should have /dev/vg/lv -> /dev/mapper/vg--lv device nodes
<seb128> svu, did you try to boot previous kernel from grub?
<Keybuk> if there's nothing else in /dev/mapper other than control, that bit is likely to be broken
<svu> Keybuk: I will check /dev/vg
 * NCommander wishes he knew why SPARC didn't boot at all anymore past the kernel
<Keybuk> (where "vg" and "lv" are your volume group and LV names)
<seb128> svu, you have the upgrade in /var/log/dpkg.log too
<svu> seb128: it is power g5. there is no grub. there is yaboot. And If only I remember how to boot the prev kernel...
<seb128> svu, oh right...
<svu> Keybuk:  I see. The real vg and lv names...
<svu> (and my Power G5 gives me only couple of minutes. The fans turn ON and make horrible NOISE, then it turns itself off automatically! :)
<svu> and no boot from USB AFAIK
<svu> what a platform :)
<NCommander> svu: LinuxOLD at the yaboot prompt
<NCommander> svu: and it should support USB boot if you hold option down and theres a proper yaboot partition on the USB drive
<svu> NCommander: ghm. I should check about LinuxOLD. Not sure it is still there - I might have removed it:)
<NCommander> svu: heh. yaboot is pathetically limited compared to grub, or silo on SPARC
<svu> NCommander: I was told in Web, they ignore USB. Well, there are some tricks with OpenFirmware...
<NCommander> but thats because openfirmware sucks
<NCommander> (openfirmware on mac anyway)
<NCommander> svu: worse case, you have to drop into the OF propmpt, and insert some voodoo into nvramrc to get it to USB boot
<svu> Anyway, I am leaving for a moment, going to try  (If am not back, count me as communist:)
<svu> NCommander: yes, as I heard
<NCommander> svu: you can have a lot of fun in OF, but you've got to also like pain
<slangasek> zul: right, seen
<slangasek> Riddell: bug #523910> so there hadn't been an FFe granted yet, were you implicitly granting one with your sync?
<ubottu> Launchpad bug 523910 in python-reportlab "sync request (unstable -> lucid/main)" [Undecided,Fix released] https://launchpad.net/bugs/523910
<NCommander> ccheney: when do arch flags get passed into the OOo build, I don't see it on the ooo-build command line
<ccheney> NCommander: hmm not sure will take a look and see if i see where its done
<mathiaz> Keybuk: what do you think about http://bazaar.launchpad.net/~mathiaz/ubuntu/lucid/upstart/workaround-status-exit-code/revision/1273
<mathiaz> Keybuk: as a workaround the lack of proper exit code for initctl status command?
<ccheney> NCommander: around line 2147, i have a different version of rules than you though
<NCommander> ccheney: ugh, hrm
<ccheney> NCommander: two different places next to each other:
<ccheney> cd $(OOO_BUILD_TREE) ; PATH=$(BUILD_PATH) LD_LIBRARY_PATH=$(BUILD_LD_LIBRARY_PATH) DEFAULT_TO_ENGLISH_FOR_PACKING=1 ARCH_FLAGS=$(ARCH_FLAGS) TMP=/tmp $(MAKE)
<ccheney> with verbose on and off
<NCommander> ccheney: ugh, let me go to bzr packaging. I really don't think either one of us wants OOo uploaded twice :-)
<Keybuk> mathiaz: I think that's exactly the kind of work-around that I don't want to do
<Keybuk> not this late in a release cycle
<Keybuk> it's also wrong ;)
<ccheney> NCommander: yea
<NCommander> ccheney: (or at least, wait until this build gets to the actual configure/build --all stage)
<ccheney> NCommander: i haven't committed my most recent changes to bzr yet
 * Keybuk introduces mathiaz to the concept of translations
<Keybuk> (plus it silences all command output from a user POV)
<slangasek> Keybuk: so what did you figure out with the plymouth segvs?
<mathiaz> Keybuk: wouldn't LANG=C handle the translation issues?
<slangasek> Keybuk: and is it related to the deadlock identified in bug #554737?
<ubottu> Launchpad bug 554737 in plymouth "Graphical bootstrap hangs on fsck" [High,Triaged] https://launchpad.net/bugs/554737
<Keybuk> mathiaz: no, because then upstart-job would output everything in english
<Keybuk> slangasek: I don't know what that bug is
<Riddell> slangasek: yes, from talking to doko earlier today
<Keybuk> I have reached the point where, even if I sat here right now
<slangasek> Riddell: ok :)
<Keybuk> and for the next two weeks just read bugs and replied to them
<Keybuk> I would have more unread mails in my LP folder than when I started
<Keybuk> slangasek: would you like me to read that bug, or would you like me to talk to you about the process_pending_events() bug?
<slangasek> Keybuk: both
<Keybuk> ok, I shall read that bug first
<mathiaz> slangasek: what's your take on bug 562261?
<ubottu> Launchpad bug 562261 in krb5 "Sync krb5 1.8.1+dfsg-2 (main) from Debian unstable (main)" [High,New] https://launchpad.net/bugs/562261
<slangasek> they're both high-priority, targeted bugs, and as I say I have suspicions they may even be related
<mathiaz> slangasek: it seems that the ABI break wouldn't effect any package in the archive
<Keybuk> slangasek: I don't see how they can be related so far
<slangasek> Keybuk: fair enough
<Keybuk> according to the back trace I've just read, plymouthd in bug #554737 is blocked in write()
<ubottu> Launchpad bug 554737 in plymouth "Graphical bootstrap hangs on fsck" [High,Triaged] https://launchpad.net/bugs/554737
<slangasek> mathiaz: does the Debian plan include any binary package name changes?
<Keybuk> hmm
<Keybuk> bug #554737 is strange
<Keybuk> plymouthd is blocked in write()
<ubottu> Launchpad bug 554737 in plymouth "Graphical bootstrap hangs on fsck" [High,Triaged] https://launchpad.net/bugs/554737
<Keybuk> plymouth quit is blocked in epoll_wait()
<mathiaz> slangasek: I don't think so
<Keybuk> this should not be possible
<Keybuk> and mountall is blocked in write() too
<mathiaz> slangasek: I haven't review the extend of the ABI break
<slangasek> Keybuk: mountall is also running; the deadlock is between plymouthd and mountall, 'plymouth quit' is just waiting its turn
<mathiaz> slangasek: sam has been answering promptly to my requests
<Keybuk> slangasek: are you sure?
<slangasek> Keybuk: as sure as I can be without having had a chance yet to reproduce it locally
<Keybuk> at a guess
<Keybuk> ply_boot_client_flush() is flushing all pending writes
<Keybuk> but not reading the replies
<Keybuk> plymouthd is blocking on sending a reply before read()ing again?
<ccheney> NCommander: so you needed more than just -marm?
<slangasek> Keybuk: yes, that's what I think is happening
<NCommander> ccheney: not sure, maybe I'm loosing it, its going to start build --all in a moment and I'll look at the GCC line to see if I'm loosing it
<slangasek> mathiaz: no package name changes in unstable; what verification did you do that the ABI change doesn't hurt us?
<Keybuk> slangasek: makes sense
<Keybuk> I agree with your diagnosis then
<ccheney> NCommander: ok
<slangasek> Keybuk: ok - and that's unrelated to the other bug?
<mathiaz> slangasek: talking and trusting the debian maintainer
<mathiaz> slangasek: I haven't had time to get into deeper investigations
<Keybuk> slangasek: completely unrelated
<slangasek> Keybuk: ok - what's the story on bug #553745, then?
<ubottu> Launchpad bug 553745 in plymouth "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [High,Incomplete] https://launchpad.net/bugs/553745
<Keybuk> slangasek: just fixing status of this
<Keybuk> slangasek: do you want a go at fixing, or do you need me to?
<slangasek> I have time to follow through today
<Keybuk> my hunch for a fix; I have that function just calling the write() side of plymouthy stuff
<Keybuk> it probably instead should do the full thing
<svu> Keybuk: I attached my mountall results
<Keybuk> maybe even call ply_boot_client_process_pending_events() in a loop until there are no more pending requests
 * slangasek nods
<Keybuk> svu: remind me of the bug number
<Keybuk> slangasek: so SEGV bug
<Keybuk> do you know much about epoll?
<svu> Keybuk: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/554478
<ubottu> Launchpad bug 554478 in lvm2 "power g5 does not boot lucid beta" [Undecided,Incomplete]
<slangasek> Keybuk: a medium amount
<Keybuk> slangasek: so cliff's notes
<Keybuk> unlike poll, the kernel keeps track of the stack of fds you want to watch
<Keybuk> when you add an fd to the epoll, you pass in "data"
<Keybuk> when you call epoll_wait(), you get an array of all the "data" that matched
<Keybuk> in plymouth's case, the "data" is a pointer to a ply_source structure
<Keybuk> that points at the handlers and stuff to call
<Keybuk> so
<Keybuk> big array of pointers to ply_source (handlers)
<Keybuk> iterate the array, calling the handlers
<Keybuk> what if the handler frees watches? :p
 * slangasek nods
<Keybuk> what if those watches actually polled true this loop - and are later in the array?
<Keybuk> I talked to Ray this morning about it, and he has proposed http://cgit.freedesktop.org/plymouth/commit/?id=5daa29168df38b8b5f0f59b0c65a5740082e002a
<Keybuk> I think it'd be a good idea to update to 0.8.2 (lots of bug fixes) and add that patch
<Keybuk> and get some testing
<NCommander> ccheney: didn't work, can't even tell if ARCH_FLAGS got passed in
<ccheney> NCommander: hmm weird
<ccheney> maybe i should commit my changes to bzr and then you can try them out
<svu> Keybuk: does my output give any hints?
<NCommander> ccheney: yeah
<Keybuk> plymouth_connect: Failed to connect to Plymouth: Connection refused
<ccheney> NCommander: ok it should be there now
<Keybuk> svu: ^ that's a little odd
<ccheney> NCommander: its 6ubuntu1 unreleased tag
<ccheney> NCommander: commit 1286
<Keybuk> svu: but yes, clearly no LVM devices here - do you have /var/log/udev from that machine ?
<svu> Keybuk: nope. my /var is in different partition, so, no /var/log here. I can create it - will it populate all necessary files?
<slangasek> Keybuk: 0.8.2> none of the bugfixes jumped out at me as urgent; I agree that testing would be the most effective way to validate those changes, but am concerned about the timeline.  You don't think cherry picking the one reference-counting commit is appropriate?
<Keybuk> slangasek: well, in terms of fixing that bug, sure
<Keybuk> but a lot of the other fixes looked really key to me
<Keybuk> like fixing all the keyboard problems ;)
<NCommander> ccheney: grabbing
<Keybuk> svu: check /dev/.udev.log
<Keybuk> or something
<Keybuk> it usually hides there until /var is mounted
<slangasek> Keybuk: ok - nothing in the upstream changelog tickled my memory on known major bugs we have right now, but I'll defer to you on this
<svu> Keybuk: ok. I will try. Thanks
<Keybuk> slangasek: oh, I just looked at the git commits and they all looked quite sane
<slangasek> Keybuk: right - go for it
<slangasek> Keybuk: do you also have some time for bug #539655?
<ubottu> Launchpad bug 539655 in linux "nouveau hard lockup in nouveau_gem_ioctl_cpu_fini" [High,Triaged] https://launchpad.net/bugs/539655
<Keybuk> slangasek: I've been running "bzr merge-upstream" for the past 6 hours
<Keybuk> it's still running
<slangasek> (to talk with me about it)
<slangasek> heh
<Keybuk> slangasek: I can talk to you about it anytime
<Keybuk> here's the dump of stuff I know about it:
<Keybuk> --
<slangasek> heh
<Keybuk> :-)
<Keybuk> smb knows a bit more
<slangasek> <Keybuk> we still haven't tracked down the mysterious source of the ioctl()s that smb is adamant that Plymouth is making
<Keybuk> something to do with "the number of cpu gets that plymouth does is not the same as the number of puts"
<Keybuk> right
<james_w> Keybuk: the command is hung?
<Keybuk> so smb looked from a kernel POV
<Keybuk> and plymouth is apparently resulting in more gets than puts
<Keybuk> so "holds the card" at the point X tries to start
<Keybuk> this could be:
<Keybuk> - a nouveau bug (plymouth is correct, nouveau is wrong)
<Keybuk> - a libdrm bug
<Keybuk> - a plymouth nouveau renderer bug
<slangasek> what does the userspace side of that ioctl look like?
<Keybuk> - a plymouth drm renderer bug
<Keybuk> or none of the above
<Keybuk> but I still don't have OOTB working nouveau hardware
<Keybuk> so I've been able to do zero testing
<slangasek> right; I do
<Keybuk> slangasek: userspace side looks like libdrm function calls
<slangasek> I meant low-level - what are the ioctls in question?  (trying to work my way up from the libdrm-nouveau1 source)
<Keybuk> ie. src/plugins/renderers/drm/ply-renderer-nouveau-driver.c
<Keybuk> oh
<Keybuk> no idea there
<Keybuk> that's beyond my knowledge
<slangasek> ok, will circle around with smb when he's here
<slangasek> oh, he's here, just not here; will follow up with him
<NCommander> ccheney: build kicked
<Keybuk> I understand from a black box POV what plymouth does
<Keybuk> it creates a buffer onto which it can draw
<Keybuk> and has that buffer mapped to the virtual console
<Keybuk> (replacing fbcon)
<Keybuk> but I don't really understand the calls it makes or anything like that
<Keybuk> even from an intel pov
 * slangasek nods
<Keybuk> it could be a "deactivate" bug
<Keybuk> ie. at the point after deactivate is called, the nouveau driver for the drm renderer has more references open than is acceptable for nouveau
<Keybuk> intel needs a reference held otherwise fbcon reasserts
<Keybuk> nouveau is probably written assuming the same
<Keybuk> it may turn out that holding that reference is what prevents X from starting
<Keybuk> it may even turn out that it's therefore impossible to do a smooth transition with nouveau
<Keybuk> etc.
<Keybuk> it may be a kernel bug
<Keybuk> (that X can't start with that reference held)
<slangasek> right
<Keybuk> it's in that hideous area I fear to tred :p
<slangasek> I'll work on understanding the drm code and try some live debugging; probably won't get to it today
<Keybuk> I don't really "understand" this layer from a programming POV, just from a black box architecture POV
<Keybuk> and I fear that if I start to learn it, I'll end up maintaining X or something
<Keybuk> or Wayland <g>
<ccheney> NCommander: ok, i'm running a build to test ooo-l10n also, let me know what you come up with and i will do the upload in a few hours (or whenever yours is done testing)
<ccheney> NCommander: i think my ooo-l10n test will probably take a couple hours
<NCommander> ccheney: I flipped the ifneq to a ifeq
<ccheney> NCommander: if that works then the check itself must be flawed as when i had it the other way it was being used even for amd64
<NCommander> ccheney: oh, I'm building on armel ;-)
<NCommander> ccheney: its possible, I copied one of the other checks in the source and tweaked it
<Keybuk> james_w: poor internet connection ;)
<james_w> ah
<ccheney> NCommander: ok, will look into it once you see if the -marm bit fixes it at least, only takes about 5-10m to fail on amd64 if its not set right on my box, heh
<NCommander> ccheney: heh, it takes a good 30-45 minutes ;.;
<ccheney> NCommander: so it should be easy enough to verify it doesn't break other things
<ccheney> only takes me 30m for a full OOo build (not ooo-l10n) :)
<ccheney> well as i have ccache primed
<ccheney> a lot of that time is spent in the shlib stuff too i think
<NCommander> ccheney: heh
<ccheney> and then running lintian and compressing the lzma debs, etc :)
<ccheney> the build itself seems to be fairly small part of the 30m
<ccheney> i wish the lzma compression was threaded
<lamont> persia: fpc is building on ppc now. armel gave http://paste.ubuntu.com/413787/
<joaopinto> thinking on a rollback sysem for dpkg, would it be as trivial as backing up all the files contained on a package before the upgrade and restoring them for the rollback (applying this recursively to dependencies) ?
<ajmitch> no, because maintainer scripts can do arbitrary things
<joaopinto> right, I know I was missing something
<joaopinto> so it would be FS snapshot based
<joaopinto> need to be
<micahg> joaopinto: etckeeper is good for helping with that
<joaopinto> micahg, it doesn't help much to revert upgrades
<svu> Keybuk: attached udev.log
<svu> https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/554478
<ubottu> Launchpad bug 554478 in lvm2 "power g5 does not boot lucid beta" [Undecided,Incomplete]
<joaopinto> hum, files created/changed from maintainer scripts could be identified on system calls (checkinstall alike) and also be backed up
<ccheney> NCommander: is our arch called armel or arm?
<ccheney> NCommander: i see another reference to filtering for arm that had both in it
<joaopinto> if those files were changed manually after the newest package install then user prompt would be required
<joaopinto> I am I missing something :) ?
<ccheney> NCommander: eg the code that sets the ICU flags for arm
<NCommander> chrisccoulson: armel
<NCommander> er
<NCommander> ccheney:
<chrisccoulson> ;)
<ccheney> NCommander: well comparing the other uses of ifneq (,$(filter $(ARCH), foo))  the foo is what it applies to code to afaict
<ccheney> NCommander: eg the openjdk-6-jre java runtime depends list, etc
<Keybuk> svu: your log confirms that no dm-X devices are being created in the kernel
<svu> Keybuk: lovely. So, is there workaround?
<Keybuk> no idea
<Keybuk> it's LVM
<Keybuk> my jurisdiction stops at the state line between sane things and LVM ;-)
<svu> :)
<svu> so, should that bug be reassigned to LVM? who should I talk to?
<Keybuk> I've reassigned the bug to LVM
<svu> and who would be my next person to talk to, if you happen to know?
<seb128> svu, the lvm2 source didn't change for 8 weeks, did you try to boot the previous kernel?
<Keybuk> svu: no idea on that
<svu> seb128: I did. same result
<Keybuk> I don't think anyone is maintaining LVM right now
<svu> seb128: my system broke ~2 weeks ago
<seb128> svu, did you try to look in the dpkg.log what you updated just before getting the issue?
<Keybuk> dpm-afk: bug #559997 probably warrants a UDS session?
<ubottu> Launchpad bug 559997 in mountall "Mountall needs to generate pot file on build" [Medium,Triaged] https://launchpad.net/bugs/559997
<svu> seb128: I just found. it was ~2 Apr
<svu> seb128: nope. ghm, I'm afraid it is on one of those volumes I cannot access
<seb128> svu, :-(
<svu> well, I can access them, booting from CD. For 2 mins - till my fans turn the system off
<svu> I can try that...
<sladen> svu: if when you boot from CD (eg. older versions), does the mapper find them
<svu> yes
<svu> can I can mount them
<svu> and I actually did apt-get upgrade on mountall
<svu> and linux kernel
<svu> but that did not help
<sladen> so the 2 minutes is because ACPI/throttling/similar is not being loaded?
<seb128> Keybuk, the packages using cdbs have their template updated by langpack.mk, we will do something similar for dh7, other packages in main not using those should update the template in their rules
<sladen> svu: sudo apt-get update --reinstall mountall
<svu> sladen: yes. perhaps. my Power G5 turns ALL fans on. Horrible noise. And after 2 mins the system turns off
<svu> sladen: why not. will try that. But Keybuk  says it is not mountall, it is most probably lvm. but it is worth trying anyway...
<sladen> svu: as in  http://www.macintouch.com/readerreports/powermacg5/index.html
<sladen> svu: or are we talking another type of G5 ?
<svu> sladen: well, http://www.everymac.com/systems/apple/powermac_g5/stats/powermac_g5_2.0_dp.html
<svu> no, this one: http://www.everymac.com/systems/apple/powermac_g5/stats/powermac_g5_2.0_dp_2.html
<Keybuk> seb128: right, it's the dh7 things I'm thinking of
<Keybuk> if it's the case where everything needs to "make -C po update-po" somewhere, then it's the kind of thing that should be done automatically
<Keybuk> sladen: the bug is clearly unrelated to mountall
<Keybuk> the logs show no devices in /dev/mapper
<seb128> Keybuk, we usually do it by calling intltool-update but right
<Keybuk> seb128: an interesting question is where that should be done, of course
<Keybuk> if the .pot is in the tarball (which it always is)
<Keybuk> then you need to run it on "debian/rules clean"
<Keybuk> since you need to commit the changes to bzr
<Keybuk> but if you have a patch system, you *also* need to run it after the patches are applied
<Keybuk> (or on build somewhere)
<seb128> right not we run it after build (at least in the cdbs version)
<Ng> if I had a lucid machine (packages a few days out of date) boot up and do a routine fsck, finish and mount / rw, but plymouth still think fsck was at 70% forever, what would I file that against? :)
<seb128> which should always be right for launchpad import
<Keybuk> Ng: you should read the list of duplicate bugs first
<Keybuk> Ng: though, since you're here
<Keybuk> Ng: can you run "ps" on that machine for me
<Ng> unfortunately it's not still in that state, but perhaps I can provoke it - do we still support /forcefsck?
<Keybuk> Ng: we do
<seb128> Keybuk, what are you looking for in the ps in case I get the issue again there? (I got it yesterday on a box)
<Keybuk> seb128: whether plymouthd is still running, whether plymouth commands are still running and whether mountall is still running
<seb128> k, noted
<Keybuk> if they are, it's a dup of bug #554737
<ubottu> Launchpad bug 554737 in plymouth "ply_boot_client_flush() does not read replies (plymouth stuck during/after filesystem check or error)" [High,Triaged] https://launchpad.net/bugs/554737
<Keybuk> if not, it isn't
<Ng> aha, rebooted with forcefsck and it looks like it's done it again
<Keybuk> Ng: "ps" output?
<Ng> Keybuk: plymouthd is running, there's a "plymouth quit" running, mountall is running
<Keybuk> Ng: sweet
<Keybuk> Ng: then you have the same bug
<Keybuk> kill the plymouth quit and mountall processes
<Keybuk> tbh, killing mountall is probably enough
<Ng> Keybuk: http://pastebin.com/cEfCkVkh fwiw
<Keybuk> actually yes, only kill mountall
<Ng> ta :)
<cjwatson> seb128: the right way to do this with dh7 would be for something to provide a langpack addon, so you'd do dh --with langpack
<cjwatson> that's basically equivalent to include langpack.mk
<Keybuk> cjwatson: I can't figure out a way to do this in debian/rules sanely *at all*
<cjwatson> seb128: /usr/share/doc/debhelper/PROGRAMMING.gz has docs on writing sequence addons, near the end
<seb128> cjwatson, we don't want to patch every rules to list it though
<cjwatson> mm, joeyh gets really upset when we patch debhelper to behave substantively differently from Debian; I assume the cdbs maintainer doesn't
<seb128> cjwatson, with cdbs we make gnome.mk which is used in most desktop packages include langpack.mk
<cjwatson> well, why not have a '--with gnome' then?
<cjwatson> and have it provide whatever semantics you want in the desktop
<seb128> because gnome packages still use cdbs in debian and ubuntu ;-)
<seb128> but right if GNOME ever migrates to dh7
<cjwatson> sure, but --with gnome is the equivalent of gnome.mk, that's all I'm saying
<Keybuk> cjwatson: but this doesn't just affect gnome packages
<seb128> I'm thinking we should maybe figure something out of the packaging system though
<Keybuk> this affects every single package for which we patch the source
<Keybuk> including those we wrote ourselves ;)
<cjwatson> Keybuk: not that simple because po files live in different places
<Keybuk> and that's regardless of the fact that there's no sane way to do this
<cjwatson> and it only affects those for which we made string changes
<cjwatson> and those for which the string changes actually matter
<Keybuk> I can't figure out how to do it at all for mountall
<seb128> cjwatson, lot of upstream tarballs don't ship a template too or some ship an outdated one
<cjwatson> (e.g. grub2, really doesn't matter that much if the two new rarely-hit error strings get translated or not)
<cjwatson> seb128: well, ok, but lots of them do it right as well
<seb128> Keybuk, run intltool-update manually and commit the update?
<cjwatson> I don't think the scale is actually all that bad
<Keybuk> seb128: there's no intltool here
<cjwatson> most of the packages where it matters, we're modifying them already
<seb128> Keybuk, you don't use intltool?
<Keybuk> no
<cjwatson> seb128: most non-desktop packages don't use intltool for translations
<seb128> oh ok
<cjwatson> gettext has an update-po target, I thought
<Keybuk> cjwatson: where do you run that? :p
<cjwatson> hooked from make dist
<Keybuk> the pot file is in the source tarball
<cjwatson> you run gettextize and it sets it up for you ...
<Keybuk> so running it in build/binary is pointless
<Keybuk> and you can't run it in clean, because there's no po/Makefile
<cjwatson> I don't really believe in this business of generating pot at build time, if the upstream is sane
<seb128> Keybuk, run make update-po and commit the update as a source change?
<cjwatson> if we're upstream, we should just ship a sane pot upstream
<Keybuk> seb128: requires every uploader to remember to do that
<Keybuk> cjwatson: how do you *generate* that
<seb128> everybody doing a string change yes...
<Keybuk> again, fundamental problem being missed
<cjwatson> you just do it occasionally as a maintenance task, string changes are relatively infrequent
<Keybuk> it requires every single person patching mountall to remember to run "make -C po update-po"
<cjwatson> huh?  that doesn't make sense to me
<Keybuk> (and have the entire mountall deps list installed - which is often impossible)
<Keybuk> why not
<cjwatson> because that's not how e.g. man-db works
<Keybuk> how does man-db work?
<cjwatson> people patching it upstream don't have to run that
<Keybuk> mountall is native
<cjwatson> because I check the damn generated files into bzr because I do not love pain
<cjwatson> native/non shouldn't matter ...
<Keybuk> so where do I put this in debian/rules ?
<Keybuk> I don't know where/how
<cjwatson> I leave it the hell out of debian/rules :-)
<GrueMaster> who can reenable partimage builds for amd64?  It has been down since hardy (if I read bug 198724 correctly).  I rebuilt it for karmic on amd64 and it is working fine.  The bug report says someone has it working for lucid as well.
<Keybuk> you clearly do
<ubottu> Launchpad bug 198724 in partimage "[amd64] partimage not synced or build" [High,Confirmed] https://launchpad.net/bugs/198724
<Keybuk> cjwatson: so where does it go?
<cjwatson> I let automake/gettext take care of it, and ignore it
<Keybuk> because right now, no fucker even remembers to bump the version properly ;-)
<Keybuk> automake never runs gettext
<cjwatson> I just occasionally run update-po when I can be bothered
<cjwatson> po/Makefile takes care of spitting out reasonably correct po files
<cjwatson> if I'm feeling disciplined, I run update-po after making string changes
<Keybuk> yeah, I don't want to depend on someone remembering to run update-po
<Keybuk> because that won't happen
<cjwatson> it isn't necessary otherwise
<Keybuk> I could add a debian/rules check I guess
<Keybuk> so build fails if you've forgotten to run it
<cjwatson> then you have your top-level makefile run it as part of all, and anyone who does a test build will have it run
<Keybuk> but test builds are done in pbuilder
<cjwatson> that works, it tends to create annoying changes in po/pot headers all the time which is why I don't
<Keybuk> which means the updated pot file gets lost
<cjwatson> it only needs one developer to do them outside pbuilder :)
<Keybuk> this is my basic problem
<Keybuk> yes
<Keybuk> and I *don't*
<primes2h> Keybuk: try asking dpm about it as well. He can probably suggest you something I think.
<Keybuk> I can't find a way for my workflow to work
<cjwatson> doing it in debian/rules clean seems not unreasonable given your use model
<Keybuk> cjwatson: that would require running configure in debian/rules
<cjwatson> it's part of preparing the source package for shipping
<Keybuk> and again, I can't install mountall's dependencies on the machine I work on mountall on
<Keybuk> so again
<Keybuk> can't be done
<Keybuk> configure will fail
<Keybuk> clean will fail
<Keybuk> etc.
<cjwatson> it should be possible to do an update-po equivalent without having configured, really
<Keybuk> yeah, but is isn't ;-(
<cjwatson> it's just a bunch of xgettext calls
<cjwatson> you could pull it out into a separate script if you wanted
<cjwatson> in fact, some packages just have their own trivial implementation of it
<cjwatson> see e.g. debconf/po/Makefile
<cjwatson> obviously gettext's Makefile.in.in is optimised for being generic
<svu> obviously, --reinstall did not help. neithe upgrade to the latest kernel
<Keybuk> hmm, that's an idea
<Keybuk> but pretty crappy
<cjwatson> Keybuk: FWIW, mind you, all that the langpack stuff in Ubuntu requires is that the pot be up to date at the end of the build
<Keybuk> cjwatson: ohhh, does it?
<Keybuk> I thought it got it from the source tarball from what dpm-afk said
<cjwatson> so while I can't be bothered with the pratting about involved in doing that (and the inevitable unclean build trees you tend to end up with if you do build/clean in bzr), it's workable
<cjwatson> probably works better if you do out-of-tree builds
<cjwatson> that's what seb128 was talking about with langpack.mk just doing it after build
<cjwatson> seb128: if gnome ever migrates to dh7> http://people.debian.org/~cjwatson/dhstats.png, I know which trend I think is the interesting one ... ;-)
<seb128> Keybuk, no, it get it from the build dir after build
<Keybuk> ahh
<seb128> cjwatson, right, should rather be "when" ;-)
<cjwatson> heh
<quidnunc> ifhp doesn't seem to show up in the repositories (e.g via apt-cache search) but it is not listed as removed here https://launchpad.net/ubuntu/+source/ifhp
<quidnunc> What give?
<quidnunc> What gives?
<cjwatson> it's only built on sparc
<quidnunc> It won't be available on x86?
<cjwatson> dunno guv, I just work here.  bit of patience and I'll see if I can track down more detail
#ubuntu-devel 2010-04-14
<quidnunc> Compile fails for me on x86
<cjwatson> yes, I think that build failures had something to do with it
<cjwatson> we recently removed a bunch of stuff that didn't build
<cjwatson> if somebody fixes the build failure, it can be put back
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2010-March/030509.html
<bdrung> now i understand: evolution does not search in attached files. therefore i did not find this email
<cjwatson> well, doesn't look like too difficult a failure, I'll have a poke
<quidnunc> cjwatson: Thanks for the info
<cjwatson> yes, transposed arguments to memset
<cjwatson> couple more problems, I'll finish it tomorrow
<quidnunc> Thanks cjwatson
<slangasek> mathiaz: FFe done
<bdrung> slangasek: bug #493805
<ubottu> Launchpad bug 493805 in ubufox "FFe: ubufox 0.8 leaves FF 3.0 folder in /etc" [Low,New] https://launchpad.net/bugs/493805
<svu> Keybuk: should the bug status be changed from Incomplete to something different?
<Keybuk> svu: unknown
<svu> perhaps
<svu> "Incomplete" means I have to provide something - but I answered all questions for a moment
<Keybuk> well, I'd disagree there ;-)
<Keybuk> "Incomplete" to me always means that the bug lacks sufficient information to diagnose it
<Keybuk> but then others would argue that "Confirmed" means that
<Keybuk> etc.
<svu> I see your point
<svu> there are different substates
<svu> "need info" = "I asked you, waiting for info"
<svu> and "need info" = "we do not have enough info and we do not know what info we need" ;)
<slangasek> bdrung: why does that need an FFe to fix?
<bdrung> slangasek: asak thinks that this is a huge (in terms of regression potential) change and that the bug is fix is a "new feature"
<slangasek> bdrung: ok; will look at the bug in a bit
<bdrung> thanks
<bdrung> slangasek: FYI i will meet my bed soon.
<_silentAssassin> allchan say goodnight
<slangasek> bdrung: doubtful that I'll get it before you go to bed then, sorry
<slangasek> maybe another release teamer is free
<bdrung> i will respond tomorrow, if there are questions
<slangasek> ok
<slangasek> bryceh: why does xserver-xorg-video-displaylink have Breaks: xf86-video-displaylink ?
<slangasek> (lintian flags a warning for this)
<bryceh> slangasek, to get it to not install alongside that package but to replace it
<slangasek> bryceh: if you want to force the removal of the other package, that should be Conflicts:
<slangasek> Breaks: only forces deconfiguring, I'm not sure it's defined to remove the package
<RAOF> So, last time I tried this, lifeless came in and said that Breaks in the One True Way and pointed at policy.
<bryceh> slangasek, in my original packaging I had Conflicts and no Breaks
<robertzaccour> RAOF, hey man
<robertzaccour> RAOF, bug free system from what i can tell now :)
<slangasek> RAOF: I'm pretty sure policy doesn't say anything about using Breaks: to force packages off the system
<bryceh> slangasek, so I think the Breaks may be something Persia added
<slangasek> hmm
<slangasek> persia: ^^ huh? :)
<RAOF> That's what I thought, too, and my reading of policy didn't make it clear either.  My hope was that lifeless would pop up, carry on a detailed discussion with you, and I'd become wiser by osmosis :)
<robertzaccour> RAOF, i see the duplicate bug noticication. is it the same graphics card as the leveno?
<robertzaccour> hopefully the fix is included in the updates so the others can get it gone as well :)
<slangasek> RAOF: in fact, reading policy pretty much confirms what I'm saying.  If you want to declare that a package should be removed, use Conflicts.  If you want to enforce upgrade order, use (versioned) Breaks.
<robertzaccour> i want pidgin to be default over empathy :)
<robertzaccour> maybe that will happen, this late doubt it though
<slangasek> it certainly won't
<robertzaccour> so whats the reason for empathy? just curious. it doesn't have all the features pidgin does
<RAOF> And similarly, pidgeon doesn't have all the features empathy does.
<robertzaccour> but one does have more than the other
<ion> [citation needed]
<robertzaccour> huh?
<robertzaccour> i think skype would be a good default also
<ion> Yeah, someone really should release a free implementation.
<RAOF> You mean, like Empathy? :)
<robertzaccour> so why is empathy the default?
<directhex> pidgin's crap for a/v. empathy does webcam chats
<robertzaccour> directhex, for yahoo?
<jdong> and it also has outstanding open denial-of-service attacks over MSN!
<jdong> *cough*
<jdong> oh yeah a couple poor souls are try: except: pass'ing the entire codebase :)
<directhex> robertzaccour, no. "Voice and video call using SIP, XMPP, Google Talk and MSN."
<robertzaccour> is yahoo in the works?
<RAOF> Doesn't yahoo use XMPP now?
<micahg> directhex: pidgin's web support seems decent now for xmpp
<robertzaccour> i dunno, don't think so
<micahg> *webcam
<directhex> micahg, can't say i've tried recently
<RAOF> How easy is it to share your desktop with pidgin?
<directhex> micahg, i think i prefer pidgin by and large, but not enough to change to it
<RAOF> (Also, how easy is it to share your Banshee library with pidgin? :))
<micahg> RAOF: I didn't know that's possible with any client?
<micahg> directhex: I never switched away from it :)
<directhex> micahg, the banshee bit definitely works... i think it was last year's gsoc?
<RAOF> micahg: I'd suggest firing up empathy and hitting the âshare my desktop with this contactâ button, then :)
<robertzaccour> i don't share my desktop with anyone
<robertzaccour> i can see that its useful for some though
<MattJ> "It's all MINE!"
<micahg> RAOF: is it the whoole desktop or just parts?
<ion> I shared my desktop with a contact and he totally my entire desktop.
<MattJ> I think Pidgin is doing better nowadays in terms of maturity, but I think having Empathy as the new default will give it a chance to mature a bit too
<directhex> i heard pidgin was having cathedral issues
<robertzaccour> pidgin and empathy devs seem to not be very concerned about yahoo implementations
<MattJ> I still find it awkward to use full-time (well, I find the same of Pidgin, so...)
<robertzaccour> whats cathedral issues?
<MattJ> robertzaccour: Good :)
<robertzaccour> MattJ, good? how so?
<RAOF> And the telepathy framework that Empathy's built on is just much more interesting - see âStream my banshee library to contactsâ, desktop sharing, gnome-games multiplayer, etc.
<directhex> robertzaccour, read "the cathedral and the bazaar"
<MattJ> robertzaccour: Never mind, OT for this channel I think :)
<directhex> RAOF, gbrainy deathmatch!
<RAOF> :)
<RAOF> directhex: I challenge you to a Quadrapassel dual!
<directhex> RAOF, did you see what i was working on today?
<robertzaccour> so there's no plans for upgrading the yahoo protocol for video/voice chat?
<RAOF> No.  I see, however, that miguel is getting psyched about mono 2.8, filled to the brim with DLR and awesome
<directhex> RAOF, http://i.imgur.com/auhrX.png -> http://i.imgur.com/9j9ah.png
<ajmitch> RAOF: so there'll be interesting mono crack in 10.10?
<directhex> robertzaccour, i don't know how many developers care about yahoo support, to be frank
<DnaX> Can be synced Postr 0.12.4 from Debian? Is only a bug fix release. There are LP: #531275.
<ubottu> Launchpad bug 531275 in postr "New version needs packaging" [Undecided,New] https://launchpad.net/bugs/531275
<robertzaccour> directhex, whats wrong with yahoo?
<RAOF> ajmitch: Most assuredly!
<directhex> robertzaccour, nobody uses it?
<robertzaccour> directhex, its the most widely used messenger right?
<ion> [citation needed]
<robertzaccour> i use it, almost everyone i know uses it
<directhex> robertzaccour, nowhere near
<robertzaccour> well then maybe its a big tennessee, florida, wisconsin, california, and kentucky thing lol
<directhex> less than half the user base of AIM
<directhex> in 2006
<directhex> and shrinking
<robertzaccour> directhex, really?
<ajmitch> DnaX: looks reasonable, but there look to be ubuntu changes that'll need to be integrated, so it won't be a straight sync
<robertzaccour> i'm pretty sure yahoo is the most used
<robertzaccour> brb
<directhex> http://envolve.com/blog/wp-content/uploads/2010/04/global_im_market_share_stats_july_08.pdf
<directhex> i'm pretty sure you have no basis whatsoever for making that claim, other than immediate anecdotes
<ion> Why are Jabber and Google Talk separate in that chart, i wonder?
<DnaX> ajmitch: seems 2 simple patch
<robertzaccour> empty link
<directhex> moar raw stats on http://spreadsheets.google.com/ccc?key=p5D5M7Vy6XNdfLH8xX9lbHw&hl=en
<MattJ> They also pre-date Facebook :)
<directhex> getting figures is hard. there are reports available, for $1500
<MattJ> For $1600 I'll give you some random figures
<robertzaccour> directhex, oh ok thanks
<robertzaccour> is that list current?
<directhex> no.
<directhex> current will cost you over a thousand dollars
<robertzaccour> no way lol
<ajmitch> these figures matter to advertisers & the like :)
<directhex> precisely
<robertzaccour> i know in America if yahoo isn't top its close to it
<directhex> expensive "trade secrets"yahoo is second in the USA, slightly above third-place MSN. it's top in India, Indonesia, and Saudia Arabia
<directhex> bah
<directhex> yahoo is second in the USA, slightly above third-place MSN. it's top in India, Indonesia, and Saudia Arabia
<robertzaccour> directhex, doesn't that mean importance for devs?
<directhex> robertzaccour, to indonesian, indian, and saudi devs, yes
<robertzaccour> most Ubuntu users are Americans, right?
<directhex> not really.
<robertzaccour> skype is my favorite overall, don't know a lot of peopole that use it though
<directhex> skype is proprietary, and will never be included in an ubuntu install
<MattJ> For my part as a developer I wouldn't contribute to Yahoo protocol support because I don't agree that we need to encourage the use of proprietary protocols in open-source
 * RAOF was *sure* Yahoo was transitioning to XMPP
<directhex> people work on protocol support for things to scratch their own itches. if i need to talk to someone using QQ< i work on QQ support - and because protocol distribution is highly regional, i'm probably in China whilst doing it.
<robertzaccour> imo skype has the best quality audio and video and theme look, and its free in price, so its good to me
<directhex> robertzaccour, you are free to use skype, but it conflicts with the ubuntu philosophy and isn't acceptable in the distro
<MattJ> robertzaccour: Either way I'd rather work on helping get open software and protocols up to that level of quality :)
<RAOF> robertzaccour: With the *tiny* problem that we can't legally include it in Ubuntu, and wouldn't include it by default because it's closed source (and not needed to make computers work).
<MattJ> and am doing just that, in fact
<robertzaccour> i use what works best for me whether it be the OS or the software thats installed. Open source is great, however usability for me ranks a little higher. having both would be great though
<directhex> MattJ, it's not really a question of that though - the thing with IM protocols is you need to use what $FRIEND uses, or you can't talk to them. if you're chinese, you use QQ. if you're Turkish, you use MSN. if you're russian, you use ICQ. like identi.ca vs twitter, the value is in the network itself, not in what the network allows
<robertzaccour> oh i think twitter is lame. thats just my opinion though
<MattJ> directhex: As someone who dropped a contact list of ICQ contacts telling them that if they wanted to contact me they would find me on Jabber, I know that's not strictly always the case :)
<directhex> how many of them followed?
<MattJ> A handful out of a hundred, the rest didn't want to speak to me that desperately it turns out :)
<MattJ> I just realised it was hypocritical to promote free software while using proprietary networks and protocols
<MattJ> Where "using" is as good as "supporting"
<MattJ> Because while people use them, the less likely other people are to switch
<MattJ> So I like to think I've done my part :)
<robertzaccour> MattJ, i'm not against open source, quite the contrary actually. its just that usability for me is priority, thats why i use skype
<slangasek> well, as that's not the order of priorities for Ubuntu, I think this conversation is quite off-topic
<robertzaccour> its a good thing we're not restricted on what we can install thats for sure
<robertzaccour> i think skype is the only application i use thats not open source
<robertzaccour> oh and my wireless driver
<DnaX> ajmitch: so, about postr?
<ajmitch> DnaX: someone needs to spend time to merge the changes & get it uploaded
<DnaX> if I do this task, you are MOTU to upload?
<ajmitch> yes, or you can subscribe ~ubuntu-sponsors
<DnaX> ajmitch: the problem is the final freeze!
<ajmitch> yep :)
<DnaX> ajmitch: can I send you the updated debian dir for Postr?
<lifeless> james_w: around ?
<lifeless> jono: or you ?
<FeasibilityStudy> I keep getting kernel errors on Lucid, but I can't diagnose them because apport keeps saying permission denied.
<robertzaccour> FeasibilityStudy, did you type sudo first?
<FeasibilityStudy> It doesn't allow you to type sudo..I just pops up a dialog box saying kernel error..  When i click details, it wont finish
<FeasibilityStudy> I get something like IO13error or some such error
<robertzaccour> FeasibilityStudy, oh that sucks, i don't know what thats about
<FeasibilityStudy> have you heard of this problem?
<robertzaccour> FeasibilityStudy, no i haven't
<FeasibilityStudy> nothing shows up in my logs either, so I have no way of finding out what the error even is
<robertzaccour> with the help of others in the community I did help fix a bug that i had
<micahg> directhex: GRE patch is needed
<persia> slangasek: seems I've misinterpeted policy 7.3 and 7.4.  I'll fix that.
<slangasek> persia: ok :)
<pitti> Good morning
<ajmitch> a belated good morning to you pitti :)
<pitti> hey ajmitch, how are you?
<micahg> pitti: good morning, I get this when I upgrade my langpacks, should I file a bug: http://pastebin.ubuntu.com/413328/
<pitti> micahg: seems rather harmless, but it's an easy fix
<pitti> (we don't need to reload gdm any more)
<pitti> micahg: so please go ahead
<ajmitch> pitti: good thanks
<micahg> pitti: where should it go?
<pitti> micahg: langpack-locales
<micahg> pitti: thanks
<micahg> pitti: is that a project?
<pitti> micahg: please assign to me
<pitti> micahg: no, it's an ubuntu package
<pitti> micahg: it's a bug in /usr/share/locales/install-language-pack
<micahg> pitti: ubuntu-bug wouldn't let me report on it...I'll file in LP interface
<pitti> micahg: oh, ubuntu-bug locales
<pitti> but yes, LP interface is fine
<pitti> micahg: langpack-locales is the source for the locales package
<micahg> pitti: ah, right, and it was decided not to overload for source package :)
<micahg> pitti: target for lucid release?
<pitti> micahg: not necessary I think; it's just cosmetical
<pitti> (I'll get to it, though)
<micahg> pitti: k, done bug 562795
<ubottu> Launchpad bug 562795 in langpack-locales "reload of gdm fails on langpack upgrade" [Wishlist,Triaged] https://launchpad.net/bugs/562795
<pitti> micahg: thanks
<micahg> pitti: np, now I think I have to go to sleep :)
<micahg> pitti: that's real service 11 minutes from filing to archive :)
<pitti> micahg: :)
<dholbach> good morning
<hyperair> YokoZar: what do you think about the winepulse patches?
<YokoZar> hyperair: I've tested them and still see the same audio issues
<hyperair> YokoZar: ah i see. what issues are they?
<slangasek> I need a volunteer who can reproduce bug #554737 reliably, any takers?
<ubottu> Launchpad bug 554737 in plymouth "ply_boot_client_flush() does not read replies (plymouth stuck during/after filesystem check or error)" [High,Triaged] https://launchpad.net/bugs/554737
<YokoZar> hyperair: constant pulseaudio popping, like the soundserver is restarting over and over
<hyperair> YokoZar: that sucks. did you notice similar issues with the alsa-pulseaudio plugin?
<YokoZar> hyperair: yes, that's the default and it's why Wine developers have believed pulse to be broken for years
<YokoZar> although to be fair it wasn't until karmic that it would constantly pop as before it would just not go at all
<YokoZar> https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/502375  is still live too
<ubottu> Launchpad bug 502375 in wine1.2 "Wine randomly cannot initialize sound [mmap() failed: ]" [Undecided,Confirmed]
<hyperair> hmm weird.
<hyperair> i'm on karmic, buti  don't get those pops
<hyperair> just that certain apps stutter like hell.  i seem to have gotten around that by switching to esound though
<pitti> urgh, esound!?
<hyperair> pitti: the esound backend.
<hyperair> pitti: pulseaudio has esound compat, remember?
<pitti> ah, *phew* :)
<hyperair> did you *really* think anyone would switch from pulseaudio to esound?  =p
<ion> The author of esound perhaps
<pitti> hyperair: I seriously hoped that I just misunderstood it :)
<hyperair> heheh
<hyperair> ion: is esound still maintained?
<Tm_T> hey, some people still misses arts too (and that was bad)
<hyperair> my, my
<crimsun> hyperair: YokoZar: pitti: err, that's usually an indication that your *sound driver* is utterly broken
<crimsun> in every case so far, David H and I have fixed both the pulse alsa-plugin and the pulse bits
<hyperair> crimsun: nah, i get stuttering sound when piping sound from certain wine apps to pulseaudio. i'm thinking wine's directsound->pulseaudio implementation is screwed.
<hyperair> i mean directsound->alsa->alsaplugin->pulseaudio pathway
<hyperair> unless i close everything and restart pulseaudio
<crimsun> hyperair: I'd try to reproduce that using linux-alsa-driver-modules-$(uname -r) from ppa:ubuntu-audio-dev
<YokoZar> Yeah since Karmic I regularly have to close everything AND THEN killall -9 pulseaudio to get Wine to start working again
<hyperair> crimsun: i don't use a stock kernel. those modules won't work for me.
<hyperair> crimsun: where do they come from? perhaps i could compile them during my kernel-compilation rounds
<crimsun> control.d/flavour-control.stub: snapshots from http://kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-snapshot.tar.bz2
<hyperair> crimsun: or better yet, is there a set of modules packaged with dkms support for this?
<hyperair> crimsun: tiwai? i remember seeing a git tree like that.. if i merge from that would it give me that?
<crimsun> dkms is slated for sid -> 10.10
<hyperair> crimsun: what do you mean?
<crimsun> hyperair: roughly, yes, building from master HEAD of sound-2.6 should get you the same
<hyperair> crimsun: ah okay.
<hyperair> crimsun: i'll just merge that in thhen.
<hyperair> crimsun: but the last time i did that, i got some pretty serious skipping issues.
<crimsun> hyperair: I mean that there is not DKMS-ized source yet; Elimar and I are working on that for Sid.
<slangasek> pitti: morning - were you among those able to reproduce bug #554737?
<ubottu> Launchpad bug 554737 in plymouth "ply_boot_client_flush() does not read replies (plymouth stuck during/after filesystem check or error)" [High,Triaged] https://launchpad.net/bugs/554737
<crimsun> hyperair: I can't speak for WINE itself, but without using the newest bits, it's more difficult to eliminate the driver as a pitfall.
<slangasek> I'm missing something, because I've been trying all evening to reproduce it and haven't been able to so far
<slangasek> which makes it hard to validate my proposed fix :P
<pitti> slangasek: hm, first time I see this
<slangasek> pitti: ok, no worries
<pitti> slangasek: I did have several fscks in the last weeks, since I reboot often, but they all worked well
<hyperair> crimsun: what about mainline 2.6.34-rc4
<crimsun> hyperair: not new enough
<pitti> slangasek: I have a relatively simple setup, though, just / and /home, and no LVM etc.
<Keybuk> slangasek: banging away at the keyboard while deactivate is called in the background?
<slangasek> well, LVM shouldn't matter, it's all a race condition->deadlock between plymouth and mountall
<baptistemm> good morning
<baptistemm> StevenK, around?
<slangasek> Keybuk: how do I know when deactivate is called?
<Keybuk> sleep 5; plymouth deactivate
<Keybuk> Alt+F7
<Keybuk> type lots ;)
<pitti> hey Keybuk, how are you? early for you..
<hyperair> crimsun: heh okay. what's the git clone url? i can't seem to find it.
<Keybuk> early?  it's not even midnight <g>
<slangasek> Keybuk: that doesn't really model the mountall deadlock, does it?
<hyperair> crimsun: no wait, i think i found it
<hyperair> http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=summary
<pitti> Keybuk: oh, so unless they towed the British islands somewhere else I figure you are at the LF summit?
<Keybuk> slangasek: oh, sorry, different bug
<Keybuk> lol
<slangasek> ok :)
<Keybuk> that's how to replicate the SEGV one
<slangasek> gotcha
<Keybuk> pitti: indeed
<pitti> Keybuk: enjoy!
<Keybuk> slangasek: no idea how to replicate the stuck-in-flush one
<Keybuk> that seems kinda kooky
<Keybuk> if the write() is blocking, the pipe must be very full
<pitti> could it be that fsck -C is writing out something unexpected which can't be parsed?
<slangasek> not unless you know of a way that would cause mountall to talk to plymouth :)
<slangasek> the deadlock is between mountall and plymouth both trying to write and nobody reading
<slangasek> I understand what the bug *is*, and I think I have a fix, but I don't understand how to *trigger* the bug so I can't validate the fix
<Optimus55> hey can anyone here point me in the right direction? I want to write together a hack/patch that outputs a small sound notification on volume change
<Optimus55> any documentation or resources i could start with would be really helpful
<RAOF> Optimus55: You should probably start by looking into gnome-settings-daemon; that's where the volume-change gets handled.  It's off-topic for this channel, though; #ubuntu-app-devel is probably where you want to go.
<hyperair> YokoZar: have you seen this before? fixme:d3d_caps:wined3d_guess_card No card selector available for GL vendor 3 and card vendor 8086.
<YokoZar> hyperair: no
<hyperair> hmm =\
<hyperair> it only appeared in newer versions of wine.
<hyperair> along with my halved frame rates
<RAOF> Isn't card vendor 8086 going to be intel?
<hyperair> RAOF: yes iti s.
<Optimus55> RAOF: thanks very much
<hyperair> YokoZar: http://archives.free.net.ph/message/20100301.182932.80602d9a.en.html <-- this says that wine is treating my intel card as a nvidia card after tossing that message out.
<YokoZar> hyperair: seems like a simple upstream bug then
<hyperair> YokoZar: indeed.
<svu_> seb128, hi. i found the solution. for some reason vg gets disabled on every boot. has to enable it manually every time
<seb128> hey svu_, oh, nice that you managed to find the issue
<svu_> thanks for the help and hints yesterday! hopefully my info will help to fix the bug (already updated). perhaps mountall needs tweaking after all
<seb128> you're welcome, right, let's see
 * hyperair finds it mildly annoying that every time he digs out wine for a short game, there are performance regressions so bad that i end up grabbing wine's source and hacking through it to look for what's gone wrong (again).
<james_w> lifeless: am now
<lifeless> nvm, dholbach showed up first ;P
<lifeless> but thanks
<lifeless> hyperair: you are playing the 'wining game'
<hyperair> lifeless: lolwut?
<lifeless> terrible joke :)
<hyperair> ..i guess.
<hyperair> the last time i had wine issues, it was crashing because it was looking for i915_dri.so in the wrong place, then using swrast or something and segfaulting.
<hyperair> the bug is *almost* fixed.
<hyperair> and then this time i have stupid performance regressions due to somebody trampling all over intel support to refactor ati support.
<hyperair> best part is it's *always* wined3d.
 * hyperair adds writing a cowbuilder that can have multiple backends to todo list.
<StevenK> baptistemm: I am now
<baptistemm> hi StevenK
<StevenK> baptistemm: What's up?
<baptistemm> StevenK, I saw you manager Bluetooth group in lp
<baptistemm> -e
<baptistemm> -r grr
<StevenK> baptistemm: If you've requested to join the team, tell me your Launchpad ID and I'll add you
<baptistemm> I'm in the pending approval
<baptistemm> My id is bmillemathias
<baptistemm> there is are some interesting people in the approval queue like Vudentz which is a core dev of bluez
<baptistemm> actually I'm triaging a lot of bug related to bluetooth bluez, gnome-blueooth, obex*)
<baptistemm_> sorry
<StevenK> baptistemm_: I've approved you
<baptistemm_> thanks StevenK
<baptistemm_> I need to go for a meeting but I'll be back to ask you some question.
<baptistemm_> see you
<cjwatson> apw: could you install dpkg 1.15.5.6ubuntu4~ppa1 from https://launchpad.net/~cjwatson/+archive/ppa and see if it can unpack a linux-headers-2.6.32-[0-9]+ package in vaguely reasonable time on ext4?
<cjwatson> for comparison, that unpack on ext3 on my laptop takes about 20 seconds
<apw> cjwatson, ack
<ogra> is https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/initramfs-tools/lucid the current branch for the initramfs-tools package ?
<cjwatson> ogra: yes
<ogra> thanks
 * ogra fixes mmc handling
<cjwatson> apw: wah, hang on, that package is buggy
<cjwatson> it's not renaming new files into place
<apw> cjwatson, gah ... how badly broken are my machines?
<baptistemm> StevenK: could you add  Vudentz to bluetooth team, he is a core dev of bluez
<cjwatson> find / -name \*.dpkg-new
<cjwatson> apw: (new dpkg will fix it up though, once I find the bug ...)
<cjwatson> it gets overwrite of existing files right, it's only newly-introduced files
<StevenK> baptistemm: Done.
<baptistemm> StevenK, thanks :)
<apw> cjwatson, ahh i was reinstalling a package so i have none
<cjwatson> apw: yeah, I'd downgrade dpkg to the lucid version for the time being anyway - discussing it on #debian-dpkg now
<cjwatson> apw: ok, in that case did you get timing data?
<cjwatson> it might still be useful
<apw> i ran before the update a few times and a few after .... on a fast(er) amd64 it looks to be about 'cold cache' speed ... before was like 6,3,2,2,2 (s) and after it was 6,5,6,5,6,6
<apw> on an atom netbook is still running
<mvo> ogra: speaking of which, do you have a opinion on bug #562231 - it mentions compcache issues
<ubottu> Launchpad bug 562231 in initramfs-tools "[initramfs-tools] initramfs.conf should be purged at upgrade" [Undecided,New] https://launchpad.net/bugs/562231
<directhex> sigh, pitti's sync script never seems to work for me :(
<pitti> directhex: how does it fail?
<ogra> mvo, i thought we excluded ramzswap everywhere, if it causes suspend/resume issues that has to be taken care of (by pm-utils i guess) i dont think we want to delete initramfs.conf
<directhex> pitti, well, it seems to work fine, then when i dput the result... nothing. no acknowledgement or rejection email, just nothing
<apw> cjwatson, and on atom its 52, 21, 58 before and 1:14, 1:33, 0:47, 1:46
<apw> very variable on atom it seems
<ogra> mvo, you might have installed to a low ram system and need ramzswap (actually i think cjwatson once added code that we can make sure its still there on systems with less than 512M post install)
<cjwatson> apw: so slower, but not hopelessly dreadful?
<cjwatson> yeah, there's a fair amount of variability for me too
<mvo> ogra: ok, it sounded very wrong to me as well
<apw> yeah i'd say its cold cache speed rather than getting faster in later iterations, which matters not as you don't install more than once
<apw> its perhaps 20-30% slower on my braindead atom, cirtainly not 1 hour to install levels
<apw> cjwatson, not hoplessly dreadful ... indeed
<MacSlow> seb128, LP: #559109 is fixed. I've a branch up for review (will ask bratsche to do it). Would you take that rather as a distro-patch or a new tarball-release?
<ubottu> Launchpad bug 559109 in notify-osd "Two notification bubbles at the same time" [Medium,Fix committed] https://launchpad.net/bugs/559109
<seb128> MacSlow, distro change is fine, thanks for working on it!
<seb128> MacSlow, do you want me to backport it now or do you prefer to have brastche to double check it first?
<MacSlow> seb128, well I've tested it with all the cases people described in the bug-report (using metacity without compositing) and it works. I'm feeling confident to suggest you just take it as-is
<seb128> MacSlow, ok, will do thanks, we can still do another upload if required ;-)
<MacSlow> seb128, still for moving it into notify-osd trunk I'll stick to our usual process... so waiting on bratsche to review and approve it
 * seb128 hugs MacSlow, good work!
<seb128> MacSlow, right, makes sense
<MacSlow> seb128, you're welcome!
<joaopinto> was there any recent change to cups-pdf ?
<joaopinto> I am sure it was working fine a few days ago, today the pdfs are not generated and I don't get any error
<joaopinto> any tip on how to debug it ?
<joaopinto> hum, there is a warning on the printers list
<joaopinto> backend cups-pdf does not exist
<joaopinto> the package was removed somehow
<joaopinto> fixed :P
<jibel_> ArneGoetje, hi, about bug 396414 and check-language-support
<ubottu> Launchpad bug 396414 in language-selector "When KDE or gnome apps get installed, the corresponding language-packs should be pulled automatically" [Medium,Fix released] https://launchpad.net/bugs/396414
<jibel_> ArneGoetje, check-language-support doesn't check the required language pack for the dependencies ?
<jibel_> ArneGoetje, for example, if I've no kde package installed at all,
<jibel_> ArneGoetje,  "check-language-support -p kturtle" returns nothing because the package that requires a lang pack is kdelibs5-data
<seb128> bdrung, hey, you have main upload rights?
<seb128> bdrung, thanks for doing some sponsoring but when you upload desktop packages would you check with #ubuntu-desktop before?
<hyperair> crimsun: the said stutters with wine and alsa-pulseaudio plugin still occur with the new sound things
<pitti> seb128: I'm just looking at the missing evolution bzr commit; I suppose you mean that?
<seb128> pitti, yes
<seb128> pitti, that + I wanted to review changes to add rather than doing an evo build for an useless build-depends change
<seb128> the upload is just wasting bandwith and buildd
<pitti> bdrung: can you please commit it to lp:~ubuntu-desktop/evolution/ubuntu ?
<pitti> seb128: yes, committing to the branch would have been enough
<bdrung> seb128: yes
<bdrung> seb128, pitti: ok
<seb128> bdrung, thanks
<foka> cjwatson, Hello!  Here?  Just wondering about grub-common 1.98-1, /etc/grub.d/10_linux has "export TEXTDOMAINDIR=@LOCALEDIR@" left untranslated.  Is it a known problem?  Thanks!
<cjwatson> interesting, didn't know about that
<foka> cjwatson, a possible fix is to edit grub2-1.98/util/grub.d/10_linux.in and change @LOCALEDIR@ to @localedir@, and that seems to do the trick, with the result being  export TEXTDOMAINDIR=${prefix}/share/locale
<cjwatson> that sounds plausible
<cjwatson> I'll get that changed upstream and backport to Debian and Ubuntu
<cjwatson> thanks!
<foka> cjwatson, Cool!  Thank you so much Colin!  :-)
<cjwatson> is there a bug open?  (no need to file one if there isn't)
<foka> cjwatson, (as you can see, I have been too lazy to file a bug report)
<foka> cjwatson, thought it would be much easier if we could discuss it on IRC like what we just did.  ;-)
<foka> cjwatson, No bug report open AFAIK.
<cjwatson> odd, this WAS fixed
<cjwatson> r1889
<foka> cjwatson, Cool!  Most likely the fix came after the 1.98 release.
<cjwatson> no
<cjwatson> it's an old change, reverted for some reason
<cjwatson> I'm looking through the history to see whether it was a mistake or deliberate for some reason
<cjwatson> it looks like a mismerge
<cjwatson> yeah, another change merged in r2156 was very close by and it looks like the person doing the merge got the conflict resolution wrong
<foka> cjwatson, Thank you so much for looking into it and discovering the root of the problem.  :-)
 * ogra sighs about initramfs-tools-bin 
<baptistemm> StevenK, would do agree to grant some power to the bluetooth group ?
<ogra> why the heck do we need it ... makes my world so much slower
<baptistemm> as I did manage the packages for a while
<baptistemm> and the bug reports
<persia> baptistemm: What sort of power did you envision?
<baptistemm> just add related projets, look to review and members
<persia> baptistemm: I may be mistaken, but I suspect that waiting at least a couple weeks after being confirmed as a member would make sense before asking for admin :)
<persia> I suspect you'll end up with it, simply because I believe you to be the primary maintainer of the bluetooth stack in Ubuntu, but still it's good to go step-by-step :)
<baptistemm> okay no problemo
<baptistemm> I just wanted to give a hand to help
<baptistemm> ah, and I wanted to update the bluetooth icon of the group to a nicer one :)
<_silentAssassin> /me leaving
<DnaX> ajmitch: ping
<pecisk> ccheney: ping?
<ajmitch> DnaX: yes?
<DnaX> ajmitch: about postr package... I've made the updated package, please, can you check and upload if ok?
<bdrung> What do do with Ubuntu hating upstream projects?
<bdrung> one upstream dev want to see the package removed from ubuntu.
<pecisk> bdrung: be more specific
<persia> Play nicer with upstream.
<bdrung> persia: i play nice with them. packaged the newest version. no extra patch applied (he rants that we patched the package to death).
<persia> And we carry no patches?
<bdrung> we carried 5 patches that are no longer required.
<bdrung> i filed a bunch of upstream bugs to make packaging simpler (e.g. distclean was not clean enough)
<DktrKranz> bdrung: I had a similar experience (http://lists.debian.org/debian-devel/2010/02/msg00714.html), and given that I don't want to waste time trying to make upstream work, I decided to remove it for good.
<bdrung> DktrKranz: the package works. it just that one or more upstream devs hate ubuntu.
<DktrKranz> cool
<DktrKranz> does the whole stuff apply to Debian too?
<josip> hello, I have just upgraded to lucid beta and there seem to be rpoblems with fglrx (can't get installed). Anyone familiar with this?
<josip> it also broke apt-get, I will poste a paste shortly
<joaopinto> hate is such a strong word, I don't see open source developers moving in such emotion
<josip> http://pastebin.com/ePkeq1BE
<josip> imagemagick as well
<bdrung> hate was one of the more harmless words
<DktrKranz> so, basically people don't want their own software to be easily installable by their own users, and don't want for-free advertisement. woohoo!
<joaopinto> I did got one "Please do not distribute our software" mail once, for a GPL software
<joaopinto> never got a reason so it was just ignored
<josip> any workaround for https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/559587 ?
<ubottu> Launchpad bug 559587 in fglrx-installer "package fglrx (not installed) failed to install/upgrade: trying to overwrite '/etc/ati/signature', which is also in package xorg-driver-fglrx 2:8.721-0ubuntu8" [High,In progress]
<sabdfl> slangasek: quick ping re https://bugs.edge.launchpad.net/ubuntu/+source/update-manager/+bug/563015
<ubottu> Launchpad bug 563015 in update-manager ""No new release found" noise printed at every console login" [Undecided,New]
<mvo> sabdfl: sorry for that, I fix it right away
<sabdfl> thanks mvo!
<sabdfl> mpt: ^
<sabdfl> thanks  mpt too
<joaopinto> mvo, we are settle on the changelog location right ? I need to file a bug report on "aptitude changelog" to support it also
<mvo> joaopinto: thanks, good point
<zul> mvo: ping any update on #556343?
<MattJ> Are there any docs on what the package urgency should be set to?
<MattJ> I'm producing an update for a package in universe, for an upstream bugfix release
<cjwatson> MattJ: policy manual s. 5.6.17
<persia> MattJ: Set to "low" for any uploads to Ubuntu.  Setting to other values makes a difference, but only if you upload something within the same hour as several other things.
<MattJ> Thanks
<cjwatson> indeed, it makes very little actual difference
<MattJ> Ok, I guess it's fine to leave then :)
<cjwatson> the only other difference I know of that it makes is the ordering of output from apt-listchanges
<tseliot> cjwatson: what key combination do we use to access the grub menu in Lucid? Shift?
<arand> tseliot: lest shift, hold, yep
<arand> s/lest/left/
<tseliot> ok, it didn't seem to work for some reason. It does now. thanks
<cjwatson> either shift actually
<primes2h> tseliot: Thanks for plymouth patches.
<tseliot> primes2h: np
<ArneGoetje> jibel_: correct. Because kturtle depends on that library, it will pull the kde langpacks.
<primes2h> tseliot: are they going to be included in bzr tree?
<tseliot> primes2h: they have to be approved for inclusion first and this doesn't really depend on me
<primes2h> tseliot: ok, thanks a lot. :-)
<mvo> zul: not yet, sorry
<psusi> if a bug is "fixed" by a hackish workaround rather than actually fixing the underlying bug, should the bug report NOT be marked as fix released?  you know, so that the real problem will eventually be found and fixed?
<zul> mvo: ok, ttx is a bit antsy with it
<mvo> zul: I run it now
<zul> mvo: thanks
<jibel_> ArneGoetje, let say I'm using LANG=fr_FR, I install kturtle with some package manager, no particular lang pack is pulled.
<jibel_> ArneGoetje, check-langugage-selector is able to tell me that french lang pack is needed only once the package is installed
<jibel_> ArneGoetje, From a "user friendliness" point of view it would be better to guess which lang pack are needed before proceeding with the installation.
<jibel_> ArneGoetje, or am I missing something?
<jibel_> ArneGoetje, it would be possible if c-l-s also checked the dependencies when called with -p
<pgraner> sabdfl: ping
<ArneGoetje> jibel_: the package manager should pull kdelibs5-data as a dependency. When it does that, it should submit the list of packages it is going to install (including the dependencies) to the function call.
<jibel_> ArneGoetje, ok, that makes sense. mvo, are you ok to implement it that way ? ^^^
<jibel_> mvo, reference is bug 396414
<ubottu> Launchpad bug 396414 in language-selector "When KDE or gnome apps get installed, the corresponding language-packs should be pulled automatically" [Medium,Fix released] https://launchpad.net/bugs/396414
<mvo> jibel_: well, doing it like this in apt is going to be a big slowdown, the idea is make it part of aptdaemon, but not apt-get itself.
<mvo> jibel_: it feel like we need a plugin mechanism in apt for this or a different solution that is more elegant
<Madkiss> good morning
<primes2h> slangasek:  Hello, I saw you merged plymouth 0.8.2 in bzr yesterday evening. Is there any chance to patch it with this bug #553954? :-) It's quite an annoying bug because the string is very visible (and quite big)
<ubottu> Launchpad bug 553954 in plymouth "[Lucid Beta 1] plymouth has a non translatable string coming up on screen" [Medium,In progress] https://launchpad.net/bugs/553954
<Madkiss> Is Scott Kittermann online?
<jibel_> mvo, I was rather thinking about doing this on the client side. but it duplicates the code in each client. :/ not the right solution.
<RoAkSoAx> Madkiss, ScottK
<primes2h> slangasek: tseliot has been working very hard to provide those patches in a short time.
<mvo> jibel_: yeah, a plugin would be ideal plus fast code, or a re-thinking of the way we do the langpacks
<Madkiss> ScottK?
<mvo> jibel_: its tricky to get right without slowdown
<yofel> pitti: hi, I have the fix for bug 562118 ready in the linked branch, do you want a debdiff, merge or can you just take the fixed script from the branch?
<ubottu> Launchpad bug 562118 in apport "/usr/share/apport/symptoms: No such file or directory when using ubuntu-bug autocompletion" [Low,In progress] https://launchpad.net/bugs/562118
<pitti> yofel: I can figure it out; if you branched against trunk, I'll just merge
<pitti> thanks!
<pitti> yofel: please assign the bug to me, so that it's on my work list
<Riddell> Madkiss: he's away for the next few hours
<yofel> pitti: will do
<ccheney> pecisk: hello?
<ArneGoetje> mvo: anything I would need to change on my side to make it possible?
<Madkiss> RoAkSoAx: About the heartbeat discussion.
<Madkiss> RoAkSoAx: I know some details about it as LINBIT is heartbeat upstream. The problem is not in Heartbeat, it's in glib.
<Madkiss> RoAkSoAx: fixed in http://git.gnome.org/browse/glib/commit/?id=37dbc09080ac280ff7a552d03869c8afa745f15a and re-introduced in http://git.gnome.org/browse/glib/commit/?id=c8e37b63e74fafdc1f299ec139677ad0e37676c3 -- also see https://bugzilla.gnome.org/show_bug.cgi?id=457641
<ubottu> Gnome bug 457641 in gthread "glib-2.13.7: C++ conversion problem in gthread.h" [Blocker,Resolved: fixed]
<RoAkSoAx> Madkiss, i see then. so would you advise to drop --disable-fatal-warnings from debian/rules in heartbeat?
<Madkiss> RoAkSoAx: it's not gonna build on numerous architectures then as long as glib is not fixed.
<robert_ancell> hey, could someone sponsor bug 87312?
<ubottu> Launchpad bug 87312 in sane-backends "xsane should not detect TV cards" [Low,Triaged] https://launchpad.net/bugs/87312
<Madkiss> RoAkSoAx: you have the choice between aids and cancer.
<RoAkSoAx> Madkiss, i'd rather keep the change then since I don't think that glib fix is going to hit ubuntu anytime soon :)
<Madkiss> RoAkSoAx: so do I.
<lamont> who knows partman-auto/expert_recipe debconf answers well enough to answer a stupid question?
<mvo> ArneGoetje: no, providing the call via a python import is a good step to interface with it
<ArneGoetje> mvo: good, thanks :)
<robert_ancell> seb128, pitti: could you sponsor ^^
<seb128> robert_ancell, ok
<robert_ancell> seb128, I promise to get around to applying for main :)
<seb128> robert_ancell, right, do that before next cycle if you can, so when you are back on distro you will be set ;-)
<robert_ancell> The paperwork always makes me fall asleep... :)
<jibel_> ArneGoetje, mvo,  thanks, report updated accordingly.
<ttx> jjohansen: bug 542208 seems to be in the same alley as our bug 546743, fwiw
<ubottu> Launchpad bug 542208 in linux "Please blacklist i830 from Kernel mode-setting" [Critical,In progress] https://launchpad.net/bugs/542208
<ubottu> Launchpad bug 546743 in linux "Blank screen at first boot with ATI ES1000 and 10.04 server" [High,Confirmed] https://launchpad.net/bugs/546743
<jjohansen> ttx: yep thanks, I'm poking
<kklimonda> cjwatson: should I get some sort of mail after I got upload privileges? something like "hello, don't break things"? the only indication I could do an upload was the fact it wasn't rejected :)
<cjwatson> the DMB chair-of-the-week should have sent something
<persia> kklimonda: Sorry.  I failed this morning.  I'll do that now.
<persia> Hrm.  I can't find any previous announcement for any per-package-uploader since the DMB took them over, except for in the meeting minutes.  Anyone have a pointer that says where I'm supposed to send those (aside from cc: devel-permissions)?
<mgiammarco_> just a quick note: ubuntu pacemaker packages miss sbd start script
<mgiammarco_> heartbeat maintainer has just made a patch for debian packages, but only for heartbeat. Corosync support should be added
<cr3> should gnome-open behave the same with file:///.../file.xml and http://.../file.xml, and respect the value of /desktop/gnome/url-handlers/http/command in the gconf database?
<sistpoty|work> mgiammarco_: can you add that info to bug #562712 and/or bug #562711 please? thanks!
<ubottu> Launchpad bug 562712 in pacemaker "[FFe] Please sync pacemaker 1.0.8+hg15494-2 (universe) from debian (unstable)" [Medium,New] https://launchpad.net/bugs/562712
<ubottu> Launchpad bug 562711 in heartbeat "[FFe] Please sync heartbeat 1:3.0.2+hg12555-2 (universe) from debian (unstable)" [Medium,New] https://launchpad.net/bugs/562711
<mpt> mvo, tremolux, Back/Forward navigation has regressed in USC
<mpt> e.g. navigate to "Accessories" and back to the lobby, and then to "Education" and then back, and you'll end up in "Accessories" rather than the lobby
<dholbach> where's the "lobby"?
<tremolux> mpt: yes, I noticed some nav problems myself, was planning to look into where that crept in...ug
 * persia suspects the lobby to be where Bob lives
<doko> http://launchpadlibrarian.net/43750033/buildlog_ubuntu-lucid-armel.libtunepimp_0.5.3-7.2ubuntu1_FAILEDTOBUILD.txt.gz
<dholbach> persia: alright, see you there in a bit! :)
<doko> any idea why this just fails on armel?
<mpt> persia, Bob the builder? or Microsoft Bob?
<mgiammarco_> sispoty ok will do
<mpt> tremolux, reported bug 563128
<ubottu> Launchpad bug 563128 in software-center ""Back" button goes to wrong place if you've gone back previously" [High,New] https://launchpad.net/bugs/563128
<tremolux> mpt: thanks!  we'll get that bad boy fixed up
<persia> mpt: The latter, I was thinking.  Lobbies belong in buildings, not software :)
<mpt> persia, yeah, the overall metaphor here is a department store, though we've not needed to express it much so far
<persia> I hope that the concept can translate with poor expression in the future as well, as that allows other metaphors to share :)
<james_w> doko: didn't you fix that in the next version?
<doko> james_w: ohh, that was a late ubuntu1 build ...
<mpt> persia, no idea what you mean there
<persia> mpt: That I think physical metaphors (desktop, department store) are a good way to think about how to structure things, because we have a lot more experience with those interfaces, but that I believe it's to our advantage to avoid expressing our internal metaphors to users to encourage the development of new or alternate metaphors that can leverage the flexibility of software to improve on the real experience rather than on the attachment to the
<persia>  metaphor.
<persia> And in many cases, it may even be to our advantage to avoid clearly expressing these metaphors to each other, for the same reasons.
<mpt> persia, it's quite the reverse here -- if/when we express it, it will be a user-level metaphor, not a development-level one
<JanC> actually, some of those metaphors are difficult to translate too
<james_w> does Build-Depends: nonexistant-package | existant-package work in Ubuntu?
<cjwatson> yes
<persia> mpt: You've just expressed it.  That said, why would you want to tell people "It's like an elephant" when it's not clearly ("elephant" picked here to avoid specifics).  The base model may be similar enough to be mistaken for "intuitive", but I'm not sure how it helps to point out the ways in which a translated interface doesn't match the model.
<mpt> persia, sorry, I don't understand what you're talking about.
<mpt> bbiab
<primes2h> Keybuk: Hello, I saw that yesterday evening you talked with slangasek about plymouth 0.8.2 in bzr. Is there any chance to patch it with this bug #553954? :-) It's quite an annoying bug because the string is very visible (and quite big). tseliot has been working very hard to provide those patches in a short time.
<ubottu> Launchpad bug 553954 in plymouth "[Lucid Beta 1] plymouth has a non translatable string coming up on screen" [Medium,In progress] https://launchpad.net/bugs/553954
<Keybuk> I'm not happy with tseliot's approach
<Keybuk> so not happy to apply his patch
<Keybuk> especially this late in our release cycle
<primes2h> Keybuk: What do you mean?
<Keybuk> I mean exactly what I said
<primes2h> are you talking about the string he put in mountall?
<Keybuk> no, I'm talking about the entire approach of cutting a string up, putting part of it in one place, part of it in the other, etc.
<Keybuk> because there's no way any kittens could be harmed that way
<Keybuk> oh no
<primes2h> Keybuk: ok, I could agree with you about this, but I don't think those patches can getting it worse as it is already
<Keybuk> right now, the "bad" is just that there's a single string that's not translated
<Keybuk> the worse could be that code segfaults during filesystem checks every time
<Keybuk> I think I know which I prefer
<primes2h> a very visible and quite big string.
<Keybuk> I'd only agree with your position if there weren't other untranslated strings all over the place ;-)
<Keybuk> if it were the *only* untranslated string, sure
<Keybuk> and if it contained more information than "1 of 2: 54%"
<primes2h> Ara you talking about the othe mountall pot bug?
<primes2h> s/othe/other
<primes2h> bug 559997
<ubottu> Launchpad bug 559997 in mountall "Mountall needs to generate pot file on build" [Medium,Fix committed] https://launchpad.net/bugs/559997
<Keybuk> no
<Keybuk> I'm asking the following question
<Keybuk> is it a "CRITICAL" bug that there is a single string that is not translatable?
<Keybuk> should we hold up the release for that to be fixed?
<Keybuk> and I'm saying "no"
<mandel> ping jono
<Keybuk> it can't possibly be a critical bug, because there are hundreds (if not thousands) of strings not translated
<Keybuk> it can't possible be a critical bug because the key information in the string is numerical anyway
<Keybuk> so it's pretty obvious that "blah blah 1 blah 4 blah 54%"
<Keybuk> which changes to "blah blah 2 blah 4 blah 23%"
<Keybuk> means it's a progress
<Keybuk> and the patch is not clean, and not simple
<Keybuk> (and I'm sure this IRC conversation will end up on Reddit and HackerNews :p)
<joaopinto> lol
<primes2h> Keybuk: I agree with you about the fact it's not critical but the message it brings is quite important. I asked you about including the patch because I thought it were not so invasive. You told me it could bring segfault bug so I understand.
<Keybuk> :-)
<Keybuk> yeah, if it were just "stick _( ... ) around the string" I'd go for it like a shot
<joaopinto> is the bug about the recovery / attempting to fix filesystem messages on boot loop reported ?
<Keybuk> joaopinto: unsure
<joaopinto> Keybuk, it was on my working laptop so I couldn't halt to gather data, but all saw someone else reporting the same experience on a blog entry
<primes2h> Keybuk: so how do you think it can be correctly addressed?
<joaopinto> I had a / corruption, and the messages where looping so fast that I couldn't read
<Keybuk> you can probably replicate it by fucking with the real time clock ;)
<Keybuk> primes2h: no idea, haven't thought about it yet
<Keybuk> primes2h: I think we probably need to extend Plymouth to support "actions" rather than abusing usage
<Keybuk> so things can say "doing blah, X% complete" properly
<primes2h> Keybuk: The main problem for me is that the string hadn't to be there from the beginning.
<primes2h> in plymouth, I mean.
<Keybuk> "hadn't" ?
<Keybuk> well, I was quite surprised that turned into a string at all
<Keybuk> earlier in lucid they were really nice, cute progress bars
<Keybuk> I liked that
<Keybuk> no idea why Design wanted it to be a string
<primes2h> I mean it shouldn't have been there
<Keybuk> well, where else does the string go?
<primes2h> Keybuk: A progress bar would be  better for sure.
<Keybuk> they were progress bars
<Keybuk> you'll have to talk to tseliot to find out why they're not anymore
<primes2h> Keybuk: I know they were, I just don't understand why putting a string so visible without thinking about localization
<primes2h> it's the only string in plymout not translatable, other are taken from mountall
<primes2h> s/other/others
<primes2h> from fsck too I think
<Keybuk> primes2h: right, but mountall doesn't know that a check is "4 of 5"
<Keybuk> and that's the kind of functionality we don't want in mountall
<Keybuk> since mountall is supposed to *go away* at some point
<primes2h> Keybuk: you are right, the chosen package is wrong
<ogra_cmpc> Keybuk, so the mountall fsck in endless loop bug gets really serious in armel
<Keybuk> clearly plymouth themes need to support localisation though
<Keybuk> ogra_cmpc: please help debug and fix then!
<ogra_cmpc> Keybuk, how did you fix it ? (you said you were expecting it to be fixed)
<Keybuk> ogra_cmpc: I didn't fix it
<Keybuk> and I didn't say I was expecting to
<Keybuk> I don't know about that bug
<primes2h> Keybuk: I was just suggesting it
<ogra_cmpc> you said you did when we talked last time
<primes2h> Keybuk: plymouth theme needs to support localisation
<Keybuk> primes2h: that's probably the *right* fix - add l10n support to plymouth themes
<Keybuk> most probably just script
<Keybuk> ogra_cmpc: no I didn't
<Keybuk> ogra_cmpc: I may have been talking about a completely different bug
<ogra_cmpc> Keybuk, if the mount time if / is in the future mountall goes into an endless fsck loop without getting you to a console
<Keybuk> ogra_cmpc: I don't know about that bug
<ogra_cmpc> Keybuk, do you see a chance that we can possibly ignore the mount time completely ?
<Keybuk> ogra_cmpc: if you could file it, or point me at a bug#, and attach --debug I would appreciate it
<Keybuk> ogra_cmpc: not by default, no
<primes2h> Keybuk: I suggested it as the first option on a bug comment.
<primes2h> https://bugs.edge.launchpad.net/ubuntu/+source/plymouth/+bug/553954/comments/1
<Keybuk> primes2h: patches welcome ;-)
<ubottu> Launchpad bug 553954 in plymouth "[Lucid Beta 1] plymouth has a non translatable string coming up on screen" [Medium,In progress]
<ogra_cmpc> Keybuk, it must be filed since months i'm not on a machine to look atm, but will get you a reference
<Keybuk> ogra_cmpc: and get me mountall --debug of it happening
<ogra_cmpc> Keybuk, i know asac was bugged by it in portland
<primes2h> I know ;-)
<ogra_cmpc> Keybuk, no way ... you cant get to the point where the daemoin would start, fsck loops
<Keybuk> the daemon must be started
<Keybuk> the daemon is what calls fsck
<Keybuk> so you must be able to get --debug output
<ogra_cmpc> doesnt fsck run before ?
<ogra_cmpc> oh, ok
<vish> mvo: hi.. software center was using a monochrome icon in the categories [weather-clear-sky ] , added an icon for applications-astronomy in humanity , have a look at this branch https://code.launchpad.net/~vish.../software-center/avoidmonochromeicon/+merge/23413 , it just changes the name in the icon name in data/software-center.menu.in file , should fix the issue
<ogra_cmpc> Keybuk, the prob i have now is though thatwe start to support HW that doesnt have an rtc battery ... so the clock will always be wrong until network is up
<vish> rather weather-clear-night*
<Keybuk> ogra_cmpc: that's unrelated to the bug you are reporting to me
<ogra_cmpc> no, thats the core issue
<Keybuk> no, the core issue as far as I'm concerned is that the problem isn't fixed and it enters a loop
<Keybuk> ;-)
<ogra_cmpc> fsck kicks off because last mount is in the future
<Keybuk> yes
<Keybuk> that's a filesystem inconsistency
<ogra_cmpc> well, i dont want iusers to end up on the fsck console every boot :)
<Keybuk> I don't want users to have a potentially serious problem hidden from them
<ogra_cmpc> but the clock will be at some certain date 2000 on every boot until we have network (if we even ever have that)
<Keybuk> so that's a hardware problem
<ogra_cmpc> its a design problem indeed
<ogra_cmpc> but none i can solve
<Keybuk> so what's your clock source on this hardware?
<ogra_cmpc> ntp only ... there is a rtc device but no battery
<ogra_cmpc> its TI omap beagleboard
 * ogra_cmpc isnt nearthe board atm, actually taking a break
<Keybuk> right, so it's not a problem actual users are ever going to see
<Keybuk> because actual users will be using real hardware that does have a battery
<ogra_cmpc> the system doesnt boot
<Keybuk> it's just a dev board issue
<ogra_cmpc> err
<svu> Keybuk, I found the matter of problem. mountall does not enable my volume group. Have to do it on every boot, manually
<Keybuk> svu: mountall has nothing to do with volume groups
<Keybuk> it doesn't know about LVM at all
<Keybuk> it's up to LVM to enable things
<svu> Keybuk, ghm. ok. SOMEONE has to enable vg. And it does not do that
<Keybuk> svu: lvm should
 * svu thought it was a part of the mount process
<Keybuk> it's done from a udev rule
<Keybuk> when a block device appears with an LVM signature, lvm vgscan etc. is called
<Keybuk> that's supposed to enable them and create devmapper devices
<svu> Keybuk, I see. but it fails. Wonder why...
<Keybuk> which is what mountall sees
<Keybuk> no idea
<svu> so udev rules fail for some reason
<Keybuk> svu: yes, lvm bug
<svu> pitti, ping?
<svu> Keybuk, or udev?
<zyga> hello
<Keybuk> no, not udev
<Keybuk> lvm
<zyga> mvo: evening!
<Keybuk> if udev wasn't working, you'd have nothing on your system - no drivers loaded, no mouse, no keyboard, no display, no filesystems, etc.
<svu> can udev rules fail?
<Keybuk> udev is clearly working just fine
<Keybuk> it's a bug in lvm
<ogra_cmpc> Keybuk, so would something like a -dveloper-board switch/bootoption/whatever be possible that makes fsck ignore the clock skew ?
<ogra_cmpc> the current solution people use is to to turn the pass sequence number in fstab and /lib/init/fstab to 0 ... thats surely worse than ignoring a wrong clock
<ogra_cmpc> sigh
 * ogra_cmpc just accidentially found out his laptop was connected to the neighbors wlan
<ogra_cmpc> and i was wondering about the huge lag, tsk
<ogra_cmpc> Keybuk, btw it took amitk and me the whole day to find the issue on the beagle because the kernel didnt have fbcon working (we were debuggong through serial) mountall doesnt seem to spit out any output in that case
<ogra_cmpc> i assume yu are planning to change that given the cdomment in init/mountall.conf ?
<ogra_cmpc> or do you need a bug ?
<pitti> svu: hello
<svu> pitti, hello. I was told you could give some insight on why lvm VG is not activated by udev. would you know anything about that?
<ccheney> doko: ping
<ccheney> doko: NCommander and I were working on getting a patch to work for OOo and the test for armel seems not to be working to apply -marm for the build
<pitti> svu: I'm not that much of an LVM expert (much less than kees), but I know some bits about how it ought to work
<svu> pitti, which udev rule should I check, if you know?
<pitti> svu: is there a bug about it with some details? udev dump, description of the setup, etc.?
<svu> pitti, well, I just got the hint about udev. There is a bug against lvm
<pitti> svu: I had expected /lib/udev/rules.d/85-lvm2.rules to bring them up
<pitti> well, udev executes the rules, but the rules/tools are provided by the lvm2 package
<Keybuk> ogra_cmpc: a kernel command-line option is an interesting way to do it
<Keybuk> right now we can't pass options to e2fsck though
<Keybuk> so that would be an effort to implement
<ogra_cmpc> Keybuk, well, i9 didnt know about /etc/e2fsck.conf
<ogra_cmpc> that will already help
<svu> pitti, https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/554478
<ubottu> Launchpad bug 554478 in lvm2 "power g5 does not boot lucid beta" [Undecided,Incomplete]
<Keybuk> ogra_cmpc: I'm sure I've told you about it about a dozen times ;-)
<svu> pitti, I see
<ogra_cmpc> Keybuk, yeah, i'm over 40 now ... you have to be patient with the elders *g*
 * Keybuk puts ogra_cmpc in a home
<ogra_cmpc> lol
<slangasek> kirkland: hrm, why did base-files become responsible for the update-notifier cleanup?
<kirkland> slangasek: discussion with mvo
<kirkland> slangasek: see the linked bug
<kirkland> slangasek: that update-manager (notifier) cache file gets updated at most once per week
<kirkland> slangasek: telling you if there's a new ubuntu release available
<kirkland> slangasek: if you take action on that (upgrading your release), we need to clear the flag
<Damascene> hi
<kirkland> slangasek: else you'll have stale data in that cache file for up to a week
<kirkland> slangasek: the file that update-manager (notifier) uses to determine this is /etc/lsb-release
<kirkland> slangasek: which is owned by base-files
<Damascene> bug 562130
<ubottu> Launchpad bug 562130 in language-selector "Selecting an RTL language should install and RTL capable terminal emulator" [Low,Triaged] https://launchpad.net/bugs/562130
<zul> slangasek: hi i was wondering if the autofs5 FFE got approved
<Damascene> what should I do to help with this bug fixing?
<kirkland> slangasek: so mvo and i discussed it, and it seemed to make sense for base-files to clear that flag (and run a new update) on base-files upgrade (since that's how /etc/lsb-release gets changed)
<kirkland> slangasek: i waffled on running the update; that could be dropped
<slangasek> kirkland: ah
<kirkland> slangasek: does that make sense to you?
<ogra_cmpc> oh, i didnt know base-files carries lsb-release
<kirkland> slangasek: b/c mvo had a slightly more complex solution that could be contained in update-manager
<slangasek> kirkland: yeah - wish it wasn't base-files, but it at least makes sense
<kirkland> slangasek: sorry...  what's wrong with base-files?
<slangasek> zul: haven't revisited it yet, sorry; will do today
<zul> slangasek; k thanks
<slangasek> kirkland: that's not a package that should have complexity added to it if it can be avoided
<kirkland> slangasek: ah
<kirkland> slangasek: i'd like to get some advice from you at some point if i should try to get our pam_motd changes into Debian and/or upstream pam
<slangasek> kirkland: yes, we should have that conversation at some point
<slangasek> but not this month :)
<kirkland> slangasek: ack ;-)
<micahg> pitti: can we change the genuine package message in apport to say not a genuine package or possibly out of date?
<slangasek> micahg: not right now, we're in deep translation freeze
<micahg> slangasek: ok, next cycle?
<slangasek> if pitti agrees :)
 * ogra_cmpc shudders hearing slangasek say the word freeze
<slangasek> freeeeeeeeeeze
 * slangasek puckers his lips and makes an ominous howling wind sound
<ogra_cmpc> giggle
<ogra_cmpc> slangasek, when do you plan to call for it tomorrow ?
 * mvo freezes instantly
<slangasek> ogra_cmpc: 0000 UTC
 * ogra_cmpc still has a bunch of flash-kernel changes on the plate for omap
<bdrung_cbase> where can i get the font of the new ubuntu logo? and how many characters are ready?
<ogra_cmpc> slangasek, like *tonight* ?!?
<Keybuk>  5397 scott     20   0  114m  27m  15m R   42  1.9   0:01.06 chromium-browse
<Keybuk>  2481 scott     20   0 57480 2288 1760 S   25  0.2   0:09.28 chromium-browse
<Keybuk>  2479 scott     20   0  250m  52m  18m S   19  3.7   3:52.63 chromium-browse
<Keybuk>  5409 scott     20   0  116m  19m  14m S   15  1.4   0:00.25 chromium-browse
<Keybuk> urgh
<Keybuk> chromium is gang-banging my CPU :-(
<ogra_cmpc> fun
<slangasek> ogra_cmpc: that's always the official freeze time, and it will be enforced rather closely this time
<slangasek> ogra_cmpc: presumably your flash-kernel changes need to get in and would be accepted if uploaded to the freeze queue?
<ogra_cmpc> slangasek, yes
<ogra_cmpc> slangasek, but we only got a properly working kernel today so i'm totally behind
<slangasek> Keybuk: hey, interesting follow-up in https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/554737/comments/30 - does mountall not make sure it's sent all its writes to plymouth before emitting the 'filesystem' signal?
<ubottu> Launchpad bug 554737 in plymouth "ply_boot_client_flush() does not read replies (plymouth stuck during/after filesystem check or error)" [High,Triaged]
<slangasek> Keybuk: since emitting 'filesystem' will kill plymouthd, with perhaps random strings left on the screen :)
<peteris_> ccheney, here?
<ccheney> peteris_: yea
<peteris_> ccheney, any success with Latvian OO.o 3.2 translation? :)
<ccheney> peteris_: it is going into the build i am working on, hopefully to upload in a few hours
<fta> doko, by "misconfiguration in the Ubuntu build", do you mean in icedtea or in chromium?
<peteris_> ccheney, nice! is it final build or we could have some fixes slipped in? :)
<ccheney> peteris_: final freeze is in about 6 hours i think
<ccheney> peteris_: so i have to upload before then
<peteris_> ccheney, ok, then it's gone forward. Thanks for including us even so late! :)
<ccheney> peteris_: no problem :)
<apw> slangasek, we are still working on an issue with dells overheating.  if we manage to fix that this week how likely would you be to allow us to upload before release
<slangasek> apw: is it going to change the package names?
<apw> slangasek, it cannot see any reason it would be an abi bumper ... so no
<apw> it would also only be the main 'linux' no other kernels would be rev'd
<slangasek> apw: is there risk of hardware damage from the overheating or does it shut down cleanly from ACPI?  and is the problem so severe that it would inhibit being able to upgrade to a fixed kernel?
<apw> all the cases i have seen to lead to an ACPI shutdown, so it would be possible to upgrade i believe
<ccheney> assuming it wasn't a large upgrade causing the system to overheat during the process, heh :)
<slangasek> apw: if you can get it in tomorrow, I think we can accomodate it
<apw> slangasek, ok thanks for that ... if we can't it'll have to be an SRU
<apw> slangasek, what time does the freeze start in which timezone
<slangasek> apw: 0:00 UTC
<apw> slangasek, thanks
<dupondje> dell overheating ? :) bug # ? seems like I don't have this issue :)
<ogra_cmpc> slangasek, probably put that into /topic :)
 * ogra_cmpc BETS THAT WILL COME UP MORE OFTEN THE NEXT HOURS
<ogra_cmpc> OOPS
<Damascene> bug 562130
<ubottu> Launchpad bug 562130 in language-selector "Selecting an RTL language should install and RTL capable terminal emulator" [Low,Triaged] https://launchpad.net/bugs/562130
<Damascene> any help?
<kirkland> ogra: lool: around?  i have an idea re: https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/532733
<ubottu> Launchpad bug 532733 in qemu-kvm "apt/dpkg in qemu-system-arm hangs if a big task is installed" [High,Incomplete]
<slangasek> Damascene: weren't you already given the answer the other day that we're not going to change the default terminal emulator, for any language, this close to release?  changes like this need to be proposed and evaluated early in the release cycle, not the day of the final freeze
<Damascene> :)
<Damascene> who said I'm asking to be in Lucid?
<slangasek> well, er, lucid is the only Ubuntu release currently under development, and you're on #ubuntu-devel, so it's kinda implied. ;)
<Damascene> I just want to make sure that will be ready for 10.10
<Damascene> we all want ubuntu to stay the best
<zyga> mvo: around?
<mvo> zyga: yes, but super busy (sorry)
<zyga> mvo: ok
<mvo> zyga: or do you have more fixes :) ?
<kirkland> ogra: lool: i posted a couple of suggestions to https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/532733
<ubottu> Launchpad bug 532733 in qemu-kvm "apt/dpkg in qemu-system-arm hangs if a big task is installed" [High,Incomplete]
<vish> mvo: could you review the merge? it is a simple fix ;)   https://code.launchpad.net/~vish.../software-center/avoidmonochromeicon/+merge/23413
<Damascene> slangasek, could you give me some hints on what I should do for now?
<zyga> mvo: no, I was going to ask you about 538306 (it's waiting on your decision)
<mvo> vish: yes, will do before the night is over, I have it on my list :)
<vish> mvo: awesome thanks :)
<zyga> mvo: I'm still preparing fixes for software-center (even we're at freeze nowdays)
<mvo> zyga: thats fine, thanks, fixes can go in after the freeze too, I just want to get done as much as possible today to not put too much burden on the release team
<zyga> mvo: understood
<mvo> zyga: c-n-f, I have a look at the diff again, but I'm inclinded to leave it as it is now, 2-3 weeks ago it was fine, but now â¦
<zyga> mvo: okay, I'll make a better version for maverick, thanks
<slangasek> Damascene: the bug appears to already be in the right state thanks to persia; I don't think there's anything to do for now besides be patient
<mvo> thanks zyga
<slangasek> Damascene: mlterm will need a MainInclusionRequest done, but there's not much sense in doing that before May
<Damascene>  ok, thanks
<Keybuk> slangasek: hey, I think I just missed you saying something really important
<Keybuk> they called lunch :)
<slangasek> heh
<slangasek> Keybuk: hey, interesting follow-up in https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/554737/comments/30 - does mountall not make sure it's sent all its writes to plymouth before emitting the 'filesystem' signal?
<Keybuk> so I'm nicely full of steamed pork buns now
<ubottu> Launchpad bug 554737 in plymouth "ply_boot_client_flush() does not read replies (plymouth stuck during/after filesystem check or error)" [High,Fix committed]
<slangasek> Keybuk: since emitting 'filesystem' will kill plymouthd, with perhaps random strings left on the screen :)
<Keybuk> why would it flush writes before emitting a filesystem?
<Keybuk> oh, interesting
<dupondje> hehe :) I had that bug today
<Keybuk> no, it doesn't do that
<dupondje> fsck stuck @ 78%
<Keybuk> it should probably flush before any event though
<Keybuk> dupondje: did it continue to boot or was it properly stuck?
<Keybuk> on the basis we shouldn't "hard code" knowledge in mountall that filesystem is the one that might kill plymouth
<slangasek> fair
<dupondje> It stayed @ 78% for like 5 minutes
<dupondje> then I gave up and rebooted :)
<Keybuk> dupondje: right, that's the underlying bug that it seems that Steve has fixed
<dupondje> not yet released ?
<bdrung_cbase> how can i get a serial number (or something similar unique) from a cd drive? i want to use it in a script.
<Keybuk> slangasek: on the bpp thing, I hit a slight snag ;-)
<slangasek> ah?
<Keybuk> the vga16fb renderer has code to attempt to reduce the number of colours to fit in the palette
<Keybuk> if you're using 16-color images, you don't want that code
<Keybuk> so need not only a "Get the BPP" function
<Keybuk> but a "Set that I'm going to write Indexed images, so don't reduce the bit depth" flag
<slangasek> dupondje: in a PPA, details in bug #554737; don't use it if you're using nouveau kms
<ubottu> Launchpad bug 554737 in plymouth "ply_boot_client_flush() does not read replies (plymouth stuck during/after filesystem check or error)" [High,Fix committed] https://launchpad.net/bugs/554737
<slangasek> Keybuk: because the code will screw up the palette of the already-indexed image?
<Keybuk> slangasek: yup
<slangasek> well, fun
<Keybuk> the other theory is to have the vga16fb renderer "check the pixel buffer"
<Keybuk> if the buffer has no more than 16-colors anyway, don't use that code
<Keybuk> am experimenting with both
<Keybuk> I think the latter might actually work better
<slangasek> Keybuk: how soon do you think you'll have that sorted?  As long as we're having to change all the theme packages for this, I think we should give the i18n patch a go at the same time
<Keybuk> though I'm being distracted by someone explaining to Till that HAL has actually been removed from both Ubuntu and Fedora
<Keybuk> and he's getting quite upset about that
<Keybuk> so that's amusing
<Keybuk> slangasek: oh, working on it right now - so today
<slangasek> ok
<slangasek> Till is getting upset about hal's removal?
<Keybuk> yes
<Keybuk> there may be tears
<Keybuk> apparently HAL still exists on Mandriva
<slangasek> heh
<seb128> Keybuk, svu: the lvm2 source didn't change for 8 weeks and the bug started recently so it's likely due to some other change
<Keybuk> seb128: nothing to do with me
<Keybuk> I don't do lvm
<seb128> Keybuk, I'm just saying it changed while lvm didn't change so it's doesn't seem a lvm bug, or lvm was relying on something which changed
<seb128> Keybuk, I've no clue what it could be though, could be linux
<Keybuk> right, most likely the kernel side of lvm
<slangasek> seb128: what's the bug?
<Keybuk> almost half of lvm/devmapper is in the kernel after all
<Keybuk> slangasek: lvm is apparently not activating vgs/lvs for svu
<slangasek> hmm
<slangasek> still works reliably for me
<seb128> slangasek, he's on ppc if that makes any different and that started happening like a week ago I think according to what he said
<slangasek> sure, that might make a difference
<slangasek> and I agree that it's most likely the kernel
<seb128> I think he said that booting the previous kernel was still not working though
<slangasek> hmm
<seb128> https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/554478
<ubottu> Launchpad bug 554478 in lvm2 "power g5 does not boot lucid beta" [Undecided,Incomplete]
<seb128> slangasek, ^
<zyga> seb128: if it helps with anything I could try this with ps3 (ppc64 after all)
<seb128> zyga, thanks for asking, it's out of my domain though so I will let people who understand lvm reply on whether that would be useful ;-)
<seb128> svu, btw as the very similar one you copied your bug in the comment
<slangasek> zyga: yes, I think it would be helpful to try to reproduce it on another ppc
<zyga> slangasek: downloading daily image for ppc now
<zyga> slangasek: this will take about 60 minutes for me, should I setup lvm or just attempt to boot at all?
<slangasek> zyga: ehm, only lvm is relevant
<slangasek> so you would need to set it up, yes :)
<zyga> slangasek: no problem
<zyga> slangasek: will you stick around for one more hour?
<slangasek> several, as it happens
<zyga> slangasek: I will have the CD in 25 minutes
<jibel_> mr_pouit, thanks a lot for the new changelog scheme, that was fast.
<mr_pouit> jibel_: no problem, it was only some shell scripting. I haven't tested with update-manager yet thoughâ¦
<jibel_> mr_pouit, I tested with u-m and synaptic and that's fine. now waiting for ppa's changelogs :)
<mvo> \o/ jibel_ and mr_pouit
<ccheney> it appears dput on chinstrap doesn't upload all the v3 files specified in a changes file
<ccheney> actually hmm no thats not quite true
<ccheney> the .dsc for some reason doesn't list all the file it needs to upload gar
<bdrung_cbase> ccheney: what file do you miss?
<ccheney> s/.dsc/.changes/
<ccheney> the .dsc has them all
<ccheney> eg the .changes only lists
<ccheney>  008c0f2d7821a0e3c27de594d9f10f5355bc87cb 9167 openoffice.org_3.2.0-7ubuntu1.dsc b73172dea71eb365940be6e1933e90867adb7957 3667091 openoffice.org_3.2.0-7ubuntu1.debian.tar.gz
<ccheney> but the .dsc has and should have the following as well
<ccheney>  1dffc3a79dd3622d9c6a4b2e33d9d318c56bb3da 14582133 openoffice.org_3.2.0.orig-ext-sources-ooo-build-3-2-0-10.tar.gz 7b322b188a51976028c2dbf189356a958bc48549 13181789 openoffice.org_3.2.0.orig-ooo-build-3-2-0-10.tar.gz
<ccheney> do i need to a -sa build any time any source changes?
<ccheney> it seems it must not be smart enough to include just the changed parts (of course i don't know how it would be smart enough anyway)
<slangasek> if it's an upstream source, yes
<zyga> slangasek: I have ppc daily cd, will test now
<ccheney> slangasek: ah ok
<bdrung_cbase> ccheney: yes, if you want the source included
<ccheney> i don't need all the sources but the changed ones, i guess that still implies -sa since it would be hard for dpkg to figure out what changed
<bdrung_cbase> ccheney: it will only add it automatically if it's the first upload of the package
<ccheney> ok
<ccheney> that won't get the package rejected overall if one of the sources is still the same as the first upstream upload will it?
<slangasek> no
<ccheney> ok thanks :)
<slangasek> only if it has the same *name* as an existing component but doesn't match
<ccheney> slangasek: ok
<ccheney> ok OOo is now uploaded, hoping for no more rejections :)
<ScottK> ccheney: Is this one supposed to work on armel?
<ccheney> ScottK: possibly, NCommander was having trouble making -marm actually apply for some reason (i don't know why)
<ccheney> ScottK: its using the same if statement format as was used for ICU Os optimization
<ScottK> ccheney: OK.  I'm sort of on hot standbye to unseed OOo from Kubuntu Netbook if it doesn't end well.
<ccheney> ScottK: if the -marm isn't applying it appears that dpkg-architecture isn't returning the right name for the arch or something similarly weird
<ScottK> Nice
<ccheney> its pretty straight forward just:
<ccheney> ifneq (,$(filter $(ARCH), arm armel)) ARCH_FLAGS += -marm
<ccheney> endif
<ccheney> there should be a return after the )
<slangasek> "arm" - bah, dead arch, why bother? :)
<slangasek> "armel" should be sufficient
<ccheney> ARCH is set via: ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
<ccheney> slangasek: i added the arm myself in case of the weirdness :-\
<ccheney> the ifneq statement worked when i changed it to check for amd64
<ccheney> so i have no idea what is going on for the arm test he did
<joaopinto> any bug report but about "unreliable button press" with some usb mouses on Lucid ?
<joaopinto> generic-usb 0003:046D:C51B.0004: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:1d.0-1/input0 to be more precise
<joaopinto> hum, can't reproduce the problem now :\
<ScottK> Apparently not unreliable enough
<joaopinto> while moving the mouse a button release event is being triggered
<joaopinto> it worked fine on windows, but since it's random it could be broken :P
<svu> seb128, oops, you are right, I will give the url to the right bug
<zyga> slangasek: installation failed mid-flight package dependency issues, I'm checking if the system is bootable
<mpt> tremolux, any progress with bug 563128?
<ubottu> Launchpad bug 563128 in software-center ""Back" button goes to wrong place if you've gone back previously" [High,In progress] https://launchpad.net/bugs/563128
<tremolux> mpt: yes, it's fixed, just uploading to trunk as we speak
<mpt> great
<slangasek> zyga: oh, you said you were downloading a daily, didn't you?  beta2 would have been a better bet, Ithink
<Keybuk> slangasek: very untested code committed and pushed for bug #558352
<ubottu> Launchpad bug 558352 in plymouth "script splash needs to expose the renderer's bpp" [High,Triaged] https://launchpad.net/bugs/558352
<zyga> slangasek: hurm, I'll download beta2 as well then
<Keybuk> with a still missing image
<slangasek> Keybuk: ok, cool - eta on the image?
<Keybuk> kwwii-time
<Keybuk> two to three years?
<slangasek> I thought you'd said earlier that you already had the image?
<Keybuk> no
<Keybuk> I had all but one
<Keybuk> kwwii missed one out of the set
<slangasek> ah
<Keybuk> kwwii has sent me the missing image
<Keybuk> I'm just waiting for the network to give it to me
<Keybuk> please test the 16-color stuff hard ;-)
<Keybuk> slangasek: all pushed
<slangasek> Keybuk: yep, will get it tested in the next 3h or so
<slangasek> Keybuk: now, what do we do about nvidia in the nearterm?  I guess you have smb this week, so I can't pick his brain about libdrm; and we can't put that regression in the archive... what are the consequences of disabling the drm backend for all nouveau until we get this sorted?
<svu> it seems udev ignore lvm rule. funny
<Keybuk> slangasek: can't think of an obvious one
<Keybuk> it'll look a bit crappy on multi-head I guess
<Keybuk> and you won't get a smooth X transition
 * slangasek nods
<slangasek> those are the issues I knew of, both seem acceptable trade-offs under the circumstances
<Keybuk> yeah
<Keybuk> works > pretty
<Keybuk> svu: the rule is probably wrong
<Keybuk> udev doesn't just "ignore" rules
<ScottK> It will once it's a teenager.
<slangasek> fear the day when going to the bar to get away from udev is no longer effective
<svu> Keybuk, SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="lvm*|LVM*", \
<svu> 	RUN+="watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'" RUN+="echo lvm2 udev rule called > /dev/lvm-logfile"
<svu> (hopefully 2 lines is not a flood)
<Keybuk> err
<Keybuk> what
<Keybuk> that's clearly wrong ;)
<svu> funny. I did not change that
<Keybuk> someone did
<svu> except adding last RUN
<Keybuk> it's got a "/dev/lvm-logfile" thing on it
<svu> yes, that was the thing recommended in bug report - i added it
<svu> just today
<svu> 20 mins ago
<Keybuk> you're missing a "," ;-)
<svu> arrrrrrgh:)
<Keybuk> though I have a vague feeling that *replaces* the previous RUN+=
<svu> how stupid I am...
<svu> ok, will be back in 5 mins:)
<slangasek> well, even if it does replace it, it should still give us new information :)
<slangasek> the rule's already not working for ihm
<slangasek> him
 * kees is damn curious what's causing his lvm issue
<svu> inserting comma did not help:)
<slangasek> seb128, chrisccoulson: bug #519541 is a hang in abiword, but I've tried to debug it and AFAICS it's a bug in thread handling within gconf+ORBit when calling gtk_show_uri (http://launchpadlibrarian.net/43377610/gdb-backtrace.txt); does this sound familiar to either of you, or is there any chance you'd be able to put together a simple test case for gtk_show_uri() to rule this out?
<ubottu> Launchpad bug 519541 in abiword "Abiword 2.8.1 freezes with document lost when help is clicked or F1 is pressed" [Unknown,Confirmed] https://launchpad.net/bugs/519541
<slangasek> svu: kees also asked whether the rules are present in your initramfs, can you check that?
<svu> even with the comma, I still do not see that log file
<svu> slangasek, ghm. good question. You mean - unpack the initrd?
<slangasek> svu:  zcat /boot/initrd.img-$(uname -r)|cpio -t | grep lvm
<svu> yes, there is that rule
<kees> well, zcat /boot/initrd.img-$(uname -r)|cpio -t | grep rules    too, in case there is weird stuff in there
<slangasek> would there be stuff so weird that it would cause the lvm2 rule to be skipped?
<svu> nothing particularly weird, I'd say
<slangasek> it would have to overwrite SUBSYSTEM, ACTION, or ID_FS_TYPE to achieve that
<slangasek> svu: you should set your /lib/udev/rules.d/85-lvm2.rules back to the way it was originally, then
<kees> svu: can you pastebin the grep for rules, just to humor me?
<svu> slangasek, ok I wll
<svu> kees, http://pastebin.com/e8EU8yZ7
<slangasek> could it be mdadm?
<slangasek> that's the only thing in there that I don't have on my system
<svu> ghm. Should I disable it?
<kees> I have those
<slangasek> svu: not if you're using mdadm, you shouldn't
<dupondje> hmmm, when trying to mount a smb share: [29612.969676] gvfsd-smb[12227] general protection ip:7f9961f4873a sp:7f995dc5df30 error:0 in libc-2.11.1.so[7f9961ed1000+178000]
<kees> those mdadm rules should both be there.  hmpf
<svu> slangasek, I think I do not use it - unless lvm has hidden dependency
<chrisccoulson> slangasek - that doesn't look too familiar to me, and there shouldn't be anything particularly wrong with gtk_show_uri (it's just a wrapper for a GIO call which is used in lots of places)
<W3ird_N3rd> Hope I'm in the right channel. I think the netboot ISO is broken again. one or two days ago it couldn't finish because seemlingly no mirror had kernel modules, today no IP can be obtained using DHCP
<chrisccoulson> i can recreate that hang though so i might be able to investigate it
<W3ird_N3rd> I am using http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-i386/current/images/netboot/
<slangasek> chrisccoulson: it's reported to not occur with abiword on other distros, and I don't see *any* thread-mangling in abiword itself, so it really looks like a lib bug to me
<kees> svu: what does blkid /path/to/a/pv  report for you?
<svu> kees, what would be typical /path/to/a/pv ?
<kees> svu: "sudo pvs" should list them all
<seb128> slangasek, I doubt gtk behaves any differently on ubuntu
<svu> $ blkid /dev/sdb1
<svu> /dev/sdb1: UUID="53eHzV-oR6r-SImQ-bO63-BxGa-liKx-P4c215" TYPE="LVM2_member"
<dupondje> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/563409 => how can I create more information?
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/563409)
<kees> I think blkid is fine, though, since it reports LVM2_member in udev log.  yeah
 * dupondje slaps ubottu  :)
<slangasek> seb128: the commentors were comparing the same version of abiword across distros, not the same version of gtk
<seb128> slangasek, could also be a build option I guess
<slangasek> svu: how long does 'vgchange -a y' take to run on your machine?
<kees> hm, how is the udev transition across initramfs to rootfs handled?
<svu> slangasek, very fast. fraction of second
<kees> is it possible that there is some kind of race where a disk comes online, udev stops, pivots, starts, and the event is missed?  I can't imagine this is happening or we'd have all kinds of other problems
<svu> kees, err.... I cannot tell really. How would I check?
<kees> svu: mostly me just thinking out loud, hoping slangasek or Keybuk might think of something.  /me goes to re-read the initramfs scripts
<slangasek> kees: so, I read the initramfs scripts earlier today and can't figure out *what* it does
<kees> hah
<slangasek> I thought udev kept running after starting in the initramfs
<slangasek> but I can't see where it's told to chroot
<slangasek> or told to stop
<svu> kees, I see:)
<slangasek> or where it's told how to write a pid that upstart can pick p
<slangasek> up
<lifeless> persia: do you recall the latest time that asia membership meetings have been held ? Trying to decide whether to stand or nto
<W3ird_N3rd> nobody here uses netboot?
<slangasek> oh, there we go - /usr/share/initramfs-tools/scripts/init-bottom/udev
<Keybuk> slangasek: none of the above
<kees> slangasek: I imagine udev stays running, since it just writes to /dev and due to the bind mounts, it never actually pivots
<Keybuk> it kills udev
<slangasek> "pkill udevd"
<W3ird_N3rd> or has a clue otherwise what to do for me, I appreciate it
<slangasek> kees: so yeah, udev has two *separate* chances to run vgchange, and both are failing
<kees> Keybuk: how do we avoid missed events in this case?
<rickspencer3> slangasek, hi
<kees> slangasek: what's the second?
<Keybuk> kees: same way we avoid missed events before udevd is run in the first place
<rickspencer3> oops, sorry to interupt
<Keybuk> that's what "udevadm trigger" is _for_
<slangasek> kees: one in initramfs, one in rootfs
<slangasek> rickspencer3: hello
<rickspencer3> slangasek, so, low color boot image ...
<rickspencer3> I think it's uploaded, but hasn't been reviewed
<slangasek> W3ird_N3rd: the debian-installer package probably needs a reupload for the latest kernel ABI change
<kees> ah right, trigger re-triggers everything
<rickspencer3> could I tell the design team that if they see it tomorrow and something is wrong, they will get a chance to upload again tomorrow?
<rickspencer3> basically, being Euro based, I'd like to let them go to bed and fix problems when they are not too tired ;)
<slangasek> rickspencer3: it's not uploaded, it's in the plymouth bzr branch; I can't guarantee it'll be uploaded by tomorrow, but will try
<W3ird_N3rd> slangasek, there's nothing I can do to fix that, or install anyway? I configured a static IP now, but nothing can be downloaded
<rickspencer3> slangasek, ok, can I tell them that all is fine and we will take care of them, don't worry?
<W3ird_N3rd> it's now stuck trying to download a release file - I would have given up by now
<slangasek> rickspencer3: there are other bugs in the plymouth branch that need addressed before I can upload - but yes, they shouldn't stay up worrying about this
<slangasek> W3ird_N3rd: oh, if you can actually configure an IP, I guess it's not a kernel ABI problem at this point - I don't know what that problem is, though
<slangasek> W3ird_N3rd: could be anything from a bad ethernet cable to a buggy or missing firmware in the installer
<W3ird_N3rd> well when I try to configure using DHCP it says my network maybe doesn't use DHCP, which is not true
<W3ird_N3rd> and with the netboot from 1 or 2 days ago I DID succeed with DHCP, so the hardware is OK
<W3ird_N3rd> ok I'll see if I can find a totally different ethernet card
<W3ird_N3rd> what the hell.. DHCP succeeded with my ancient 3Com 589C and now the installer just..broke?
<cjwatson> Keybuk: will translation kittens die if I fix a typo in one of mountall's strings?
<cjwatson> -                                                     _("Press C to to cancel all checks currently in progress")));
<cjwatson> +                                                     _("Press C to cancel all checks currently in progress")));
<Keybuk> heh, they'll hate you
<W3ird_N3rd> no, it didn't, it's really loading now
<W3ird_N3rd> Xircom modules broken then?
<cjwatson> I didn't see any translations in mountall's source; I guess they're just in language packs?
<cjwatson> I'd *actually* like to fix the run-on sentence as well but that seems less justifiable :-)
<W3ird_N3rd> should I report that?
<cjwatson> slangasek: pretty sure I uploaded d-i earlier for the ABI change
<slangasek> cjwatson: ok then :)
<cjwatson> no idea what's broken for W3ird_N3rd; not aware of having changed anything to do with DHCP
<slangasek> cjwatson: translations are in langpacks for mountall, yes
<W3ird_N3rd> cjwatson, DHCP ain't broken, it appears to be the xircom driver
<cjwatson> ah, well I wouldn't know about that
<W3ird_N3rd> I'm now installing using an old 3Com card, but the Xircom Realport and Realport2 are silent in every possible language
<cjwatson> right, guess I ought to do a big d-i translations sync
<svu> I wonder .. if I am trying to do /etc/init.d/udev start (in manual repare mode, when only root is mounted), I am getting "basename: not found"
<slangasek> svu: udev doesn't use the init script in /etc/init.d, that's just a wrapper for the /etc/init/udev.conf upstart job
<cjwatson> it would be good if /lib/init/upstart-job didn't use executables in /usr though
<kees> svu: instead of running vgchange -a y, try udevadm trigger
<cjwatson> given that it's trivial to avoid - INITSCRIPT="${0##*/}"
<svu> kees, just "udevadm"? no params?
<Keybuk> cjwatson: why?  it's an education wrapper
<Keybuk> if anything *calls* it, that's a bug
<cjwatson> I didn't say it was critical, I just said it would be good
<W3ird_N3rd> after the install is finished I'll burn the mini.iso one more time and try, if it still doesn't work it must be a bug, should I report it in that case? or is there no need for that
<slangasek> not maintainer scripts; but you don't run maintainer scripts in rescue mode either
<slangasek> (or: it's a bug, but it's not a bug in the maintainer script :)
<cjwatson> it would be so easy to avoid depending on /usr there, so it might as well
<cjwatson> W3ird_N3rd: I guess if the xircom driver is broken, that should be reported as a kernel bug
<W3ird_N3rd> I don't know what kernel the netboot disc uses.
<W3ird_N3rd> anyway that part was working 1 or 2 days ago.
<cjwatson> the standard kernel
<W3ird_N3rd> so must be a bleedingedge kernel
<kees> does that still not bring them online?
<chrisccoulson> seb128 / slangasek - frames 10 and 11 of the main thread in the abiword backtrace are weird
<cjwatson> W3ird_N3rd: it's just rebuilt occasionally against whatever's current in lucid
<W3ird_N3rd> lucid kernel is frozen so that makes this case very mysterious
<chrisccoulson> the GConfClient passed to gconf_client_get_full is pointing to the wrong address
<chrisccoulson> as is the key
<chrisccoulson> someone might want to get a valgrind log there
<svu> kees, what would be the right parameter to pass to kernel - to get rid of plymouth?
<slangasek> chrisccoulson: good point; could easily be a gdb bug instead, but valgrind is a good next step
<directhex> i think i know why my syncpackage upload was disappearing
<wgrant> seb128: Thanks for the swift upload of that papyon fix.
<chrisccoulson> in any case, the client and key parameters in frames 10 and 11 should be identical
<seb128> wgrant, thanks for coming with a patch for the issue ;-)
<slangasek> ** (abiword:16501): WARNING **: Running under buggy valgrind, see http://bugs.kde.org/show_bug.cgi?id=164298
<ubottu> KDE bug 164298 in general "finitel() returns false normally but true under valgrind" [Normal,Resolved: wontfix]
<slangasek> heh
<slangasek> chrisccoulson: no valgrind errors of note
<chrisccoulson> slangasek - ok, i'll have to have another think then
<zyga> slangasek: still installing, ps3 is dog slow for I/O
<persia> lifeless: Latest time?  We varied for a bit, but seem to have standardised at 10:00 UTC.
<persia> lifeless: Mind you, if you're counting in CHADT, that can be quite late indeed.
<matumba> Keybuk, i've run the 16-bit plymouth theme and got some initial flicker: http://www.youtube.com/watch?v=8aM2lrrjzGc - other than that it seems to work fine
<kees> svu you can't get rid  of plymouth.  if you want to drop splash, just leave off "splash".  I tend to drop "splash" and "quiet"
<svu> kees, udevadm trigger worked. activated my VG
<svu> so... what does it prove?
<kees> svu: that is simultaneously encouraging and disheartening.  :)
<svu> :)))
<slangasek> svu: is /etc/init/udevtrigger.conf present on your system?
 * svu feels proud
<kees> it means that the udev rules are correct in that they bring the vg online.  but, they should be since it works everywhere else.
<svu> slangasek, yes
<slangasek> svu: boot with --verbose, and post your /var/log/boot.log?
<svu> kees, yes, that sounds logical. but ... I see what I see :)
<svu> slangasek, where should I add --verbose ?
<kees> slangasek: where does --verbose go?
<kees> heh
<lifeless> persia: I'm considering NZ DST time impacts
<slangasek> svu: the kernel commandline
<kees> network lag ftl
<slangasek> which is the awesomest thing ever
<lifeless> persia: which would have it at 11pm
 * svu never heard of such kernel option
<slangasek> it's not a kernel option, it's an upstart option :)
<Keybuk> slangasek: most awesomest thing ever?
<lifeless> persia: meh, I can do that every 2nd week for 6 months:- care to nominate me ?
<persia> lifeless: Right.
<slangasek> Keybuk: yes!
<Keybuk> slangasek: what is?
<persia> lifeless: Sure.  Up for an exchange?
<svu> slangasek, I'm afraid there won't be much use - because /var/log is on lvm partition
<slangasek> Keybuk: --verbose as a boot option
<lifeless> sure
<Keybuk> ahh ;)
<Keybuk> wait until you see what I have planned in Maverick
<Keybuk> svu: that's ok ;)  there are tricks once you've booted
<slangasek> svu: that's ok - as long as you don't kill plymouth, once the vg is up the log should get written
<ajmitch> lifeless: you're going to be back in NZ?
<svu> how would I disable that stupid graphical screen? I want to see the console all the way! nosplash does not help
<Keybuk> svu: remove "splash"
<Keybuk> where the hell did somebody document "nosplash"
<svu> Keybuk, I have "nosplash"
 * Keybuk has NEVER heard of that
<svu> ok
<Keybuk> svu: where did you read to put "nosplash" there?
<svu> ok
<svu> so, just append="--verbose" ?
<Keybuk> yes
<Keybuk> well, with root= and all that other useful stuff
<svu> sure
<slangasek> Keybuk: I have heard of other distros having the inverse default and passing nosplash to disable; so it's probably cross-distro confusion rather than Ubuntu-specific docs
<Keybuk> slangasek: other distros can't include Fedora/RedHat - otherwise this would work <g>
<slangasek> maybe it was Mandriva?
<Keybuk> Heh
<lool> kirkland: I had suggested to try similar cache= settings for the qemu-kvm hang bug, but I don't know whether anybody tried; thanks for writing it in the bug
<Keybuk> I think they use Plymouth too actually
<slangasek> oh, crap
<slangasek> first google hit for 'nosplash' is ubuntuforums
<ccheney> openjdk takes over 12hr to build on amd64? thats even longer than OOo, heh
<Keybuk> first google hit for "beetroot salad" is probably ubuntuforums
<Keybuk> ubuntuforums is the first google hit for *anything*
<slangasek> the second hit is "no splash, no flush urinals from Kohler"
<Keybuk> it's the ultimate source of people being wrong on the internet
<lool> lol
<kees> ccheney: it's the testsuite timing out, mostly
<lool> slangasek: You should turn safe search on
<W3ird_N3rd> the selected kernel, kernel package linux-generic, could not be installed
<slangasek> lool: oh man, and miss out on cheap urinal humor?
<W3ird_N3rd> I consider the netboot ISO untestable
<W3ird_N3rd> it's just too damn buggy.
<lool> slangasek: No, I meant to hide the ubuntuforums results
<slangasek> lool: hah
<W3ird_N3rd> I guess this means nobody really uses the netboot ISO
<W3ird_N3rd> poor me
<slangasek> W3ird_N3rd: wait, you're using the netboot *ISO*?  No, people generally don't use that
<W3ird_N3rd> http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-i386/current/images/netboot/mini.iso
<W3ird_N3rd> so what do people use?
<cjwatson> Keybuk: nosplash was an installer option for about a day
<cjwatson> before I saw the light and replaced it with debian-installer/splash=false
<cjwatson> hey, I use the netboot ISO sometimes
<cjwatson> works fine for me
<cjwatson> broken for you != untestable in general
<lifeless> ajmitch: yes, end of the month
<lifeless> ajmitch: you should look at facebook more often :P
<cjwatson> the netboot ISO is just a simple repackaging of the separate netboot kernel and initrd files - it's unlikely to suffer from different bugs
<W3ird_N3rd> cjohnston, linux-generic cannot be installed, how can that be my fault
<cjwatson> "cjwatson"
<W3ird_N3rd> *cjwatson
<cjwatson> W3ird_N3rd: that's just a transient archive problem, wait a bit
<W3ird_N3rd> autocomplete..
<cjwatson> type more characters first then, and read the output.
<cjwatson> netboot is very susceptible to the state of the archive
<cjwatson> that's not a bug, it's just the way netboot works
<W3ird_N3rd> I'm usually in channels with less people and your names have a similar length, so easy to get wrong..
<cjwatson> might even be a problem with the mirror you're using being out of date
<cjwatson> http://people.canonical.com/~ubuntu-archive/testing/lucid_probs.html says that, while a number of things are uninstallable in lucid right now, linux-generic is installable
<W3ird_N3rd> I like netboot because it's only 12MB, less writing time and some CD-RW's have some flaws, but the first 12MB are usually OK. also it gets me the latest packages right away
<cjwatson> but I'm happy to look at an installer syslog to check
<cjwatson> "save debug logs" from the main menu to extract it
<svu> boot.log : http://pastebin.com/0e5rAABM
<cjwatson> it gets you the latest bugs right away too ... :-)
<cjwatson> netboot gets a lot more stable once we release
<ajmitch> lifeless: I should, but it's usually such a waste of time :)
<svu> amazing. boot.log is using MSDOS EOL convention. hehe
<W3ird_N3rd> cjwatson, nah, damn, found it. failure resolving nl.archive.ubuntu.com. sigh
<Keybuk> svu: it's using terminal convention
<Keybuk> it's the log of writes to a pty
<svu> ok
<svu> but I do not see much interesting there
<cjwatson> W3ird_N3rd: that would do it, although it's odd it didn't fail before that
<Sarvatt> hmm, anyone familiar with why dbg packages in the archive for mesa and xserver are messed up while PPA ones are fine? the CRC's in .gnu_debuglink are wrong with the archive versions
#ubuntu-devel 2010-04-15
<Keybuk> svu: the general idea is that you give *us* the log - and we look for things ;)
<svu> Keybuk, :) ok. I provided pastbin url :)
<Keybuk> oh, missed that
<Keybuk> slangasek: you know what I *don't* spy in that boot.log ?
<slangasek> Keybuk: udev?
<Keybuk> udev
<svu> I would be surprised if you find something there. it looks so empty
<slangasek> so udev is *running*, but not under control of upstart
<W3ird_N3rd> cjwatson,  kernel [nnnn.nnnnnn] eth2: interrupt(s) dropped! < bloody hell
<Keybuk> slangasek: but why isn't upstart even trying to start it?
<Keybuk> you should see, at least, an attempt to start udev
<cjwatson> W3ird_N3rd: sorry, I don't know anything about that, I doubt it's installer-specific
<slangasek> svu: can you pastebin /etc/init/udev.conf, please?
<svu> sure
<svu> http://pastebin.com/9m2GArqB
<slangasek> interesting
<W3ird_N3rd> I'll just wait for mini.iso rebuilding 14 april and try again. I'm going to sleep now
<slangasek> Keybuk: I got nothin'
<W3ird_N3rd> had enough :P
<Keybuk> upstart must think it's already running
<Keybuk> *but that makes no sense*
<Keybuk> svu: what does "status udev" say?
<svu> udev start/running, process 393
<Keybuk> err
<kirkland> lool: no problem ... let me know how it goes.  it's extremely timely for me to reproduce it as i don't have a ports mirror, etc.
<svu> Keybuk, or should I do "status udev" when in manual recovery mode?
<lool> I don't have enough space to try to reproduce myself either
<Keybuk> please
<svu> Keybuk, ok, 2 mins, another reboot
<Sarvatt> hmm so the -dbgsym packages are correct but -dbg has the wrong CRC
<kees> Sarvatt: I'd noticed that too, but never investigated since -dbgsym works so well
<svu> Keybuk, udev start/running, process 401
<kees> Sarvatt: they also crash libbfd sometimes :)
<kees> Sarvatt: if you could open a bug report, I can confirm it.  I'd never gotten the time to really dig into that.
<Keybuk> svu: can you pastebin a ps at this point
<Sarvatt> kees: will do, I was just insure where to file it. pkg-create-dbgsym?
<svu> Keybuk, arrgh. I wish you had asked a bit earlier :) ok
<slangasek> Keybuk: btw, thinking about it some more I know my fix for the deadlock is still racy, because "process incoming events until the queue is empty; write our request" is not atomic
<slangasek> but I don't think I'll have time to fully fix this
<Keybuk> right, I was thinking we should just call poll() in the loop
<slangasek> Keybuk: in which loop?  to fully fix it, ply_write() has to be interruptable, neh?
<IntuitiveNipple> Is there a way to force update-manager to offer a restart?
<lifeless> persia: wow, quite eloquent
<Keybuk> in the loop in that function
<slangasek> kirkland: are you still seeing bug #540091?  Because bug #559582 claims to still have the problem, and that was filed after 540091 was fixed
<ubottu> Launchpad bug 540091 in mountall "libplymouth2<->mountall circular dep prevents upgrade from karmic" [High,Fix released] https://launchpad.net/bugs/540091
<kees> Sarvatt: no, dbgsym is fine.  it's the -dgb infrastructure from debian that is broken
<ubottu> Launchpad bug 559582 in mountall "Upgrade from karmic to lucid failes with Internal Error, Could not perform immediate configuration (2) on mountall" [Undecided,Confirmed] https://launchpad.net/bugs/559582
<slangasek> Keybuk: ah
<Keybuk> that'll mean it'll call read when it can, call write when it can
<Keybuk> etc.
<slangasek> right
<persia> lifeless: thanks :)
<lifeless> persia: I don't think I achieved your eloquence, but I think you're rather better known than I:P
<bryceh> persia, btw I got X up on your little displaylink device
<persia> lifeless: I think the key bit for any nomination of me is probably "he seems to be around a lot".  No eloquence required :)
<persia> bryceh: With the xsfbs build?
<svu> Keybuk, http://pastebin.com/k2yHLzsA
<bryceh> persia, well it also needed another library libdlo
<bryceh> which I just installed manually, it'll still have to be packaged I guess
<bryceh> persia, good news is I now understand what it'd take to make this thing work
<persia> bryceh: What did you do that needed that?  I had it working in February without it.
<persia> bryceh: By "work" do you mean "autodetect and have GUI config interface"?
<bryceh> persia, but bad news is it looks like it'll only work with Xinerama
<bryceh> no I mean be able to get X running on it with an xterm
<persia> bryceh: Did you try the xorg.conf in the README?  That mostly just worked for me with no extra libraires.
<bryceh> persia, yep, after installing the lib and verifying that worked I put the xorg.conf changes in and verified that worked.  again though, it requires Xinerama if you want to fire up both the display and your regular monitor
<persia> bryceh: So, what does the xinerama limitation mean?  What needs to happen to make it work the desired way?
<bryceh> so that's only feasible with -nvidia for now
<slangasek> Keybuk: triaged bug #559761 for the "mountall needs to flush" issue; I think we should fix this for final, is this something you'll be able to get to?
<ubottu> Launchpad bug 559761 in mountall "mountall needs to flush plymouth message queue before emitting upstart events" [High,Triaged] https://launchpad.net/bugs/559761
<persia> I really had it working with -intel without the library :)  I'll fiddle with it more after UDS, when I have hardware again.
<Keybuk> slangasek: it's just adding that same flush function call into emit_event right?
<slangasek> Keybuk: I dunno, haven't looked at the code :)
<Keybuk> svu: at this maintenance shell, do you have lvm working?
<Keybuk> slangasek: can't see any reason why it would be harder than that
<Keybuk> though it'd be a good idea to fix flush first ;)
<persia> bryceh: So, on a more general note: what does the xsdfbs bit bring to the package?
<svu> Keybuk, at that shell I can do "vgchange -a y" - and continue booting. otherwise I cannot boot
<Keybuk> svu: that's not what I asked
<persia> bryceh: I noticed the extra Provides and dependency on the right base X lib, but that seemed to be two lines from the bundle of stuff.
<svu> Keybuk, well, perhaps I did not understand your question.
<svu> how do you mean "lvm working" - do you mean lvm binary?
<bryceh> persia, it means the driver needs to support xrandr (and will require upstream to support multiple video devices (bug #316514))
<ubottu> Launchpad bug 316514 in xorg-server "MASTER: Xinerama/Multihead with several video cards is not supported" [Wishlist,In progress] https://launchpad.net/bugs/316514
<Keybuk> svu: can you reboot
<Keybuk> get back to that maintenance shell
<Keybuk> and then gather some information for me
<bryceh> persia, that's the packaging system debian uses, so if we want them to eventually adopt the package it has to have that packaging system
<Keybuk> (without running vgchange or anything yourself)
<svu> ok
<svu> what commands should I run, what info to collect?
<Keybuk> do you not have a second machine to IRC from?
<persia> bryceh: Did you plan to bring it to XSF for adoption?  I had thought I'd just toss it in as an arbitrary optional extra package post-squeeze, but I'm happy if someone else wants to maintain (or team maintain) it.
<bryceh> persia, I have no such plans
<svu> Keybuk, ghm. I will check if my 2nd mac has any irc client...
<Keybuk> svu: I guess a useful answer would be whether you have a /dev/.udev.log file at that maintenance shell
<bryceh> persia, in fact I think it looks like the work to get this supported is well beyond my scope and time availability
<Keybuk> if you do, what is the output of "lvm vgs" and "lvm pvs"
<Keybuk> are there device nodes in /dev/mapper?
<Keybuk> ls -l /dev/mapper
<Keybuk> include owner/group stuff
<Keybuk> (even just of control)
<snow_ru> hi
<persia> bryceh: Fair enough.  If you have time, I'd appreciate a write-up of what you think needs doing, and I'll recollect the device and fiddle with it some more myself.
<bryceh> persia, anyway, I'll return the device to you at UDS
<svu> Keybuk, I know for sure I have /dev/.udev.log !
<Keybuk> svu: at that maintenance shell?
<svu> yes
<Keybuk> and it has contents?
<snow_ru> is there any project that needs a volunteer ?
<persia> bryceh: Sounds good.  Thanks for confirming it still worked after the changes to the package.
<bryceh> persia, when you got it working before, did you get the full desktop session up and everything?
<svu> Keybuk, yes. IIRC I copied it yesterday here (pastebin)
<Keybuk> ok
<Keybuk> the answers to the other questions would be nice to have
<bryceh> persia, and was that with only the usb monitor enabled or did you have two monitors going?
<Keybuk> oh
<Keybuk> output of "cat /proc/self/mountinfo" there too
<persia> bryceh: I didn't try that far, as I only had about three days with the device, and was otherwise occupied at the time.  I got X running in it with metacity and terminator though.
 * persia mostly found it happened to still be in the laptop bag when the SiS USB devices were being bandied about.
<bryceh> well I didn't get to those either
<svu_> ok, another me
<Keybuk> yay, clones
<svu> :)
<persia> heh.  No worries.  A quick search found a fix for XRandR that was reported to work in Jaunty.  I'll see if I can't get it to work more sensibly for maverick.  Do you think that the USB probing might hit X so that it would be autodiscovered, or still need an xorg.conf.
<Keybuk> svu_: ok, let's start with the basics
<bryceh> persia, to be honest I haven't dug into the usb probing to know if there's been work on that upstream
<Keybuk> reboot the other box, and get it to that maintenance shell
<persia> snow_ru: There's heaps of stuff that needs volunteers, but here in Ubuntu we tend to focus on everything, rather than specific things.  If you want to work on a specific thing, I recommend finding a bit of software you like, and chasing it to fix all the bugs (bugs.launchpad.net/ubuntu/+source/${PACKAGE}/+bugs is a good place to start.
<bryceh> persia, well, I should say I scanned through the xorg-devel mailing list but didn't find anything there
<bryceh> persia, but that was a few weeks ago
<persia> bryceh: Is USB probing something you're likely to be able to investigate in maverick?
<svu_> yes, there is /dev/.udev.info
<svu_> a lot of stuff inside
<bryceh> persia, no I won't be working on X in meerkat
<Keybuk> svu_: no /dev/.udev.log
<svu_> sorry I meant udev.log
<svu_> of course
<Keybuk> svu_: ok, can you get me the output of /proc/self/mountinfo ?
<Keybuk> cat /proc/self/mountinfo I mean
<persia> bryceh: Ah, in that case, no worries.  I'll file a bug if I run into a solution.
<svu_> ghm.... smbmount does not work :(
<Keybuk> svu_: ? I didn't ask you to run smbmount
<svu_> how would I copy that stuff here?
<svu_> on second machine?
<svu_> Or just save it into different location and provide you after I boot successfully?
<svu_> or copy to usb flash?
<Keybuk> svu_: can you not take a photo of the screen?
<svu_> ghm. ok :)
<Keybuk> we're trying to debug a failure to mount a filesystem
<Keybuk> going around mounting filesystems is *going to change the result* :p
<svu_> indeed. ok, I got some shot using my mobile...
<svu_> Keybuk, is rapidshare good enough?
<slangasek> svu_: you could just post it to the bug report?
<svu_> slangasek, right:)
<svu_> added to bug report
<svu_> http://launchpadlibrarian.net/44204574/Image0021.jpg
<svu_> anything else?
<snow_ru> ok
<snow_ru> bye
<Keybuk> svu_: ok, well that all looks right
<Keybuk> hmm
<Keybuk> ls -l /dev/mapper/control
<Keybuk> what's the permissions and ownership?
<svu_> root:root
<svu_> crw-rw----
<Keybuk> ok
<slangasek> Keybuk: didn't tseliot say he had a bzr branch for part of this i18n fix?  I can't find it now
<Keybuk> svu_: ls -l /dev/tty1
<Keybuk> same question
<svu_> root:tty
<Keybuk> ok
<Keybuk> so udev is working
<svu_> crw--w----
<Keybuk> what does "lvm vgs" say?
<svu_> it shows VG1
<svu_> PV 1 LV 3 Attr wz--n-
<svu_> BUT
<svu_> there is one thing
<svu_> suspicious
<svu_> many commands say File descriptor 8 leaked
<svu_> I noticed that before many times
<svu_> does it matter?
<Keybuk> that's just the shell ;-)
<svu_> ok
<svu_> I felt I have to let you know :)
 * kees wonders if watershed is iin the intramfs
 * svu_ feels soon he will have to tell the superuser passwd and IP address :)
 * ScottK gets a pencil.
<svu_> ScottK, nothing interesting on that system. Just old power g5...
<ScottK> ;-)
<psusi> well that was interesting... updated my system which included an update to grub and a new kernel, and it decides not to add the initrd line to the new boot stanza.. add it myself and it boots.... grub-update again and it does it right this time.... I have a feeling there's a race condition somewheres.. ugh...
<svu_> Keybuk, anything else to check?
<Keybuk> well
<Keybuk> I'm stuck
<Keybuk> lvm knows about your vgs
<Keybuk> no idea why it hasn't activated them
<Keybuk> I think udev has run lvm
<svu_> how would I check that in .udev.log ?
<svu_> how could I debug udev activities on boot?
<IntuitiveNipple> Keybuk: Excuse me, I've not seen the bug you're working on but mentioning the LVM not mounted issue reminded me I've seen that here too, but always just gone into maintenance mode
<Keybuk> that's harder
<Keybuk> modify udev.conf to start with --debug
<svu_> IntuitiveNipple, and what did you do in the maint mode?
<IntuitiveNipple> Keybuk: strangely what I found was that whilst I was at the prompt thinking what to do, the missing device 'appeared' after a delay
<IntuitiveNipple> so I just exit M mode and the system continues to start correctly
<psusi> svu_, the volumes don't belong to another machine or instance do they?  unless they have been set up or imported they won't be automatically activated
<IntuitiveNipple> I assumed a race condition in mountall or similar
<svu_> psusi, all same machine, SATA drive
<svu_> Keybuk, why is that harder?
<Keybuk> svu_: well, you have to do something ;-)
<svu_> Keybuk, :) I just did. interesting change in behaviour after reboot
<svu_> When I ask 'vgchange -a y' - I am getting error about missing mapper in /proc/misc
<svu_> !!!
<Keybuk> slowed it down enough to make it work?
<svu_> But
<Keybuk> oh, that's kinda interesting
<svu_> after some while
<svu_> and several attempts
<svu_> it worked
<svu_> and ... I think I had to make udevadm trigger as well
<svu_> yes
<svu_> and I see device-mapper in /proc/misc - all the time!
<svu_> actually!
<svu_> device-mapper is not there initially
<svu_> indeed
<svu_> not in /proc/misc
<kees> that's odd
<svu_> even after udevadm trigger
<svu_> suddenly (timeout??) I see a lot of output on console
<Keybuk> I thought we built that in
<svu_> and voila - device-mapper in /proc/misc
<psusi> sounds like the driver isn't being loaded before the tools try to use it
<svu_> it seems there was some delay
<svu_> and --debug made that delay even bigger
<cjwatson> ./config.common.ports:289:CONFIG_BLK_DEV_DM=m
<cjwatson> ./config.common.ubuntu:375:CONFIG_BLK_DEV_DM=y
<cjwatson> so on svu_'s powerpc box it won't be built-in
<svu_> ports!!!!!!!!
<Keybuk> oh, that's kinda fun
<Keybuk> so when the underlying block device shows up ...
<Keybuk> lvm is run ...
<cjwatson> silly ports split
<Keybuk> but device-mapper isn't loaded
<Keybuk> so boom
 * persia filed a bug about that recently, and hunts up the number
<svu_> boom
<svu_> baga boom
<persia> bug #560717
<ubottu> Launchpad bug 560717 in linux "lucid sever fails to boot with LVM root" [Undecided,New] https://launchpad.net/bugs/560717
<Keybuk> cjwatson: well done
<Keybuk> shall I try and bread roll a kernel dev?
<persia> svu_: Please confirm and mark as affecting you :)
<cjwatson> Keybuk: might not hurt, I don't know if they have time for another upload / were planning one anyway
<cjwatson> slangasek: so that mountall typo I noticed above - do you think we can squeeze in a fix for it?
<svu_> persia, I marked "affects me too"
<cjwatson> it's sitting there on the screen for some time and I'd rather not have a typo there
<persia> svu_: Thanks.  If we can get all the powerpc LVM users to do that, maybe we can get an SRU, even if we can't get a prerelease upload :)
<slangasek> cjwatson: we're getting mountall string changes anyway today (unfortunately) to fix an untranslatable string, so yes
<slangasek> (just as soon as I verify the upgrade path on mountall+plymouth)
<cjwatson> ok
<cjwatson> will commit in a sec
<svu_> persia, ok. Thanks a bunch, I would love to get that fixed. Otherwise the boot process does not look nice :)
<psusi> Keybuk, say... what sort of tools should I look at to investigate a blocktrace during boot?  I got e2defrag to pack all the files ureadahead wants at the start of the disk and oddly, the peak throughput went down slightly though total time in ureadahead also went down by a few seconds
<svu_> thank you all lads for you help
<asac> directhex: hola
<asac> directhex: why do you tink that having minVersion 1.9 is right?
<asac> in gluezilla
<directhex> asac, because it works (although not with 1.9.3 according to micahg), whereas the previous hard-coding caused more issues than it solved
<asac> directhex: its not a good idea to just keep it fully open
<Keybuk> psusi: blktrace ;)
<asac> directhex: so definitly minVersion needs to be 1.9.2
<psusi> lol... of course ;)
<asac> directhex: there is no guarantee that standalone glue works with something lower than what it was linked from
<asac> directhex: for higher versions we would need to review what xpcom components it uses. if those are all frozen its fine to keep 1.9.*
<asac> as maxversion
<asac> but 9.9 is definitly wrong ;)
<micahg> I'll push my working patch up to the ffox36 transition PPA to test
<kees> Keybuk: udev starts before modules are loaded...
<directhex> asac, frankly, i'm sick to death of the package. do whatever, i really don't care as it only affects people running system.windows.forms apps with embedded browser controls (i.e. nothing in the archive). do what you like with it, use http://www.java2s.com/Code/CSharp/GUI-Windows-Form/WebBrowserinaction.htm to test it
<kees> init-top, then module loads, etc.
<Keybuk> kees: well, yes
<Keybuk> udev *loads* modules
<asac> directhex: kk
<kees> since ide is builtin, the vgchange triggers before device-mapper is loaded
<persia> Keybuk: Ought udev be loading dm_mod in this case then?
 * kees is fighting tmobile's network
<asac> directhex: sorry about that :(
<Keybuk> persia: no
<asac> will take care
<Keybuk> dm_mod is one of those modules that can't be auto-loaded
<Keybuk> which is WHY IT'S BUILT IN! :p
<persia> aha! (except it's not) :)
<Keybuk> well, that's the bug
<persia> Right.
<directhex> asac, also try shana on gimpnet #mono, within portugese working hours
<persia> But now I understand it, rather than it just being a mysterious failure which I knew how to make go away :)
<directhex> asac, at the very least, -2 works, -1 segfaulted, so it could be worse
<asac> heh ;) thanks alot
<psusi> well, it could be auto loaded... if udev tested for and loaded it if not already before invoking the tools that depend on it... or better yet, the tools could do that... I don't see why libdevmapper doesn't do that already
<directhex> or @sh4na on twitter
<Keybuk> psusi: because libdevmapper can be invoked by users
<kees> Keybuk: so, bug on the kernel then?  won't make rc1...
<Keybuk> kees: I think so
<Keybuk> psusi: users can't load modules
<kees> Keybuk: yeah, looks like it's built-in in karmic.
<asac> directhex: ok. makes some sense. the currently disabled patch forced the load of xulrunner 1.9.1. so yeah. that crashes :)
<Keybuk> kees: yeah, it's like unix, ppp, fuse, etc.
<Keybuk> it makes no sense to be a module
<directhex> asac, forcing 1.9.2 didn't work for me on one machine, just had a grey screen
<Keybuk> it has to be loaded by hand to work
<directhex> asac, so be sure to test changes
<Keybuk> etc.
<Keybuk> so just build the thing in
<persia> kees: I can confirm it was built-in for powerpc/amd64 in karmic and amd64 in lucid (but not powerpc).
<asac> directhex: yes, dont bother. we will check this out
<kees> hrm. only I don't see it ... ah! not built-in in ppc!
<asac> directhex: will let you know
<persia> kees: RIght, or, for that matter, on sparc/ia64.  armel is messy enough I don't even want to look.
<kees> we could make the initramfs hook for dmsetup fail if dm_mod isn't built-in...
<psusi> Keybuk, they can't use libdevmapper either
<Keybuk> psusi: sure they can
<cjwatson> psusi: is this discussion anything other than academic?  things clearly work better if it's built-in, so build it in.  the only downside is a small increase in core kernel size, which really is not that much of an issue on Ubuntu.
<persia> Could we make the initramfs hook for dmsetup attempt to load dm_mod if it's not present?
<Keybuk> then you just move the bug to requiring an initramfs
<Keybuk> seriously
<Keybuk> just build the module in
<cjwatson> there's no point bikeshedding when there's precious little upside to making it be a module
<Keybuk> lots of things stop working if you go around changing random =y to =m
<kees> persia: it does already.  it's just after udev starts
<psusi> Keybuk, crw-rw---- 1 root root 10, 59 2010-04-14 20:02 /dev/mapper/control
<Keybuk> psusi: chmod id
<psusi> cjohnston, true
<persia> Anyway, my bug calls for it to be a built-in.  Let's hear from a kernel dev.
<Keybuk> psusi: you're allowed to do that
<Keybuk> persia: the kernel dev who walked past on his way to get a nexus one said it's ok to build it in on ports
<Keybuk> since it is in common ;)
<kees> persia: which bug #, btw, I'm a bit lost on scrollback
<kees> heh
<persia> kees: bug #560717
<ubottu> Launchpad bug 560717 in linux "lucid sever fails to boot with LVM root" [Undecided,New] https://launchpad.net/bugs/560717
<psusi> Keybuk, think the kernel checks for CAP_SYS_ADMIN anyhow ;)
<asac> directhex: oh. what was the best way to test?
<Keybuk> psusi: for devmapper? it shouldn't
<directhex> asac, paste the code from http://www.java2s.com/Code/CSharp/GUI-Windows-Form/WebBrowserinaction.htm into a .cs file, run gmcs -pkg:dotnet foo.cs; mono foo.exe
<kees> psusi: SYS_ADMIN for what operation?
<directhex> asac, that's a reasonably minimal example SWF browswer
<slangasek> Keybuk: tested out the low-color icons, I think I'm ready to upload - any objections?
<Keybuk> slangasek: none
<Keybuk> does it look at least 5% less crappy?
<slangasek> it looks pretty crisp
<psusi> kees, the ioctls to manipulate the device mapper tables
<asac> directhex: it wants dotnet.pc
 * asac esarches
<directhex> asac, mono-devel
<kirkland> slangasek: i haven't tried a karmic -> lucid upgrade in a while
<asac> oh .. thats a lot of stuff
<slangasek> kirkland: did you test one after I uploaded the change?
 * psusi wonders what the HELL could be confusing parted about what fs type is on partition 1 after creating it while partition 2 is mounted... yet unmounting partition 2 OR reformatting partition 1 from within parted fixes it
<kirkland> slangasek: what's the date of that?
<kees> psusi: ah, yeah
<kirkland> slangasek: i can background one in a vm, if you like
<slangasek> kirkland: 30 Mar
<slangasek> kirkland: a test would be helpful
<kirkland> slangasek: i probably have not
<kirkland> slangasek: i'll do that now
<Keybuk> psusi: blkid
<Keybuk> touching things would result in blkid running again from udev
<kirkland> slangasek: via do-release-upgrade -d ?
<MattJ> Is there a default user group for admins?
<slangasek> kirkland: however it was reproduced before
<slangasek> kirkland: and/or however that bug says it's reproducible
<MattJ> I'm making a package, and debating what permissions to put on the config folder in /etc
<kirkland> MattJ: there is an admin group
<MattJ> Do you know if that's an Ubuntu-only thing, or Debian too?
<psusi> Keybuk, yea... and blkid recognizes the partition type just fine... but even rescanning/restarting parted and it still doesn't
<kirkland> MattJ: i'm pretty sure admin is consistent across Ubuntu and Debian
<kirkland> slangasek: upgrade underway, against local mirror
<kirkland> slangasek: give it a few minutes, i'll check back
<psusi> partition 1 exists, is readable, writable, mountable, yet parted won't detect the fs type... it's so weird....
<Keybuk> right
<Keybuk> party
<bcurtiswx> how long do the builders wait with no buildlog changes before they fail out?
<persia> bcurtiswx: 150 minutes
<bcurtiswx> persia: yikes, openjdk is immobile right now
<persia> which arch?
<MattJ> I think it's been like that a bit longer than 150 minutes :/
<bcurtiswx> persia: i386
<bcurtiswx> persia: https://edge.launchpad.net/ubuntu/+source/openjdk-6/6b18-1.8-0ubuntu1/+build/1691250
<persia> bcurtiswx: How long do you think it's been sitting at "Error: com/sun/jdi/BacktraceFieldTest.java"?
<bcurtiswx> Persia: honestly, no idea, saw the backlog of i386 packages waiting to build, thought maybe there was one package holding a few back.. looked at openjdk and saw it was stuck
<kirkland> slangasek: i did get an error with mountall
<kirkland> slangasek: is this logged to a file somewhere I can pastebin or attach to that bug?
<bcurtiswx> persia: plus it was started 14 hours ago
<persia> bcurtiswx: That's never a safe indication: the prior upload took 15 hours, 37 minutes, 55.9 seconds to build on i386.
<bcurtiswx> persia: nice.. good to know
<persia> See https://launchpad.net/~ubuntu-security/+archive/ppa/+build/1625847
<kirkland> slangasek: nevermind; i'm running again, tee'ing output
<MattJ> Oh yay, the PPA build queue seems to be moving, thanks for that whoever :)
<bcurtiswx> persia: hey, it moved!
<bcurtiswx> persia: thanks for your help :)
<persia> bcurtiswx: Happy to share how things work to avoid confusion :)
<kirkland> slangasek: http://paste.ubuntu.com/414635/
<kirkland> slangasek: let me know if there are more detailed logs somewhere else
<slangasek> kirkland: no more verbose logs unless you pass apt some debugging options; can you follow up with mvo on this?
<ryanakca> Hmmm... can anybody confirm having difficulty unlocking a disk at boot with plymouth?
<ryanakca> At first I thought it was my imagination, but it is happening often enough for me to think there's an issue. I can usually unlock a disk on the first try if I boot in rescue mode (and enter my passphrase without it going through a plymouth theme). But if I boot normally, it takes me 6-7 tries.
<ryanakca> This happens even if I type in each character, one by one. I don't think it's a keyboard issue because I can type perfectly once the netbook starts up
<ryanakca> One thing that I've noticed is that sometimes when I enter a character, it doesn't show up in the passphrase box.
<slangasek> ryanakca: there's a bug open on plymouth about this, but I can't reproduce it here
<ryanakca> slangasek: Has the bug been confirmed? If not and you have the bug number handy, I can confirm and add whatever lacking information there may be...
<slangasek> ryanakca: sorry, don't have time to look for it right now; it should stand out in the list though, it has a pretty clear title
* slangasek changed the topic of #ubuntu-devel to: Lucid Beta 2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ajmitch> everything's icy now?
<spm> ice ice baby
 * TheMuso shivers.
<JontheEchidna> whew, uploaded with only seconds to spare
 * TheMuso notes that powerpc is not taking jobs.
<ScottK> TheMuso: IA64 and Sparc neither.  It's been reported.
<TheMuso> ScottK: ok thanks.
 * ccheney notes reading through 1,132 tax forms is not fun
<pitti> micahg: I'm open to improving the strings in maverick; would you mind opening a bug about it?
<pitti> Good morning
<micahg> pitti: good morning, can I resurrect the one that was marked invalid or file new?
<pitti> micahg: resurrecting sounds fine
<micahg> pitti: k, on another note, is Monday too late to drop xul191?
<pitti> micahg: no, we should really get rid of it IMHO
<micahg> pitti: actually, I'll talk to asac, the last thing that uses it AFAICT is gjs and that uses an older version that is in archive so maybe tomorrow :)
<micahg> pitti: could I trouble you for an FFe to fix the vlc FTBFS against xulrunner-1.9.2 (bug 558981)
<ubottu> Launchpad bug 558981 in vlc "vlc fails to build against xulrunner-1.9.2" [High,Confirmed] https://launchpad.net/bugs/558981
<pitti> micahg: this isn't an FFE, just a bug fix, so please go ahead
<micahg> pitti: even though there are 7 patches added?
<pitti> micahg: they don't add new features, change strings, etc.
<micahg> pitti: no, ok, thanks
<micahg> pitti: actually, OJI is disabled in xul192, so that's a small change
<robert_ancell> asac, how do you use libntrack?
<dholbach> good morning
<imbrandon> moins dholbach
<dholbach> hi imbrandon
<MattJ> Mornings
<baptistemm> good morning
<MattJ> I have a package for a new upstream bugfix version of a package in Lucid
<MattJ> The new upstream isn't in Debian (yet)
<MattJ> But it fixes some important issues, so should I file a bug and attach my .diff.gz?
<MattJ> or would it be fine to wait for Debian and request a sync? (not sure what's best, regarding the freeze)
<micahg> MattJ: what package?
<MattJ> prosody
<micahg> MattJ: I think you have this next week to get a sync from debian for that
<micahg> MattJ: if it's bug fix only
<MattJ> Ok, thanks, I'll give a shove in that direction :)
<MattJ> It is bugfix only, including one that allows a DoS against connected clients from remote ones
<robert_ancell> pitti, I'm trying to use the libntrack package but I get linking errors, when I rebuild the deb locally it works fine.  Does it make sense the archive should recompile it?  If so, what is the best way to do that (just bump the version number?)
<pitti> robert_ancell: if it demonstrably helps, a 006-1build1 is fine; but it would be good to find out what broke in particular (ABI change in dependent library?)
<robert_ancell> pitti, it seems like an internal symbol, and I can't work out why that would be
<pitti> robert_ancell: well, at this point, if a rebuild helps just upload it
<_minerva> hi
<robert_ancell> pitti, can you give ntrack a kick, it's waiting for approval (are we in final freeze now?)
<pitti> oh, we are?
<pitti> sure
<mdz> is anyone else finding that their desktop runs out of memory when left idle overnight
<mvo> pitti: could you please have a look at the u-m upload? just a trivial frbfs fix
<ogra> hrm, so fsck does not respect the e2fsck.conf file ...
<pitti> mvo: sure, approved, thanks
 * ogra wonders why we have fsck *and* e2fsck ... 
<RAOF> mdz: Evolution seems to be consuming an unreasonable and increasing amount of memory here; maybe that's a part of it?
<mdz> RAOF: yes, that's consistent with my symptoms as well
<mdz> usually evolution-data-server and chromium fight over who gets OOMed
<mdz> once swap is exhausted
 * ogra sighs ... so there is no way to boot a system that has no RTC battery unless i edit both fstabs 
<mvo> thanks pitti
<ogra> thats really bad
 * ogra waits for Keybuk
<mdz> it's not happening every day, but it's happening most days
<superm1> pitti, could you have a glance at the casper upload too?  would ideally like to get today's dailies unbroken for early commands if possible
<pitti> superm1: done
 * pitti also accepts command-not-found
<superm1> thanks, most appreciate
<superm1> d
 * ogra files bug 563618 in the hope we can somehow get that fixed for release
<ubottu> Launchpad bug 563618 in util-linux "there is no way to tell fsck to ignore broken clocks on embedded systems" [High,New] https://launchpad.net/bugs/563618
<mdz> I'm seeing an issue on mbark's laptop where plymouth is flickering rapidly during fsck, and never makes progress
<mdz> it doesn't seem like bug 554737
<ubottu> Launchpad bug 554737 in plymouth "ply_boot_client_flush() does not read replies (plymouth stuck during/after filesystem check or error)" [High,Fix released] https://launchpad.net/bugs/554737
<ogra> mdz, is his clock wrong ?
<mdz> ogra, I doubt it, but I didn't check
<mdz> it's flickering between two different messages, one of which shows fsck progress and "F to fix, I to ignore, M for manual" or similar
<ogra> mountall doesnt seem to respect fsck returning nonzero in severeal cases
<ogra> i have such an issue on the beagle which renders it unbootable (no rtc battery so the clock is always reset)
<mdz> ah, sounds like bug 538433
<ubottu> Launchpad bug 538433 in mountall "[Lucid] fsck flips rapidly between two messages" [Low,Fix released] https://launchpad.net/bugs/538433
<al-maisan> Hello, where would I get plymouth 0.8.2-1 from? On my "fully patched" lucid box I currently have plymouth Version: 0.8.1-4ubuntu1
<james_w> do we still use xsplash at all?
<dholbach> james_w: it's in universe fwiw
<james_w> al-maisan: it hasn't built yet
<al-maisan> james_w: ah, I see, thanks!
<mdz> also bug 501801
<ubottu> Launchpad bug 501801 in mountall "Infinite-loops in fsck when booting with damaged /" [Undecided,Incomplete] https://launchpad.net/bugs/501801
<ogra> mdz, Bug 563618 too
<ubottu> Launchpad bug 563618 in util-linux "there is no way to tell fsck to ignore broken clocks on embedded systems" [High,Confirmed] https://launchpad.net/bugs/563618
<ogra> (i think i pointed to at least one of the above in the report)
<mdz> ogra, are you saying you think the root cause is the same?
<mdz> 563618 doesn't say what symptoms you actually see when this goes wrong
<ogra> mdz, yes, we dont seem to get to a maintenance shell in either case
<Laney> Could https://launchpad.net/ubuntu/+source/highlighting-kate/0.2.6.2-1/+build/1689855 be rescored, please?
<ogra> mdz, "that behavior together with a mountall bug which does not give the user a maintenance shell when fsck exits but makes it go into an endless loop renders many ARM platforms we support unbootable"
<slangasek> al-maisan: ah, looks like it hasn't built yet, sorry - too many other last-minute uploads in the queue, I suppose
<al-maisan> slangasek: no problem -- I will test when it becomes available.
<asac> robert_ancell: re: libntrack: in the source there are examples in common/tests glib/tests gobject/tests etc.
<asac> robert_ancell: i have patches for empathy and weather applet in my ppa
<robert_ancell> asac, thanks got it to work.  The problem was the lucid version fails to link. if I rebuild it it works.  Could you check if that's the case for you?
<robert_ancell> I've bumped the version number so it rebuilds but I don't know why it had the problem
<asac> robert_ancell: you mean the package doesnt build?
<robert_ancell> asac, I mean if you compile a hello world -lntrack it fails to find some internal symbols
<asac> robert_ancell: with an empty test.c it doesnt happen here
<asac> robert_ancell: can you paste what you got ;)?
<robert_ancell> asac, it's in an email I sent you
<asac> ah
<robert_ancell> /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libntrack.so: undefined reference to `_ntrack_arch_new'
<robert_ancell> /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libntrack.so: undefined reference to `_ntrack_arch_get_rfds'
<robert_ancell> /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libntrack.so: undefined reference to `_ntrack_arch_process_data'
<asac> interesting
<asac> will check it out after getting coffe
<robert_ancell> asac, thanks
<robert_ancell> asac, off now, good luck!
<Riddell> ev: did you manage to recreate the kubuntu oem issue?
<ev> Riddell: indeed, working on it as we speak
<nosse1> is there a link to the armel build queue somewhere?
<nosse1> oh, sorry. wrong channel
<jpds> nosse1: https://launchpad.net/ubuntu/lucid/+builds?build_text=&build_state=building&arch_tag=armel
<slangasek> dpm: ping
<dpm> hey slangasek
<slangasek> dpm: hiya - so, I've just pushed through the queue the last change to fix bug #553954, which is good news and bad news
<ubottu> Launchpad bug 553954 in plymouth "[Lucid Beta 1] plymouth has a non translatable string coming up on screen" [Medium,Fix released] https://launchpad.net/bugs/553954
<dpm> first the bad news
<slangasek> dpm: good news because it means the fsck interaction is translatable, bad news because it means there's another string for everyone to translate
<dpm> slangasek, ah, untranslatable strings becoming translatable are never bad news :)
<slangasek> dpm: can you rouse the translation teams to see if we can get that translated a few places before the langpack deadline next week? :)
<slangasek> dpm: I also accepted a change from cjwatson to fix a typo in another mountall string, so translations will need to be un-fuzzied in LP however that's done...
<dpm> slangasek, sure, thanks for the heads up. Do you know if the now translatable string appears in different templates, or is it just mountall?
<slangasek> dpm: just in mountall
<dpm> ok, cool
<slangasek> hmm, I was going to see what translations are currently out there for the unfuzzied string, but I fail at navigating rosetta
<dpm> slangasek, let me see...
<slangasek> LP doesn't know about mountall as an upstream project, only as an Ubuntu package...
<LaserJock> anybody seen any "hard drive suddenly becomes read-only and I can't reboot" sort of bugs in the last day or so?
<slangasek> aha, https://translations.launchpad.net/ubuntu/lucid/+source/mountall
<dpm> slangasek, that's the one
<slangasek> so, 16 existing translations
<slangasek> oh
<dpm> slangasek, actually, there are more, there was another bug in mountall
<dpm> and the imports queue has been quite slow lately
<slangasek> in fact, since the .pot file in the package was out of date, maybe nobody has translated the pre-fuzzy string, either
<dpm> slangasek, that could well be. I had to manually upload an updated template a couple of days ago exactly because of that, but it hasn't been imported yet
<dpm> https://translations.edge.launchpad.net/ubuntu/lucid/+source/mountall/+imports
<slangasek> dpm: ok - so we should have an up-to-date pot now once it gets processed, and I don't have to feel bad about fuzzying anyone's translations
<LaserJock> I guess I'll take that as a "no" :(
<slangasek> LaserJock: I have not
<LaserJock> hmm, not good, not good at all
<LaserJock> well, good for Ubuntu, not good for me
<dpm> slangasek, yeah, if the typo fix was on a string not having yet been exposed in LP for translation, we should be good to go, no ugly unfuzzying :). And just for reference, actually the fix for the outdated POT file was on the same upload (bug 559997)
<ubottu> Launchpad bug 559997 in mountall "Mountall needs to generate pot file on build" [Medium,Fix released] https://launchpad.net/bugs/559997
<slangasek> yep
<james_w> zul: is your mysql-cluster upload going to fix this too? http://people.canonical.com/~ubuntu-archive/NBS/mysql-cluster-common
<zul> james_w: it should
<james_w> good
<james_w> doko_: will a rebuild of visualvm move it off libnb-platform10-java?
<doko_> james_w: no, it needs a the new minor upstream version, but part of the sources are not yet released, and I did fail to pick them up out of the netbeans repo. may become a sru
<james_w> ok
<james_w> it's NBS, so what's the best way to proceed?
<james_w> you're keeping an eye on it?
<doko_> yes
<james_w> ghreat
<debfx> could someone from the release team please have a look at bug #563771
<ubottu> Launchpad bug 563771 in ttf-indic-fonts "package ttf-indic-fonts-core 1:0.5.4ubuntu2 failed to install/upgrade: subprocess new pre-installation script returned error exit status 127" [Undecided,Confirmed] https://launchpad.net/bugs/563771
<dholbach> pitti: HAPPY BELATED BIRTHDAY! :)
<pitti> dholbach: *hug*, thank you!
 * dholbach hugs pitti
 * dholbach hugs pitti
 * dholbach hugs pitti
<mdz> pitti!
<mdz> when was it?
<slangasek> debfx: looking, though there's nothing there that looks like it needs the release team?
<dholbach> mdz: yesterday
<slangasek> (just someone with upload rights?)
<didrocks> oh late birthday greetings pitti (hadn't match this with your evening) :)
<primes2h> pitti: Oh... happy belated birthday from me too :-)
<slangasek> pitti: happy birthday :)
<mvo> happy birthday pitti!
<ev> happy birthday pitti!
<pitti> wohoo!
<pitti> thanks a lot, guys
<pitti> it was yesterday, the big three-o
 * pitti blogged some thoughts on http://www.piware.de/, but sorry, German
<pitti> at least it has a nice photo of the cake :)
<debfx> slangasek: I thought uploads need release team ack in final freeze
<dholbach> pitti: Jungspund!
<slangasek> debfx: they need an ack, but they don't need approval prior to upload
<pitti> dholbach: pah
<debfx> slangasek: ok sorry, I misunderstood the process
<sebner> pitti: congratulations from me too! :) I didn't know that you are still _that_ young. Looking forward to your next list in 2020 :)
<pitti> sebner: thanks
<Daviey> slangasek: bug 563785, i think is a dupe of bug 423667 - which i thought had been fixed.
<ubottu> Launchpad bug 563785 in fortunes-ubuntu-server "[MIR] fortunes-ubuntu-server" [High,Incomplete] https://launchpad.net/bugs/563785
<ubottu> Launchpad bug 423667 in ubuntu-server-tips "[MIR] fortunes-ubuntu-server" [Medium,Fix committed] https://launchpad.net/bugs/423667
<Daviey> (it hasn't been included in main, but is that just waiting on an AA?)
<slangasek> debfx: 563771 - fix uploaded, thanks!
<slangasek> Daviey: ah, that bug has no task on the package, making it entirely search-proof
<slangasek> Daviey: thanks, will close this out
<Daviey> ahh.. good point.. TBH, i prepaired an upload of this yesterday, thinking it was main :S
<jdstrand> slangasek: hi!
<jdstrand> slangasek: I have a profile change to fix bug #517714 which I, *ahem*, reintroduced just before freeze. ok to upload?
<ubottu> Launchpad bug 517714 in libvirt "[Lucid] Error starting domain: could not remove profile" [Critical,Triaged] https://launchpad.net/bugs/517714
<apw> jdstrand, not sure if steve is still awake, might ask on #u-release
<jdstrand> apw: thanks
<genii> Getting version mismatches between initramfs-tools and initramfs-tools-bin ..paste here: http://pastebin.com/p17rMcLi ... needs ver 73 of initramfs-tools-bin or ver 72 of initramfs-tools
<persia> genii: You're clearly not running i386: arch skew: wait a bit :)
<genii> Will do :)
<persia> genii: When https://launchpad.net/ubuntu/+source/initramfs-tools/0.92bubuntu73 shows your arch to have been built, you should be able to upgrade within about an hour or so.
<cjwatson> I'd score that amd64 build up, but it's going to start in 25 minutes anyway so not much point
<cjwatson> Riddell: I probably ought to change gfxboot's background colour to match the new Kubuntu background image, yes?
<amitk> ogra: so do you know why I don't see initramfs output on the serial console? Or rather - why only on tty0?
<cjwatson> Riddell: do you want the foreground colour changed too, and if so to what?  While *I* can read light-blueish on slightly-darker-blueish, those with impaired colour vision may have rather more difficulty
<starshiptrooper> pitti: do you happen to have time to look at bug 560659
<ubottu> Launchpad bug 560659 in kpackagekit "kpk shouldn't check for distro upgrades in karmic" [Medium,In progress] https://launchpad.net/bugs/560659
<pitti> starshiptrooper: I don't know about kpackagekit, I'm afraid
<cjwatson> Riddell: http://people.canonical.com/~cjwatson/tmp/kubuntu-boot-screen.png
<starshiptrooper> pitti: needs SRU :)
<pitti> ah, ok
 * starshiptrooper is wondering whether he uploaded that though
<apachelogger> ^^
<pitti> apachelogger: looks fine, please go ahead and upload
<apachelogger> pitti: Successfully uploaded packages.
<pitti> apachelogger: is there any chance to prevent that from a different place as well? I'm not sure how many people install those updates in a timely manner
<pitti> ok, I'll do an SRU round later on then
<apachelogger> pitti: unfortunately not
 * apachelogger actually complained about that in december but didnt file a report and forgot to fix it :/
<genii> Also on the dist-upgrade just before that it got stuck trying to install ttf-indic-fonts or ttf-indic-fonts-core (no conffile to remove, error in line 19 of preinst, etc) since I don't think I was using any Indian fonts anyhow, removed it so things could progress
<Pici> genii: Someone in u+1 reported that earlier.  I don't know if they filed a bug though.
<dholbach> .
<jdstrand> slangasek: nm (taken care of)
<ogra> amitk, because the first console option is kernel only .... if you only have one console= setting it will show output on serial
<ccheney> NCommander: seems to be working so far, still building after 17hr on arm
<mathiaz> slangasek: hi - is the concept of runlevel still correct in the upstart world? see bug 561779
<ubottu> Launchpad bug 561779 in squid "squid is not started on runlevel transition 1 -> 2" [Low,New] https://launchpad.net/bugs/561779
<james_w> I'm starting a packaging training session on using bzr for Ubuntu development now in #ubuntu-classroom
<psusi> son of a... according to this blktrace  the kernel merges readahead with the original request, thus delaying the completion of the original request, and leaving the disk idle until user mode issues the next request
<doko_> smoser: 562787, is this something to be fixed for lucid?
<ScottK> genii: The ttf-indic-fonts bug is fixed.  You should have an updated package shortly.
<genii> ScottK: Thanks :)
<genii> I see the 64bit initramfs is also built now, will update shortly
<bdrung> debfx: bug #563933
<ubottu> Launchpad bug 563933 in ttf-indic-fonts "package ttf-indic-fonts-core 1:0.5.4ubuntu2 failed to install/upgrade: subprocess new pre-installation script returned error exit status 127" [High,Triaged] https://launchpad.net/bugs/563933
<genii> Looks like it hasn't propogated yet, I'll try again later (initramfs-tools-bin). The ttf-indic-fonts reinstalled fine though.
<persia> genii: You need to wait for the publisher run to complete, which takes unfortunately long.  Try again at the top of the hour.
<debfx> bdrung: that's one of the many duplicates of bug #563771
<ubottu> Launchpad bug 563771 in ttf-indic-fonts "package ttf-indic-fonts-core 1:0.5.4ubuntu2 failed to install/upgrade: subprocess new pre-installation script returned error exit status 127" [High,Fix released] https://launchpad.net/bugs/563771
<ScottK> bdrung: It was the old version still trying to unpack
<bdrung> marked as dup
<bdrung> i should have searched the fixed bugs
<genii> persia: OK, thanks
<Sarvatt> kees:  about the -dbg/-dbgsym problems with xorg-server and mesa - https://bugs.edge.launchpad.net/ubuntu/+source/pkg-create-dbgsym/+bug/562418
<ubottu> Launchpad bug 562418 in xorg-server "xserver-xorg-core-dbg debug symbols mismatch" [Undecided,Incomplete]
 * ogra sighs about the armel buildfarm ... 5 active builders and all are busy with the 5 biggest packages we have
<ogra> we'll never clear the queue
<amitk> ogra: send them off to mdeb.org
<amitk> they've got 35
<ogra> yeah
<ogra> and probably icecc or distcc to trunk several of them together on demand
<ogra> our queue needs to get more intelligent ... allowing oo.o, firefox, TB, mesa and openjdk at the same time should simply not be possible on armel
<ScottK> ogra: There's a gcc-snapshot in queue too.
<ogra> oh, fun
<MarkieMark1> hi, is it #ubuntu-app-devel for indicator-applet-session / indicator-applet?
<pitti> starshiptrooper: I reject the older one of your two kpackagekit uploads, so don't get scared of the rejection message
<davmor2> Guys empathy is only using the simple account manager now which means you can't setup an irc account is this known?
<davmor2> seb128, pitti ^
<pitti> davmor2: hm, seems to work here?
<seb128> you can't during initial config
<seb128> you can after
<seb128> there is a bug about it yes
<seb128> it's an upstream decision
<starshiptrooper> pitti: right, thanks :)
<dholbach> asac: did you get any reports about thunderbird not starting anymore?
<davmor2> pitti, seb128: I'm only getting the simple account manger here all the time
<seb128> ?
<seb128> oh you mean you don't want to configure any non IRC account
<seb128> not even a local avahi one
<seb128> it works after having configured one account
<davmor2> I did the avahi one and then closed empathy
<seb128> empathy is an IM client not an IRC client
<seb128> the main aim is not to do IRC
<seb128> well in the account dialog you should be able to add any account now
<davmor2> I ten open empathy and hit F4 and get the simple account setup still
<seb128> ok, so you need to configure a real account
<davmor2> yes so I just added my FB account and now I can gain access to the proper account manager
<kees> slangasek: I believe lvm2 for bug 358654 is a false-positive, as it depends on dmsetup, which depends on initramfs-tools.  am i misunderstanding some element of dark magic that requires I have a depends on initramfs-tools for lvm2 also?
<ubottu> Launchpad bug 358654 in watershed "udevadm trigger is not permitted while udev is unconfigured" [Medium,Fix released] https://launchpad.net/bugs/358654
<pitti> jdstrand: was the "CVE-2010-XXXX" in the sudo changelog deliberate?
<jdstrand> pitti: yes
<jdstrand> pitti: to be filled in later (it is not assigned yet)
<davmor2> seb128: thanks I'll file a bug against it
<seb128> davmor2, there is a bug aobut it already as said before
<davmor2> oh sorry miss read
<pitti> ogra: uboot-envtools> is that actually used/useful on non-arm arches?
<kirkland> mvo: slangasek: hi, i'm at a point where i can do-release-upgrade -d from a karmic vm to lucid, to reproduce that problem;  how do i introduce more debugging?
<ogra> pitti, not at all unless someone implements uboot as bootloader on !arm
<pitti> ogra: I just wondered because it's arch:any
<ogra> well, i dont know if there is any HW way to use NAND on a different arch or some such i couldnt imagine one though
<ogra> but it might be possible to create binary images that you can dd to NAND
<ogra> so in that case you would want to use it on x86
<ogra> generally thats just a corner case though
<micahg> I've got a problem with a package that did something it shouldn't, but non-desctructive, and I want to display a message on upgrade to this new version what the fix is, is PKG.listchanges the way to do that?
<pitti> ogra: ok, done
 * ogra hugs pitti 
<pitti> ogra: please seed/depend on
 * pitti hugs back ogra, np
<ogra> pitti, you just made omap work ! :)
<mvo> kirkland: hello, what problem? 559582 ?
<ogra> that was the last missing piece in the puzzle
<pitti> ogra: no I won't come to the mobile team :) OEM got me first
<ogra> haha
<ogra> pitti, OEM ?
<ogra> you move ?
<pitti> ogra: rotation, starts in about two weeks
<ogra> ah
<pitti> for once, I'll earn my wages :)
<ogra> heh
<ogra> you already do by giving them a foundation :)
 * ogra wonders off for some early dinner
<micahg> what's the proper way to display a message on how to fix something on install
<kirkland> bug 559582
<ubottu> Launchpad bug 559582 in mountall "Upgrade from karmic to lucid failes with Internal Error, Could not perform immediate configuration (2) on mountall" [Undecided,Confirmed] https://launchpad.net/bugs/559582
<kirkland> mvo: yeah, that one
<micahg> zul: can you help me, how did you get the notice to show in the apache package on install?
<zul> micahg: what?
<micahg> zul: about the changes that affect the user
<mvo> kirkland: do you can reproduce it already? does it fail like this?
<zul> micahg: i dont know what you are talking about
<micahg> zul: I have a package where I need to display a message to the user on install, I noticed apache2 did this recently
<zul> micahg: you probably want to do it in the postinst
<kirkland> mvo: i'm bzipping a kvm disk image
<kirkland> mvo: it's an up-to-date default 9.10 server install
<mvo> kirkland: thanks, /var/lib/dpkg/status + etc/apt/sources.list should be enough I think
<kirkland> mvo: you and fire it up in kvm, and see for yourself
<mvo> kirkland: cool
<kirkland> mvo: i'll pastebin those two in the mean time
<mvo> kirkland: thanks, it is/was on my list for today, but a initramfs-toolls / initramfs-tools-bin mismatch prevented further debugging today
<smoser> doko_, the only way to fix that upgrade path would be to have glibc remove that file if it existed.
<kirkland> mvo: http://paste.ubuntu.com/415052
<mvo> smoser: hi, did you had a chance to re-run the upgrade with --sandbox?
<kirkland> mvo: http://paste.ubuntu.com/415053
<smoser> doku_, its a very unlikely path to be cared about.  the reason for that is that a.) we've only published "instance-store" instances of hardy and b.) instance store instances cannot change the kernel . thus there is no way to reboot after you did an upgrade (unless we wanted to support hardy kernel lucid user space, which i dont think is desired)
<mvo> thanks kirkland
<smoser> mvo, i haven't. i can easily test that though if you want me to
<mvo> smoser: not urgent, but the fix for this is in the archive now
<mvo> smoser: not sure how well aufs is doing these days with that particular workload, but I would be interessted
<smoser> yeah, i had seen that.
<mvo> but be careful, don't try it on a producation server just yet
<smoser> mvo, yeah, andin this case its not "these days" that you'd be interested in, but "hardy days"
<mvo> heh :) indeed
<mvo> kirkland: hrm, I just tried to reproduce with the state file in the bugreport, no luck
<mvo> kirkland: I wait for your vm image I think
<hacksaw> I'm looking for a pointer to docs on the best way to create a deb which contains additions to /etc/apt/sources.list.d
<kirkland> mvo: uploading now... i'm heading to lunch.  should be here in ~25 minutes:  http://people.canonical.com/~kirkland/karmic-server.img.orig.bz2
<kirkland> mvo: ubuntu/ubuntu is user/pass;  bunzip it  and then you can just run:  testdrive-kvm karmic-server.img.orig
<kirkland> mvo: or kvm with your own parameters
<doko_> smoser: unconditionally?
<smoser> doko_, ?
<smoser> the only case where upgrade from a "Official Ubuntu Image" of is possible is really just a test case.
<doko_> smoser: well, attach a patch, what you think needs to be done
<mpt> persia, do you use IBus?
<persia> mpt: Yes.
<persia> mpt: ibus-anthy to be specific.
<smoser> doko_, ok. i'll see if i can come up with something.  its really edge case that it would matter. and definitely would not affect anyone running one of our published images.
<mpt> persia, I'm wondering how much of a problem it is that in Lucid it doesn't show the icon of the current input method in the panel
<persia> mpt: For me, none at all, because I never switch (ibus-anthy allows entry of ã­ã¼ãå­ without switching).  For folks in places that don't do that, it makes it impossible to know what one will type.
<mvo> kirkland: thanks!
<mpt> persia, that's what I feared
<snow_ru> haha
<persia> mpt: I believe it should be painful for anyone who isn't using a Japanese or Korean keyboard, since I believe these are the only sorts that have dedicated keys to control the IME (which are used by the various ibus backends), to give you an idea of scope.
<mpt> jcastro, ^^^
<asac> dholbach: hop into -mozillateam ... i am not really on top of all the recent regressions
<asac> dholbach: one reason might be that you have some extension that has .xpt files
<asac> but i think we cherry-picked that patch to tbird too
<dholbach> asac: thanks discussed it there
<asac> but check with micahg and chrisccoulson ... actually both are here ;)
<asac> ah
<asac> ok
<tjaalton> slangasek: rpc.gssd no longer accepts options from /etc/default/nfs-common...
<jcastro> persia: ok, what did the icon do in 9.10? (for ibus)
<seb128> bug #563893
<ubottu> Launchpad bug 563893 in thunderbird "Thunderbird will not launch do to a recursive symlink" [High,Triaged] https://launchpad.net/bugs/563893
<persia> jcastro: I don't remember.  Sadly, I'm not an affected user (because my keyboard has the extra key, and my ibus backend supports it)
<seb128> ^ for information
<seb128> binaries will be blocked from download due to this bug
<seb128> could people let that know to users in due forums, irc channels, etc?
<jcastro> mpt: ok we need to figure out what it's supposed to do.
<jcastro> mpt: also the engineering resources that did the work are not around anymore, so we're going to need to figure out a course of action quickly
<mpt> jcastro, I'm not a packaging expert, but I expect it's just removing 05_appindicator.dpatch
<jcastro> mpt: oh so you're saying just revert the whole thing?
<persia> mpt: In which package is the patch?  I can test that.
<tjaalton> slangasek: and with active directory I need to feed at least '-n'
<seb128> jcastro, persia: what should be displayed in the indicator and what is displayed now?
<mpt> persia, ibus, afaict
<persia> seb128: I think the icon for the backend should be displayed, so folks know what they wlill type.  RIght now, there's just an unchanging keyboard icon.
<jcastro> now it just displays a keyboard
<persia> mpt: I'll test that quickly then.
<seb128> it's an icon right? because indicators don't do labels for now
<mpt> thanks persia
<jcastro> mpt: I could have sworn at some point we decided to show a 3 letter country code or something?
<seb128> jcastro, indicators don't do labels...
<seb128> jcastro, that's why we reverted the keyboard indicator one
<persia> jcastro: That wouldn't be a good choice, because some countries have multiple sane input methods.
<jcastro> ok so basically we don't really have a choice, we have to revert it.
<mpt> seb128, jcastro, persia: I've reported bug 564034 with all I know
<ubottu> Launchpad bug 564034 in ibus "Panel no longer shows which input method is being used" [Undecided,New] https://launchpad.net/bugs/564034
<jcastro> we neither have the person to fix it and we're out of time for the cycle
<smoser> mvo, so, i just tested --sandbox
<seb128> jcastro, mpt: I would recommend just dropping the indicator port if we can't fix it
 * persia is testing that now
<jcastro> right
<smoser> i got to the first prompt, it said do you want to continue.  I thought "i should run this in screen" so I hit 'N'.  then reran it.  it says failed to setup aufs.
<jcastro> and even if we did fix it we wouldn't have time to test. ibus has had the old tray support for years so this seems the least risky option.
<doko_> seb128: any idea about #528892 ? just removed the wrong directory by pasting ... I know we had this kind of bug before, but it was fixed for karmic
<seb128> bug #528892
<ubottu> Launchpad bug 528892 in vte "[regression] double-click to copy and middle-click to paste pastes the previous selection" [Undecided,New] https://launchpad.net/bugs/528892
<mpt> seb128, I was just in a meeting where we were discussing the menus in general, and tedg mentioned that custom bitmap icons currently aren't possible at all. So yeah, I don't think it's easily fixable except by reverting. :-/
<seb128> doko_, no sorry, first time I read about it and mvo does vte usually
<seb128> mpt, I set a lucid task and assign the our team now
<mpt> Thank you seb128
<jcastro> thanks seb
<seb128> it's weird that nobody reported the issue in months though
<jcastro>  yeah that's worrying to me
<seb128> how come we have so few testing in that area?
<doko_> mvo: ^^^
<seb128> I'm reluctant to set the bug to high based on statement from one person there
<seb128> persia, do you know if that has been discussed by some user communities in launchpad or forums or lists?
<mpt> jcastro, seb128: One possibility is that most of the people affected don't know English. Another is that it doesn't actually affect that many people, because most people are using a single input method that covers all the characters they need to use.
<seb128> jcastro, bug #563893 on an another topic
<ubottu> Launchpad bug 563893 in thunderbird "Thunderbird will not launch do to a recursive symlink" [High,Triaged] https://launchpad.net/bugs/563893
<seb128> jcastro, we had to block binaries of this version in lucid, can you make the word being said around so users know about what is going on?
<jcastro> seb128: I'll update the platform twitter feed
<seb128> jcastro, thanks
<seb128> jcastro, can you let me when it's done?
<persia> seb128: mpt's highlight was the first I've heard of it.  I'm not affected, for complex reasons.
<jcastro> seb128: yep, one sec
<seb128> persia, are you in touch with communities or people who are affected by the issue or did you read anything about it?
<persia> mpt: We may also have a low number of lucid testers from affected locales.
<mpt> yes
<persia> seb128: No, sorry.  The ibus-using communities with which I'm in contact are also users of keyboards with dedicated switch buttons.
 * ScottK loves it when filing the bugs afterwards takes longer than doing the actual New review.
<mpt> jcastro, seb128: Also, the change has been in for only a month.
<seb128> mpt, still we should get feedback about such issues
<persia> mpt: I removed the patch, rebuild the packages, installed the results, logged out, logged in, and see no behaviour change.
<mpt> persia, so it hasn't moved back to the notification area?
<persia> No.  It was there for a few days last week for some reason though.
<pitti> micahg, chrisccoulson: can you please ping me once the upload is done? I'll care about reviewing/accepting from the queue and jumping the buildd queue
<mpt> Well, I don't know.
<chrisccoulson> pitti - ok, will do
<mvo> kirkland: I get a 403 on the file
<kirkland> mvo: try now
<kirkland> mvo: it's perm'd 444, you might have to chmod it 644 after you get it local
<mpt> the Ubuntu China forums seem to be all "uninstall ibus, install fcitx"
<mpt> which isn't that helpful
<mvo> kirkland: thanks, downloading now
<mvo> smoser: aha, thanks. sort of known, it now created the overlay, so running it normally should have the same effect (double check with mount please)
<mvo> seb128: that is the issue with vte (sorry, missed context)?
<smoser> mvo, well, i opened 564053
<smoser> bug 564053
<ubottu> Launchpad bug 564053 in update-manager "do-release-upgrade --sandbox fails after cancelling" [Undecided,New] https://launchpad.net/bugs/564053
<smoser> which describes it.
<persia> mpt: Only to be expected.  Let's consider this a failed test, and maybe someone who knows what needs doing can fiddle the bug.
<mvo> thanks smoser
<smoser> its "fixable" with 'sudo umount /var/cache/apt/archives'
<mpt> thanks for trying persia
<mvo> doko_: hi, interesstinging. i never saw that and I use gnome-terminal and copy/paste all the time
<ogra> Keybuk, which fsck does mountall use exactly ?
<Keybuk> ogra: the big red one
<ogra> can a buildd admin bump initramfs-tools on armel please ?
<Keybuk> it usually has the keys in the ignition
<Keybuk> and mountall likes to go *fast*
<ogra> Keybuk, i mean, does it use the util-linux one or the one from e2fsprogs ?
<ogra> (fsck vs e2fsck)
<Keybuk> I think you're confused ;)
<ogra> i found the e2fsck.conf setting does nothing
<pitti> fsck is just the wrapper, which calls e2fsck, fsck.vfat, etc
<ogra> am i ?
<Keybuk> the util-linux fsck (which was stolen from e2fsprogs originally anyway) is just a wrapper
<Keybuk> it calls fsck.<type>
<Keybuk> so when you fsck an e2fs filesystem, fsck calls fsck.ext4 for example
<Keybuk> which is e2fsprogs
<ogra> hmm, the manpage is confusing then
<Keybuk> "the manpage" ?
<ogra> of fsck
<pitti> ogra: i-t bumped
<ogra> pitti, merci beaucoup
<pitti> ogra: de rien
<Keybuk> the manpage attempts to describe the common options
<Keybuk> just as the mount manpage does
<Keybuk>        In  actuality,  fsck  is simply a front-end for the various file system
<Keybuk>        checkers (fsck.fstype) available under Linux.  The file system-specific
<Keybuk>        checker  is  searched for in /sbin first, then in /etc/fs and /etc, and
<Keybuk>        finally in the directories listed in  the  PATH  environment  variable.
<Keybuk>        Please  see  the  file system-specific checker manual pages for further
<Keybuk>        details.
<Keybuk> that's the key page
<ogra> right, i didnt think fsck.ext{2,3,4} would be identical to e2fsck
<ogra> and since the config file is ignored that seemed to prove my point
<ogra> i even shoveled into the initramfs
<ogra> +it
<ogra> though i just saw rcn-ee's comment on bug 563618
<ubottu> Launchpad bug 563618 in util-linux "there is no way to tell fsck to ignore broken clocks on embedded systems" [High,Confirmed] https://launchpad.net/bugs/563618
<ogra> might be that broken_system_clock = true simply doesnt suffice here
<ogra> though rcn just mailed me and told me he still has to bear a fsck on every first boot
<ogra> but thats at least better than infinite rebooting
<psusi> ogra: huh?  what config file is ignored?  fsck.ext[234] are just hard links to e2fsck
<ogra> psusi, read the bug :)
<ogra>  /etc/e2fsck.conf
<W3ird_N3rd> cjwatson, to let you know, I just burned the 15-04 netboot ISO and it did detect the Xircom, get DHCP and am trying to install right now..
 * psusi goes back to blktraceing
<W3ird_N3rd> for..why... :'(
<W3ird_N3rd> debootstrap warning: couldn't download package locales
<Keybuk> ogra: sorry, not following
<W3ird_N3rd> something somewhere is seriously wrong, I just wonder if it's the netboot ISO or this laptop..
<Keybuk> you're saying that fsck fails even with that config option?
<ogra> Keybuk, right
<ogra> and mountall goes into an endless loop still
<Keybuk> ogra: the bug is unclear
<Keybuk> frankly, I don't believe you that this fails
<Keybuk> because Robert has pasted an e2fsck.conf that he says works
<Keybuk> that's basically identical to what I suggested
<ogra> Keybuk, you suggested broken_system_clock = true ... that definately doesnt change behavior
<Keybuk> ok, well, that's a bug
<ogra> i havent tried his option yet
<Keybuk> does the config snippet robert pasted work for you?
<Keybuk> (broken_system_clock = true is simply a shorthand for the exact config robert pasted)
<ogra> will try now, i just saw it after i pinged you
<ogra> yes, i thought that too
<ogra> though his might be a bit more detailed
<Keybuk>                 if ((code == PR_0_FUTURE_SB_LAST_MOUNT) ||
<Keybuk>                     (code == PR_0_FUTURE_SB_LAST_WRITE)) {
<Keybuk>                         profile_get_boolean(ctx->profile, "options",
<Keybuk>                                             "broken_system_clock", 0, 0,
<Keybuk>                                             &broken_system_clock);
<Keybuk>                         if (broken_system_clock)
<Keybuk>                                 ptr->flags |= PR_PREEN_OK;
<Keybuk>                 }
<ogra> hmm, the difference might be that one is in [options] while the other is in [problems]
<Keybuk> see above, that's quite correct
<ogra> where does [problems] get catched ?
<Keybuk> later down
<ogra> hmm, then options should overrule
<Keybuk> no, options sets the default
 * ogra reboots his beagle
<ogra> awesome !
<ogra> so there is a discrepancy between [problems] and [options] i think
 * ogra tries with powering off the board 
<Keybuk> well, problems is detailed, complex, overrides
<Keybuk> options is short-hand
<Keybuk> but the code above seems to suggest that the options should get processed
<pitti> chrisccoulson: I see the tbird upload, reviewing now
<Keybuk> I wonder whether this bug is that it sets PR_PREEN_OK
<pitti> it would help if my keyboard would work
<Keybuk> but then unsets it when parsing the non-existing problems
<pitti> it stopped after current dist-upgrade
<ogra> hmm, might be
<Keybuk> ogra: don't suppose you can gdb e2fsck? :p
<ogra> hard to do if it fails ...
<ogra> my board is in an infinite reboot loop now :/
<ogra> powering off the board gives me the same behavior as with "broken_system_clock"
<ogra> it was just that i only rebooted which kept power on the clock
<Keybuk> hard to do?
<Keybuk> just open a root shell on another vt :p
<ogra> if the board constantly reboots ?
<ogra> i dont get to a shell
<ogra> i see the splash for a short moment and then it resets hard
<Keybuk> ogra: upstart.ubuntu.com/wiki/OMGBroken
<Keybuk> ohhhhhh
<Keybuk> I just worked this out
<Keybuk> broken_system_clock=true is clearly working
<pitti> chrisccoulson: tbird accepted and bumped build score; i386 building now
<chrisccoulson> pitti - excellent, thanks
<chrisccoulson> pitti - i'm just drafting the mail to u-d-a now
<chrisccoulson> will be done in a couple of minutes
<Keybuk> ogra: sorry, I'm just going to bang my head into a window for a while
<Keybuk> you don't get a maintenance shell, do you?
<Keybuk> your system *reboots*
<ogra> no, it reboots
<Keybuk> so it's boot ... fsck ... reboot ... fsck ... reboot ... fsck ... reboot ... fsck ?
<ogra> but formerly the same bug showed the fsck message endlessly on the screen
<ogra> right
<Keybuk> riiiight
<Keybuk> ok
<Keybuk> err
<pitti> chrisccoulson: I first need to fix my system anyway before I can get back to real productivity
<Keybuk> ogra: I can't fix this
<ogra> Keybuk, who can ? :)
<Keybuk> ogra: nobody
<Keybuk> fsck is working
<ogra> why ?
<Keybuk> it corrected a problem with your root filesystem (timestamps all wrong)
<Keybuk> and, therefore WE HAVE TO REBOOT
<Keybuk> we just raw edited a mounted filesystem
<Keybuk> we can't continue
<ogra> thats fine ...
<Keybuk> so reboot
<ogra> oh, but the clock is reset again
<Keybuk> and of course, reboot kills your hardware clock again
<Keybuk> so your timestamps are wrong
<ogra> yes
<Keybuk> so fsck has to run again
<Keybuk> and corrects the problem again
<Keybuk> and changes the root filesystem
<Keybuk> SO WE HAVE TO REBOOT
<ogra> indeed
<Keybuk> and that kills your hardware clock again
<psusi> lol
<Keybuk> the only way to "fix" this would be to run fsck from inside the initramfs
<Keybuk> before mounting the root filesystem
<ogra> what about the version where it doesnt reboot but wants to give you a maintenance shell and doesnt ?
<Keybuk> that way the raw change doesn't require a reboot
<psusi> why is fsck modifying the fs in the first place?
<Keybuk> ogra: that I haven't heard of
<Keybuk> that would be a different bug
<Keybuk> psusi: because the hardware clock is wrong
<Keybuk> all of the filesystem timestamps are wrong
<psusi> if you know you can't trust the clock then you shouldn't be updating the fs timestamps
<Keybuk> ext3/4 are JOURNALLED FILESYSTEMS
<ogra> i had that before i successfully mounted the rootfs for the first time (by editing both fstabs)
<Keybuk> the timestamp is IMPORTANT
<Keybuk> they have to go in one direction ;)
<ogra> and amitk sees it too
<ogra> as well as asac
<Keybuk> ogra: then those people need to supply mountall --debug output for me
<ogra> its the same but without rebooting
<Keybuk> journalled filesystems can't have timestamps suddenly jump backwards
<chrisccoulson> pitti - ok, mail sent to u-d-a now
<ogra> its scrolls so fast you nearly cant read it
<Keybuk> "I had a write pending at 14:00, and another at 14:05, and another at 08:00"
<Keybuk> WTF
<Keybuk> that's an inconsistent journal
<Keybuk> that's bad
<ogra> indeed
<ogra> i understand what you say
<Keybuk> so that's why we have to fix the timestamps if your hardware clock is broken
<psusi> the timestamps in the journal have to go in one direction?  sure, but once the journal is empty what difference does it make that the clock is at the epoch?
 * ogra notes that epoch != epoch :)
<ogra> the board we talk about sets the time to april 1st 2000 by default :)
<ogra> Keybuk, the thing is that it worked before we changed mountall ...
<ogra> pre-karmic or so
<Keybuk> psusi: if you want to write your own filesystem, please feel free to not include this constraint ;)
<Keybuk> ogra: the fact it worked is probably a bug ;)
<ogra> heh, might be
<pitti> chrisccoulson: moderated
<Keybuk> any change to the root fs needs to result in a reboot
<psusi> Keybuk: I'm just trying to understand what the constraint is... what does it care about timestamps when the journal is empty for?
<psusi> i.e. what is it that you are "fixing"?
<ogra> but i think it only told you to reboot and didnt do it automatically
<Keybuk> psusi: ask a filesystem engineer
<Keybuk> this is a constraint they have engineered into it
<ogra> that way you could call hwclock from the maintenance shell
<ogra> and as long as you dont power off the board the rtcd is correct
<Keybuk> ogra: yeah, but you still technically had to reboot
<ogra> right
<ogra> but less harmfull
<pitti> ok, so what part of the  dist-upgrade messed up my /etc/default/console-setup
<ogra> s/rtcd/rtc/
<psusi> here's an idea.. how about have the initramfs read the last unmount time from the fs and set the clock to that before calling fsck ;)
<Keybuk> psusi: hides potentially dangerous problems
<ogra> Keybuk, as ignoring the clock completely does
<ogra> but psusi's hack could make it work for me while ignoring the clock apparently doesnt
<ogra> though it would add slowdown to the boot
<psusi> also you can change the clock backwards while the system is running... why does that not screw up the journal?  the answer to that probably could form a basis for what to do when the clock is broken
<Keybuk> psusi: because the kernel uses a monotonic clock
<Keybuk> anyway,
<Keybuk> I'm done with this bug
<Keybuk> I've updated the notes and marked it as Triaged ;-)
<Keybuk> someone else can worry about fixing it
 * Keybuk will look into the mountall infinite loop on fsck failure bug if someone provides him --debug output
<ogra> Keybuk, i'll try to get it for you with the next install (waiting for the next image though which might take a biit until the queue clears out)
<ogra> it definately shows up on brandnew installs
<ogra> and turns into the reboot thing once you mounted successfully
<Keybuk> that's an odd one, mountall should just exit() if it gets an fsck failure
<ogra> which i can only achive by editing fstab
<ogra> (both of them)
<ogra> Keybuk, aha, i reset the system to original state (removing e2fsck.conf and resetting the fstabs) now i get bug 501801
<ubottu> Launchpad bug 501801 in mountall "Infinite-loops in fsck when booting with damaged /" [High,Triaged] https://launchpad.net/bugs/501801
 * ogra drops splash and tries again
<Keybuk> ok
<Keybuk> I have a --debug from matty barker
<Keybuk> if you could supply one too, that would be k-rad-appreciated
<ogra> right .. without splash: "last mount time is in the future, run fsck manually" infinitely
 * ogra edits init/mountall.conf 
<Keybuk> slangasek: I asked a question on bug #553290  (you're not subscribed?)
<ubottu> Launchpad bug 553290 in mountall "Loops on mount failure when Plymouth not running" [High,Triaged] https://launchpad.net/bugs/553290
<ogra> Keybuk, err, tricky indeed it doesnt write to /vat/log/boot.log if it cant mount
<Keybuk> ogra: that's ok
<Keybuk> now do the mount
<Keybuk> and then plymouth will flush it out
<Keybuk> you could even just pop a tmpfs there
<Keybuk> and call plymouth --sysinit
<ogra> hmm ?
<ogra> i edited init/mountall.conf
<ogra> which indeed gets me a lot on the screen but i cant capture it
 * ogra tires serial console 
<ogra> argh
<ogra> plymouth sucks !!!
<mvo> kirkland: that is very odd, image is here, unzips fine, shows boot grub prompt very briefly and then just a cursor
<Keybuk> ogra: why?
<ogra> Keybuk, even with console=ttyS2,115200n8 plymouth ignores me and writes to tty0 (there is no other console option in the cmdline, the kernel shouldnt know about tty0)
<ogra> [   70.382324] sd 0:0:0:0: [sda] Assuming drive cache: write through
<ogra> [   70.406768] sd 0:0:0:0: [sda] Assuming drive cache: write through
<ogra> [   70.658721] sd 0:0:0:0: [sda] Assuming drive cache: write through
<ogra> init: ureadahead main process (142) termi
<Keybuk> err
<Keybuk> tty0 is ttyS2
<ogra> thats where the serial output ends on ttyS2
<Keybuk> yes
<Keybuk> I don't follow
<ogra> the rest goes to the display
<Keybuk> plymouth will pick up console= and put a "details output" on that
<Keybuk> oh
<Keybuk> that's odd
<ogra> console=ttyS2,115200n8 root=UUID=d088bcbb-ba37-4f21-914b-886eeb6863cc ro quiet vram=12M omapfb.mode=dvi:1280x720MR-16@60
<Keybuk> that's probably a bug
<ogra> thats my bootargs
<ogra> there is an fbcon indeed
<ogra> but no console attached to it
<Keybuk> right, that should result in plymouth using ttyS2
<ogra> and the output on the screen is garbled
<Keybuk> and not displaying anything on the main display
<ogra> right
<Keybuk> sounds like a bug
<ogra> might be a kernel bug though
<Keybuk> yeah could well be a kernel bug
<ogra> i dont really trust the omap fb code
<ogra> it has issues everywhere so that wouldnt be a surprise
<ogra> hmm, how do i solve that so i can get you a proper log
<qense> If reportbug exits with the message "Please install an MTA on this system if you want to use sendmail!" does that mean it has just thrown away your bug report?
<qense> That would be quite annoying.
<mvo> kirkland: sorry, gtg for the evening, if you could check if the file is correct and send a quick mail I work on it tomorrow (my) moring
<ogra> Keybuk, is there any way to omit plymouth completely ?
<ogra> hmm, i guess i'll need to follow http://upstart.ubuntu.com/wiki/OMGBroken
 * ogra tries that
<Keybuk> no
<Keybuk> you need plymouth to get the boot log I need anyway ;)
<ogra> hmm
<ogra> so how do i get that for you
<ogra> (i'm in a sulogin console now)
<ogra> heh
 * ccheney just found out his internet connection speed supposedly doubled recently, now to reconfigure my qos so i can use the extra
<joaopinto> is there a page describing how to debug boot problems ?
<tormod> joaopinto, how far into the boot?
<joaopinto> tormod, I don't have a problem myself but I see several people asking for help with such issues and I couldn't find instructions to guide them
<joaopinto> I know a boot related problem can be related to many components, but there should be some checklist
<tormod> there are some kernel docs, hang on
<tormod> joaopinto, some stuff here: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Problems%20in%20capturing%20information
<joaopinto> hum, that one is kernel oriented
<joaopinto> I don't see any reference to boot.log there :)
<hunger_> What is up with gwibber? It does no longer start:-(
<hunger_> Looks like desktopcouch python module fails to load.
<ccheney> slangasek: i think openoffice.org-l10n is marked as NEW due to some upgrade packages
<jcastro> rickspencer3: robbiew: https://blueprints.edge.launchpad.net/sprints/uds-m
<jcastro> I think we should enforce "$track-m" for the naming convention
<jcastro> otherwise the session names get too long and look bad on the schedule
<jcastro> so like "desktop-m-monoflamewar" instead of "desktop-maverick-monoflamewar"
<robbiew> jcastro: sure
<seb128> jcastro, can't you just strip <track>-maverick on the schedule display?
<seb128> jcastro, or change those to <track>-name?
<jcastro> seb128: The scheduling system runs on hope and dreams, not going to touch it
<seb128> jcastro, oh come on
<jcastro> I'm being dead serious
<ScottK> It took a full time developer and a barrel full of hamsters running on their wheels as fast as they could to keep it going last time.
 * ccheney bbs, checking his router to see if it is bottleneck
<tormod> ScottK, you noticed you posted comment to the wrong bug? 45768
<ScottK> tormod: I did.  I also got the right one.  Thanks.
<ccheney> it appears my old linksys wrt54g is slowing down my internet connection :-\
<amalthea> hello
<micahg> ccheney: I'm assuming OO.o is supposed to be using 5MB less of space
<ccheney> micahg: hmm?
<ccheney> micahg: if it got smaller thats good i think :)
<micahg> ccheney: pdfimport, report builder bin, and core totalling about 5MB
<ccheney> micahg: one of the things i fixed in the recent upload was reduced duplication in usr/share/doc some more, i don't know how much it helped the cd but definitely would help in full install
<ccheney> er full install of OOo (including stuff not on cd)
<ccheney> micahg: the symlinking of those dirs might be what you see in the size reduction
<slangasek> mathiaz: sure, runlevels still exist; I don't think that's a case we can handle right now w/ upstart, though, since a runlevel change doesn't assure us that the network is up
<slangasek> kees: 358654> nope, if there's a transitive dep, then that's enough
<micahg> ccheney: apt double counts the file size?
 * micahg is not getting along with symlinks today
<kees> slangasek: okay, I set it invalid :)
<ccheney> micahg: no, i mean they used to be real files but got changed over to just symlinking to the uno-libs3 doc dir
<micahg> ccheney: ah, ok, cool
<slangasek> tjaalton: rpc.gssd> /etc/init/gssd.conf is a conffile which you can edit directly
<ccheney> micahg: as new packages are added i sometimes forget to add them to the symlink list so i went through and updated it for this past upload
<micahg> ccheney: awesome
<slangasek> Keybuk: bug #553290> replied
<ubottu> Launchpad bug 553290 in mountall "Loops on mount failure when Plymouth not running" [High,Triaged] https://launchpad.net/bugs/553290
<ogra> Keybuk, i'd like to schedule a session at UDS to discuss the "clock fights fsck" issue, would you participate ?
<ogra> Keybuk, given we will hit that issue a lot with ARM partners
 * ccheney kicks comcast, the problem isn't really my router its a lack of them being able to sustain a stable rate period
<Keybuk> ogra: I don't see the point of discussing it at UDS
<Keybuk> are you going to invite the ext4 or btrfs filesystem authors?
<Keybuk> if not, what's the point?
<ogra> Keybuk, well, we need to find some kind of solution for that
<Keybuk> ogra: the solution is to change the filesystem design to not need reliable timestamps
<ogra> how about attacking it at the clock side instead ?
<Keybuk> if you can persuade Ted, you can probably fix it for ext5 - but knowing Ted, he will think it's your problem
<ogra> heh
<Keybuk> the btrfs author may be more receptive and it's not stable yet
<ogra> well, i'm not sure either of them will be there
<ogra> and we will also likely use other filesystems like ubifs in the future
<ogra> and i dont even know if that issue would be an issue on such filesystems
<Keybuk> so if we don't have filesystem authors, no point discussing it
<Keybuk> this is a problem with the filesystem design
<ogra> well, depends on your POV
<ogra> i'd call it a problem with the hardware design probably ;)
<ogra> and software should be able to overcome issues in bad HW design imho
<Keybuk> yeah, but the problem is the filesystem needs timestamps
<ogra> even if its a (temporary) workaround
<Keybuk> if we change them in fsck, we have to reboot because the filesystem is MOUNTED
<Keybuk> like I said
<Keybuk> you can work around this by doing the fsck before mounting the root filesystem in the initramfs
<ogra> right, so store a timestamp somewhere to set the clock
<ogra> would be one possible workaround ...
<Keybuk> that's another option, set the clock from the last mount time of the filesystem
<ogra> right
<Keybuk> but again, never going to do that in the standard distro
<seb128> ogra: why can't you fix the hardware clock?
<Keybuk> seb128: because he's too cheap to buy a battery <g>
<ogra> seb128, because there is no battery ... as soon as you remove power the clock is zeroed
<seb128> you get what you deserve there? ;-)
<Keybuk> ogra: there will be pins to which you can attach a battery
<ogra> Keybuk, sure
<Keybuk> so do that ;)
<ogra> no :)
<ogra> i'm working with the HW as it comes from the vendor
<seb128> ogra: just set the clock on boot to what you had as a value before...
<ogra> right or even to the timestamp you read from the fs
<jdong> ccheney: I thought it was widely understood that at best those things can route at somewhere around 15 mbit/s just due to NAT overhead.
<jdong> err wow irssi scrolling fail.
<jdong> stale comment
<bluefoxicy> okay
<bluefoxicy> who the fuck am I supposed to cut
<persia> !ohmy
<ubottu> Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
 * bluefoxicy wonders what moron decided to move the control boxto the LEFT side ofthe windows
<kklimonda> seriously? now you are wondering?
<slangasek> Keybuk: did you want that mountall --debug output with or without the bustification patch applied?
<Tm_T> bluefoxicy: something else we can help you with?
<kklimonda> bluefoxicy: the change has been made on the request from design team some time ago
<bluefoxicy> kklimonda:  My close/minimize buttons are top left in lucid, never mind thunderbird eating infinite memory trying to open any e-mail message
<bluefoxicy> kklimonda:  right, didn't see that one.  Filing a bug on the control box placement thing.
<kklimonda> bluefoxicy: no point - it's not a bug, it's theme-dependant and there is already a lengthy discussion on the LP about it
<ion> I wasnât happy with the close button not being in the window corner, but that annoyance has been fixed and iâm happy with the layout now.
<ion> s/the window corner/a window corner/
<bluefoxicy> kklimonda:  really?  Because I'm not using the default theme, I'm using glossy.  And in Appearance Preferences it shows the control box in the top right...
 * bluefoxicy switches back and forth between themes a few times and the whole thing goes away, even in human.  Huh.
<Keybuk> slangasek: I want to see it fail, obviously ;-)
<slangasek> Keybuk: I'll have to think if I can even accomplish that; the only way I've been able to recover is with break=init and manually mounting the filesystems *before* mountall runs
<bluefoxicy> kklimonda:  out of curiosity, what prompted the rearrangement of the UI?  Is someone on the design team left handed?  An Apple fanboy?  Trying to be different from Windows?  Sick in the head?
<slangasek> Keybuk: I suppose I could mount / rw, tweak the upstart job to log to the rootfs, and let it go
<bluefoxicy> top-right is functionally easier for right-handed people, though top-left is for left handed people
<W3ird_N3rd> bluefoxicy, it is said canonical has plans to but different functionality top-right
<kklimonda> bluefoxicy: really, such remarks about developers are improper and this isn't really channel to discuss whys of this particular decision - I'm pretty sure that all has already been said about it on various blogs, forums and mailing lists and if you are really interested in it you can just do some research.
<W3ird_N3rd> which would lead us to guess to have already moved the controls so users get used to it being there
<W3ird_N3rd> *but=put
<W3ird_N3rd> and totally with kklimonda
<bluefoxicy> this is akin to moving the accelerator pedal to the left of the brake pedal in a car.
<W3ird_N3rd> don't worry though, I heard you can put them back where they used to be
<ion> bluefoxicy: Sound good to me.
<ion> s
<bluefoxicy> yeah, I touched the appearances box and that particular change disappeared forever.  TO the point that I can't find a way to get it back.
<bluefoxicy> I'm amused that a broken idea is implemented broken.
<W3ird_N3rd> bluefoxicy, don't go on about it, not here. Move the buttons back if you want to, discuss it on a blog, I would guess there is a thread on ubuntuforums, maybe launchpad or the idea-site (what was it called), but this is not the place
<W3ird_N3rd> it is not broken, it is not what you are used to, and if you want to change it do some research on how to change it back - you are not alone and there is no-doubt a good guide on restoring the buttonlocation
<bluefoxicy> "broken" has a different definition in UI design than in engineering.
<bluefoxicy> Anyway I have other things to worry about now
<ion> A Windows user who was visiting me used my computer for a while and *immediately* found the close button without asking. Based on this usability study with 1 sample, the layout is intuitive. ;-)
<kirkland> slangasek: Keybuk: does this look familiar?  http://pastebin.ubuntu.com/415224/
<bluefoxicy> oh, I saw it, I can hit it, but I don't have the twitch muscle memory to hit it fast enough when i.e. thunderbird is rapidly allocating memory because it's currently incapable of functioning.
<TheMuso> Anyone on the release team/release queue, please reject the ubuntustudio-meta upload as it was adjusted incorrectly.
<joaopinto> is there a formal announcement for the final freeze ?
<W3ird_N3rd> other than https://wiki.ubuntu.com/LucidReleaseSchedule ?
<slangasek> bryceh: hum, what's xorg-server-1.7.6/debian/patches/index.html?id=3083c5d0c4386cdd7083b7a83ac72
<slangasek> bryce ...fdad2f1e61e ?
<jpds> bluefoxicy: Try turning off the global indexing feature in Edit â Prefs â Advance.
<joaopinto> that's the schedule, not an announcement :)
<bluefoxicy> jpds:  you're faster than google :| or I suck at this.
<Keybuk> kirkland: that's the lucid release schedule?
<bryceh> slangasek, sorry that's cruft that should be removed
<W3ird_N3rd> bluefoxicy, train your mucles to hit alt+f4, always faster than moving your mouse :P
<kirkland> Keybuk: huh?
<bluefoxicy> jpds:  and unfortunately that doesn't help...
<bryceh> slangasek, should I re-upload with that deleted?
<ion> I wonder what creates boot.log? :-)
<slangasek> bryceh: seems to be a duplicate of debian/patches/115_xext_fix_cursor_ref_counting.patch - will it cause a build failure from the duplication?
<slangasek> bryceh: I just want to know if it's build-tested before I throw it at the buildds
<bryceh> slangasek, nope, only patches listed in series gets applied
<slangasek> bryceh: ok
<bryceh> slangasek, yes it is build tested
<TheMuso> disregard my above request
<slangasek> bryceh: great, accepted - thanks!
<kirkland> Keybuk: http://pastebin.ubuntu.com/415224/ is a boot log
<slangasek> TheMuso: disregard> so you *do* want us to accept it? :)
<bluefoxicy> jpds:  more interesting was when i first tried to start thunderbird it didn't work... the upgrade process moved ~/.thunderbird to ~/.thunderbird.upstream and made ~/.thunderbird a symlink to .thunderbird
<jpds> bluefoxicy: bug #563893.
<ubottu> Launchpad bug 563893 in thunderbird "Thunderbird will not launch due to a recursive symlink" [Critical,Fix released] https://launchpad.net/bugs/563893
<bluefoxicy> jpds:  Yep.
<slangasek> kirkland: 'Skipping mounting / since Plymouth is not available" - I guess that will look familiar to Keybuk, but I don't know why plymouth is breaking for you
<slangasek> whee, mismatched quotes
<bluefoxicy> jpds:  i'm trying to find a bug/workaround/whatever for the infinite memory usagething though.  It happens when it tries to load a message, so as long as I don't click the main tab I'm good.
<TheMuso> slangasek: bdrung updated the package without updating the seeds. I dare say it can slide for now, but I have told him about the seeds bzr repo for the future.
<Keybuk> slangasek: that's one of those error messages like "beg for mercy" from the kernel when the module list changes
<Keybuk> in fact
<Keybuk> I may add it
<Keybuk> "Skipping mounting / since Plymouth is not available.  BEG FOR MERCY!"
<slangasek> Keybuk: the logic seems flawed to me, though - why should mountall refuse to even *try* to mount just because plymouth died?  shouldn't it wait until interaction is needed before giving up?
<bluefoxicy> Huh.  the solution for the memory problem ... is to create a .thunderbird.upstream folder.  I symlinked it from .thunderbird and thunderbird moved it.  Without .thunderbird.upstream, it... immediately allocates infinite memory, wtf?
 * bluefoxicy isn't sure how you even write an application with a bug like that!
<slangasek> "I can't interrupt this stupid fsck that takes too long" > "I can't boot at all because plymouth is broken"
<kirkland> slangasek: Keybuk: is there a compelling reason to use plymouth at all in a cloud image?
<Keybuk> slangasek: it didn't try
<Keybuk> it got bored
<Keybuk> that was the interaction that was needed ;-)
<slangasek> kirkland: yes, because it's part of the base system and an integral part of the boot design and it's hard enough to support *one* model for the boot system without having to worry about making a completely separate design work because of people trying to rip a core component out every time there's a bug
<slangasek> Keybuk: by "interaction" I mean "input" - what input is required from the user?
<kirkland> slangasek: alrighty
<Keybuk> slangasek: "/ hasn't showed up, want to skip it or get a maintenance shell?"
<mathiaz> slangasek: how often is run fsck?
<slangasek> Keybuk: ah, so it only does that when mnt->error is set, ok... it's a bug then that we're hitting the boredom timer?
<mathiaz> slangasek: after a specific number of times it has been mounted or is it time based (last 30 days)?
<slangasek> mathiaz: ext3 has settings for both
<slangasek> mathiaz: I haven't looked at ext4
<mathiaz> smoser: are the lucid images using ext3 or ext4?
<Keybuk> slangasek: well, it might not be a bug
<Keybuk> who knows
<Keybuk> but yeah
<slangasek> Keybuk: either a bug that the boredom timer is hit, or a bug that mountall isn't able to see the filesystem
<Keybuk> maybe yeah
#ubuntu-devel 2010-04-16
<TheMuso> 00000000/c
<ccheney> jdong: seems it couldn't even do ~ 6mbps for me
<ccheney> jdong: but if they hit the limit at 15mbps then i might need a better one, assuming the newer ones work better? i have a wrt54g
<persia> ccheney: Some of the newer consumer routers can handle ~250Mbps, but some are still limited to very low speeds.  It's worth looking for some user reports on specific models and usages before buying if you're currently feeling limited (alternately, wait a bit more, and get one with an Atom or ARMv7 proc that lets you reinstall with Ubuntu and run quagga)
<bluefoxicy> hmm
<bluefoxicy> crappy pseudo-security mechanism crashes.
 * bluefoxicy ponders the security implications of password-protected screen savers and implementations.
<jdong> bluefoxicy: you mean how plugging in an external monitor made the screensaver segfault? XD
<bluefoxicy> jdong:  nope.  gnome-screensaver-gl-helper crashed and I got an unlocked desktop
<jdong> lol niiiice
<jdong> I still like the way Windows does their screensaver locking.
<persia> bluefoxicy: There's a number of good rants out there about how screensavers that use complex libraries are pointless (and why xscreensaver is the only real screensaver, but all screensavers are inherently bad)
<jdong> the terminal services redirector unplugs the monitor and keyboard away from your session
<bluefoxicy> persia: see jdong
<jdong> and you get re-plugged into a kernel-owned winlogon dialog
<jdong> kinda like if we chvt'ed and didn't let the user chvt back
<persia> bluefoxicy: Hrm?
<bluefoxicy> persia:  it's possible to move a window on top the screen saver by some magic; or to move keyboard focus;etc.
<slangasek> bluefoxicy: gnome-screensaver-gl-helper crashing doesn't unlock the desktop.  That's why it's a separate helper.
<bluefoxicy> slangasek:  yet, I got a box telling me i had an application error, and nothing asked me for my password...
<slangasek> then something else is going on besides gl-helper crashing
<ccheney> persia: there are some routers that will be able run Ubuntu? i thought they all were using the older arm like the new marvell plug 3.0
<bluefoxicy> jdong:  I've actually had my keyboard focus wind up in another window too
<jdong> bluefoxicy: if you use compiz, there's some interesting exploits too
<bluefoxicy> I ctrl+alt+F1'd and logged in, then killed gnome-screensaver
<bluefoxicy> that got me back to my desktop XD
<jdong> ebroder demonstrated a zephyr popup based glitch to me before
<persia> ccheney: I don't know of any current consumer routers than can run Ubuntu.  I saw some Atom consumer NAS boxes a few weeks ago, and I hear persistent rumours about new ARM devices.  I imagine it won't be too long.
<jdong> where alert boxes can pop up *over* the screensaver
 * persia is waiting for such a router as well
<bluefoxicy> jdong:  nods.
<ccheney> persia: ok
<jdong> I kinda wish for a chvt-based solution.
<ebroder> jdong: That wasn't quite it. It was actually *another* window that would pop above the screensaver, not the popup itself
<jdong> ebroder: lol even worse then
<ccheney> persia: do you happen to know if weird fluctuations could be due to using a DOCSIS 2.0 instead of 3.0? I am seeing the weird spikes even connected directly to my modem with my laptop
<bluefoxicy> ebroder:  now can you pick which window?
<ebroder> jdong: That's why Athena disabled Compiz - we didn't want to get in trouble when a browser with somebody's grades popped up over the screensaver
<ebroder> bluefoxicy: I think it was pretty consistently the window that had focus before the screensaver activated
 * ccheney is considering getting a Motorola SB6120 at the store and seeing if it helps any
<ebroder> bluefoxicy: Let me see if I can track down the bug...
<bluefoxicy> ebroder:  ahh.  Damn.  My cologne has better hacking power than that.
<persia> ccheney: No idea.
<ebroder> bluefoxicy: bug #336932
<ubottu> Launchpad bug 336932 in compiz "New windows cause panels to be raised above fullscreen applications (e.g. screensaver)" [Low,Triaged] https://launchpad.net/bugs/336932
<bluefoxicy> ebroder:  lol.
<persia> ccheney: I've had persistent issues with network in lucid being slow (compared to karmic), but I don't think changing my router affects that, as I get the same going between two local machines (both lucid).
<bluefoxicy> ebroder:  panel -> run -> killall gnome-screensaver -> unlocked.
<jdong> yikes, it's any creation of new windows?
<ccheney> persia: i'm getting a range from ~ 800kbps to 28000kbps with my line speed supposedly being 12000kbps
<ccheney> persia: and overall a large transfer it ends up an average of 12000kbps
<ccheney> but with that big of a range it makes QoS pretty much useless even if it were to work on my router
<persia> ccheney: What's your uplink implementation?  That sounds like transit issues rather than the local router.
<ccheney> persia: its a cable modem with docsis 2.0 support connected to Comcast
<bluefoxicy> ccheney:  why would QoS ever work?
<ccheney> bluefoxicy: well it worked ok in the past when the speed was consistent
<bluefoxicy> huh.
<bluefoxicy> ccheney:  a more recent RFC deprecates QoS entirely
<bluefoxicy> not that anyone cares
<persia> ccheney: In that case, I expect you have an overprovisioned link and a governor to maintain an average speed of 12M, and you're seeing QoS hiccups from your provider's QoS.
<ccheney> bluefoxicy: i meant QoS at the router level throttling lower priority traffic, perhaps the routers concept of QoS isn't the same as TCP's
<bluefoxicy> ah, okay.
<ccheney> bluefoxicy: but with the router needing to know your link speed for that to work when it ranges from 800kbps to 28000kbps its useless
<persia> bluefoxicy: QoS is undeprecatable: that said, specific implementations (e.g. 802.16) are likely to be replaced by newer imple,entations quite regularly.
<ccheney> persia: yea probably so :-\
<persia> ccheney: When I was at an ISP, we used to sell 1.5Mbps and provision 10Mbps, just to be able to flood it to mask transient issues and keep the clients happy.  Mind you, this was a long time ago, when that was actually fast.
<ccheney> yea
<ccheney> persia: that seems to be what they are doing, before going to the new speeds they didn't over provision the speed by 2-3x like it appears is happening now
<micahg> is there a reason why libiw30 doesn't replace libiw29?
<ccheney> i just remembered something i saw a while back, is there a reason that checkmarks in human theme are white on menus?
<ccheney> i thought they used to be black
<slangasek> micahg: is there a reason it should?
<persia> overprovisioning local link is best practice for ISPs as they typically underprovision uplink, and need to reschedule packets to maintain SLA.  The only way I know to get out of such an arrangement is to provision a 1Gpbs local link, but that exposes you to uplink throttling directly.
<micahg> slangasek: get rid of an old package
<slangasek> micahg: that's not what Replaces does
<ccheney> persia: yea
<micahg> slangasek: doesn't it do the same thing?
<micahg> slangasek: the package I mean
<slangasek> micahg: that's irrelevant.  That's not what the *Replaces field* means
 * micahg goes to read the policy manual again
<slangasek> Replaces means "files previously belonging to that package have moved to this package"
<micahg> slangasek: I see, so do we have a way to remove old packages?  is that update-manager?
<slangasek> micahg: update-manager; or 'apt-get autoremove'?
<slangasek> ccheney: what in the world are these new OOo-l10n binaries for?
<ccheney> persia: yea thats true, i also may be getting more bursty nature now since i don't have docsis 3.0 so can't use those channels
<ccheney> slangasek: smooth upgrade from hardy/karmic to lucid
<ccheney> slangasek: they mention that in the package desc
<micahg> slangasek: I mean in an automated fashion, not by user input, I know how to remove it myself :)
<persia> micahg: The right way to remove old libraries is to have them be marked as installed automatically, and be automatically uninstalled when nothing depends on them (which should be the case for an upgrade).  This is implemented in apt, and used by update-manager as well as other things.
<persia> For non-libraries it's a bit trickier, but that's not the situation in this case.
<slangasek> micahg: well, packages don't upgrade themselves automatically either - you're either using update-manager, which gives you the option to remove packages it knows are obsolete; or if you're not using update-manager, 'apt-get autoremove' is the low-level interface
<slangasek> ccheney: hrm, were those leaf packages in hardy?
<slangasek> ccheney: if they should only have been pulled in as dependencies of, say, language-support-gu, then an upgrade should Just Work?
<slangasek> ccheney: ah; we don't have language-support-translations-* anymore either, ok
<ccheney> slangasek: they should only get used if the user already had eg openoffice.org-l10n-as-in installed to make sure they get openoffice.org-l10n-as now
<slangasek> ccheney: yes, I understand that - the question was why we need transition packages for something that was normally auto-installed
<ccheney> oh hmm, well would it automatically upgrade ok for a user who had the old version installed previously?
<ccheney> i'm not sure how our lang support does that during an upgrade process
<slangasek> no, because language-support-translations-* have gone away in lucid
<ccheney> but does language-support somehow handle that for upgrades now instead?
<ccheney> language-support the app i mean
<ccheney> if not then i think we would need this transition packages, right?
<slangasek> yes, I've accepted the transition packages
<ccheney> ok
<ccheney> also how does language-support app know which packages to install, is there something in there i need to have updated not to use the transition packages for new installs?
<slangasek> I don't believe anything needs updated there; I'm sure language-support uses a whitelist
<ccheney> ok
<slangasek> and isn't going to randomly install packages with similar names
<ccheney> well the whitelist might be out of date for those indic languages, but we should have gotten bugs about that by now i would think
<persia> ccheney: Don't be confident about that: we typically have very poor translations for quite a while during development, and lots of users don't test in local languages.
<ccheney> ok
<ccheney> persia: do you know if the whitelist is in the language support app package itself, if so i can check it for accuracy
<persia> I don't.  Arne should be around in an hour or so, and would know.
<ccheney> persia: ok
<jdstrand> bluefoxicy: fyi, in an effort to detangle these screenlocking issues, mdeslaur created https://wiki.ubuntu.com/DebuggingScreenLocking. It might be worthwhile to look there and file a bug
<bluefoxicy> haha
<bluefoxicy> everybody knows this is broken,huh?
<jdstrand> it is far too complicated... :(
<jdstrand> the security team got scores of these bugs, so we (mostly mdeslaur) talked to people and tried to figure it all out
 * ccheney got a new cable modem, i hope it helps :-\
<TheMuso> ccheney: Connection problems?
<ccheney> TheMuso: weird sinewave download speed pattern, got a docsis 3.0 modem to see if it hels
<ccheney> er helps
<TheMuso> Is the cable network you are on using DOCSIS 3?
<ccheney> yes my old modem is 2.0 though
<TheMuso> ah ok
<ccheney> ok bbiab calling them to update my mac and replace the modem with the new one
<raof> Man I hate trying to do anything slightly complicated with CDBS
<TheMuso> raof: Heh
<raof> Ok.  What's the magic incantation for getting CDBS to call some stuff *after* dh_makeshilbs for one package and *before* calling dh_installdeb :/
<ajmitch> raof: because the source is the only decent documentation for it?
<raof> ajmitch: And because the source is *labarynthine* and the control flow saunters through various underground tunnels.
<ajmitch> there's the binary-fixup rule, not sure if that's useful
<raof> Actually, I think I did this already for... launchpad-integration?
<raof> Let me check.
<ajmitch> raof: did you find the required incantations?
<raof> Yeah.
<raof> I'd done them before in my quest to make liblaunchpad-integration CLI-policy compliant.
<raof> I'll need to do the same for indicator-application for Maverick; it's a bit of a mess.
<un214> grrr I just hit another nasty bug
<un214> basically nothing running under dpkg should ever assume that upstart or any other services are running
<un214> was running apt-get dist-upgrade in emergency mode
<un214> kbuntu-desktop depends on mysql-server ?!?
<raof> Yes, of course kubuntu-desktop depends on mysql-server.  Amarok needs a serious SQL server for your music library :P
<imbrandon> raof: it does for mine :) ( 30k+ mp3's )
 * micahg thought amarok used an embedded mysql
<Dracari> has any work on PPC ATI Rage pro Drivers been made? i'd be willing to test a si have two Fruitie iMacs (G4 700MHZ and a G3 400MHZ)
<imbrandon> it can , but its crap
<raof> Does sqlite really not scale up to a mere 30k mp3s?
 * raof sckeptates.
<imbrandon> raof: no it dosent, not well atleast
 * raof lunches
<lamont> feeling lazy, I freely admit.  if I have a root password, how the hell do I get all the gnome auth dialogs to use sudo instead of wanting the root password?
<raof> That sounds quite poetic :)
<RAOF> What's the process for pushing and upload through the freeze these days?  Is it still https://wiki.ubuntu.com/FreezeExceptionProcess ?  I'd like to get bug #564351 through.
<ubottu> Launchpad bug 564351 in indicator-application "Fails to install library to GAC" [High,Confirmed] https://launchpad.net/bugs/564351
<mdke> RAOF: you can always check https://wiki.ubuntu.com/LucidReleaseSchedule for that sort of thing. It's currently https://wiki.ubuntu.com/FinalFreeze
<RAOF> Right.  So, first I need to convince someone that the library package being totally broken is RC and then...?  It was the âand thenâ that I was after :)
<mdke> RAOF: my understanding is that you need release team approval to the debdiff which you attach to the bug report
<mdke> RAOF: as to the way to attract the release team's attention, I think it's either to upload directly (but I'm not 100% sure that is acceptable), to grab someone or irc or perhaps to subscribe them to the bug
<RAOF> I don't have upload priviledges for indicator-application, so I can't just upload.  ubuntu-archive are subscribed to the bug, though.
<snow_ru> hi
<mdke> RAOF: ok, although i think it's ~ubuntu-main-sponsors that needs to be subscribed
<mdke> RAOF: also try and attract the attention of whoever tends to care for that package with upload privileges
<pitti> Good morning
<RAOF> â[ 5912.463012] This should not happen!!  Data will be lostâ is not a friendly dmesg
<OdyX> Hi. I'm the Debian maintainer for usb-modeswitch{,-data} and just got a report on Launchpad for a version bump for Lucid (#564353). I guess it's too late already or is it worth to file a syncrequest
<OdyX> (of courseâ¦ usb-modeswitch and -data have to come together, both from Squeeze)
<OdyX> ohâ¦ final-freezeâ¦ I guess that's a no thenâ¦
<joaopinto> freeze = developers vacations :P
<ttx> joaopinto: I wish.
<dholbach> good morning
<joaopinto> morning
<hunger> Why are there more and more "Don't show this message again" buttons appearing in the notification? First there was one, then two, now I am up to 4 of them in the same notification.
<joaopinto> hunger, are you refering to the crash reports ?
<hunger> joaopinto: No, I see this when connecting/disconnecting from networks mostly.
<joaopinto> ah, ok, no idea
<hunger> joaopinto: But that are the only notifications I regularly see:-)
<ScottK> OdyX: It's not necessarily too late.  Depends on what it would bring.
<joaopinto> I am trying to upgrade a server hardy->lucid
<joaopinto> I am having problems to upgrade from jaunty
<joaopinto> Error during update
<joaopinto> A problem occurred during the update. This is usually some sort of
<joaopinto> network problem, please check your network connection and retry.
<joaopinto> what should I check ?
<Tm_T> your network connection
<Tm_T> or does that come all the time?
<mvo> joaopinto: what does /var/log/dist-ugrade/main.log contain?
<joaopinto> it comes all the time, it's a server , I am sure it's connected :P
<joaopinto> mvo, there is no such dir
<mvo> joaopinto: sorry, type "upgrade" instead of ugrade
<joaopinto> 2010-04-16 08:59:52,657 WARNING updateStatus: dlFailed on 'http://localhost:3142//de.archive.ubuntu.com/ubuntu/dists/karmic-security/Release'
<joaopinto> 2010-04-16 08:59:52,830 ERROR IOError/SystemError in cache.update(): 'The server may be overloaded'. Retrying (currentRetry: 2)
<joaopinto> ok, that explains :)
<joaopinto> tks
<dholbach> ttx: do you think it makes sense to raise the importance of bug 552360 and fix it for lucid?
<ubottu> Launchpad bug 552360 in squid "package squid 2.7.STABLE7-1ubuntu11 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Low,Confirmed] https://launchpad.net/bugs/552360
<joaopinto> I was using an apt-cacher-ng proxy which must be failing after the upgrade
<joaopinto> mvo, it would be nice to have a "Please check logfile blahblah" ;)
<Tm_T> joaopinto: I agree
<joaopinto> much more helpful than "The server may be overloaded " :P
<ttx> dholbach: looking
 * ttx struggles to send mails to the MLs, apparently something blocks them
<mvo> joaopinto: agreed, the message is not ideal
<joaopinto> I am feeling confident, upgrading a server to lucid :)
<ttx> dholbach: yes, dunno why I set it to Low.
 * dholbach hugs ttx
<dholbach> fantastico
<ttx> will look into that
<ttx> targeting to Lucid + High
<ttx> dholbach: am I the only one reporting trouble sending mails to the MLs ? I've been trying to send meeting minutes to ubuntu-devel and ubuntu-server since yesterday, without success or error messages
<dholbach> weird
<dholbach> no idea
<ttx> sounds like I fall into a spamblocker /dev/null or something
<ttx> I even tried resubscribing, fwiw
<joaopinto> btw, I had an issue during development upgrades  which can lead to failures on clean installs that can't be detected on upgrades
<slangasek> ogra_cmpc: flash-kernel> why should the package depend on uboot-envtools? the udeb already apt-installs that package based on subarch, and the only place you've added fw_setenv calls is in the udeb
<joaopinto> I have a working package which depends on another package which was removed from the repository during development
<ScottK> joaopinto: Why was it removed?
<joaopinto> ScottK, because it failed to build, it is fixed now, but the point is that I would never find out unless I did a clean install
<joaopinto> I just noticed the problem because someone else with a clean install was not able to use the app
<cjwatson> that's why we have automatic dependency analysis tools
<joaopinto> I mean, to install
<ScottK> There was a list published of the intended removals and warning was given.
<cjwatson> although I don't think we have an equivalent of lucid_probs.html for universe
<joaopinto> cjohnston, well, I got no warning that a package on my system was not re-installable due to a change on the repositories :P
<cjwatson> "cjwatson"
<cjwatson> no, you wouldn't
<ScottK> I think apt-cache unmet -i would cover it.
<cjwatson> ogra_cmpc: I agree with slangasek, there's no need for that dep
<joaopinto> ScottK, I am referring to a proactive technical validation
<cjwatson> unfortunately our efforts to run a full dependency-correctness analysis of the archive have failed in the past
<ScottK> joaopinto: I think what you are inadvertently arguing is that we were inusufficiently aggressive with our removals.
<cjwatson> simply took far too long
<cjwatson> I thought the removals had been rdepends-analysed, though?
<joaopinto> ScottK, no, I am just describing that I have was unable to detect a critical change during development, which has technical means to be validated
<ScottK> I think we looked at reverse build-depends.
<joaopinto> I am arguing that eventually it should be done automatically at some stage
<cjwatson> normally it is
<cjwatson> as in, normally removals are prefaced by the archive administrator who does the removals running checkrdepends
<cjwatson> I think it's an anomaly that that wasn't done here
<cjwatson> unless you're talking about a local package with the dependency, not one in the Ubuntu archive
 * Dracari sighs
<Dracari> "why does it seem liek USB Support is broken for Dell laptops again?"
<joaopinto> I am talking about an Ubuntu archive package, it was libuser1, which builds now
<ScottK> cjwatson: I have run into cases before when we were following Debian removals where it appeared that wasn't done too.
<ScottK> joaopinto: Yes and we should have (but apparently didn't) removed the packages that required it too.
<joaopinto> right
<joaopinto> uff, 9.10 done, one more upgrade to go
<Tm_T> joaopinto: I upgraded directly from Intrepid to Lucid (:
<Tm_T> was bit of a mess here and there
<joaopinto> well, I expect some mess at the end, but custom config related, if the server boots I am happy :)
<joaopinto> LTS2LTS is a long way :)
<joaopinto> Error during commit
<joaopinto> 'E:Internal Error, Could not perform immediate configuration (2) on
<joaopinto> mountall'
<joaopinto> Restoring original system state
<joaopinto> ok, let me check the log this time :P
<joaopinto> I hate cryptic errors :P
<mvo> joaopinto: that is a know bug, I'm working on it.
<slangasek> joaopinto: that's a known bug which kirkland and mvo are working ... yeah, what he said :)
<mvo> bug 559582
<ubottu> Launchpad bug 559582 in mountall "Upgrade from karmic to lucid failes with Internal Error, Could not perform immediate configuration (2) on mountall" [Undecided,Confirmed] https://launchpad.net/bugs/559582
<joaopinto> ah ok :\
<lifeless> mvo: Cron <conflictchecker@macaroni>  user=conflictchecker cd $HOME/findconflicts && PYTHONPATH=. bin/findconflicts > ../public_html/possible-conflicts.txt
<lifeless> 				
<lifeless> mvo: that blew up without warning - check your mail.
<lifeless> mvo: any thoughts?
<joaopinto> mvo, do you need more data ?
<joaopinto> mountall is quite popular on bugs
<vish> mvo: hi.. any news regarding this branch > https://code.launchpad.net/~mvo/synaptic/ubuntu-ui-changes   has it been merged to main?
<joaopinto> otherwise I will just continue with the workaround
<mvo> lifeless: no and I'm deep in lucid tasks, maybe sbeattie can help? otherwise I can try to look at it later today (its not in my mail yet for some reason)
<lifeless> mvo: probably filtered out
<lifeless> you are listed in the to: clause
<mvo> vish: hi, not merged to main yet, I was focusing on the lcuid branch
<lifeless> mvo: perhaps you can poke sbeattie when he arises
<mvo> lifeless: can do
<vish> mvo: any chance of that landing for Lucid?
<mvo> vish: no, because of the UI freeze
<lifeless> mvo: thanks!
<vish> mvo: ah ok.. thought you were getting a UIFe for that branch.. i guess it is too late now ;)
<mvo> vish: yeah, sorry. early maverick it can land
<vish> np..
<vish> thanks :)
<mvo> np
<joaopinto> mvo, is the workaround suggested on the bug safe, or do you suggest to wait for a fix ?
<slangasek> ogra_cmpc: rejected the flash-kernel upload for the abovementioned issue; everything else looks ok, so please reupload once fixed
<mvo> joaopinto: depends on your needs I guess, if you don't mind waiting another day I would wait for the fix
<mvo> joaopinto: otherwise you can just do ahead
<joaopinto> hum, vmware server without access to the console, I think I will wait
<slangasek> mvo: is bug #522225 on your radar for final release?  I don't know how hard it is to add that to u-m; if it's not likely to be fixed for final, we can just push it to SRU
<ubottu> Launchpad bug 522225 in mysql-dfsg-5.1 "permissions incorrect on libmysqlclient16_7.0.9-1_amd64.deb" [High,Fix released] https://launchpad.net/bugs/522225
<snow_ru> hi
<mvo> slangasek: its on my radar, but not with very high priority as it affects lucid->lucid only, right? this is a bit more tricky because on same-dist -> same-dist upgrades no quirks  handlers are usually run
<slangasek> mvo: correct - if you tell me it's too tricky even for SRU, then we should just wontfix it; we've already warned people on u-d-a and in the release notes, so if we aren't able to automatically solve this for users on upgrade, it's not critica
<slangasek> l
<mvo> slangasek: I haven't put that much thought into it, I don't think its too tricky
<mvo> slangasek: its just not trivial as it would be on release -> next-release
 * slangasek nods
<slangasek> chrisccoulson: have you been able to verify whether gtk_show_uri() works in isolation?
<snow_ru> ls
<chrisccoulson> slangasek - not yet, but it is used for launching help from a lot of other gnome apps already
<chrisccoulson> it's blocking on a gconf call, which is weird :-/
<slangasek> chrisccoulson: oh, didn't realize that
<chrisccoulson> there is a gvfs module which uses gconf to find the handler for the URI, and that's where it blocks
 * slangasek nods
<chrisccoulson> i tried stepping through it in gdb, and confirmed that the orbit code is taking a recursive lock
<chrisccoulson> but i don't know orbit enough to figure out why just yet
<jibel> mvo, hey, can you review fix for bug 564320 ? 'mark for upgrade' in synaptic is currently broken.
<ubottu> Launchpad bug 564320 in synaptic "'Mark for upgrade' does not work for upgradable packages" [High,Fix committed] https://launchpad.net/bugs/564320
<mvo> jibel: yes
<jibel> mvo, thanks.
<seb128> slangasek, did people say if other distros not having the issue are building with gio too?
<slangasek> seb128: I don't know
<slangasek> I didn't see anything about that in the bug
<slangasek> dpm: I need your input on bug #539676; I think there was some miscommunication about this, the string was *not* changed previously but is now sitting in the unapproved queue
<ubottu> Launchpad bug 539676 in ubuntuone-client "[Freeze Exception] Add instructional text to Ubuntu One Preferences application" [Medium,In progress] https://launchpad.net/bugs/539676
<slangasek> dpm: I think the right thing to do here is to ask them to roll back that change and reupload; what do you think?
<dpm> hi slangasek, sorry for the delay. I agree. It is quite late and the translations imports queue is really slow at the moment. I'm not sure whether there'd be time to import the new template.
<slangasek> dpm: ok - I'll review for other issues, reject and ask for the revert, thanks
<dpm> thanks
<OdyX> bug 564353
<ubottu> Launchpad bug 564353 in usb-modeswitch "usb_modeswitch crashes with Sony adapters" [Undecided,Fix committed] https://launchpad.net/bugs/564353
<OdyX> ^any external opinion on this ?
<OdyX> it works in squeeze and has no bugs so farâ¦ so the sync doesn't seem risky to me. But just IMHO
<ogra> geez
<ogra> so my laptop just OOM'ed .... with 4G of RAM !
<tjaalton> ScottK: I've prepared sssd-1.0.5 which fixes all three bugs filed against it, one being rather serious. note that this is the last release from 1.0.x bugfix series, and not the more featureful 1.1.x ;)
<ScottK> tjaalton: And 1.0.2 to 1.0.5 is all bug fixes?
<tjaalton> ScottK: yes, let me grab the changelog..
<ScottK> tjaalton: It's fine then, just upload it and it'll get reviewed.
<tjaalton> ScottK: ok, thanks (there was no changelog..)
<ogra> mdz, did you track doen the evolituon issue you had yesterday ? i suspect i was just hit by it
<ogra> *down
<ogra> sigh and apport doesnt want to report because i didnt upgrade since yesterday
 * ogra upgrades
<ttx> ogra: I see little progress on the RC-level bug 532733 -- could you help providing some of the information Dustin requested ?
<ubottu> Launchpad bug 532733 in qemu-kvm "apt/dpkg in qemu-system-arm hangs if a big task is installed" [High,Incomplete] https://launchpad.net/bugs/532733
<slangasek> ogra: hi, did you happen to see my comments about flash-kernel (directed at ogra_cmpc)?
<ogra> ttx, i uploaded rootstock with the -disk change but the archive was out of sync until today so there was no way to verify yet
<ttx> ogra: ok, keep us posted :)
<ogra> slangasek, nope
<ogra> ttx, i had a build running when my machine crashed
<mdz> ogra, yes, I mentioned the relevant bug reports in the channel
<mdz> ogra, well, "track down" as in cross-reference and report. I didn't isolate the root cause, but think I found a workaround
 * ogra goes to the other laptop to look for slangasek's comments
<slangasek> ogra: I don't see any reason for flash-kernel to depend on uboot-envtools, the only call you added to fw_setenv was in the udeb - and cjwatson confirms; I've rejected that upload, please reupload without the dep or explain why it's needed
<ogra> slangasek, well, i didnt want to explicitly seed it, there is no other straight dep to get it into the image
<ogra> but indeed i can just seed and drop the dependency
<persia> ogra: Why not seed it?  It only belongs on the image: running systems don't need it.
<ogra> persia, well, its for changing the uboot config from a running system
<slangasek> persia: running systems don't need it> well, they get it /anyway/ because this uses apt-install
<ogra> you surely want it on installed systems
<slangasek> ogra: but the difference is that making it a dep puts it on *all* systems, regardless of subarch
<cjwatson> seeding it is appropriate
<ogra> right, the only reason for seeding it was to have it in the image
<slangasek> so seeding it is the right answer
<cjwatson> it belongs in the d-i-requirements seed
<ogra> right, no prob ... was out of lazyness to fiddle with seeds and metapackages
<cjwatson> just like uboot-mkimage
<cjwatson> there is no reason to treat this package differently from uboot-mkimage
 * ogra fixes
<ogra> well, i oriented myself on redboot-tools
<slangasek> it's not a metapackage issue
<ogra> that should be changed accordingly
<doko__> Riddell: could you check #555868 on kubuntu?
<persia> slangasek: Only a small subset of systems in one subarch.
<ogra> lool made that a dep of flash-kernel back when we enabled imx51 ... i'll bump it down to a suggests too
<slangasek> persia: having it as a dep of flash-kernel, which is what's being disputed, means it'll be installed anywhere flash-kernel is; and flash-kernel certainly appears to be used on more than one subarch
<persia> slangasek: RIght.  I'm agreeing that it shouldn't be a dep :)
<slangasek> ogra: no, please don't change redboot-tools at this stage - it's almost certainly wrong, but I don't want the possibility of extra churn trying to get it right
<ogra> ok
<lool> slangasek, ogra: Right, I don't remember why I added the dep since I remember I went through the extra effort of ensuring it got installed on end systems via d-i
<slangasek> ogra: seeding redboot-tools in d-i-requirements is ok - but don't drop the dep
<ogra> will do
<lool> I mean via anna-install
<lool> and apt-install
<lool> slangasek: agreed, let's defer fixing this to maverick
<doko__> chrisccoulson: does the private nss3/nspr4 copy stay in firefox for lucid?
<chrisccoulson> doko__, it does, i'm afraid. is that still an issue for you? you had a workaround didn't you?
<doko__> chrisccoulson: the workaround is in place. just curious, why it has to stay?
<ogra> slangasek, uploaded newly and d-i-requirements changed and pushed
<chrisccoulson> doko__, we've deliberately minimised the dependencies of firefox as per https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model
<ogra> (i guess that needs a published run or something to pick up the seed change)
<ogra> *publisher
<persia> 2 of them
<ogra> yeah, i guess there is enough in the queues to make that automatic :)
<james_w> bdrung: how's the audacious transition going?
<slangasek> ogra: it's a seed change, not a task change
<slangasek> all it needs is a new ISO build
<ogra> great
<persia> slangasek: Aren't the ISOs built off the tasks based on the seeds?
<ogra> not everything
<persia> Or is this special because it's not actually installed in the livefs?
<bdrung> james_w: one of five packages are done. remaining:  bug #564087, #564088, #564091, #564092
<ubottu> Launchpad bug 564087 in g15daemon-audacious "FTBFS against audacious 2.3" [Undecided,New] https://launchpad.net/bugs/564087
<ubottu> Launchpad bug 564088 in imms "FTBFS against audacious 2.3" [Undecided,New] https://launchpad.net/bugs/564088
<ubottu> Launchpad bug 564091 in upse "FTBFS against audacious 2.3" [Undecided,New] https://launchpad.net/bugs/564091
<ubottu> Launchpad bug 564092 in xmp "FTBFS against audacious 2.3" [Undecided,New] https://launchpad.net/bugs/564092
<slangasek> persia: liveCDs are built from tasks; the archives that sit on the iso9660 fs are built from seeds
<slangasek> ogra: accepted
<ogra> \o/
<persia> That makes sense.  OK.
<ogra> we have omap !
<james_w> do we have rmadison for ports?
<cjwatson> persia: or, putting it a different way, not all seeds generate tasks
<persia> james_w: Unfortunately not.
<james_w> damn
<james_w> can lp tell us about binary publishing status?
<cjwatson> james_w: this obviously doesn't help everyone, but you're an archive admin, you can run madison-lite on cocoplum
<james_w> ah!
<james_w> of course
<james_w> thanks
<ogra> persia, on the livefs there is also Recommends: .... uboot-envtools [armel] .... in ubiquity which makes livecd-rootfs pull it into the images
<james_w> doko__: is it worth keeping the packages from http://people.canonical.com/~ubuntu-archive/NBS/zope2.11 around? they seem to be zope2 only
<slangasek> ogra: that also looks wrong to me... surely it should be seeded in the same place as the kernel, so that it's only pulled into the omap livefs instead of into the livefs for all subarchs?
<ogra> slangasek, thsta what we do on all subarches ... i only followed cjwatson's suggestion here
<ogra> *thats
<slangasek> alrighty
<ogra> uboot-mkimage as well as redboot-tools are in that line too
<ogra> what we really miss though is support for [$arch+$subarch]
<ogra> in the deps
<ogra> lool, might it make sense to have a BOF for that at UDS ^^^ ?
<persia> Ooh.  madison-lite is nifty (even if it does have an implicit dependency on a heap of disk space)
<doko__> james_w: no, zope2.12 isn't ready either, one of the zope-pkg maintainers did leave the team to have more time for general python ranting
<james_w> heh
<james_w> doko__: zope-common too?
<doko__> james_w: still in testing; it doesn't hurt
<lool> cjwatson: Do you think you could update debootstrap for maverick upstream and copy it to lucid?  That would be excellent
<james_w> doko__: ok, I'll just remove the ones that depend on zope2.11 then?
<slangasek> persia: just needs Packages/Sources - a mere 180MB :)
<doko__> james_w: yes
<james_w> ok, doing, thanks
<lool> slangasek: Note that ogra mentions the ship and ship-live seeds here
<lool> slangasek: not e.g. the desktop seed
<lool> I think it's right to have the livefs relatively generic with some packages which can be installed when installing the target system (via anna-install IIUC)
<slangasek> lool: hrm?  he was talking about ubiquity recommends
<lool> slangasek: He mentionned seeds though
<ogra> i meantioned seeds (wrt d-i-reqs) and recommends for ubiquity
<lool> Right I see it's in the recommends as well, not sure why
<lool> Again something we'd better not touch, but which is probably not needed
<lool> Ah apparently this relates to network access
<ogra> Recommends: grub-pc [any-amd64 any-i386 any-lpia] | grub [any-amd64 any-i386 any-lpia], flash-kernel [armel], uboot-mkimage [armel], uboot-envtools [armel], redboot-tools [armel], yaboot [powerpc], hfsutils [powerpc], silo [sparc], dmraid
<ogra> thats what ubiquity has
<lool> http://paste.ubuntu.com/415455/
<cjwatson> lool: I already updated it upstream in svn
<lool> cjwatson: You think we should just change it in Ubuntu right now with a new symlink and better not wait for a Debian upload + sync?
<cjwatson> I can probably upload that to Debian
<cjwatson> slangasek: debootstrap upload OK? ^-
<cjwatson> er, sync that is
<slangasek> cjwatson: yes, go ahead
<cjwatson> hmm, lucid only has .20, and the changes since are extensve
<cjwatson> +i
<slangasek> oh
<cjwatson> so I think I'll just change it directly in lucid
<slangasek> ok
<lool> cjwatson: thanks
<lool> bug #537007
<ubottu> Launchpad bug 537007 in ubiquity "flash-kernel fails hard when network access fails" [High,Fix released] https://launchpad.net/bugs/537007
<ogra> lool, so do you think discussion dpkg support for [$arch+$subarch] would make sense at UDS ?
<lool> ogra: I don't think dpkg should support that
<cjwatson> I doubt there would be any point unless there are dpkg hackers present, anyway
<lool> but perhaps I'm wrong
<ogra> i think that would make our life a lot easier wrt ARM
<cjwatson> I tend to agree with lool on this
<slangasek> dpkg doesn't even support [$arch] the way you mean
<cjwatson> but that's kind of beside the point - we don't have anyone who could reasonably be assigned to implement that right now, even if the consensus were that it is a good idea
<lool> Ack
<ogra> well, we often end up with a lot of unneeded packages due to missing finer grained subarch support in the packaging system
<cjwatson> there's no point having UDS discussions for things that are infeasible to implement
<lool> ogra: We have xserver-xorg-video-* on all intel systems
<cjwatson> instead, I suggest you take it up with debian-dpkg@
<slangasek> I think you end up with unneeded packages because of not using the seeds the way they should be
<slangasek> (seeds and kernel package recommends)
<ogra> (ther live images conatin all armel linux-headers packages for example) (which is a bug i plan to fix in livecd-rootfs, but a finer dependency system would solve that better imho)
<lool> Right, we should have a beagle or omap seed instead of pushing down to the desktop / netbook seeds
<lool> I think I discussed a beagleboard task with someone recently, but I don't remember who it was
<lool> I wondered whether we can build the list of tasks dynamically
<ogra> so more fine grained seeds instead of finer grained dependency system ?
<ogra> i think we shuld have both
<persia> Why not just add subarch support to the various tools that use seeds?  Splitting seeds on a per-arch or per-subarch basis sounds like a recipe for merge pain.
<cjwatson> adding subarch support to germinate is kind of useless unless apt understands subarches, which is why I have never done so
<ogra> right
<mvo> jibel: uploaded, many thanks
<cjwatson> or at least only useful in very constrained circumstances
<ogra> the package system needs to understand it at some level
<cjwatson> honestly, the number of packages involved is sufficiently small that I don't think it's worth massive extensions to the package manager
<ogra> if it would be a massive extension i agree ...
<lool> Frankly, our definition of subarches would only cover a subset of the use cases
<ogra> i dont know whats involved to make it work ... i only see the user side and where we suffer
<cjwatson> it would be pretty substantial, yes
<lool> That is, you might be able to express a couple of dependencies usefully for a SoC, but you'll face the same issue again when trying to address packages for different boards for instance
<cjwatson> syntactic changes to run-time dep expansion, teaching dpkg and apt to understand subarches at all, potentially changing every tool that parses Packages
<ogra> and i fear that if we support ten or more armel subarches it can get painful
<lool> We're talking about ridiculously small packages anyway
<ogra> linux-headers isnt so small
<ogra> but yes, the rest is
<lool> ogra: Perhaps the kernel packaging can be improved to share more headers then?
<lool> Across subarches, and even across upstream versions, the difference is probably very small
<ogra> there are other areas we need to touch ... i.e. livecd-rootfs
<bdrung> james_w: help for fixing these bug would be appreciated
<lool> ogra: We're not reusing livefses, so we could apt-get install ubuntu-netbook^ beagle-board-support^ or omap3-specific^
<slangasek> lool: the linux-headers packages exist specifically to enable building modules against that kernel; you can't know a priori which headers are shareable across subarchs / upstream versions
<ogra> lool, we will go on using it in ubuntu
<ogra> slangasek, well, the kernel team tried to solve that by adding different subarch names to the package naming (and introducing several different ABI numbering systems) ... which apparently didnt work out
<slangasek> ogra: which was designed to do the *opposite* of what lool suggested
<slangasek> i.e., it was designed to ensure no header files were shared between any subarchs
<ScottK> ogra: re your rootstock upload: How is "merge patch from Robert Nelson <robertcnelson@gmail.com> to generate initramfs from external kernel debs" not a new feature?
<lool> slangasek: Yeah, trying to think how it would work I can only think of hackish way to share the headers
<ogra> slangasek, designed to vs working reality :)
<lool> Are these actually installed by default?
<slangasek> lool: step 1) get all subarchs using the same kernel version
<lool> We could also keep them compressed most of the time given we're using them for a heavy build anyway
<slangasek> s/version/tree/
<amitk> lool: every arm kernel is on a different version, how are you going to share headers?
<lool> slangasek: That's crazy, who would want to use the same kernel tree to support multiple SoCs or architectures!!  Debian??   ;-)
<ogra> ScottK, i just dont have a bug report for that, robert uses rootstock to build rootfses for arches we dont have kernels for, it was always considered a bug that he doesnt use initramfses, that patch fixes it ... we are discussing it via IRC though, not through bugs
<slangasek> amitk: see step 1 :)
<lool> lol
<ogra> hehe
<amitk> slangasek: see you after 2 years
<slangasek> ack
<lool> So just thinking "sky is the limit", if we were to upload a single kernel source package with a base tree + extra tarballs / patches for all subarches, we could have this single package build output a consistent set of headers
<ogra> ScottK, do you want a FFe bug for it to have proper  paperwork (i dont want to drop it it took me long enough to convince him to do it that way)
<slangasek> ogra: looks like bug #562888 was meant to be closed in the flash-kernel upload?
<ubottu> Launchpad bug 562888 in ubiquity "omap installation failed with unrecoverable error" [Medium,Invalid] https://launchpad.net/bugs/562888
<lool> That is, we could have a source package creation step from a single git repo with multiple branches which outputs a single source package
<ogra> slangasek, no, i duped it to the ubiquity bug
<ogra> slangasek, next ubiquity upload will close it
<slangasek> ogra: no it won't, the open task is on flash-kernel
<lool> That would be unpractical to work with in terms of debdiff and apt-get source, but it would be able to ship binary headers package sharing headers safely
<ogra> slangasek, ugh ... i would have expected duplicating closes all tasks ... i'll go and close it
<amitk> lool: single source tree? How? we have 2.6.31, 32 and 33 version right now for fsl, mvl and ti respectively
<ogra> oh, i was thinking of a different bug :P
<lool> amitk: Single source package
<ScottK> ogra: Since the queue is frozen at this point, it probably doesn't matter much.
<lool> amitk: Well we could tar up .31, the .31 -> .32 diff, the .31 -> .33 diff etc.
<ogra> ScottK, ok
<lool> amitk: I dont think this would be practical to work with, but it would be technically feasible; perhaps we can research a saner approach which allows sharing headers
 * ScottK will probably leave it to someone more familiar to review though.
<amitk> lool: so you get 'base' headers that don't change across kernel versions. What about the headers that do change?
<lool> amitk: I don't understand
<persia> lool: Consider the case where you have *different* kernel headers for different patches being applied for different flavours.
<lool> amitk: I guess there are multiple options to shipping, depending on the complexity we can tolerate and the gains we're looking for
<amitk> lool: how many header packages would you generate? 3? or 1?
<lool> persia: Yes, so you could have symlink farms for most files and overrides for the modified headers, or you could patch a copy of the installed headers
<lool> amitk: Doesn't really matter
<lool> probably one per subarch
<persia> lool: We already have issues with per-flavour kernel headers differing, which makes dkms messy.  I'm not sure extending that is best.
<lool> I find the first idea I throwed bad enough that it should be getting the critics!
<james_w> ok, looks like just sugar and audacious left for NBS
<lool> persia: I agree it's a risk/gain tradeoff, yes; trying to come up with a way to avoid losing space
<ScottK> lool: It looks like in your u-d-t upload there are changes in get-branches done by soren, but not in debian/changelog.  Would you mind having a look at documenting them.
<slangasek> mvo: is your WI for foundations-lucid-non-applications-in-software-center still in progress?
<slangasek> mvo: ("test that on a fresh install, a-x-i db and apt lists are created/updated")
<mvo> slangasek: it is, late but sitll on my list
<ogra> amitk, you also forgot the buglink in the omap upload for Bug 561424 (slangasek just moved it to updates)
<ubottu> Launchpad bug 561424 in linux-ti-omap "console switching does not work with ti-omap " [High,Triaged] https://launchpad.net/bugs/561424
<slangasek> mvo: ok - I'll move the milestone, so it stays on the radar
<mvo> thanks
<lool> ScottK: Sure, how shall we proceed, do you want a reupload?
<lool> ScottK: Or I could upload a new version fixing the changelog
<ScottK> lool: Please fix and upload.  There was one post-upload commit to the branch you may want to consider.
<lool> ScottK: Updated 0.98 pushed
<ScottK> Lookng
<ScottK> ..i..
<doko__> james_w: while you are at removals, can you remove gnat-4.3? doesn't build using the gnat pointing to gnat-4.4
<ScottK> lool: Accepted.  Thanks.
<james_w> doko__: done
<Riddell> ev: did you get anywhere with kubuntu oem?
<cjwatson> slangasek: I recently changed grub2 to single-quote menuentry titles, as part of fixing bug 552921
<ubottu> Launchpad bug 552921 in grub2 "An apostrophe translation in the line "echo Loading Linux 2.6..." of Grub breaks the boot menu from this entry included in Grub (in Ubuntu 10.04)" [Undecided,Fix released] https://launchpad.net/bugs/552921
<ev> Riddell: indeed, I fixed it
<cjwatson> slangasek: I've just noticed that os-prober fails to handle this, and I've committed a fix upstream - would it be OK to sync that into lucid?
<ev> it called into question my understanding of python's scoping and garbage collection rules though
<ev> Riddell: r4081
<Riddell> ev: you're my hero
<ev> :)
<slangasek> cjwatson: yes, go ahead
<ev> Riddell: we still seem to have issues with the advanced partitioning page in Kubuntu.  I've asked Roman to look at that, as it appears to be specific to the KDE frontend.
<Riddell> ev: what sort of issues?
<ev> Riddell: bug 563309
<ubottu> Launchpad bug 563309 in ubiquity "ubiquity crashes on manual disc setup" [Undecided,Incomplete] https://launchpad.net/bugs/563309
<ev> and the interface in the KDE frontend is still slow, but not nearly as bad as before
<Riddell> cjwatson: gfxsplash colours should probably be changed, selection background to match the blue background and black text I think
<Riddell> cjwatson: should I look into that or is it easier if you just do it?
<cjwatson> Riddell: if you could give me hex colour codes that should be used, I can take care of applying them
<cjwatson> some of the syntax is a bit nonintuitive
<Riddell> cjwatson: background 00507f and text 000000
<cjwatson> Riddell: hmm, doesn't seem to be a perfect match
<Riddell> cjwatson: how about 005082
<cjwatson> Riddell: http://people.canonical.com/~cjwatson/tmp/kubuntu-boot-screen-2.png - slight visible bar across the "Install Kubuntu" line
<cjwatson> the white/black thing OK there?
<cjwatson> ah yes, that's better thank
<cjwatson> s
<slangasek> doko__: when do you plan to upload eglibc for these milestoned fixes, and are there any others pending besides the three I see on https://bugs.launchpad.net/ubuntu/lucid/+bugs?field.milestone=21439 ?
<doko__> slangasek: I hope soonish/today, but I get different feedback on the networking bug
<doko__> currently talking with pitti
<slangasek> ok, cool
<cjwatson> Riddell: applied
<doko__> slangasek: but the networking stuff really isn't my core knowledge ...
<squirrelpimp> i just tried installing lucid with full disk encryption using lvm inside luks on sda2. However the boot drops out at "root device /dev... does not exist. dropping to a shell". Is there some new specialty about the boot process in lucid? i found the page where all configurations should have been testet for plymouth, but it looks quit unfinished.
<squirrelpimp> is there any page describing the interaction between cryptsetup and plymouth, so i can pick some thread up to fix my boot?
<cjwatson> I thought that mode was tested and passed in beta-2
<cjwatson> does this happen every time?
<squirrelpimp> yes... i tried thrice without success. The system was installed using the live cd, while manually setting up the crypted disk and lvm. This has worked on previous versions before.
<squirrelpimp> right now i boot into the livecd again to double check the initramfs steps
<cjwatson> oh, well, full-disk-encryption installs using the live CD are unsupported, so successes are essentially down to luck
<cjwatson> why not use the alternate CD, where this mode is actually supported?
<squirrelpimp> i always used this mode as it gave me the feeling of full control over the result. however usually it also worked
<squirrelpimp> :)
<squirrelpimp> sometimes i wish myself back to the old days when all was init.d scripts
<squirrelpimp> well, now i get another symptom (after recreating initramfs):
<squirrelpimp> plymouth halts with "cryptsetup: lvm device name (/dev/disk/by-uuid/"ad9f...7d7") does not begin with /dev/mapper
<james_w> bdrung: two done, there's a partial patch for xmp http://xmp.git.sourceforge.net/git/gitweb.cgi?p=xmp/xmp;a=history;f=src/plugin/audacious.c;h=9a3b7cb2725c65cc2ad40fb04d5f08eed1f004d7;hb=HEAD but it's not complete
<cjwatson> init.d scripts aren't relevant to mounting the root filesystem anyway, and never were
<squirrelpimp> weren't they? ok then...
<squirrelpimp> is the alternate installer capable of reusing an already existing lvm inside luks?
<squirrelpimp> as my /home is in there and i'd like to keep it (though i have a backup of course)
<cjwatson> I don't remember for sure, I'm afraid
<persia> It is, but you have to drop to a shell to unlock it before running partman.
<persia> (or it was for jaunty: I haven't tested that use case since then)
<squirrelpimp> is there a way around the "does not start with /dev/mapper" issue... as this would render me with a usable system much quicker
<squirrelpimp> and i'd learn something about plymouth
<squirrelpimp> :)
<persia> squirrelpimp: Which architecture?
<squirrelpimp> x86_64
<persia> Hrm.  Dunno.  Works for me on that arch with LVM-inside-luks
<squirrelpimp> can you give the entry from your crypttab?
<persia> data /dev/disk/by-uuid/78a09fa1-31e2-4ef2-bcc6-93bef9f2efc5 none luks
<squirrelpimp> mine s
<squirrelpimp> sry... lvm UUID="ad9f4b...c7d7" none luks
<squirrelpimp> i'll try to make it more similar to yours
<squirrelpimp> maybe it doesn't like the UUID="..." syntax with the " around
<squirrelpimp> next try
<squirrelpimp> great... it works now
<pitti> "seb128@ubuntu.com has 299 fixes"
<pitti> go, seb128, go!
<pitti> kirkland: oh, we are on par again *hug*
<cjwatson> gar, plymouthd really doesn't like being straced
<tseliot> pitti: where do you see that kind of information?
 * sladen hits the mountall fsck fail business
<tseliot> cjwatson: either halfline or brejc8 might have some ideas in #plymouth (if you need help)
<Riddell> ev: I take it you managed a complete OEM install on kubuntu after your fix?  so we can confirm that bug 540922 is gone?
<ubottu> Launchpad bug 540922 in ubiquity "apt error when running oem-config-kde" [Undecided,New] https://launchpad.net/bugs/540922
<ev> Riddell: that's a duplicate of bug 539710.  I've marked it as such.
<ubottu> Launchpad bug 539710 in ubiquity "OEM Lucid installation - configuring system for a new user - error occurring installing new packages" [High,Fix released] https://launchpad.net/bugs/539710
<ev> but yes, I did complete a full run of oem-config in kde
<seb128> tseliot, number of bug fixed you mean as information?
<seb128> tseliot, http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html
<seb128> pitti, http://qa.ubuntu.com/reports/bug-fixing/canonical-desktop-team-lucid-fixes-report.html has slightly different counts
<Riddell> ev: I can't recreate bug 563309, at least not on a virtual machine, will try on real hardware in a bit
<ubottu> Launchpad bug 563309 in ubiquity "ubiquity crashes on manual disc setup" [Undecided,Incomplete] https://launchpad.net/bugs/563309
<ev> Riddell: okay, thanks
<tseliot> seb128: ah, thanks a lot
<pitti> seb128: right, that seems slightly more recent
<pitti> seb128: congrats for breaking the 300 mark!
<seb128> pitti, thanks ;-)
<ogra> seb128, wrt our fsck discussion last night: https://bugs.edge.launchpad.net/ubuntu/+source/mountall/+bug/563618/comments/14
<ubottu> Launchpad bug 563618 in util-linux "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Triaged]
<ogra> :)
<squirrelpimp> fglrx broke kms, as it doesn't support it of course. is there an easy way to disable the graphical part and return to text mode?
<squirrelpimp> right now i get the plymouth boot screen, but in huge dimensions almost not fitting on the monitor and with large pixels
<dmart> ogra, do you think it would make sense to turn off all the system time releated checks and fixes if broken_system_clock = true ?  The more I think about this, the more sense it seems to make
<cjwatson> add the 'nomodeset' kernel parameter, assuming that you have xserver-xorg-video-radeon either at the very latest version or else not installed at all
<ogra> dmart, well, currently broken_system_clock auto-fixes the timestamp which results in a reboot ... after which the timestamp is wrong again ... but yes, enhancing it might make sense, but probably by introducing another parameter
<squirrelpimp> i have it installed at the latest version and before installing fglrx, plymouth looked very nice. i already tried adding nomodeset without success
<squirrelpimp> still the boot screen and password prompt looks to big and broken
<dmart> ogra: The way I look at it, broken_system_clock informs e2fsck that the system time is random rubbish with respect to the last boot.  So there is nothing sensible to set the clock _to_
<ogra> yeah
<dmart> All e2fsck can do is set the fs mount time to, er, rubbish
<ogra> which it does atm
<thebishop> hello!
<dmart> Better to treat the fs as clean if this is the only error, and not change anything imho
<thebishop> is the Power Management config app an Ubuntu project, or Gnome?
<ogra> right, though i'm not sure how the journal will end up in this case
<ogra> it might get confused which in turn will give you an inconsistent fs
<ogra> because once your network is up your clock is set again
<dmart> I think the journalling uses a serial number system, in which case dates and times only exist at a higher level of abstraction.  (I could be totally wrong about that one though... 2 mins reading jbd.h != wisdom)
<dmart> NTP already warps the clock if the network time isn't the same as the system time (questionable whether is should... but it's handy)
<ogra> well, i didnt look at code at all yet, relying on Keybuk here who told me timestamps are used in the journal
<squirrelpimp> thebishop, there are several available but usually the are provided by your deskop environment (KDE, Gnome, XFCE)
<dmart> ogra: could be right... I should do more homework
<thebishop> squirrelpimp, i see.  So I should ask #gnome@irc.gimp.org to submit modifications to that piece?
<squirrelpimp> well, if you're using gnome, then "yes" :)
<dmart> ogra, mind you, the journal is recovered _before_ e2fsck gets to run, so if it really does rely on timestamps, you've already lost by this stage
<ogra> yeah, which is why i focused on the clock with my workarounds
<thebishop> squirrelpimp, got it, thanks
<ogra> (guessing you have seen my script on the bug)
<dmart> yep, vary sneaky ;)
<DktrKranz> pitti: I created a branch to be eventually merge syncpackage script into ubuntu-dev-tools. your version didn't have any copyright notice, I temporarily used GPLv3 pending your comment. Is it fine for you, or do you prefer something else?
<pitti> DktrKranz: fine for me
<DktrKranz> ok, thanks!
<OdyX> Okay. I filed bug 564353 and bug 564695. Ball's on your side now.
<ubottu> Launchpad bug 564353 in usb-modeswitch "usb_modeswitch crashes with Sony adapters" [Undecided,Fix committed] https://launchpad.net/bugs/564353
<ubottu> Launchpad bug 564695 in usb-modeswitch-data "Sync usb-modeswitch-data 20100322-2 (universe) from Debian squeeze (main)" [Wishlist,New] https://launchpad.net/bugs/564695
<seb128> doko__, chrisccoulson: is bug #561124 fixed now or does it still require firefox changes?
<ubottu> Launchpad bug 561124 in openjdk-6 "firefox sets LD_LIBRARY_PATH which breaks the icedtea6-plugin" [High,Fix released] https://launchpad.net/bugs/561124
<doko__> seb128: I have a workaround for the plugin, but IMO other plugins could be affected as well. so maybe remove the milestone, but keep the report open
<seb128> doko__, ok, I was checking for the r-t meeting today, thanks
<joaopinto> mvo, ping, new bug on upgrade
<mvo> joaopinto: ok
<mvo> joaopinto: on the phone, but I will read backlog
<joaopinto> E:Unable to correct problems, you have held broken packages.
<joaopinto> I don't have broken packages afaik
<mvo> joaopinto: amd64?
<joaopinto> yes
<joaopinto> Package plymouth has broken Depends on udev
<joaopinto>   Considering udev 23 as a solution to plymouth 10011
<joaopinto>     Reinst Failed because of initramfs-tools
<joaopinto>  Try to Re-Instate udev
<mvo> ok. sort of known
<joaopinto> not sure if this helps, tail from apt.log
<mvo> transient
<joaopinto> need to way for something to be built ?
<joaopinto> wait
<persia> Essentially, yes.
<persia> Or be published, or be mirrored, etc.
<joaopinto> ok thanks
 * kirkland high fives pitti
<kirkland> pitti: i do everything i can to keep up with you :-)
<kirkland> pitti: but you're just a friggin machine!
<pitti> kirkland: I was just going to say the same about you!
<nigelb> ccheney, do you have any more thoughts for bug 512395? there is a new patch for it
<ubottu> Launchpad bug 512395 in openoffice.org "Openoffice.org's .desktop files do not contain translation domain info" [Undecided,New] https://launchpad.net/bugs/512395
 * ccheney sees if he can get OOo working for hardy now
<soreau> Hello. I'm having trouble figuring out which package provides the files in /usr/local/lib/python2.5/site-packages/ccm/* on karmic. I tried apt-file and packages.ubuntu.com but I can't seem to figure it out
<Daviey> pitti: Have you spoken to superm1 about bug 563053 - mythtv?
<ubottu> Launchpad bug 563053 in mythplugins "Please remove Mysql 5.0 from the archive for lucid." [Undecided,In progress] https://launchpad.net/bugs/563053
<nailor> git-svn does not seem to work with the latest git. there no git-svn binary seems to be in the path at all. can somebody confirm this?
<pitti> Daviey: not on IRC yet, just on the bug
<Daviey> pitti: Okay, i know he's busy with a few things at the moment - so if you want to reassign that to me, that would be great.
<pitti> Daviey: oh, great; please feel free to just assign to you yourself
<pitti> Daviey: I should probably have assigned it to mythbuntu-dev, right?
<Daviey> done
<Daviey> pitti: yeah, that would be good i guess for future :)
<pitti> but I didn't want to break mythtv behind your back by removing it now
<pitti> but we really should remove 5.0 from lucid
<pitti> Daviey: noted for the next time
<Daviey> full agree :)
<Daviey> +y
<Daviey> Doing a local build now, will push it if it works. :)
<joaopinto> mvo, the upgrade to lucid was now successful, thanks for the quick fix
<mvo> joaopinto: cool
<mvo> thanks for verifying
<micahg> jdstrand: can I poke you about 2 archive syncs?
<jdstrand> micahg: sure, what?
<micahg> jdstrand: phpmyadmin and libnetx-java, I'll grab the bug #s
<micahg> bug 563549
<ubottu> Launchpad bug 563549 in phpmyadmin "Please sync phpmyadmin 4:3.3.2-1 (universe) from Debian unstable (main)" [High,Confirmed] https://launchpad.net/bugs/563549
<micahg> bug 563745
<ubottu> Launchpad bug 563745 in karl3 "Show syslog entries in batches" [Low,New] https://launchpad.net/bugs/563745
<micahg> oops
<micahg> bug 563745
<micahg> ah
<micahg> bug 562745
<ubottu> Launchpad bug 562745 in libnetx-java "Sync libnetx-java 0.5-2 (universe) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/562745
<jdstrand> micahg: phpmyadmin is bugfix only?
<nailor> my bad. it is not supposed to work that way any longer...
<micahg> jdstrand: looks like it from upstream changelog, it also fixes and install issue
<micahg> jdstrand: thanks
<jdstrand> micahg: sure
<pitti> zul: "Rebuild with libmysqlclient15-dev."? that's the one we are trying to get rid of :)
<zul> pitti: meh :)
<zul> pitti: can you reject it so I can fix the changelog
<pitti> zul: (btw, I recommend adding LP: #xxx to the changelog, to avoid having to manually chase down the task closing)
<pitti> zul: rejected; thanks
<zul> pitti: fixed the changelog now
<Keybuk> ogra: I have talked to Ted for you
<ogra> Keybuk, what did he say ?
<Keybuk> he sympathised, and suggested that maybe broken_system_clock should *ignore* clock errors
<Keybuk> rather than fix them
<ogra> ++
<ogra> Keybuk, thats what dmart suggested too today :)
<ogra> Keybuk, beyond that i'm fiddling with a workaround initramfs script for now (in case you saw my bug comments)
<Keybuk> so consider the bug upstreamed
<ogra> thanks so much !
<cjwatson> Keybuk: bug 534743, I noticed that psusi's branch still just removes "change" which you objected to in comment 4 - did the mentioned discussion he had with you on IRC clarify that at all, and does your objection stand?
<ubottu> Launchpad bug 534743 in dmraid "dmraid causes udev event feedback loop in Lucid" [High,Triaged] https://launchpad.net/bugs/534743
<Keybuk> cjwatson: I don't have the context for that
<Keybuk> but I have a vague feeling I may have decided not to care about dmraid being broken ;)
<Keybuk> so if psusi wants to patch it, he can <g>
<cjwatson> I'll talk with him about it when he next shows up, then
<didrocks> slangasek: you assigned me bug #522858, didn't you see my comment at https://bugs.edge.launchpad.net/ubuntu/+source/maximus/+bug/522858/comments/7 ?
<ubottu> Launchpad bug 522858 in maximus "Sometimes app windows come up undecorated, unselectable, and not full screen" [High,New] https://launchpad.net/bugs/522858
<ubottu> Launchpad bug 522858 in maximus "Sometimes app windows come up undecorated, unselectable, and not full screen" [High,New]
<didrocks> asac: who can I reassign it in your team? (bug #522857 and #522858). The efl launcher should be in cause there as I don't have this behavior on the 3D one and not sure I currently have time to invest on efl launcher :)
<ubottu> Launchpad bug 522857 in cwiid "X crash" [Undecided,New] https://launchpad.net/bugs/522857
<ubottu> Launchpad bug 522858 in maximus "Sometimes app windows come up undecorated, unselectable, and not full screen" [High,New] https://launchpad.net/bugs/522858
<asac> didrocks: i think the undecorated is bug soemthing we can take back. assign it to JamieBennett
<nxvl> slangasek: can you please take a look at Bug #564190 if you have time
<ubottu> Launchpad bug 564190 in terminator "Update Terminator to 0.93" [Undecided,New] https://launchpad.net/bugs/564190
<asac> didrocks: the focus thing i would really love to get your idea on
<didrocks> asac: thanks :)
<didrocks> asac: I can try next Monday to get some trace on maximus
<didrocks> (maybe the two things are related)
<asac> could be yeah.
<sistpoty|work> nxvl: does terminator build, install and work fine?
<nxvl> sistpoty|work: yup
<nxvl> sistpoty|work: in my chroot works fine
<nxvl> sistpoty|work: want me to upload to my ppa first?
<sistpoty|work> nxvl: only in case you haven't done a test-build yet ;)
<nxvl> heh
<nxvl> :P
<nxvl> i've
<nxvl> and it's on the prosess to get sponsored to debian already
<sistpoty|work> nxvl: approved then, go ahead
<sistpoty|work> excellent!
<nxvl> \o/
<nxvl> Ng: ^^
<Ng> \o/
<Ng> thanks very much folks
<Ng> as much as I like cutting a juicy bugfixing release, I hope that's about it for bugs for now ;)
<nxvl> :D
<nxvl> we all hope
 * persia takes that as an invitation to hunt and file more
 * sistpoty|work files a bug against persia :P
<persia> sistpoty|work: Actually, all the stuff I want in terminator would fall into "New Feature" and so be unsuitable for lucid anyway (e.g, better screen integration, memory of window sizes in layouts, etc.)
<sistpoty|work> heh
<Ng> persia: I really want to fix as many bugs/regressions as I can, but if the flow slackens off then I have time to start knocking out the sane wishlists and pushing for 1.0, then fame, glory, riches and retirement ;)
<persia> Ng: heh, yeah.  But from what you write above, it sounds like you're getting close to catching up on bugs/regressions.
<persia> (and thanks for that: it's an immensely useful tool that has massively improved my workflows)
<Ng> persia: I hope so. the unfixed bugs at this point are, afaict, weird interactions between different gtk/pygtk/vte versions
<Ng> if I had an interactive test suite I could automate finding them with VMs of different distro versions :D
<Keybuk> cjwatson: Val's giving a talk about VFS Union Mounts now ;-)
<persia> Ng: If it's accessibility-enabled, mago ought be able to do most of that.
<Ng> persia: yeah I really want to poke at ldtp to see if I can make a functional test suite. Maybe I can beer my way to some tuition from a QA person at UDS ;)
<persia> Ng: There's a good chance of that :)
<slangasek> didrocks: it came up for discussion in the release meeting and your name came up - no, I hadn't seen your comment, sorry :)
<didrocks> slangasek: no pb, fixed with asac :)
<psusi> Keybuk, two questions for you... 1) does ureadahead open() all of the files first to get the inodes and any directory blocks needed to be read and out of the way before calling readahead(), and 2) is there a tool to do the leg work of translating the block numbers in the blktrace to file names for me?  manually using debugfs is getting real annoying ;)
<Keybuk> psusi: bzr branch lp:ubuntu/ureadahead
<psusi> hehe... getting that and the kernel sources now... after looking at the blktrace it looks like sometimes ureadahead only queues a few reads that may span a few files, and other times it queues up to read_ahead_kb, which I increased from 128k to 64mb, so it queues a WHOLE Lot in one burst, then blocks until it all finishes while it waits for a directory block to be read
<kenvandine> slangasek, i am going to upload ubuntuone-client with a patch reverting that string change
<psusi> I've got one huge burst where it fills the queue very deep with sequential reads, and the disks spinf full titlt, then it goes haywire... this is after having defrag pack all the files ureadahead wants at the start of the disk
<slangasek> kenvandine: great, thanks
<Keybuk> psusi: bzr branch lp:ubuntu/ureadahead
<kenvandine> slangasek, ok, ubuntuone-client uploaded again, make sure you approve the latest one :)
<psusi> ohh, interesting...  * So an mpage read of the first 16 blocks of an ext2 file will cause I/O to be submitted in the following order:  12 0 1 2 3 4 5 6 7 8 9 10 11 13 14 15 16.  e2defrag lays out the blocks 0-11, then the indirect block.  sounds like it should lay out the indirect block first
<psusi> ohh, nevermind... comment further on says they correct that ;)
<zyga> hello
<bryceh> slangasek, brian murray found a pretty nasty performance bug with the latest -ati 6.13.0 update - bug #564181
<ubottu> Launchpad bug 564181 in xserver-xorg-video-ati "[RV730] GPU soft reset infinite loop scrolling in firefox with compiz" [High,Triaged] https://launchpad.net/bugs/564181
<bryceh> slangasek, in investigating it, I've found that upstream slipped in a bunch of performance optimization changes right prior to 6.13.0 which seems to have caused some performance regressions, including this one as brian's testing confirmed
<bryceh> slangasek, given that we're in final freeze, my conservative reaction is to revert all those performance changes
<bryceh> slangasek, in parallel it appears Sarvatt felt similarly since he prepared the patches to revert all of it - http://sarvatt.com/downloads/radeon/
<bryceh> slangasek, pulling this set of changes out gets us down fairly close to the .192 version we had tested fairly heavily which would give me a good deal of confidence
<bryceh> slangasek, however since this would be a pretty hefty amount of change to -ati in FF, I wanted to run it by you first for sanity checking.
<bryceh> slangasek, the other option would be for us to stick with what we've got and wait for upstream to come up with fixes and sru them in.
<bryceh> the only concern I have with that strategy is that maybe there are other performance bugs hiding in this new code.  Honestly, this seems like the sort of changes which should *not* have gone in right before a release.
<nosse1> Hi guys. How is lucid going? E.g. I'm considering upping my amd64 to karmic on my work laptop. Is it stable enough to try (please, I do know it's beta)?
<nosse1> s/karmic/lucid/
<ScottK> nosse1: If you have to ask, the answer is no.
<nosse1> ScottK: It depends. When I was working on Debian, beta 2 didn't usually mean that the sw were bad. It was just the stability of the package system (dep's and such) which were going up and down
<ScottK> nosse1: It's ~probably OK, but if you  can't afford a few days of broken, I wouldn't advise it.
<nosse1> ScottK: So I hoped lucid were like "The SW is mostly ok, but the pkg system might be broken. wait until tomorrow to recheck"
<ScottK> nosse1: There have been a lot of uploads in the last day or two.  Hard to tell.
<nosse1> ScottK: If so, I'll jump in and help to discover issues :D
<ScottK> If you aren't running i386 I would definitely not upgrade now as archive skew will get you almost for sure.
<nosse1> ScottK: Even on amd64?
<ScottK> nosse1: It's less behind, but it's still behind.
<ScottK> So you can end up with arch all bits and amd64 specific bits of packages out of sync.
<ScottK> My predcition is that by tomorrow amd64 will be caught up.
<nosse1> Yeah, I see there's 28 waiting jobs in the build farm
<psusi> aha!  readahead() blocks to read the indirect block.... damn... I guess I have to get extents working
<micahg> mvo: ping
<mvo> micahg: pong
<micahg> mvo: we have an issue that app-install-data is using the firefox.desktop file from kubuntu-firefox-installer instead of firefox-branding, is there a way for multiple packages to have the same name for a .desktop file ATM or do we need to get the kubuntu-installer updated?
<Riddell> kubuntu-firefox-installer shouldn't be in app-install-data
<Riddell> probably needs some exception somewhere to be told that
<Riddell> cjwatson: I was able to recreate bug 563309 :(  logs attached
<ubottu> Launchpad bug 563309 in ubiquity "ubiquity crashes on manual disc setup" [High,Confirmed] https://launchpad.net/bugs/563309
<cjwatson> Riddell: evan committed a patch earlier today ...?
<cjwatson> Riddell: ubiquity r4095.  maybe wowrth testing if you can reproduce it?
<cjwatson> -w
<Riddell> cjwatson: tsk, I should refresh my bugs before commenting :)
<cjwatson> I haven't looked at the bug myself yet TBH
<mvo> micahg: uh, I could manually fix it up, but currently that is not possible to have multiple ones
<mvo> micahg: the extractor is not very smart
<micahg> mvo: is there a way for packages to exempt themselves from app-install-data ATM or is there an exception list in the data package itself?
<micahg> mvo: per Riddell kubuntu-firefox-installer shouldn't be in there
<micahg> mvo: also, should I file a feature request to support multiple .desktop files w/the same name
<mvo> micahg: I can do that via a manual blacklist
<micahg> mvo: k, should I file a bug and where?
<mvo> micahg: I added it now, I need to re-run the extraction, that will take a while
<micahg> mvo: thanks, so, is it worth the feature request for multiple .desktop files w/the same name or should that normally be not done anyways
<mvo> micahg: yeah, lp:~mvo/archive-crawler/mvo is the thing that is currently doing it
 * mvo runs a update
<micahg> mvo: k, thanks
<cjwatson> sbeattie: can you reproduce bug 558382 on demand?
<ubottu> Launchpad bug 558382 in debian-installer "Partitioner throws "Unable to satisfy all constraints" when trying to use previously created partitions" [Medium,Confirmed] https://launchpad.net/bugs/558382
<cjwatson> sbeattie: if so, I might like to have you do some rather detailed debugging
<joaopinto> on the boot process when rescue mode is selected is plymouth still used somehow ?
<joaopinto> what could causing an hang immediately after a successful mountall using rescue mode ?
<sbeattie> cjwatson: I think I can but it'll take some time.
<ScottK> joaopinto: You can't boot without plymouth.
<cjwatson> sbeattie: that's OK, I'm still working through the maths
<cjwatson> I hope to be able to figure it out on my own, but I'm not certain ...
<joaopinto> ok, so after mountall it's likely to be upstart or plymouth related right ?
 * ScottK is not the Scott you are looking for ....
<joaopinto> it's kind of frustrating to see an user trying to boot for several hours and not have the know-how to help him :\
<Keybuk> plymouth probably
<joaopinto> Keybuk, how can we debug it ?
<Keybuk> root shell alongside
<psusi> neat... ureadahead is smart enough to figure out what block groups the inodes of the files it's reading are in, and has e2fslib go read the inode tables for those groups off the bat so they are already in memory when needed by open().... slick... now this blktrace is making much more sense
<Keybuk> psusi: that's because the author of ureadahead is a genius
<joaopinto> Keybuk, is it described somewhere ? (I don't want to bore you with trivial questions)
<psusi> hehehe ;)
<Keybuk> joaopinto: the "open vt" trick on upstart.ubuntu.com/wiki/OMGBroken is the one I use
<psusi> Keybuk, I also figured out that readahead() can block.. if it needs to read an indirect block... I need to get rid of those now... but first i need to figure out this big gap of no io in the middle of the ureadahead...
<cjwatson> psusi: so this dmraid bug - it wasn't entirely clear to me from the bug log.  are you and Keybuk now agreed that it is harmless to leave out change events from the rule?  that's my understanding from having gone back and trawled IRC logs, but I wanted to check
<Keybuk> psusi: does fadvise make any difference?  I tried it but couldn't tell
<psusi> Keybuk, I think it's basically the same code in the kernel, though I didn't specifically check that sys call, most of the code I read had comments indicating it was used by both
<Keybuk> right, that's what I thought
<Keybuk> which means one of the man pages is lying about always blocking or always not blocking ;)
<psusi> Keybuk, it tries very hard to queue bios for the largest reads it can, but it doesn't know where the blocks are until it reads the indirect block
<Keybuk> I suspect, since fadvise came later, the readahead man page is wrong
<Keybuk> bear in mind, of course, that ext4 doesn't have indirect blocks
<psusi> so it has to wait until the indirect block is read before it can queue reads for the blocks it maps... at least if the file is > 11 blocks
<psusi> yes... I'm using -O ^extents right now though because I have not yet got e2defrag to understand them
<Keybuk> right, I think that the e2fs inode group preloading is supposed to get those into memory too
<Keybuk> but you never really know
<psusi> once I do that, then readahead() should generate one quite bio to read the whole file, stick it in the queue, and return... so eventually ureadahead should exit and upstart will move on to mountall while most of the reads are still in the queue
<ccheney> grr ooo-l10n backport test build is taking forever :-\
<psusi> cjwatson, I dunno, have to ask Keybuk ;)
 * psusi wonders wtf shorted out in his brain that made him type quite bio
<Keybuk> psusi: once you do what?
<cjwatson> 17:06 <Keybuk> so if psusi wants to patch it, he can <g>
<Keybuk> oh, you mean once you get defrag to work?
<psusi> Keybuk, get e2defrag understanding extents
<Keybuk> yeah that should turn ureadahead into a bunch of calls that result in ONE VERY BIG READ
<psusi> yea... extents is the last of the new ext4 features I don't have it working with yet
<Keybuk> I appear to have put cjwatson on ignore
<cjwatson> psusi: I just wanted to make sure that you'd considered the stuff in comment 4 on that bug, and explicitly rather than implicitly disregarded it :-)
<Keybuk> I have no idea how I did that
 * cjwatson pouts
<psusi> exactly... one very big async read that completes in the background after ureadahead returns and upstart moves on
<Keybuk> psusi: extents is basically *the* ext4 feature though ? :)
<Keybuk> though doesn't the defag currently in e2fsprogs deal with them?
<psusi> Keybuk, yep... I should have it working in a few more days
<cjwatson> this is a very tedious form of debugging
<psusi> you mean the still experimental and unshipped e4defrag?
<Keybuk> yes
<cjwatson> /nick cjwatson-running-gdb-in-my-head
<psusi> yes, since it uses ioctls to manipulate the blocks though the mounted filesystem rather than on the raw block device
<psusi> though it just defragments files by allocating a new file, checking if that is contiguous, and atomically swapping the blocks as far as I have read
<psusi> doesn't pack files, or defragment free space
<psusi> the nice thing about the old e2defrag is that you can feed it a list of inodes to give higher priority to so it packs them together at the start of the disk
<psusi> i.e. the list from ureadhead.pack
<psusi> though I had to kind of hack it to force blocks there instead of allocating from their native block group first... I need to clean up that patch and probably add a switch to enable/disable it
<psusi> cjwatson, what was that bug# again?
<Keybuk> cjwatson: sounds like my life ;)  gdb -p 1 ... FAIL
<cjwatson> psusi: bug 534743
<ubottu> Launchpad bug 534743 in dmraid "dmraid causes udev event feedback loop in Lucid" [High,Triaged] https://launchpad.net/bugs/534743
<tedg> slangasek: Howdy.  I have a patch for indicator-application which renames a binary package.  Is that okay?  bug 564506
<ubottu> Launchpad bug 564506 in indicator-application "libappindicator-cil-dev's .pc file points to the wrong place" [Critical,Triaged] https://launchpad.net/bugs/564506
<psusi> cjwatson, yes, as far as I know, there is no sensible situation where a change event on the underlying disk would occur and dmraid would care... it just needs to notice when the disks are added and scan them
<psusi> cjwatson, and to get my system running I had to remove the |change and have not had any issues with it since
<cjwatson> GrueMaster: bug 564992 - isn't this an arm platform, in which case dmidecode is unavailable?  the installer syslog is generally the useful thing
<ubottu> Launchpad bug 564992 in debian-installer "Debian installer fails to properly detect Marvell Avenger development platform" [Undecided,New] https://launchpad.net/bugs/564992
<cjwatson> GrueMaster: (and if so, the Ubuntu armel porters might be better-placed to work on it)
<psusi> by the way, that upgrade I did a bit ago took AGES... we didn't get that bad sync() a million times dpkg patch again did we?
<cjwatson> different one
<cjwatson> apw tested it on ext4 and it didn't slow down unpack all that badly
<psusi> ok, so what sucky thing does this one do? ;)
<cjwatson> oh sod off
<cjwatson> it's a Friday evening
<psusi> hehehe
<cjwatson> be polite or I'll do something else
<cjwatson> sorry but not feeling up to this
 * psusi passes cjwatson a cold one
<cjwatson> have a look at the dpkg 1.15.5.6ubuntu4 diff if you like
<cjwatson> I'm interested in data if it is slow, but I would greatly prefer it not come with attached vitriol
<psusi> sigh... guess I'll have to... took a good 5-10 minutes to update on my ssd
<psusi> used to take maybe 1 min
<cjwatson> and with no fsync at all, we know that some people end up with zero-length files
<psusi> you mean if their system crashes?
<cjwatson> yes
<cjwatson> we have to do something, that isn't an acceptable failure mode
<psusi> true... but a huge slowdown isn't either
<cjwatson> depends how huge
<cjwatson> Keybuk's one hour to unpack linux-headers was unacceptable
<cjwatson> in between, there's some room for manoeuvre
<Keybuk> actually, I did notice a slow upgrade this morning ...
<cjwatson> what dpkg now does is to batch up all the fsync/renames for a package and do them at the end of its unpack
<Keybuk> but hadn't had enough coffee to think about it
<mrenouf> How do I use git-buildpackage with pbuilder?
<psusi> ok... so it's not quite as bad, especially on packages with lots of files.... but still quite a hit flushing between each package when upgrading a number of packages
<Keybuk> but there's also a fine line here between YES! FASTER! HARDER! and HURT ME! MAKE ME BLEED!
<cjwatson> something like comparative unpacks of a single package with dpkg 1.15.5.6ubuntu3 vs. 1.15.5.6ubuntu4, and then also strace -tt of each, would be useful
<psusi> would be much better to save all of the flushing and renaming until after all packages are unpacked
<Keybuk> it's all well and good unpacking packages really fast, but we kinda need them to stick to the disk
<psusi> and should still be safe, no?
<cjwatson> if dpkg deferred all the renames very much further, it would substantially impair reliability of the packaging system as a whole
<psusi> how so?
<cjwatson> because it would mean that we'd go from having the new files available immediately after unpack, to having the old files or none available immediately after unpack until very much afterwards
<cjwatson> it would not remotely surprise me if that broke a load of stuff
<psusi> why is that a problem?
<cjwatson> feel free to try it, then try a dist-upgrade, and see :-)
<cjwatson> but my instincts tell me that it will be a problem
<psusi> nothing should need the new files until after ALL of them have been unpacked no?
<cjwatson> sadly, it isn't that simple
<Keybuk> no
<Keybuk> that's not the behaviour of dpkg
<psusi> it's only then that you start doing any configuring and such right?
<psusi> for configure they have to be in place, but doesn't dpkg unpack all, then configure all?
<Keybuk> not when pre-depends and conflicts get involved
<cjwatson> in practice, there are a number of cases even outside the essential set where some files from some packages are expected to be usable to some extent even while unconfigured
<Keybuk> anyway, what you're talking about is very complicated
<Keybuk> so patches welcome *after* the release ;-)
<psusi> cjwatson, yes, but not while not yet unpacked ;)
<psusi> the state of each package does not need to become unpacked until after all of the files have been extracted, THEN flushed and renamed do they?
<cjwatson> I do not want to exercise that part of the packaging system
<cjwatson> besides, it would use a hell of a lot more disk space during unpack
<psusi> true...
<cjwatson> the one thing I'd like is some way for dpkg to know that it doesn't need to bother with fsync, because the filesystem isn't optimised to death for benchmarks, but instead is designed for normal applications
<cjwatson> but that requires kernel cooperation
<psusi> by optimised to death for benchmarks do yuo mean using data=writeback?
<psusi> if using the normal data=ordered this isn't a problem then... well... there is a reason why data=writeback is not the default, not recommended, and known to be dangerous ;)
<cjwatson> and yet there's not a lot we can say when people file bugs saying that their system is now busted
<psusi> sure there is... you busted it... don't use data=writeback
<cjwatson> doesn't work that way
<psusi> if the user is dumb enough to enable hardware write though cashes and disable barriers, there isn't anything the developers can do besides tell them they are an idiot, they were warned not to do that...
<sladen> lock free ring buffers
<jdong> I've dealt with a couple users who enabled data=writeback for their ext4
<cjwatson> for other applications, sure.  but if dpkg breaks then you may not even be able to get back into your system to undo it.  that's unacceptable
<jdong> and had parts of kern.log show up in /var/lib/dpkg/status and all other fun stuff
<jdong> in talking to those users, the best I can get is an admission they followed some sort of HOWTO on "tuning" their filesystems :)
<jdong> so yes, the point is, it does happen
<psusi> cjwatson, first, does this really only happen with data=writeback, or data=ordered too?  if it happens either way then this discusstion is moot, but if it's only with data=writeback, that's the risk they take when they enable that and have been told this can hose your system
<cjwatson> I honestly don't know, and have not put the effort in to finding out
<cjwatson> because I don't think it's OK for dpkg to break either way
<Keybuk> I'm going to start writing a new series of articles called HOWNOTTOs
<cjwatson> sure, it's a filesystem configuration error, almost certainly.  but dpkg is not the place you want to discover it
<Keybuk> I can probably just C&P from ubuntu forums
<psusi> hehe
<ion> keybuk: Helpful workarounds from Launchpad bug report comments should also be good material.
<psusi> personally I'm the kind of person who dose use writeback, no journal, no barriers and hardware write back caches, but I have a UPS and won't be surprised if the whole system crashes and leaves me with an unbootable system
<psusi> good backup policy for the winz ;)
<cjwatson> and frankly, from a user's point of view, Ubuntu should be a unified system.  If we ship the ability to configure a system such that our own packaging system falls over, they won't be blaming the Linux kernel developers or themselves, they'll be blaming us, and all the protestations we make about it not being our fault aren't going to cut much ice
<psusi> so are we going to try and prevent them from doing an rm -fr / too? ;)
<Keybuk> cjwatson: this is why I say we shouldn't support XFS <g>
<cjwatson> psusi: sigh, why does everyone always make this kind of comparison?
<cjwatson> now, performance regressions do not make me happy, but if they're within vaguely reasonable bounds, I'll live with them if they're going to significantly improve reliability
<psusi> hehe, reductio ad absurdum
<cjwatson> if the performance regression makes you sad (and you can reproduce it - it's not something I see so I'm not in a good position to do anything about it), then find a way to achieve both goals
<ion> I donât think --preserve-root is as much for stupid users as for one-letter typos in maintscripts or equivalent things.
<cjwatson> Keybuk: to be fair, XFS has had rename barriers since 2.6.17
<cjwatson> or so I understand it - pretty sure nobody's reported dpkg status files full of \0 on XFS for quite a while now
<psusi> if the problem is specific to data=writeback then maybe dpkg could force a remount to data=ordered
<ion> Iâm under the impr\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0oblem has been fixed quite some time ago, yeah.
<psusi> cjwatson, for testing purposes is there a magic flag I can throw so dpkg WON'T sync?  that way I can get a good comparison
<psusi> dpkg --please-break-my-system ;)
<ion> If nothing else, LD_PRELOAD something that makes syncs dummy. :-P
<psusi> hrm... never tried doing something like that
<cjwatson> psusi: the other changes in ubuntu4 aren't all that performance-critical - just downgrade?
<cjwatson> no, there is no such flag
<psusi> hrm... ok
 * psusi really wishes that btt's seeks output would combine sequential reads into one instead of spitting out 0 distance seeks over and over and over
<Keybuk> cjwatson: not only am I running gdb in my head
<Keybuk> I'm now also running mountall in my head
<GrueMaster> cjwatson: Ok, thanks.  I'll reassign it (if you haven't already).
<cjwatson> GrueMaster: I haven't
<cjwatson> sbeattie: so, having run through a good chunk of libparted in my head (well, with an editor window and a calculator), its algorithms check out :-/
<cjwatson> sbeattie: so I'll probably have to give you debug patches to partman-base and parted to apply, build, and copy into a running d-i image before starting the partitioner
<sbeattie> cjwatson: okay.
<slangasek> bryceh: -ati> so looking at the publishing history, I'd say batch-reverting the performance-related changes to get us roughly to the code base we had for both betas is appropritae
<cjwatson> sbeattie: ... but I think tonight I probably need to fall over now
<cjwatson> sbeattie: I'll stick them on the bug for you?
<sbeattie> cjwatson: that will work.
<bryceh> bdmurray, have you had a chance to test my ppa?  Given slangasek's go ahead I can upload once you verify it does in fact resolve the issue for you.
<bdmurray> bryceh: just rebooted
<slangasek> tedg: indicator-application> yes, seems reasonable here, please go ahead
<bdmurray> bryceh: if I don't respond you'll know why! ;-)
<tedg> Yeah!  slangasek thinks I'm reasonable!  ;)
<tedg> slangasek: Thanks, will do.
<bryceh> tedg, well that's just weird
<cjwatson> psusi: merged and uploaded your dmraid change, thanks!
<cjwatson> (subject to release team approval)
<bdmurray> bryceh: no crashing yet
<psusi> cjwatson, yay!  whew... dodged that bullet
<bryceh> slangasek, bdmurray, ok also got confirmation of the ppa's goodness on #ubuntu-x so I've gone ahead and uploaded it
<bdrung> bryceh: is there something i can do to speed up the fixing of bug #541579?
<ubottu> Launchpad bug 541579 in xserver-xorg-video-intel "[gm45] does not detect monitor on docking station" [Undecided,Confirmed] https://launchpad.net/bugs/541579
<bryceh> bdrung, that's handled by the kernel now with kms
<bryceh> bdrung, so your bug really should be filed against the kernel, not X
<bdrung> bryceh: so i change it from intel -> linux
<bryceh> bdrung, anyway, I would probably forward it upstream, they'll probably want you to test a newer kernel, it'll be fixed there so they'll just close it, so then you go hunting through kernel drm trees for a patch
<bryceh> alternatively you could shut off kms and/or fiddle with it using xrandr and the usual UMS troubleshooting steps documented on the ubuntu-x wiki
<bdrung> bryceh: ok, i will try a newer kernel and/or shut off kms once i get access to this machine.
<slangasek> sladen: why do you have this impression that server doesn't have plymouth installed?  mountall *depends* on it
<bdrung> bryceh: if i disable kms and the bug persist, then i would be a bug in xserver-xorg-video-intel, right?
<slangasek> bdrung: that just means it's a bug in both, I think :)
<bdrung> ok
<bdrung> testing a kernel from the mainline build would be sufficient, wouldn't it?
<bdrung> something like v2.6.34-rc4-lucid?
<slangasek> I dunno
<bryceh> bdrung, no ums and kms each have their own separate code paths for handling outputs.  They are different so it's possible one works where the other doesn't, but they both share common origins so if they're both broken it doesn't necessarily signify anything substantial except that they're both bugged
<bryceh> bdrung, but if ums is *not* bugged then you can use it as a workaround, and it confirms the bug's in the kernel
<bdrung> thanks
<bryceh> bdrung, also be aware even if ums is still buggy, that is not getting maintained any further upstream, and we're carrying it only for fallback purposes and don't plan to fix bugs in it, so if ums doesn't work, don't worry about that, just focus on the kms aspect of the bug
#ubuntu-devel 2010-04-17
<joaopinto> is there a reason for a deboostrap to take 5x more time on lucid than it did on karmic ? mostly on the unpacking phase
<bdrung> bryceh: yes, ums would be only a workaround.
<bdrung> Keybuk: regarding bug #507613: i am not satisfied with the solution. why can't mountall mount the partition once the network is up? udev should help there.
<ubottu> Launchpad bug 507613 in mountall "boot stops due to failed mounting of a sshfs partition" [Undecided,Fix released] https://launchpad.net/bugs/507613
<bdrung> Keybuk: the second issue: pressing S or M does not have any effect.
<Keybuk> oh sorry
<Keybuk> I appear to have confused two bugs
<Keybuk> bdrung: some poor sod got told to add _netdev to their /home I think
<bdrung> Keybuk: i forced a reboot and something strange happend: first it look like it hang. one minute later the prompt asking whether you'd like to continue or drop to a shell appears. i pressed S and M. then the boot proceeds and the desktop appears with a mounted sshfs partition.
<Keybuk> ?
<Keybuk> if you have anything to add to the bug, please add information there
<bdrung> something strange goes on there. i will try to reproduce the behavior
<bryceh> pitti, slangasek, kees: I've added feedback from the three of you to the rootless-x blueprint page:  https://wiki.ubuntu.com/X/Rootless - it'll need further massaging to unify all the ideas, but that can be done post-uds.
<bryceh> meanwhile feel free to elaborate on ideas further on that page
<bryceh> not even really sure if we should still move forward with rootless-x for MM but if we do, sounds like there'll be a fair bit of work to do
<bryceh> since 3 of the 4 of us will be off on other assignments, I phear for kees and raof ;-)
<bdrung> Keybuk: adding _netdev worked.
<Keybuk> bdrung: \o/
<Keybuk> ok, mount man page says you had to have that
<Keybuk> since fuse doesn't imply network
<bdrung> Keybuk: since which release does this option exist?
<Keybuk> err
<Keybuk> sometime in the 1940s I think
<Keybuk> certainly pre-Ubuntu
<slangasek> kenvandine: um... ping
<bdrung> Keybuk: :D
<slangasek> kenvandine: the latest ubuntuone-client upload *still* has the string change in ubuntuone-preferences
<bdrung> Keybuk: thanks for your help
<YokoZar> cjwatson: I just removed libv4l from ia32-libs, you added it a long time ago, but we have lib32v4l now
<bdrung> Keybuk: i updated the ubuntuuser wiki to avoid other user to have the same problem
<Keybuk> schweet
<bdrung> Keybuk: (and for me to not forget this parameter :)
<Keybuk> slangasek: I gardened all the mountall bugs
<Keybuk> can I have a lollipop?
<slangasek> Keybuk: sure!
<Keybuk> now to tell evolution I've read all the comments
<Keybuk> keithp was showing me "notmuch" yesterday
<Keybuk> I have never wanted a piece of software so much
 * slangasek grins
<psusi> Keybuk, I have marked up a bootchart with the area that appears to have almost no IO for about a second that seems to be caused by reading directory blocks during all of the open() calls by ureadhead for reference at http://imagebin.org/93343,
<psusi> Keybuk, I was wondering if it would be possible ot hard link the files in the pack so they can be opend using that name where they all are in one directory
<Keybuk> but then the path lookups wouldn't be cached
<psusi> what happens if the file has multiple hard links?  does ureadahead go with the one that was used to open it when profiling?
<Keybuk> it open()s both
<psusi> hrm... good point
<Keybuk> but only reads blocks once
<Keybuk> there's benefit to getting those directory blocks into the page cache too remember
<psusi> true... but you don't want to block waiting for a single 4kb read to do it...
<psusi> hrm...
<psusi> maybe you could readahead() the directory itself?
<Keybuk> maybe, try it
<psusi> guess I'll have to take a look at the tracing code now... I assume it was written to specifically filter out directories?
<Keybuk> nope
<psusi> hrm... it uses the same system blktrace does to trace?  so wouldn't it see the IO to the directories too?
<Keybuk> no, it uses ftrace
<Keybuk> well, trace_event specifically
<Keybuk> I think blktrace uses something lower
<Keybuk> though cbw
<psusi> yea, it uses debugfs to relay trace events from the kernel
<psusi> hrm... so you didn't have to filter out directories then?  so I guess yuod on't get them... hrm... damn..
<Keybuk> apps don't tend to open() directories <g>
<psusi> ohh, ftrace hooks the system calls of the processes to open()?
<psusi> like with an LD_PRELOAD?
<psusi> wait... no... hrm...
<kenvandine> slangasek, it does?  debian/patches/revert_string_change.patch should be reverting it
<slangasek> kenvandine: oh, it's under debian/patches, how quaint ;)
<kenvandine> :)
<slangasek> kenvandine: right - almost done reviewing, looks good so far
<kenvandine> i didn't do it inline... to make it real clear :-D
<kenvandine> thx
<slangasek> I find this a strange definition of clarity :)
<kenvandine> dpm has asked the translators if they will approve it, so they might want to revert... but i doubt it
<kenvandine> this late
<slangasek> yep
<kenvandine> slangasek, well thx... i gotta go get these kids to bed :)
<Keybuk> slangasek: I can tell I'm going to get distracted by writing a GTK+ interface to notmouch
<Keybuk> notmuch too
<slangasek> heh
<slangasek> Keybuk: bug #537133> if I fix portmap, is there still an outstanding mountall bug?
<ubottu> Launchpad bug 537133 in mountall "mountall issues with NFS root filesystem" [Medium,Confirmed] https://launchpad.net/bugs/537133
<Keybuk> slangasek: I'm not 100% sure yet
<slangasek> ok
<Keybuk> the patch works around the fact he never got SIGCHLD/wait() for the mount pid
<Keybuk> which itself is a bit of an alarm
<Keybuk> so would like a bit more debugging
<Keybuk> need another machine to test NFS roots though, so will have to wait until I'm home
<Keybuk> "Hi robbiew, I went to the Apple store and bought a new laptop because I needed a second one to test a bug while stranded in SF, hope that's ok"
<akgraner> hi all I updated today and all my social from the start accounts are missing from empathy and gwibber, as if I never set them up and when gwibber trys to open I get more than 10 gwibber windows that open then I close them all and gwibber tried to reopen this time opening 5 gwibber windows  :-(
<akgraner> has anyone heard of that happening today?
<slangasek> akgraner: no, but there have been two gwibber uploads in the past two days; perhaps a bug report against that package is warranted
<mhall> I am working on a kernel module which crashes when I try to load it due to some bug. Unfortunately plymouth on this lucide machine seems to be impossible to uninstall without also having forced uninstallation of mountall which seems dangerous. How can I cripple plymouth and just have a traditional pure ASCII VT with no framebuffer? Right now it prevents seen the crash dump, etc.
<mhall> seeing the*
<slangasek> mhall: boot without 'splash'
<slangasek> not that this disables the framebuffer - plymouth isn't responsible for the framebuffer anyway, that's kernel+udev
<mhall> yes but with splash off, the fb driver usually does not load fortunately
<slangasek> not true
<mhall> was empirically the case in the past on other machines for me at least
<mhall> or perhaps it did load, but imperceptibly, and in a way which did not corrupt the dumps
<slangasek> Keybuk: what's your availability this evening?  I'm going to put your new mountall ppa upload through its paces, wondering if I should try to get that done before you vanish for the evening
<Keybuk> slangasek: I'm going to vanish in 43 minutes
<slangasek> ok
<slangasek> doubtful I'll have anything meaningful to report by then :)
<Keybuk> I'll be back sometime later
<Keybuk> unless I end up down the Castro ;)
<slangasek> heh
<psusi> god damnit... can't call readahead() on a directory fd... think it fails because directories don't get a mapping
<mhall> psusi: what about madvise / mmap?
<mhall> psusi: i suppose mmapping directories would not work
<mhall> that's an annoying problem
<psusi> yea, mapping doesn't work and it looks like the implementation of readahead() requires a mapping
<mhall> psusi: d'oh
<psusi> at least in the pagecache
<psusi> and it looks like directories don't get pagecache mappings maybe?  not sure but that's where I see the code path returning EINVAL
<mhall> psusi: it seems like the sort of thing which would be important for usenet, mail, etc.
<mhall> psusi: typical Linux, implement something nice, but leave half of it totally broken for no clear reason. :D
<Keybuk> someone is having a barbecue nearby, the smell is wafting into my room
 * mhall barbecues plymouth
<Keybuk> fortunately I'm going to a Churrascaria tonight
<ion> Well, cat directory might as well output a bunch of struct dirents. :-P
<slangasek> mhall: so does booting without 'splash' not let you see the crash dump?
<mhall> slangasek: problem is, i removed all instances of splash from /etc/default/grub
<mhall> slangasek: yet it keeps getting reintroduced on every update-grub
<mhall> slangasek: and it is unclear what thing is reintroducing it... rww was assisting in main #u and was likewise baffled
<psusi> read() refusing to work on a directory is fine, as is requiring O_DIRECTORY for open() to work on one ( doesn't seem to actually be required anymore ) but damnit, you should be able to readahead() the thing ;)
<slangasek> mhall: it's being reintroduced *to /etc/default/grub*?
<mhall> slangasek: reintroduced to the grub.cfg, sorry should have been more precise
 * psusi wonders how the hell directories aren't mapped into the page cache... you'd think that would be rather large performance booster
<mhall> psusi: i'm kind of horrified to hear it actually
<mhall> psusi: perhaps they rely on the inode caching instead?
<psusi> you mean dentry? yea, I guess so...
<mhall> maybe they do not expect people to low-level hack on the directory FD
<mhall> i mean, once you run 'find' on a dir, any operations inside or on the inodes there do go faster
<mhall> so something is getting cached
<psusi> yea but the kernel has to read the directory to parse the entries... it should just have it mapped in the page cache for easy access and caching....
<psusi> well there is the dentry cache
<psusi> once you namei() to translate a file name to an inode, that gets cached in the dentry cache
<psusi> but you'd thing multiple nameis on files in the same directory would reuse the cached directory block... hrm..
<mhall> psusi: perhaps because the pagecache is not a very efficient structure for holding dentries
<mhall> psusi: maybe it makes more sense to store them in another way
<psusi> well yea, the dentry cache is good, but while adding entries to the dentry cache you have to parse the raw directory... doing that should not require reading the block from disk every time... it HAS to be cached
<mhall> but, let's say you read the dir, and push them all to the dentry cache
<mhall> seems redundant to store the backing data in page cache eh?
<psusi> yes but names only get put in the dentry cache when you try to open them
<mhall> hmm
<psusi> or stat...
<mhall> so the block itself does not get cached anywhere
<mhall> that's bad
<mhall> so every new dentry from there needs to reread the block
<psusi> it must be somewhere, just not in the usual pagecache way....
<mhall> *facepalm*
 * psusi reads more code
<akgraner> slangasek, I'll file a bug just checked with some folks in my LoCo team they are having issues as well with empathy and gwibber - they need to be filed separately right?
<slangasek> akgraner: that's best to start with, yes
<akgraner> alrighty  - thanks
<akgraner> :-)
<Bacta> Hello
<slangasek> Keybuk: mountall still no worky
<slangasek> bryceh: xkeyboard-config> is an assertion that "this is how Windows does it" sufficient for us to change a keyboard layout?  And this layout already has the quotedbl symbol on the 2 key; eliminating the doublelowquotemark entirely means Russian-style quotation marks aren't supported
<slangasek> bryceh: (I'm not surprised to be unable to find a description of Kazakh quote styles on the Internets, but the layouts here include "ruskaz" and "kazrus", which I would expect to support standard Russian orthography even if the quotes aren't used in Kazakh - http://en.wikipedia.org/wiki/Quotation_mark,_non-English_usage#Russian.2C_Ukrainian_and_Belarusian)
<Bacta> Hello
<Bacta> What's a good way to contribute code to Ubuntu?
<Bacta> I have comitted some patches before but they weren't directly related to Ubuntu
<owen1> dpkg shows  2:7.2.245-2ubuntu2    what does the 2: means?
<imbrandon> epoc
<imbrandon> 9.5-0ubuntu1 > 9.4-0ubuntu1 but 9.5-0ubuntu1 < 1:9.4-0ubuntu1
<imbrandon> owen1: ^^
<imbrandon> basicly its used when version numbers get wonky, but its best not to use it at all if possible
<owen1> imbrandon: got it. so if i tell someone to install a version of a package, i should also mention those numbers?
<imbrandon> no
<imbrandon> its only for dpkg
<slangasek> not exactly.  apt also uses it.
<slangasek> so it depends on how you expect them to install the package
<slangasek> if you're specifying a version on the commandline with apt, the epoch must be included in the version number
<imbrandon> ahh my mistake, i thought apt ignored it also, well not ignored but would work without
<cjwatson> YokoZar: thanks, fine by me
<cjwatson> generally if you're describing a version number you should quote the epoch too
<cjwatson> it gets left out of filenames to avoid causing problems with certain tools, that's all
<cjwatson> but it's still part of the version number
<bryceh> slangasek, I didn't really look into it very deeply, if you think it's not right, go ahead and punt out the package.  The patch should go upstream regardless, and if they take it we'll get it eventually.
<slangasek> bryceh: the patch may be correct for the default keyboard variant, but I think it'll regress the variants that are meant to support Russian
<bryceh> I figured since the guy is a Ubuntu translator for that language and submitted a patch to change it, he knew what he was saying, but perhaps he didn't
<slangasek> bouncing the package, then
<nigelb> the kazak keyboard quote bug?
<slangasek> yes
<nigelb> hm, even I was hoping upstream would give us a comment about it
<slangasek> tjaalton: the pam-config integration you've proposed adding to sssd has some problems; the maintainer script integration is missing (calling pam-auth-update --package), and the 'password' entries indicate that password changes will not be possible for users with local-only accounts
<slangasek> tjaalton: and the 'Priority' field doesn't seem to follow the guidelines in https://wiki.ubuntu.com/PAMConfigFrameworkSpec
<slangasek> tjaalton: so I'm rejecting the upload; will follow up to the bug report
<tjaalton> slangasek: oops
<tjaalton> slangasek: if I fix those will you accept it?-)
<slangasek> tjaalton: I would at least consider it; though I'm wary of such changes at the last minute, since the last pam config /I/ wrote broke all kinds of things for users that were only caught after upload, and I wrote pam-auth-update :-P
<tjaalton> slangasek: ok, I could drop that too
<tjaalton> then there would be only real bugfixes in the upload
<slangasek> that would be fine
<tjaalton> alright, will upload it without the pam-config
<matumba> s.
<matumba> slangasek, cause you're talking about pam-auth-update: could you check if i filed bug 564842 against the right package?
<ubottu> Launchpad bug 564842 in samba "Installing winbind causes sudo to behave weird on SIGINT" [Undecided,New] https://launchpad.net/bugs/564842
<tjaalton> i'm having weird problems with winbind as well.. I get the krb ticket but still need a kinit to access my kerberized nfsv4 $HOME
<aburch> Is there an extra channel for backports?  I was wondering why #550880 was not approved yet given that the dependencies are currently broken.
 * antivirtel is back (gone 00:34:03)
<stikonas> I've reported bug #565294 about the broken Lithuanian KDE translations.
<ubottu> Launchpad bug 565294 in language-pack-kde-lt "Plural translations are broken for Lithuanian language" [Undecided,New] https://launchpad.net/bugs/565294
<nigelbabu> !away > antivirtel
<ubottu> antivirtel, please see my private message
<ion> Uh. The private message feature is kind of moot if the bot sends a channel message anyway. :-P
<nigelbabu> ion, not if the original message is around 4 or 5 lines long
<Riddell> stikonas: I've added Ubuntu Translations to that bug report
<Riddell> stikonas: dpm is the guy to poke, give him a ping on Monday if you haven't heard by then
<tjaalton> slangasek: hmm, looks like on shutdown rpc.gssd is killed before the shares are unmounted, making shutdown take several minutes
<wgrant> tjaalton: Kerberized NFSv4 home, or something more sinster?
<tjaalton> tjaalton: yep
<wgrant> Odd -- works fine for me here.
<tjaalton> well, maybe the fact that there are 100 mounted shares has something to do with it
<wgrant> Ah.
<tjaalton> lots of users
<tjaalton> so it's stuck flushing them
<wgrant> Yep.
<tjaalton> 15:11 < tjaalton> tjaalton: yep
<tjaalton> wtf :)
<joaopinto> is it plymouth do the KMS mode switch ?
<joaopinto> argh, Canonical ppl shuld work on the weekends :P
<ircipimp> hi
<ircipimp> i'm still troubleshooting the nomodeset issue, since i'd like to have some "acceptable" boot process using fglrx. yesterday i was recommended using "nomodeset", but still the splash screen looks just like a 8bit magnified version of the standard splash.
<ircipimp> is there a way to force plymouth into text-only mode?
<ircipimp> plymouth-set-default-plugin text as used on fedora doesn't exist on ubuntu and changing the text.plymouth entry in /etc/alternatives doesn't work
<ruthgard> !couchdb
<ruthgard> !ubuntuone
<ubottu> Ubuntu One is a service where you can back up, store, sync and share your data with other Ubuntu One users - For more see https://one.ubuntu.com/ support and help available at #ubuntuone
<jdong> at what stage of initramfs is plymouth supposed to draw a splash
<jdong> on my nvidia system, it seems like the splash only shows up after the root mounts
<jdong> and barely stays on the screen for 2 seconds before X starts
<jdong> (but there is 5 seconds or so worth of blank blinking cursor after GRUB before plymouth)
<ion> jdong: Sounds like the expected behavior to me.
<ion> jdong: Not that the behavior is pretty or non-confusing, but thatâs how itâs implemented for lucid.
<kklimonda> yup, plymouth doesn't start from initramfs - it's launched pretty late on purpose (see bug 540801)
<ubottu> Launchpad bug 540801 in plymouth "X server starts before Plymouth, or a very short time after (no or brief splash)" [Low,Triaged] https://launchpad.net/bugs/540801
<kklimonda> there is a nice command one can use to make plymouth start drawing a bit earlier..
<ion> Yes, but itâll make your system boot slower.
<kklimonda> heh
<jdong> ion: ok, gotcha.
<ion> To get a pretty splash sooner, you have to load an assload of stuff before doing readahead, which is a loss.
<jdong> ion: sounds logical -- just wanted to make sure
<ScottK> jdong: OK.  Now that you're sure, go fix some bugs ...
<jdong> lol hehe
<ircipimp> http://pastebin.com/xChbj6D1
<ircipimp> that's the list of packages jockey installs when setting up a brother network printer
<jdong> what's unusual?
<ircipimp> is this expected to happen... the list looks totally bloated to me, thinking that all there's needed was the correct .deb file supplied by brother
<jdong> seems like it installs a QT4 based control panel and the Brother driver is an RPM?
<ircipimp> yes, but it used to be a deb and i'm sure, brother-cups-wrapper-laser is all that's needed, as it used to be under karmic
<ScottK> doko: Would you please look at Bug #542634 and make a recommendation.
<ubottu> Launchpad bug 542634 in zope.security "Add python-zope.security-untrustedpython metapackage" [Undecided,Incomplete] https://launchpad.net/bugs/542634
<ircipimp> i'm unable to select a driver from the printer settings. all possible printers are displayed but the "next" button is grayed out.
<ircipimp> :(
<c_korn> can someone confirm that vino-server consumes a lot of cpu after some minutes ?
<slangasek> matumba: bug #564842 - I'm not sure if that should even be considered a bug
<ubottu> Launchpad bug 564842 in samba "Installing winbind causes sudo to behave weird on SIGINT" [Undecided,New] https://launchpad.net/bugs/564842
<slangasek> tjaalton: oh; should we avoid stopping gssd on runlevel [06]?
<matumba> slangasek, sudo reacts different on the same input depending on the existence of a totally unrelated package - doesn't sound like expected behavior (not that i would consider this anything but cosmetic)
<slangasek> not unrelated at all
<slangasek> winbind is an authentication-related package
<tjaalton> slangasek: how exactly can I test if that'd help?
<slangasek> tjaalton: well, I'm fairly certain it will help you, I'm just trying to think if there's a downside
<tjaalton> slangasek: heh, right
<slangasek> tjaalton: you can test it by editing /etc/init/gssd.conf and changing it to just 'stop on stopping portmap'
<tjaalton> oh, of course
<slangasek> mr_pouit: when updating xubuntu-meta, please use the debootstrap from the current Ubuntu dev release; using the Debian one causes germinate to throw an error for the next person to try to update :)
<joaopinto> is anyone familiar with KMS issues with intel graphic cards, hanging during boot ?
<ScottK> joaopinto: Which Intel?
<ScottK> The i845 experience is known to be "unfortunate".
<tormod> loads of i8xx cards were blacklisted for this in the last kernel
<joaopinto> ScottK, I have been trying to help an user which has been on #ubuntu+1 since yesterday
<joaopinto> bug 565109
<ubottu> Launchpad bug 565109 in ubuntu "Upgrading from 9.10 to 10.04 on Dell Inspiron 6400 makes the system unbootable" [Undecided,New] https://launchpad.net/bugs/565109
<joaopinto> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
<joaopinto> disabling plymouth he was able to boot with an older kernel, that was the best we have achieved
<ScottK> 945 I'm not aware of any major issues.  You might ask in #ubuntu-x.
<ScottK> tormod: I think those were all 845.
<slangasek> I have a 945 and it works fine; I've seen signs that there may be Dell-specific problems with 945+KMS
 * ScottK has an 865 system that is a little fragile, but working not so bad (much better than Karmic)
<slangasek> joaopinto: what happens when booting with 'nomodeset'?
<joaopinto> isn't plymouth the one using the KMS ?
<ScottK> No, it's a kernel option
<ScottK> (as slangasek suggests)
<joaopinto> hum, but how is it invoked ? the loads fine, he gets fine into the initramfs
<joaopinto> so there is something after which invokes the mode set for the graphical mode
<ScottK> joaopinto: To avoid it, add nomodeset to the boot parameters
<joaopinto> slangasek, checking, he did so many things :P
<joaopinto> ok, will do
<slangasek> KMS is "kernel mode setting".  It's /used/ the first time something wants a graphical mode; initially that will be plymouth, after that it'll be X, generally any bugs in KMS will be seen with or without plymouth because plymouth doesn't do anything clever with KMS
<joaopinto> slangasek, ok, like I was thinking, so if we have disabled plymouth, and we are booting into rescue mode, and it still hangs can't be KMS related, or shouldn't be
<slangasek> true
<slangasek> well - depending on what you mean by "disabled plymouth"
<joaopinto> mv /etc/init/*plymouth* /etc/disabled
<slangasek> don't do that
<slangasek> you might be causing a *different* bug if you do that
<joaopinto> however, disabling plymouth makes it boot with 2.6.28, and then it hangs on gdm
 * hyperair wonders if the nosplash option works with plymouth
<joaopinto> slangasek, it was just to be sure plymouth was not the one hanging :P
<joaopinto> and according to some user which disabled like that it works :)
<matumba> slangasek, err, you're obviously right (common-auth...), shame on me. so you think this bug report would rod in lp and nobody would care? if so, i'm fine with closing it.
<slangasek> hyperair: no, 'nosplash' has never been a supported option
<hyperair> slangasek: the lack of "splash" then.
<slangasek> hyperair: we use 'splash' - if you don't want splash, take the 'splash' option /off/
<hyperair> slangasek: so it can be disabled that way. i was just checking.
<slangasek> matumba: probably so - the behavior of pressing ^C at a PAM prompt isn't defined, modules are totally allowed to retry
<joaopinto> slangasek, "nomodeset" did not help, still hanging
<slangasek> hyperair: dropping 'splash' means you don't get a splash screen.  plymouth still runs.
<slangasek> hyperair: because even if you don't want a splash screen, something has to be there to serialize console I/O
<hyperair> slangasek: ah i see.
<slangasek> joaopinto: hanging with a splash screen up, or hanging when gdm starts?
<joaopinto> uff, there should be some easy way to do step by step boot for this problems
<hyperair> slangasek: strange, when we used usplash, it just completely didn't run, or did it? what serialized the console I/O then?
<slangasek> joaopinto: and does the user have all packages up-to-date?
<slangasek> hyperair: nothing, that's why we *got rid of usplash* :)
<slangasek> it was inadequate for the task
<hyperair> slangasek: okay, then why do we need to serialize console I/O? does it make a difference?
<joaopinto> slangasek, yes, he did an update && upgrade with livecd+chroot
<slangasek> hyperair: because in the general case, mountall and cryptsetup both need to talk to the user at boot time, and may each have more than one question, and something needs to arbitrate
<hyperair> slangasek: aah i see. thanks for the info =)
<slangasek> if you don't have plymouth, you have *no* way of talking to mountall
<slangasek> and everybody kinda needs mountall
<matumba> slangasek, it doesn't retry - it just shows the password prompt (as soon as i hit the enter key i'm back at the terminal prompt, even if the pwd was ok)
<slangasek> matumba: oh; then that sounds like a low-prio bug, yes
<hyperair> slangasek: what does the user need to talk to mountall for?
<hyperair> slangasek: wasn't it for the recovery shell and fsck thing?
<slangasek> hyperair: when a fsck fails, you're going to want to talk to mountall
<slangasek> hyperair: or when you can't mount /home because the drive caught on fire, but you still want to be able to boot and recover
<slangasek> or when you misconfigured /etc/fstab and it's waiting for a device in the gamma quadrant before continuing
<matumba> slangasek, i'll edit the description to make that clear - but the package is samba and not pam, right?
<slangasek> matumba: it is *probably* samba, but I would have to dig to see
<hyperair> slangasek: nice descriptions =p
<hyperair> slangasek: i remember being able to talk to both cryptsetup and mountall in karmic, though
<slangasek> do you?
<slangasek> my memories disagree with yours
<slangasek> I remember cryptsetup+mountall in karmic being a total disaster
<slangasek> you could talk to one of them, as long as the other didn't want your attention at the same time
<joaopinto> slangasek, it hangs during text mode, no splash or error is shown
<matumba> slangasek, k, i'll leave it at samba then. thx for your input :)
<hyperair> slangasek: i use cryptsetup on a daily basis. and during the days of 2.6.32, ext4 gave me endless hell. every other time i booted up, mountall failed and i had to run a manual fsck.
<tjaalton> slangasek: turns out that it's just as slow umounting them even with gssd running, so it's something else
<slangasek> hyperair: cryptsetup for the rootfs, or cryptsetup for passphrase prompting post-initramfs?
<slangasek> tjaalton: ok
<hyperair> slangasek: rootfs. i guess that made the difference
<slangasek> hyperair: yep - the initramfs is already serialized for you
<hyperair> ah
<slangasek> so doesn't count :)
<hyperair> i see.
<hyperair> heheh
<joaopinto> btw, we have tried init=sulogin+exec init, it hang on init
<hyperair> i'm glad i had a weird enough setup that avoided this bug =p
<slangasek> hyperair: nah, that's how I'm set up too, but /I/ got to see all the bug reports from people who set up their systems differently.. :)
<hyperair> slangasek: i don't envy you =p
<slangasek> joaopinto: I've tried init=/bin/sh and it doesn't work, I haven't investigated why
<slangasek> joaopinto: "no splash or error shown" - are you booting without 'quiet'?
<joaopinto> I am sure it did that already, re-checking
<joaopinto> I have checked the http://upstart.ubuntu.com/wiki/OMGBroken , it doesn't help much to debug upstart if we can't start it without automatically starting the "hanging" task
<slangasek> joaopinto: if booting with an initramfs, 'break=init' works; you just have to run 'chroot /root /bin/bash' first before doing anything else
<slangasek> (and init= failing is definitely a bug that we should get fixed in Lucid, I've just been too busy fixing the bugs that led me to *need* init= first...)
<joaopinto> slacker_nl, well, booting with init=/sbin/sulogin works, and the / is already mounted
<joaopinto> ops, slangasek
<slangasek> does it?
<joaopinto> it does
<slangasek> interesting
<slangasek> then maybe I just have a local bug
<joaopinto> but then the  "exec /sbin/init" to lunch upstart will hang
<slangasek> hmm
<slangasek> try booting with '--verbose init=/sbin/sulogin'
<joaopinto> --verbose is a kernel option ?
<slangasek> no, it's an upstart option
<slangasek> oh
<slangasek> you could also just do 'exec /sbin/init --verbose' ;)
<joaopinto> ok :)
<joaopinto> btw, it boots fine from the livecd
<joaopinto> slangasek, it hangs after "[    8.672448] EXT-fs: mounted filesystem with ordered data mode" with or without verbose
<slangasek> joaopinto: oh?  this problem *only* happens when booting from disk?
<joaopinto> slangasek, yes
<tormod> joaopinto, try "nohdparm"
<joaopinto> tormod, tomorrow, he is travelling
<joaopinto> luckily he had a lot of patience, has been trying for about 24h
<tormod> joaopinto, well you have a lot of it too :)
<joaopinto> it was a good opportunity to re-learn the boot process, is not very interesting unless you have a problem to identify :P
<joaopinto> after this I may be able to write a wiki page, there is nothing covering the boot process in general, you have one about kernel options, another about upstart, etc, but nothing general to guide
<tormod> joaopinto, that would be awesome
<joaopinto> it needs to cover: bios intro+grub2+kernel+upstart+core tasks: plymouth, mountall, gdm
<tormod> joaopinto, I started on an overview once: https://wiki.ubuntu.com/Booting
<joaopinto> tormod, oh looks great, we just need to continue it :)
<tormod> that page mostly tries to explain how your disk is discovered independently three times after each other :)
<ScottK> nhandler: Would you make me a debdiff out of 564070, suitable for sponsoring?
<tormod> or in fact how this can be thee different disks
<nhandler> Yeah, I can do that ScottK
<ScottK> Thanks.
<mr_pouit> slangasek: hmpf, because it harcodes the debootstrap version somewhere? annoying :]
<mr_pouit> ah right, in debootstrap-version
<c_korn> ok, I think vino-server crashes and it should be reproducible
<c_korn> I filed bug 565633
<ubottu> Launchpad bug 565633 in vino "vino-server consumes 50% of cpu (1 core)" [Undecided,New] https://launchpad.net/bugs/565633
<c_korn> is there a tag I should add to notice that I have a backtrace ?
<chrisccoulson> c_korn - are you sure you just enable remote desktop in vino-preferences? the backtrace shows vino-server got a SIGTERM
<chrisccoulson> incidentally, i can recreate the CPU usage issue when stopping vino-server
<c_korn> chrisccoulson: hm, yes. might be that the cpu consumption started after I stopped it. let me try again.
<chrisccoulson> yeah, it looks like
<chrisccoulson> it
<chrisccoulson> urgh
<chrisccoulson> oops
<c_korn> indeed it crashes on stop
<chrisccoulson> c_korn, yeah, that makes sense. so, i get your issue too
<chrisccoulson> would you mind forwarding that upstream?
<c_korn> chrisccoulson: is there some reportbug script for GNOME bugs ?
<chrisccoulson> c_korn - not that i'm aware of
<c_korn> chrisccoulson: https://bugzilla.gnome.org/show_bug.cgi?id=616063
<ubottu> Gnome bug 616063 in Server "vino-server consumes 50% of cpu (1 core)" [Normal,Unconfirmed]
<chrisccoulson> c_korn - thanks
<c_korn> chrisccoulson: how can I link the upstream bug in LP ?
<chrisccoulson> c_korn - click on "Also affects project"
<chrisccoulson> i just added the upstream link though
<c_korn> chrisccoulson: oh, ok. thanks.
#ubuntu-devel 2010-04-18
<sistpoty> lamont, Laney: I've just given back haskell-src-exts on armel. (build appeared to have been terminated). Hope there's not a good reason to terminate the build
<lamont> sistpoty: all the pegatron buildds are gone - I was waiting for the queue to flush before doing a mass armel giveback
<sistpoty> lamont: ah, ok :)... just hoped that I wouldn't cause a problem like eglibc for sparc ;)
<sistpoty> *glibc* even
<Laney> sistpoty: I don't think it will work â check the Debian status
<Laney> same for pandoc
<lamont> sistpoty: glib2.0
<sistpoty> or that :)
<lamont> mass armel giveback done
<lamont> well, running
<lamont> meh.  1033 builds givenback
<sistpoty> Laney: hm? don't see anything particular?
<sistpoty> lamont: thanks a lot!
<Laney> sistpoty: you don't see all of the ftbfsen?
<Laney> particularly a timeout on armel
<sistpoty> Laney: oh, didn't look at build status, only at bugs
<sistpoty> lamont: is the estimation of ten days on https://launchpad.net/builders/ more or less correct?
<sistpoty> lamont: that would mean we're very close to the border (or even after it) where we need to close the archives for publishing afaict
<lamont> well, lots of them should ftbfs quickly, no?
<lamont> estimation is kinda waggy, but if folks are fixing things, we may want to keep a list of what to bump up
<ScottK> lamont: Your mass giveback should all score at 0, right?
<ScottK> If so, it won't interfere with any uploads.
<lamont> either zero or they get rescored - I can't remember which
<Laney> i'd appreciate the haskell stuff being rescored
<lamont> they're all 0 now, but wouldn't hurt to check back later. IIRC, the job that would rescore them isn't running these days
<ScottK> Ah.
<ScottK> That's why rebuilds haven't been jumping back up.
<lamont> something like that
 * lamont is a bit fuzzy on the details
<wgrant> lamont: you're correct. queue-builder is no longer running, so retries will stick at 0 until someone pokes them manually.
<persia> Is it a problem that they are zero?  most of my requested rebuilds have been running (albeit at low priority)
<wgrant> It probably isn't much of a problem, no. Even ia64 is almost OK now.
<ScottK> I don't think it's a problem, it's just a change.
<lamont> wgrant: if it did its sql queries a bit more granularly, we might let it run more
<wgrant> lamont: The only useful thing it does, though is... nothing?
<wgrant> 1) Bumps score by a few points based on time in the queue. Useless.
<wgrant> 2) Rescores retries. Worse than useless.
<lamont> wgrant: well, it rescores builds so non-buildd-admins can get their builds bumped back up after they retry them... so all in all, I'm not sure I care to do that
<lamont> yeah - 2) is a big -555 from me
<wgrant> 3) Locks thousands of buildqueue rows for aaaages and breaks the world.
<persia> Just out of curiosity, why the mass-giveback?
<lamont> persia: because I stabbed all of haskell after we got ghc6 to build
<lamont> installing ghc6-doc on a pegatron was a great way to generate an infinite loop outside of the timeouts
<persia> Ah.  This makes sense.
<lamont> so rather than find the 100ish packages affected, I just went all 5-blades on the problem
<persia> Makes sense, although I'm expecting a good ~200 of those to ftbfs as they just failed yesterday from a not-quite-so-massive-mass-giveback :)
<lamont> heh. yeah
<persia> I'm also a bit surprised at the number: we only had ~150 showing on the FTBFS page.  From where come the other ~800?  Is it worth a similar mass-giveback of missing binaries for other architectures?
<Laney> I thought haskell was almost done
 * persia too
 * Laney is eyeing agda with suspicion
<wgrant> I'm not sure that buildd-mass-retry.py excludes superseded builds.
<wgrant> So the numbers may be artificially high.
<persia> By 800?
<persia> But anyway, if the point is to throw stuff at the wall and see if it sticks because the builders are bored, it makes sense to me to do other architectures as well.
<persia> (although maybe not ia64, as that likely needs considerable build-dep order unwiding to make sense)
<sistpoty> persia: the idea for haskell is to throw things at the wall to get the next bits of packages back in a buildable state (since the dependency graph is quite complex)
<Laney> Is that how it was done?
<persia> sistpoty: I thought that's why we had http://orangesquash.org.uk/~laney/haskell-installability/armel.png
<Laney> I thought we had just been giving them back individually
<Laney> that's what I've been doing anyway
 * persia specifically excluded haskell from the not-quite-so-massive-mass-giveback beacause of the understanding that they were being done in order
<sistpoty> persia: yep, but there are some false positivis
<wgrant> lamont, persia: Yeah, buildd-mass-retry.py gives back even superseded builds, which explains the vast number.
<Laney> packages which have never built will show up as installable on that graph indeed
<wgrant> When buildd-manager goes to dispatch most of them, it will notice and throw them away.
<persia> wgrant: So the queue should actually process fairly quickly then?
<sistpoty> Laney: up to a certain point, I did, yes. then things became complex since a few buildds failed to install a -doc package (segfaulted there), probably depending on the kernel version
<Laney> sistpoty: I saw that, but I'm not sure why it would happen... ghc6-doc isn't anything special is it?
<Laney> is it some haddock problem?
<persia> It seemed to segfault the old buildds though.
<Laney> or just subarch skew
<wgrant> persia: Indeed.
<persia> I think it was bad silicon.  The old buildds were a collection of experimental boards.
<sistpoty> Laney: no idea, just that it worked in a later rebuild
<Laney> fair
<persia> The new buildds are semi-production development boards from what I understand.
<Laney> you should me-too 527245
<Laney> would have helped us here ;)
<wgrant> Yes, but that's not really easy.
<persia> Needs coding thogh, and wgrant seems to be faily busy doing other incredibly useful stuff :)
<Laney> I never said it was
<wgrant> OK, then "Yes, but that's not really easy, and it's probably not going to be scheduled in the next decade or three."
<persia> heh.
<persia> Anyway, it only takes a couple hours to run thorough all the failed builds and retry the ones that fail for that reason after testing installability.
<persia> Probably less if I could be bothered to script it.
<lamont> Laney: I want to say unimplented instr trap or some such
<lamont> frankly didn't pay much attention to it
<Laney> seems like those machines were on the way out anyway
<persia> lamont: On another porting note: did you get a chance to try doko's fpc debs?
<lamont> not yet, will do
<wgrant> lamont: You used buildd-mass-retry.py for this, right?
<lamont> yep
 * wgrant fixes it.
<lamont> oh, yay
<lamont> fix == ??
<wgrant> lamont: It retries every failed build, even those that are long-superseded.
<lamont> oh, thanks
<wgrant> So the build queue looks huge, but in reality most of those builds will never hit a builder.
<lamont> persia: for future bootstrap requests, note that the standard is to build debs using $whatever, then use those debs to build a chroot to statisfy build-deps, and let LP do its thing with that - so there's always a double-build
<persia> lamont: Right.  Unfortunately, LP doesn't have an edit feature, so I can't ever change that request, but I'll fail to mention it again when we get the next new architecture.
<lamont> heh
<lamont> no worries
<lamont> armel build running
<persia> Cool, thanks.
<persia> With luck, we'll have fpc before the set of stuff that build-depends on it attempts rebuild again :)
<ScottK> Speaking of boot strapping...
<ScottK> lamont: Any thoughts about dealing with eigenbase-farrago and eigenbase-resgen?
<ScottK> At least it's arch all, so it only needs doing once.
<lamont> dunno
<lamont> fire something at rt.ubuntu.com?
<lamont> most notably, wiht instructions that work
<ScottK> Nevermind then.  Whining on IRC is about the most caring I can muster.
<lamont> heh
<lamont> well, throw your whine at rt.u.c and we'll make that the testcase for my docs, then
<ScottK> OK.
<lamont> I'll throw in the extra instr that might be needed.  and yeah, bootstrapping is something that at least needs an RT request
<ScottK> lamont: RT 10582
<lamont> ta
<lamont> thanks, even
<slangasek> ArneGoetje: ttf-kacst-one has a conflict with the version of ttf-kacst we have in the archive; this will make DVDs unbuildable
<ArneGoetje> slangasek: ok, will update ttf-kacst
<slangasek> ArneGoetje: thanks (btw, ttf-kacst-one also had a Recommends: ttf-kacst, which I've gotten rid of)
<Keybuk> the idea of recommends on fonts amuses me
<Keybuk> that's like ttf-arial recommends ttf-times-new-roman just because they're usually used together
<slangasek> "users who like these wingdings also enjoyed..."
<Keybuk> heh
<micahg> thanks for dojo slangasek
<Keybuk> ttf-ms-comic-sans Recommends euthanasia
<slangasek> micahg: thanks to ScottK - I just pushed the button :)
<slangasek> mdke: hi, do you have an ETA for final uploads of ubuntu-docs and gnome-user-docs for 10.04?
<tjaalton> slangasek: am i pushing too far, or should we get the final round of changes from debian xserver & input drivers? :) (xorg.conf.d moved to /usr/share/X11, and allows admins to have stuff in /etc/X11/xorg.conf.d)
<tjaalton> slangasek: the xserver is also an rc for 1.7.7, though we already had most of the relevant bugfixes as separate patches
<ArneGoetje> slangasek: https://code.edge.launchpad.net/~arnegoetje/ubuntu/lucid/ttf-kacst/ttf-kacst-lucid/+merge/23625 and https://code.edge.launchpad.net/~arnegoetje/ubuntu/lucid/ttf-kacst-one/ttf-kacst-one-lucid/+merge/23624
<hunger> Anyone else getting somany "Do not show this message again" buttons in the connect/disconnect notifications that the network connected to is no longer visible since the left side of the notice is pushed off screen?
<hunger> This is in lucid.
<peteris> mdke, here?
<mdke> peteris: hi
<mdke> peteris: yesterday at about 14:30
<peteris> allright, mixed up days :)
<peteris> nevermind
<mdke> peteris: you can send me a po file if it's important
<peteris> well, it's more like 5 ot 6 po files :)
<peteris> and they are in LP
<peteris> mdke, nevermind then, I'm more interested if I could get them in the future 10.04.1 release
<mdke> peteris: we'll certainly do an update this time
<peteris> mdke, you mean on .1 release?
<baptistemm> hello
<mdke> peteris: yes, before that
<peteris> cool
<peteris> mdke, .1 will be propably in the end of Juny, right?
<slangasek> ArneGoetje: you can't delete a file from the upstream source in a package: dpkg-source: warning: ignoring deletion of file KacstOne.ttf
<slangasek> tjaalton: it's pretty late, but I would consider the xorg.conf.d change as time permits if you upload it
<mdke> slangasek: today is the aim
<slangasek> mdke: ok, cool
<joaopinto> slangasek, we have found the issue with that dell upgrade, about 48 h later :P
<joaopinto> "none /proc/bus/usb usbfs devgid=127,devmode=664 0 0" on /etc/fstab caused an error on mountall which somehow leads to upstart hanging
<slangasek> ah, that bug
<tjaalton> slangasek: yep, the server has Breaks and bumps serverminver to minimize any damage
<slangasek> joaopinto: well, that should be assigned to the mountall package, then; I thought there was an open bug report about it, but I don't see it now
<joaopinto> well, it will affect all users which have followed https://help.ubuntu.com/community/VirtualBox/USB
<joaopinto> ok, will do
<slangasek> er, well, that documentation should be fixed then, because /proc/bus/usb doesn't work in 10.04, period
<joaopinto> slangasek, right, but having a system hanging without any clue after an upgrade can't be blamed to that doc
<joaopinto> :P
<slangasek> yes, that part is a mountall bug
<joaopinto> at least now I know how to step by step uptart tasks :)
<joaopinto> I have updated bug 565109 description
<ubottu> Launchpad bug 565109 in ubuntu "Upgrading from 9.10 to 10.04 on Dell Inspiron 6400 makes the system unbootable" [Undecided,New] https://launchpad.net/bugs/565109
<joaopinto> hum, cache ?
<joaopinto> ubottu, refresh
<ubottu> Remember that every time you hit refresh, Canonical is wasting money, bandwidth, and CPU time serving your request instead of doing useful things like uploading the image or paying for ShipIt disks.  Please do so sparingly.
<joaopinto> lol
<tormod> joaopinto, will you paste those step-by-step instructions to a wiki page, please?
<joaopinto> tormod, yes. I am just thinking that it migh worth a different page, that page we have describes the boot process, while this new one would be troubleshoot oriented
<joaopinto> a single page would probably get too long
<tormod> sure, make a new page
<tormod> maybe it eventually should go to the upstream upstart wiki
<tormod> but having such instructions somewhere in any form would be a huge improvement
<joaopinto> hum, is there a good reason for the recovery option to start mountall ?
<joaopinto> it's chain of events is likely to bring problems from which you want to recover from
<slangasek> NCommander, ccheney: OOo FTBFs on armel with a debian/rules bug
<slangasek> dh_gencontrol -popenoffice.org-pdfimport -- \
<slangasek>                 -v1.0+OOo`echo 1:3.2.0-7ubuntu1 | cut -d: -f2`
<slangasek> dpkg-gencontrol: error: current host architecture 'armel' does not appear in pac
<slangasek> kage's architecture list (i386 m68k mips mipsel powerpc s390 alpha amd64 hppa ia
<slangasek> 64 ppc64 s390x sparc)
<slangasek> ccheney: the OOo source package doesn't seem to be in sync with the bzr branch
<slangasek> ccheney, NCommander: I've uploaded what I believe should be a correct fix for the OOo FTBFS - no conceivable way for me to build-test it, but it looks like the new armel buildds can fail to build OOo in < 2 days now...
<sladen> mvo: https://bugs.launchpad.net/bugs/516727  appears still to be an upgrade breaker, even with the update-manager tweaks
<ubottu> Launchpad bug 516727 in openoffice.org "breaks dist-upgrade: E: Couldn't configure pre-depend openoffice.org-core for openoffice.org-filter-binfilter, probably a dependency cycle." [Critical,Fix released]
<wgrant> Odd. My Lucid laptop has been thrashing sometimes lately (no swap), and I just watched it OOM kill several things with well over 2GiB of the 4GiB of RAM apparently used as disk cache.
<wgrant> drop_caches does not reduce that volume :(
<james_w> wgrant: ogra is having similar sounding issues in bug 563879
<ubottu> Launchpad bug 563879 in evolution-data-server "evolution-data-server consumes massive amounts of memory, invokes OOM killer" [Undecided,Confirmed] https://launchpad.net/bugs/563879
<wgrant> Hmm.
<wgrant> wgrant@magrathea:~/launchpad/lp-branches/bug-565739-dont-retry-superseded-builds$ cat /proc/dri/0/gem_objects | grep object\ bytes
<wgrant> That cannot be normal.
<wgrant> -1296973824 object bytes
<wgrant> It also looks like almost 3GB when interpreted unsigned.
<james_w> certainly sounds suspicious
<tormod> wgrant, sarvatt also saw this gem_object wrapping negative
<hyperair> wgrant: that sounds like an ancient i915 bug.
<hyperair> i used to see that.
<tormod> and vish in bug 563400 has more > 1gb gem (on ATI)
<ubottu> Launchpad bug 563400 in xserver-xorg-video-ati "[RV515] Playing flash video causes memory hogging" [Undecided,New] https://launchpad.net/bugs/563400
<hyperair> wgrant: try using a newer kernel and see if that happens
<hyperair> wgrant: also, restarting X should clear this gem_object madness
<tormod> hmm ogra is also using chromium, like vish was
<wgrant> hyperair: It has cleared it, yes.
<wgrant> I had a similar thing around the GEM switch.
<wgrant> But not significantly since.
<wgrant> I don't use Chromium much, but I did use it at one point during that session.
<hyperair> wgrant: so did i. and ever since the bug was fixed upstream, i've used a custom kernel, and have never had this problem again
<hyperair> wgrant: i found that it needed somewhere around one X restart a day, during the time of that problem
<hyperair> wgrant: we're shipping an old DRM stack aren't we?
<wgrant> hyperair: I had to restart X multiple times a day.
<wgrant> But it hasn't been that bad since -- maybe once a week?
<tormod> hyperair, we're shipping a .33.2 drm stack
<hyperair> tormod: weird, i could have sworn .33 had it all fixed..
<wgrant> (this is a GM45, btw)
<hyperair> and mine a 965GM
<hyperair> regression perhaps?
<hyperair> wgrant: there's an option in driconf about buffer object reuse
<hyperair> perhaps that is related?
<wgrant> I guess I should get something to monitor the GEM memory usage and scream if it jumps suddenly.
<wgrant> Although I guess it's more likely to be a cumulative problem.
<hyperair> wgrant: from my experiences during that time, it never jumped suddenly.
<hyperair> something like a terminal open with watch cat /proc/dri/0/gem_objects would do
<wgrant> That is exactly what I've been doing, yeah.
<tormod> the gem objects are allocated all the time, that is normal, but it seems they are not all deallocated
<wgrant> Right.
<tormod> every time I open a youtube fan in firefox and close it again, firefox has grown 2MB, gem count as well. after closing firefox, I got only 1MB back there
<tormod> for t in `seq 1 10`; do firefox ; grep "object bytes" /sys/kernel/debug/dri/0/gem_objects; done # and press ctrl-Q's
<tormod> I can use e.g. eog /usr/share/backgrounds/ instead of firefox
<joaopinto> slangasek, I am still playing with the mountall issue, it seems to be related to bug 553290
<ubottu> Launchpad bug 553290 in mountall "Loops on mount failure when Plymouth not running" [High,Fix committed] https://launchpad.net/bugs/553290
<wgrant> tormod: So it looks like a general thing -- just Flash is really good at it?
<joaopinto> ops, wait, maybe not, this is a side effect of starting the mountall manually, I am hitting this bug
<tormod> wgrant, yes even "xterm" does the job
<tormod> and X does not grow
<joaopinto> I get both a failed mount, and skipping mount
<joaopinto> looping
<wgrant> tormod: Hmm, indeed. That grew the GEM object size by 100MB, and it has not decreased.
<wgrant> At least we can easily reproduce it now...
<wgrant> This really reminds me of the early days.
<wgrant> But I cannot remember exactly when it started happening again.
<tormod> the early days when we had flies amid the vacuum tubes?
<wgrant> tormod: Heh, not going *quite* that far back.
<tormod> you can also track it here: awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names
<wgrant> Which are we treating as the One True Bug?
<tormod> none I think , they are all blaming different things. the "-ati" bug even got "fixed" by an ati release, then reopened
<wgrant> Yeah, I saw that...
<wgrant> Anyway, I'm sort of glad that I'm not alone and/or crazy.
<vish> yay ,I'm not alone.. :p
<vish> wgrant: so the bug is actually in which package?  Bug 563400 is not -ati?
<ubottu> Launchpad bug 563400 in xserver-xorg-video-ati "[RV515] Playing flash video causes memory hogging" [Undecided,New] https://launchpad.net/bugs/563400
<juliank> Why don't I have the permission to access  bug 538253?
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/538253)
<azeem> juliank: could be an security issue, some of them are private AFAIK
<vish> juliank: seems no one other than the reporter are subscribed
<vish> or maybe what azeem said ..
<juliank> azeem, vish - "There was a changelog entry:     - make sure to record the maintainer script that requested the  reboot in /var/run/reboot-required.pkgs (LP: #538253)" , and now I don't know the reason for it.
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/538253)
<juliank> that's bad.
<tormod> wgrant, vish, I thought I would make a master bug 565981, although I do not know if this gem count really pinpoints the issue
<ubottu> Launchpad bug 565981 in linux "[KMS] gem objects not deallocated" [Undecided,New] https://launchpad.net/bugs/565981
<vish> wfm :)
<strange> is this the place to discuss bugs?
<tormod> strange, in most cases not, try #ubuntu or (#ubuntu+1 for lucid)
<strange> i've tried #ubuntu thats a no go heh
<SwedeMike> strange: if you have registered a bug on launchpad, going to #ubuntu-bugs might help.
<strange> ok thank you
<joaopinto> slangasek, isn't bug 543251 a duplicate from bug 507881 ?
<ubottu> Launchpad bug 543251 in mountall "mountall causes boot-up to hang on unknown fstab entry" [Medium,Incomplete] https://launchpad.net/bugs/543251
<ubottu> Launchpad bug 507881 in mountall "Lucid alpha 2 fails to start up unless you remove /proc/bus/usb from the fstab" [Medium,Confirmed] https://launchpad.net/bugs/507881
<ArneGoetje> slangasek: I have new language-packs ready... do you want them?
<nhandler> ScottK: Bug #564070 has a debdiff
<ubottu> Launchpad bug 564070 in libgtk2-perl "Please sync libgtk2-perl from Debian (fixes FTBFS)" [Wishlist,In progress] https://launchpad.net/bugs/564070
<joaopinto> mountall/plymouth is seriously broken :(
<Keybuk> joaopinto: WFM
<joaopinto> Keybuk, it means I have been playing with it the last couple of hours and is not reliable :P
<joaopinto> my last experiment was with some invalid entry on /etc/fstab, wrong filesystem type, missing mount poing, .. tested several reboots, and it just hang on the splash screen
<joaopinto> on my last reboot it did show the failure prompt (as expected)
<Keybuk> joaopinto: it's worked for me reliably every time
<joaopinto> Keybuk, being reliable for you that dot make it reliable in general :)
<Keybuk> being unreliable for you doesn't make it unreliable in general
<Keybuk> joaopinto: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
<joaopinto> Keybuk, I am not alone, anyway this comes from debugging the virtualbox proc usb issue
<joaopinto> which is affecting >20 people :P
<Keybuk> I'm sorry, but my INBOX disagrees with you
<persia> So, let's not argue about this.
<Keybuk> the only know triaged bug with mountall is with NFS root filesystems
<persia> joaopinto: Please file detailed bugs.
<joaopinto> Keybuk, it's hard for your INBOX to get mails from unskilled people which can't boot a system ;)
<joaopinto> persia, I am just commenting, the bugs are filled, I am not complaining, I am just expressing myself
<persia> Keybuk: Please acknowledge that mountall is very fast, but not necessarily careful at protecting users from shooting themselves in the foot with the right configuration.
<Keybuk> joaopinto: do you have --debug output from a boot?
<Keybuk> persia: I do not acknowledge that, I spent a very long time making mountall *careful*
<joaopinto> Keybuk, I tried --debug, I got the debug on the console after hitting "ESC", which got me in text mode, but /var/log/boot.log was empty
<Keybuk> joaopinto: bug #507881 ?
<ubottu> Launchpad bug 507881 in mountall "Lucid alpha 2 fails to start up unless you remove /proc/bus/usb from the fstab" [Medium,Incomplete] https://launchpad.net/bugs/507881
<joaopinto> Keybuk, bug 507881 is reproducible on a virtualbox system
<joaopinto> yup, that was I have spent more time with
<Airells> hi , i have created simple app using qtcreator ( gui app ) what is the simplest way to create .deb now ? dh-make ?
<Keybuk> I just commented on that asking for more information
<joaopinto> then I decided to play with random errors on fstab, with random results
 * Keybuk doesn't have virtualbox
<joaopinto> Keybuk, I am reinstalling my vbox with a daily cd, I played too much with my /etc/init :P
<persia> Airells: Depending on your taste, either that, or manual generation of the 4 packaging files: the folks in #ubuntu-packaging would be glad to help you through it.
<Airells> pecisk thx
<Airells> persia thx
<joaopinto> Keybuk, but I have tried  "/something 	/somewhere somefs defaults 0 0" on my real hw :P
<Keybuk> hmm
<Keybuk> when it hangs, where does it hang?
<joaopinto> Keybuk, wouldn't be safer for the recovery mode to not trigger mountall ?
<joaopinto> Keybuk, mountall
<Keybuk> not really, cause then you wouldn't get any mounted filesystems ;)
<Keybuk> no, I mean where in the boot process?
<Keybuk> what do you see on screen?
<joaopinto> Keybuk, at that time you do have the root filesystem, mounted from the jernel, that's "recovery" ;)
<joaopinto> ah, splash screen
<joaopinto> always moving
<Keybuk> so you do see the splash screen?
<joaopinto> yes
<joaopinto> btw, ATI fglrx
<Keybuk> that's kooky then
<joaopinto> Keybuk, recovery would be safer without mountall, because as you know it triggers several services, making optional (the personc could issue the start for it) would make it usable on more cases
<joaopinto> the mountall could even be an option on the recovery menu
<Keybuk> joaopinto: we're kinda getting rid of the "current" recovery mode
<Keybuk> since mountall does a large part of it already
<Keybuk> e.g. when filesystems fail, mountall lets you run fsck -y, or skip them, etc.
 * persia is impressed by the detailed set of special-casing in mountall, and clearly ought check fresher code before making accusations based on hearsay.
<Keybuk> persia: that's why I get frustrated at people; mountall is about a thousand times *better* than the crappy shell scripts we had before
<Keybuk> sure, there might be bugs, but it's not a crap piece of code - it's a very carefully planned and written piece of code :p
<persia> Indeed.  I always agreed it was better.  I just didn't think it was perfect yet.
<Keybuk> well, no code is ever perfect
<Keybuk> the only perfect code is the code you've removed
<joaopinto> Keybuk, so there will be another option to boot with minimal services ? as I see it recovery is not mainly for fs recovery, it has a large use for services related recovery
<persia> heh
<Keybuk> joaopinto: I think we'll have something like
<Keybuk> Start apache [y/n/d/?]
<Keybuk> Received starting apache event, Start tomcat? [y/n/d/?]
<Keybuk> et.c
<joaopinto> ah, that would be great
<joaopinto> brb, installing the vbox, will try to get that log
<Keybuk> joaopinto: http://launchpadlibrarian.net/44707171/2010-04-18%2009.46.53.jpg
<Keybuk> that's what you're supposed to see
<ion> My plymouth doesnât show the shirt. :-(
<Keybuk> ion: you have to buy that separately
<nigelb> Keybuk, :)
<Keybuk> Processed 265456 of 577332 files (12h 45m 58s remaining).
<Keybuk> whew....
<ScottK> nhandler: I've got no keys for several hours, so please subscribe ubuntu-sponsors and I'll look at it when I get back to my keys if no one else does.
<ion> keybuk: Whatâs that?
<Keybuk> ion: importing my e-mail into notmuch
<Keybuk> then going to run some experiments as to just how fast it is
<ion> Ah
<Keybuk> and if it's as awesomely fast as I hope, stick webkit on the front and write a GUI
<Keybuk> I did some experiments on Friday
<Keybuk> it suggested "all unread emails from Launchpad on bugs that I'm assigned to, and include the rest of the threads" would be of the order of a quarter of a second to run
<joaopinto> Keybuk, pristine install on a vbox after adding the proc usb line: http://www.ubuntu-pics.de/bild/52848/screenshot_003_3Ouok9.png
<Keybuk> ah
<joaopinto> Keybuk, and just to be clear, I am testing on a virtualbox environment, but the original reportees where using real systems
<Keybuk> now that's more like what I'd expect
<Keybuk> when you said you saw the splash screen, that confused me
<joaopinto> Keybuk, that is another case, the invalid entry
<joaopinto> one bug at a time :)
<Keybuk> can you give an example of "invalid entry" ?
<joaopinto> let me try it on virtualbox now
<Keybuk> also what kind of invalid entry are you putting in?
<joaopinto>  /something 	/somewhere somefs defaults 0 0
<Keybuk> hmm
<joaopinto> assume it to be a major typo ;)
<Keybuk> and that one you see a blank splash screen?
<Keybuk> with little animated dots?
<joaopinto> on that I see the blash screen with the animated dots
<Keybuk> right
<Keybuk> now
<Keybuk> can you do this:
<Keybuk> echo FRAMEBUFFER=y >> /etc/initramfs-tools/conf.d/splash
<Keybuk> update-initramfs -u
<Keybuk> (as root obv.)
<Keybuk> then try both the usbfs and somefs cases
<joaopinto> Keybuk, nothing changed for the usbfs case
<Keybuk> joaopinto: you don't see any splash screen?!
<joaopinto> usbfs case, no , still hanging on the initial text mode
<dupondje> http://paste.ubuntu.com/417152/ => what is this ? :s
<joaopinto> Keybuk, both usbfs and random entry on /etc/fstab result in the text mode screen without any output
<joaopinto> the splash vs no splash are related to VM/Real system
<Keybuk> but there should be no initial text mode if you set that FRAMEBUFFER=y
<joaopinto> Keybuk, ops, my mistake, addng the framebuffer now
<Keybuk> ;)
<joaopinto> Keybuk, it would be nice to have an option to provide a different tasks config location, like, --initdir=/etc/init.custom
<joaopinto> it would be a simple way to use different profiles
<Keybuk> well, different profiles there's a proposal for
<Keybuk> but that's not a bad idea for testing
<joaopinto> I had a bad time moving all the confs out of the regular tree and moving them back for testing :\
<Keybuk> yeh
<Keybuk> can you file a wishlist bug on that http://launchpad.net/upstart
<joaopinto> Keybuk, I get the splsh and the error prompt now
<joaopinto> splash
<Keybuk> do you get it for both usbfs and somefs?
<joaopinto> yes
<Keybuk> sweet
<Keybuk> then I know what causes both of these
<Keybuk> they're technically different bugs
<joaopinto> great :)
<Keybuk> the somefs one is simply a race
<Keybuk> mountall sends the messages, but plymouth isn't running
<Keybuk> so they never get there
<Keybuk> and when plymouth starts, it doesn't resend
<Keybuk> but the usbfs one is more tricky
<joaopinto> ok, that explains while I got a random prompt once booting from my real system
<Keybuk> because usbfs is a nodev filesystem, it holds up the "virtual-filesystems" event
<Keybuk> which is what causes drivers to be loaded
<joaopinto> I checked the code, TAG_VIRTUAL, the wait rule applies :)
<Keybuk> which means if it's holding up the boot, then the graphics drivers never get loaded
<Keybuk> so plymouth is never shown
<joaopinto> can't an exception be added, like there is one for fuse ?
<joaopinto> I mean, for the usbfs case, assuming it can be ignored
<Keybuk> well, it'd be an exception for a filesystem that we don't recognise anymore
<Keybuk> that might be a workaround
<Keybuk> also the FRAMEBUFFER=y thing
<Keybuk> I'll talk to slangasek when he's up
<Keybuk> since this becomes an RM decision at this point in the release
<joaopinto> someone else was suggesting to strip usbfs's on the upgrade process, that's an option
<joaopinto> people adding usbfs to a new system will most likely understand that caused the hang
<joaopinto> or maybe not :)
<Keybuk> right
<Keybuk> though other mistakes can cause this too :-/
<joaopinto> the main issue for "end users" is that there is no message to understand the cause
<Keybuk> sure
<Keybuk> but that's the bug
<Keybuk> it's not that there's no message
<Keybuk> the bug is that the message isn't getting on the screen ;-)
<joaopinto> it's a chicken and egg problem
<Damascene> hello, there is a problem with ogv in ubuntu recordmydesktop at least
<Damascene> http://www.google.pl/support/forum/p/youtube/thread?tid=7b9148c46c6b6f90&hl=en&safe=active
<persia> Damascene: Are you sure that's a bug in Ubuntu?  Looks like a bug in YouTube to me.
<Damascene> you can try it your self persia
<Damascene> ffmpeg -i video.ogv video.avi
<Damascene> see if it works
<persia> Well, if it doesn't, file a bug.
<Damascene> I tried it doesn't you should try now
<Damascene> I need confirmation
<Damascene> maybe it's in recordmydesktop
<Damascene> persia, any luck?
<tjaalton> slangasek: ok, here you go (didn't upload straight to the archive) https://launchpad.net/~tjaalton/+archive/test/+packages
<persia> No.  I don't have a source video, and I'm working on something else.  The best way to get the confirmation you want is to file a bug, as I said.
<Damascene> np. I just though you are trying to reproduce
<popey> Damascene: i can help you reproduce this
<Damascene> thanks
<popey> looks like a bug in ffmpeg or gstreamer to me
<Damascene> and youtube is using them?
<popey> Damascene: i just recorded a video with gtk-recordmydesktop and it plays fine in mplayer
<Damascene> yeah it plays fine in totem to
<popey> Damascene: i then used ffmpeg to convert to avi as you just suggested, and tried playing that in mplayer and it looked bad
<Damascene> *too
<Damascene> same here
<popey> right, so my guess is ffmpeg or gstreamer or some libavcodec bit, not gtk-recordmydesktop
<Damascene> how to make sure?
<popey> well the fact that the video which gtk-recordmydesktop plays fine, and only corrupts after ffmpeg touches it is a clue
<popey> I'd file a bug in ffmpeg if I were you
<Damascene> and youtube is using ffmpeg?
<popey> i dont know
<popey> Damascene: I tend to upload to blip.tv and have them send the video to youtube and that works okay
<Damascene> by the way do you know any open source video hosting?
<popey> blip.tv hosts ogv
<Damascene> or only technical stuff
<popey> http://ubuntuscreencasts.blip.tv <- those videos are ogv which I uploaded to blip.tv
<Damascene> was that your sound?
<popey> was what my sound?
<YokoZar> Did human-theme disappear off the CD?
<Damascene> yes
<Damascene> popey,
<popey> Damascene: can you please explain, your short sentences are hard to parse
<Damascene> I'm just asking if that is your sound in the video
<popey> which video? :) there are lots
<popey> I'm the one talking in the releases one
<Damascene> that was really good
<popey> thanks. i didnt make the video, i just did the audio
<popey> YokoZar: just booted a live cd in testdrive and yes, human is not there
<Damascene> that was the thing I'm talking about
<YokoZar> popey: That's bad, it was one of our best themes (honestly I'm still using it due to window buttons)
 * popey quite likes radiance
<popey> ar
<popey> no, the other one
<popey> :)
<popey> I think they're named the wrong way round "radiance" makes me think dark for some reason.
<spy6> hi there
<spy6> how is the procedure to sync a package from unstabe to lucid?
<spy6> (cause https://bugs.launchpad.net/ubuntu/+source/ipplan/+bug/565781)
<ubottu> Launchpad bug 565781 in ipplan "ipplan incompatible with php 5.3" [Undecided,Confirmed]
<persia> !sync
<ubottu> Helpful information for filing a sync request can be found at https://wiki.ubuntu.com/SyncRequestProcess
<spy6> persia: i did read this
<persia> OK.  What part is confusing?
<spy6> but its not very usefull, cause luvid is in freeze
<spy6> lucid
<spy6> there is no "resync from new debian version" documented
<persia> Oh, just get a freeze exception, which tends to be easy for stuff that's completely broken.
<spy6> in case of freeze
<persia> !ffe
<ubottu> Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process.
<persia> Mind you, if there's lots of *other* changes, it may need a cherrypick rather than a sync.
<spy6> persia: there just minor changes beside the fix
<persia> Well, get input fom the release team.  Sometimes they want a sync, and sometimes they want cherrypick.
<spy6> persia: sorry, i don't have a clue about ubtunu stuff, i'm just the debian maintainer
<persia> spy6: OK.  So, we have two options: I'm happy to explain how to do this, or I can do it for you.  Which would you prefer?
<spy6> persia: dunno, i'm open for new stuff ... but the proble is just, lucid is not far ;)
<persia> OK.  So the way we usually get input from the release team is to file a bug with "FFE" in the title (or edit a bug title), and subscribe "ubuntu-release".
<persia> The release team with ack it, reject it, or ask for more input (usually within 24 hours).
<persia> If you get an ACK, then subscribe ubuntu-sponsors, and someone will push it to the archive admins to get it synced.
<spy6> okay ... so i add heading "FFE" into the title?
<persia> Yep
<persia> (and if you get stuck, or you think the process is stuck, come back here, and we can fix it)
<spy6> hmm ... what about the sponsor list? just looking if someone is pushing it?
<persia> So first you want to subscribe "ubuntu-release" to get feedback from the release team.
<persia> Once you have approval, then subscribe "ubuntu-sponsors" to ask someone to upload.
<persia> (both using the "Subscribe someone else" button)
<spy6> persia: which button? I'm on the mailman interface of lists.u.c
<persia> spy6: At https://bugs.launchpad.net/ubuntu/+source/ipplan/+bug/565781
<ubottu> Launchpad bug 565781 in ipplan "FFE: ipplan incompatible with php 5.3" [Undecided,Confirmed]
<persia> You want to subscribe the team to the bug in launchpad.  Whether you want to subscribe to the team mailing list is entirely unrelated :)
<spy6> ah ... i contacts add to the bugreport
<spy6> i though i should subscribe to a mailinglist ;)
<persia> Sorry for the confusion.  You may also subscribe the the maillinglist if you like, but that's up to you and unrelated to getting approval.
<spy6> damn, i just have to revert from the subscription ;)
<spy6> okay ... i got it
<spy6> persia: many thanks
<persia> spy6: Looks right from here.  Come ask again if you don7t get feedback in the bug in a reasonable time.
<spy6> great :)
 * _silentAssassin is away: I'm busy
<persia> !away > _silentAssassin
<ubottu> _silentAssassin, please see my private message
 * _silentAssassin is away: sleeping
<Damascene> hi again. I used the ffmpeg from svn with x264 and the problem have gone
<Damascene> popey,
<matumba> Damascene, could this be related to bug 305286 ? if so, let them know, because I can confirm that the patch mentioned in the report doesn't fix it (ffplay fails to play the ogv)
<ubottu> Launchpad bug 305286 in ffmpeg "fails to playback ogv produced by recordmydesktop" [Medium,Confirmed] https://launchpad.net/bugs/305286
<Keybuk> Processed 281161 of 577332 files (15h 37m 5s remaining).
<Keybuk> that remaining time is going *up*
<ion> Yet another piece of software that doesnât bother to violate causality.
<slangasek> joaopinto: 507881> ah, that's the one; wonder how I failed to see that in the list
<slangasek> ArneGoetje: what's in the new langpacks?  The deadline isn't until next week, and a full langpack upload right now wouldn't give them time to build before we need to start ISO mastering
<slangasek> (for RC)
<slangasek> Keybuk: if /proc/bus/usb is already supposed to be handled with the generic "An error occurred" message, that's partially bug #563621 in plymouth
<ubottu> Launchpad bug 563621 in plymouth "[script splash] 'plymouth message' before 'plymouth show-splash' doesn't render" [Medium,Triaged] https://launchpad.net/bugs/563621
<Keybuk> slangasek: no it's worse than tha tone
<Keybuk> /proc/bus/usb ends up being tagged virtual
<Keybuk> since it's a kernel filesystem
<slangasek> Keybuk: should misc filesystems listed in /etc/fstab that aren't part of mountall's known list *ever* hold up virtual-filesystems?
<Keybuk> slangasek: yes, if listed as "nodev" in /proc/filesystems
<slangasek> tjaalton: hum, please upload straight to the archive instead, that's actually much more efficient at this stage of the release
<slangasek> Keybuk: what's the rationale for that?  Future-proofing mountall against new kernel filesystems that it doesn't know about yet?
<Keybuk> slangasek: anything nodev is a virtual filesystem
<slangasek> true, but tautological as far as the question of whether we want to block on it before emitting the signal :)
<tjaalton> slangasek: ok, on the way. -joystick would need to be synced if accepted, and debfx is working on virtualbox-ose (vboxmouse)
<slangasek> Keybuk: anyway, I'll accept a mountall change to blacklist usbfs specifically; it just seems to me that the more elegant solution is to treat nodev filesystems locally specified by the admin as something other than 'virtual-filesystems', and let them be handled by the normal error handler
<tjaalton> slangasek: btw fyi; there's finally support for AES/3DES/RC4 for rpcsec_gss coming up for .35, 22 commits applied without any problem on .32 ;) (needs three patches for nfs-utils as well)
<slangasek> tjaalton: that's going to have to be considered as an SRU
<tjaalton> slangasek: yeah I'm hoping for it
<tjaalton> will test it tomorrow
<tjaalton> but according to steved it has been tested with .32/.33/.34 using cthon
<tjaalton> so it should be ok
<tjaalton> my problems with pam_winbind were due to getting the ticket with RC4 on top, and kinit would then replace it with an nfs compatible one..
<tjaalton> slangasek: would you like me to propose it on the kernel list?
<slangasek> tjaalton: um... sure :)
<slangasek> I'm not on the kernel team, so whatever method you and they agree on is fine with me :)
<tjaalton> ok will do :)
<persia> tjaalton: Be aware there's still some .31 trees backing lucid packages (linux-rt, linux-fsl-imx51)
<tjaalton> persia: I doubt that the code has changed much, it has had DES hardcoded for a loong time
<persia> (yes, we're breaking new ground, with *3* different upstream versions of the kernel in lucid)
<persia> OK.  You just mentioned .32/.33/.34 and as far as I know, lucid has .31/.32/.33
<tjaalton> persia: actually, here's the patch: http://users.tkk.fi/~tjaalton/foo/auth-gss-update.diff
<persia> (-rt/-fsl-imx51, everything else, -ti-omap)
 * persia has no idea about other changes in the area: just wants to make sure that any sensible patch with behaviour on which we want to rely works on all the different kernel trees we ship)
<tjaalton> yeah well I can't see a reason why it wouldn't work with .31 as well, though it certainly doesn't hurt to test..
<tjaalton> so -rt is .31?
<persia> Yeah, -rt and -fsl-imx51
<tjaalton> I doubt the other flavors run nfs&krb5 :)
<tjaalton> handhelds or such
<persia> Actually, NFS is *very* common for -fsl-imx51 and -ti-omap as most devices don't ship with significant onboard storage.
<ajmitch> stranger things have happened
<persia> Dunno about -rt.
<tjaalton> well, DES is still there
<tjaalton> and if people have been using it, they've had to hardcode the configs too
<persia> (but -ti-omap is *closer* to .35, so less likely to have backporting issues)
<tjaalton> anyway, -rt is probably something that has to be tested
<tjaalton> since i can imagine it being used on such environments
<tjaalton> ok, 1 hunk failed on top of .31.13
<tjaalton> out of 22
<tjaalton> likely due to 14ace024b1e missing
<tjaalton> yep
<tlp> is anyone else dramatically affected by bug #131094 and perhaps #343371 in Lucid? Seems to be happening more than it used to, but I could be wrong.
<ubottu> Launchpad bug 131094 in linux "Heavy Disk I/O harms desktop responsiveness" [Medium,Confirmed] https://launchpad.net/bugs/131094
<tlp> when my HDD light is solid, I can't really do anything. Sometimes I can switch over to a tty and login so I can kill whatever it is that's doing it, but many times I'll just power the box off.
<spy6> hmmmm
<persia> Yes?
<spy6> persia: "sync acked"  means, i don't need  to subscribt ubuntu-sponsors?
<persia> Right.  A sponsor (ajmitch) already got to it, acked it, and passed to ubuntu-archive.  Now you're just waiting for an archive-admin to publish the sync.  Given that it's monday, I'd expect that sometime in the 9-12 UTC range.
<spy6> persia: ah okay ... that should be fine for lucid i guess :)
<spy6> thanks
<persia> For the purposes of taxonomy "archive-admin" in Ubuntu is roughly analogous to "ftp-master" in Debian.
<spy6> i thought so
<slangasek> Keybuk: re: bug #565185, bug #563878 - my first reaction was also to treat it as invalid, but on second thought, I don't think the design team was ever designing for 640x480 - I'll bet they're assuming a minimum res of 1024x768.  Maybe we should consult them about shrinking those graphics down by a factor of 1.6 or so, so that VGA16fb is more consistent with the experience they've actually designed?  (But not for final release, and proba
<ubottu> Launchpad bug 565185 in plymouth "the xx16.png's are scaled to large" [Undecided,Won't fix] https://launchpad.net/bugs/565185
<ubottu> Launchpad bug 563878 in plymouth "Ubuntu splashscreen big and ugly after installing ATI graphics driver" [Undecided,New] https://launchpad.net/bugs/563878
<slangasek> ... candidate for SRU)
<persia> slangasek: I'm sure 1024x600 is a closer approximation to expected minimum, although there have been N bug reports about stuff not working at 800x480.  I don't think anyone is seriously targeting 640x480.
<slangasek> persia: right - but of course 640x480 is what the VGA fb gives you
<slangasek> the trouble is, none of our positioning code assumes 640x480 either, so just resizing the images is going to look weird
<persia> Yep.  There's been some interesting discussions in #ubuntu-installer about the side effect of various scalings at various resolutions regarding the install process.
<slangasek> hmm; actually, our positioning code *might* all use the image sizes as the point of reference, and might just work
<slangasek> sorry, might Just Work
<joaopinto_> it works fine for me with the (ugly) ATI fglrx resolution
<persia> Most stuff seems to scale reasonably down to medium resolutions, but 640x480 gets a bit tight.
<persia> Anyway, anything that depends on number of pixels for apparent size is inherently broken.
<persia> There exists no relationship between screen size and pixel count, even aside from the vesafb issues.
<slangasek> as it happens, I had already tweaked the positioning code in the ubuntu-logo to eat up some of the space below the logo if we didn't have room to display all our text, based on feedback in prior bugs
<slangasek> so we should actually *fit* on 640x480
<slangasek> it's just not pretty
<persia> I think that's fine.  We can't get pretty until we can get em-aware renderers into pre-boot in a sensible way.
<persia> And even then it's tricky (go ahead: just try to make things look sensible on my 0.75" 800x600 display)
<slangasek> you know we use pango for the text rendering, right? :)
<persia> slangasek: Doesn't help with images though.
<slangasek> well, yes
<persia> Plus pango uses dpi as input trying to reach target size, rather than using dpi as input to reach sensible aspect.
<slangasek> but we don't want to be scaling images anyway, they're not going to look crisp if we do that
<persia> Right.  We need to render crisp images in realtime on the target hardware.
<slangasek> heh
<persia> But even that won't look crisp when we have framebuffer issues, because the display resolution won't match the native resolution.
<persia> (at least for non-raster devices)
<persia> Well, there's always the alternative of generating a pre-rendered image for every resolution at every size, but that gets tedious in a hurry.
#ubuntu-devel 2011-04-11
<psusi> cjwatson, will that partman-auto fix automatically make its way into ubiquity, or does more work need done?  ( or did you already do it? )
 * stgraber really hates race condition ... it's been 10 boot that pub doesn't get any event
<stgraber> cjwatson: updated bug 752393 with some more examples and thoughts. I'll change the package from lsb to plymouth as it seems to be a plymouth issue.
<ubottu> Launchpad bug 752393 in lsb (Ubuntu) "lsb init scripts show line buffering problems on bootup" [Medium,Confirmed] https://launchpad.net/bugs/752393
<cjwatson> ok
<cjwatson> I'm going to bed shortly, will look tomorrow
<cjwatson> The archive mirrors aren't updating right now.  IS are aware
* cjwatson changed the topic of #ubuntu-devel to: Mirror updates stopped (hw problems) | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots:
<pitti> Good morning
<cdbs> Good morning pitti
<cdbs> pitti: How was your weekend?
<pitti> hey cdbs; was nice, thanks! how are you?
<cdbs> pitti: Completely fine :)
<abhinav-> pitti: good morning. What do you think about the screenshot problem in https://bugs.launchpad.net/ubuntu/+source/apport/+bug/357847
<ubottu> Ubuntu bug 357847 in apport (Ubuntu) "ubuntu-bug wish: allow to just point at the window of a buggy application" [Wishlist,Fix released]
<micahg_> pitti: good morning, I'm finishing up a pidgin merge, would you be able to sponsor before the freeze
<pitti> abhinav-: sorry, what's the problem?
<pitti> micahg_: yes, no problem
<pitti> abhinav-: what does this have to do with screenshots? the main task there is to find out the process ID of the faulty app through the window ID?
<abhinav-> pitti: yes, but in the comments, there was a suggestion to take screenshot as well of the window having problem
<pitti> abhinav-: ah, so that's something different then
<pitti> abhinav-: well, both GNOME (gnome-screenshot) and KDE have builtin screenshot capabilities
<abhinav-> pitti: gnome-screenshot doesnt let take screenshot by pointing at a window ?
<pitti> abhinav-: apparently not via CLI
<abhinav-> pitti: but I suppose the solution has to be generic enough, so that it works on both KDE and GNOME ?
<pitti> abhinav-: not necessarily; there can be a method in AbstractUI, and the Gtk/KDE/CLI implementations can then differ
<abhinav-> pitti: right. I will look more into gnome-screenshot then. Although there is another screenshot application shutter, which provides the feature to point at a window and take screenshot. But it uses0 libgnome2-wnck-perl
<broder> Before I start trying to argue with people on the internet, does anybody else want to look at http://lifehacker.com/#!5790311 and confirm that e4rat shouldn't make more than a ~100ms max difference over a correctly functioning ureadahead?
<TheMuso> Ok this is weird, for some reason dput is erroring out for me saying that my public key isn't valid... but its the same key I've been using to upload packages for ages, and I've changed nothing locally or in lp.
<TheMuso> Can anybody else confirm?
<StevenK> TheMuso: Yes, ScottK mentioned it in #launchpad.
<TheMuso> ah ok
<StevenK> I'm not sure what is going on yet.
<TheMuso> np I'll jump over there to follow.
<TheMuso> thanks
<pitti> abhinav-: shutter and its dependencies are an additional 19 MB compressed packages, which is prohibitively expensive
<pitti> TheMuso: confrimed
<pitti> TheMuso: it still uploads, though
<TheMuso> pitti: oh does it?
<pitti> I pulled my hair out on that one for an hour yesterday when uploading langpacks
<pitti> until I noticed that they actually work
<pitti> TheMuso: well, it did for me. YMMV
<TheMuso> Right, we'll see what happens.
<TheMuso> I uploaded twice thinking something was transient. :)
 * TheMuso checks natty-changes.
<RAOF> abhinav-: You can get a one-window screenshot out of gnome-screenshot, too, I'm sure.  GNOME Do appears to, at least :)
<pitti> RAOF: you can, but it takes the currently focused window, there's no picker
<RAOF> Eh.  That's a SMOP.
<abhinav-> pitti: the author of shutter gave me a perl script (~100 lines) which does this, but it requires libgnome2-wnck-perl :)
<pitti> abhinav-: then you can probably do the equivalent in python with gir1.2-wnck-1.0
<abhinav-> pitti: yes, perhaps. I can try. thanks. :)
<pitti> abhinav-: great; good luck!
<TheMuso> pitti: yeah my upload went through too.
<dholbach> good morning
<micahg_> if I have a PKG_CHECK_MODULES check in configure, should the Cflags automatically get added or do I need to do something else?
<slangasek> PKG_CHECK_MODULES() will automatically add cflags to a variable for you
<slangasek> as long as that variable is then referenced in Makefile.in, you should be good
<micahg_> ah, that's what I need to do, thanks :)
<pitti> micahg_: no, they won't; you have to do something like myprogram_CFLAGS = $(MYLIB_CFLAGS)
<broder> micahg_: you give it a name (e.g. PKG_CHECK_MODULES([GLIB], [glib-2.0]) ) and then it defines, e.g., GLIB_CFLAGS and GLIB_LDFLAGS (or is it GLIB_LIBS? i don't remember)
<slangasek> _LIBS iirc
<pitti> _LIBS, yes
<pitti> and confusingly myprogram_LDADD = $(MYLIB_LIBS)
<micahg_> I was trying to add a proper check for launchpad integration for pidgin since the check it was under before was dropped
<damno> hello
<damno> I need a bit of help
<damno> anyone here?
<pitti> !ask | damno
<ubottu> damno: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<damno> i just compiled abiword
<damno> successfully
<damno> but coolab isnt orking
<damno> sorry, collab
<ScottK> pitti: I've uploaded KDE 4.5.5 for Maverick and filed Bug #757065 to track it.  I was hoping we could use the free buildd time once the Beta 2 freeze solidifies a bit to get it out the door.
<ubottu> Launchpad bug 757065 in oxygen-icons (Ubuntu) "Tracking bug for SRU update of KDE to 4.5.5 in Maverick" [Undecided,New] https://launchpad.net/bugs/757065
<pitti> ScottK: that sounds like a good opportunity indeed; I would like to wait a bit still, as the buildds are still quite busy, and I expect some more last-minute uploads
<ScottK> pitti: Certainly.  I was guessing likely tomorrow.
<damno> the install process created a archive named 'backup-041120111230-pre-abiword.tgz'. is it essencial to keep it?
<ScottK> The core packages are all there.  I don't have the translation updates yet.
<ScottK> No need to particularly wait on those though.
<pitti> meh, Launchpad's "I hate your key" messages are really confusing
<StevenK> pitti: Currently being investigated.
<StevenK> But yes, it's exposing internals in an ugly way.
<TheMuso> Yes, and prevents dput uploading multiple packages simultaneously.
<TheMuso> Since an error is being thrown.
<ScottK> Yes.  Yes it does.
<TheMuso> ScottK: Oh yeah, that would have been painful.
<pitti> ScottK: ok if I upload a new kubuntu-restricted-addons to drop the NBS kopete-gcall?
<damno> you guys are too busy to help a new guy ,  I think
<damno> buy
<ScottK> pitti: Certainly.
<micahg_> pitti: in the interest of getting this done, would it be ok to attach the launchpad integration check onto something else (like glib), I can't seem to get this to work
<micahg_> it was previously attached to startup notification
<pitti> micahg_: so perhaps just leave it where it was before, on startup-notification?
<micahg_> pitti: would have loved to do that, but that check was removed in 2.7.11 :)
<micahg_> hi seb128, since you've done most of the pidgin merges, do you have an opinion about the above?  (4 lines)
<seb128> just put it on whatever is used to build that part of the code
<micahg_> ok
<\sh> hmm...did anyone see this error lately on natty while uploading? http://paste.ubuntu.com/592510/
<lifeless> yes
<lifeless> its being fixed
<lifeless> gpg.conf file got reaped by tmpreaper
<\sh> lifeless: means?
<\sh> lifeless: error on user side or on server side?
<lifeless> server side
<lifeless> workaround is in place if you want to try again
<\sh> lifeless: ok...so I don't care, actually the package was accepted
<TheMuso> hrm, alsa-lib on amd64 failed for some weird reason. I386 built fine. http://paste.ubuntu.com/592512/
<TheMuso> This is on the buildds.
<diwic> TheMuso, yeah, saw that as well. "gcc: not found" seems to be the error
 * micahg_ thinks slangasek was talking about that earlier
<TheMuso> Ok thanks.
<apw> there is an incantation (possibly as tasksel one) including a ^ which says 'install everything i would expect to have installed'
<apw> can anyone remind me what it is?
<pitti> apw: that's called installing a task
<pitti> apw: apt-get install ubuntu-desktop^ should do that
<apw> pitti, ahh that looks like it ... thanks :)
<pitti> hey apw
<apw> pitti, hiya
<micahg_> seb128: for the new symbols, do you just copy them from Debian and add an epoch?
<slangasek> TheMuso, micahg_: no, I was talking about a change that's in a linux-libc-dev version that isn't published yet
<TheMuso> hrm ok thanks.
<seb128> micahg_, yes
<slangasek> TheMuso, micahg_: oh oops, I read the output wrong - yes, linux-libc-dev is published on amd64, so that explains perfectly the failure
<TheMuso> slangasek: ok thanks.
<micahg_> seb128: do we care about sort order?
<seb128> no
<micahg_> seb128: thanks
<micahg_> pitti: bug 757146 if you have time to sponsor
<ubottu> Launchpad bug 757146 in pidgin (Ubuntu) "Please merge pidgin 2.7.11-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/757146
<slangasek> TheMuso: verified that gcc-multilib 4:4.5.2-1ubuntu2 will fix this; as soon as that publishes we can retry alsa-lib
<TheMuso> slangasek: Thanks.
<pitti> micahg_: on it
<micahg_> pitti: thanks
<JamesMR> Hi, I'm looking for some help/advice with an error I'm getting when trying to use apt, this is the error - "dpkg: syntax error in file triggers file `/var/lib/dpkg/triggers//File'" I'm on 10.10, it started appearing after trying to update to 11.04 beta via update-manager -d and my system froze partway through. 11 hours later I decded to rebooot my computer, the error has been bugging me since
<poolie> JamesMR, try in #ubuntu
<poolie> or rather, #ubuntu+1
<micahg_> pitti: did you upload pidgin yet? (if not, hold off)
<pitti> micahg_: too late
<poolie> clint's in a us timezone, right?
<poolie> i wanted to push along https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/707075
<ubottu> Ubuntu bug 707075 in bzr (Ubuntu Lucid) "[sru] lp-propose fails with a 404 error" [Undecided,New]
<micahg_> ugh, I built this thing multiple times, and the last time it tells me symbols are missing
<TheMuso> heh
 * micahg_ wonders if -j17 had anything to do with it
<micahg_> pitti: I think I'll have a fixed pidgin in a few minutes, it seems if a symbol is listed twice it fails now
 * micahg_ is confused, not all the duplicates failed
<micahg_> ok, so there's something I don't understand, can the same symbol appear multiple times in a file?
<slangasek> micahg_: the same symbol /name/ can, but only if it has a different symbol version AFAIK
<micahg_> slangasek: ok, so these are all the same version
<micahg_> can I safely remove one?
<slangasek> sorry, maybe I'm confused - are you talking about removing it from a symbols file or from a library?
<micahg_> symbols file
<slangasek> ah, I thought you were talking about an object file.  Sorry, I'm not sure I know the answer then
<soren> micahg_: Which package?
<micahg_> soren: pidgin
<soren> I probably don't know the answer, I'm just curious :)
<micahg_> heh
<micahg_> I'm rebuilding without the duplicate symbols which I expect to succeed locally, I just would like to know if it's safe for the archive
<soren> "bzr branch lp:ubuntu/pidgin" takes a while...
<micahg_> soren: try pull-lp-source pidgin :)
<soren> not a bad idea
<soren> libpurple0.symbols?
<micahg_> soren: yep
<micahg_> so Debian removed the symbols, I'm just not sure why, it also wasn't noted in their changelog, but they're duplicates, so idk if that means anything was removed or not
<micahg_> pitti: so, the build succeeded w/out the duplicate symbols, but idk if that's the right thing to do or not
<pitti> micahg_: duplicate *.symbol entries don't really make sense, so this sounds like the right solution
<soren> Well, this particular symbols file has information for two separate libraries.
<soren> libpurple.so.0 and libpurple-client.so.0
<micahg_> ah
<soren> They could both export the same symbol.
<soren> Whether they actually *do*... I don't know.
<soren> I can imagine situations where it makes sense, but I have no idea if that applies here.
<soren> Say, if the same binary package ships two flavours of the same library, both exporting (mostly) the same symbols.
<soren> Now that I've added to the confusion, I'll wander off. Toodles :)
<micahg_> pitti: so, they're not duplicates, it's as soren suggested, they are gone from libpurple-client and now solely in libpurple
<soren> Without a soname bump?
<soren> *sob*
<soren> Oh, right I wandered off.
 * micahg_ doesn't think the pidgin devs know what the so version is for, it seems to be tied to their dev version instead of soname changes
<micahg_> or it could just be coincidence
<micahg_> pitti: so, options are, upload an ubuntu2 that follows what Debian did (remove symbols w/out soname bump) or upload a 2.7.9-2 version and try to get this fixed properly
<pitti> micahg_: I think just removing the duplicates from libpurple-client will do
<pitti> at most it'll affect library dependency versions, but they should already be alright with the other symbols
<micahg_> pitti: ok, I'll attach the debdiff
<TheMuso> ...i thought freeze was at 9:00UTC.
<pitti> TheMuso: yes, freezing right now; the higher priority for the admins was to get the archive mirrors back working :)
* cjwatson changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots:
<TheMuso> right
<cjwatson> (mirrors should return shortly)
<micahg_> pitti: bug 757311, thanks
<ubottu> Launchpad bug 757311 in pidgin (Ubuntu) "pidgin fails to build due to missing symbols" [High,In progress] https://launchpad.net/bugs/757311
<pitti> micahg_: cheers, uploaded
<micahg_> pitti: thanks, sorry for all the trouble :)
<pitti> micahg_: no worries, thanks to you for sorting it out!
* pitti changed the topic of #ubuntu-devel to: Archive: Beta-2/Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots:
<pitti> archive now frozen for beta-2
 * ogra_ curses this insane freeze time 
<pitti> ?
<ogra_> we shouldnt do freezes on monday mornings
<ogra_> that kind of forces people into weekend work
<ogra_> either have them in the evening or on the friday before
<pitti> the main difference is that the release team cross-checks the uploads; little difference for developers
<ogra_> i know :)
<pitti> ogra_: how would a freeze on Friday help in any way?
<cjwatson> well, I sympathise with the weekend work bit, but how would moving it help?  if you haven't got the work done yet, you haven't got it done, and moving the freeze would make little difference
<pitti> if you don't work on the weekend, fri/mon morning freeze is no different
<ogra_> if you have work to do that requires less than a day you dont have to work on the weekends to make it into the archive before freeze
<ogra_> if the freeze is in the evening or afternoon UTC
<cjwatson> moving it later, sure; however that does have other consequences for the release team
<pitti> ogra_: you can still do that; freeze -> controlled what's going in, not "doors firmly closed"
<pitti> we already have negotiated an exception for unity
<cjwatson> the later it is, the higher the chances of Tuesday's daily builds not being usable and us having to scramble
<pitti> but we really need to coordinate uploads, to not collide with image builds, QA smoke testing, etc.
<ogra_> i know, i also have discussed the possible alsa and pulse changes with kate
<cjwatson> in private or in channel/bug?
<ogra_> but i still would like to give the community more time before we freeze
<ogra_> cjwatson, during fridays meeting
<cjwatson> ok
<mdz> pitti, is the amd64 retracer possibly down or backlogged? bug 757219 has been pending for 3 hours so far
<ubottu> Error: Launchpad bug 757219 could not be found
<pitti> mdz: it was, but the log was empty; I restarted it for now
<seb128> pitti, I've restarted it 2 times already today
<pitti> seb128: and it doesn't produce any log?
<seb128> it does "consolidating the duplicates" and seem to crash
<pitti> ah, log_dupcheck
<seb128> or never went over that
<seb128> pitti, well there is nothing in the logs, I guess I should try to run it manually
<pitti> sladen: your ubuntu-mono upload dropped --with-scour, but doesn't document why?
<sladen> pitti: oh bollocks, could swear I did  bzr revert debian/rules  first
<pitti> sladen: want me to reject and you reupload?
<pitti> (same version number is fine)
<sladen> pitti: yes
<sladen> pitti: I just do that to save 20 minutes on the local build time
<pitti> quite a large set of new icons as well, I hope they got some testing?
<sladen> pitti: urm?  Should only be 1.  But a lot of symlinks/alternate names
<pitti> sladen: ah, then debdiff just got confused :0
<sladen> pitti: it's overriding one icon (and all of its aliases) from Humanity, as Humanity maintainers/upstream don't want the icon that Mark wants, but Humanity upstream (vish) is being kind enough to ensure it correctly goes into ubuntu-mono as a mutal solution :)
<sladen> pitti: weird.  debian/rules  has --with-scour,  and bzr status shows nothing
<pitti> sladen: maybe you had an older source package around?
<doko> pitti: do you intend to address all the other v4l issues too?
<pitti> doko: so far I am aware of gambas (which built locally, but not on the buildds, sorry), and hal, but both are fixed now
<pitti> doko: what else?
<pitti> I'm mainly fixing NBS right now, but can look into other issues if required
<doko> pitti: https://launchpad.net/ubuntu/+bugs?field.tag=ftbfs+natty+v4l&field.tags_combinator=ALL
 * pitti sighs on timeout
<pitti> doko: if you happen to have the page open, perhaps you can toss me a bug list on IRC?
<pitti> tried 5 times now
<doko> pitti: http://paste.ubuntu.com/592569/
<chrisccoulson> nobody noticed any new firefox issues since i turned on -pie in the builds again last night?
<pitti> chrisccoulson: hardly, as the mirrors are still not updated :)
<chrisccoulson> ah
<chrisccoulson> that's not good ;)
<pitti> doko: any priorities there? I can do two or three, but not 25
<doko> enoclue, I just filed these with the tag, because it's obvious from the build logs
<lamont> ScottK: "fond" isn't exactly the word I would use
<pitti> doko: I'll grab linphone, vdr, and kino then, they seem to be the most popular
<pitti> doko: ah, linphone already fixed
<doko> yeah, sorry, I may have filed issues for superseded versions
<pitti> ah, no, LP output is just confusing
<pitti> it went to universe, that's why it shows published on Apr 8
<pitti> so yeah, will have a look at these three
<janimo> what is the procedure for freeze exception uploads?
<arand> I wonder if there is a...
<arand> !ffe
<ubottu> Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process.
<janimo> arand, thanks
<ogra_> janimo, adding features ?
<janimo> ogra_, nope, hopefully fixing the gconftool crash
<janimo> working around actually by building with -O0 :(
<ogra_> well, just have a bug for it and mention the bug number in the changelog will suffice
<ogra_> bugfixes that dont add new features dont need an FFE
<ogra_> just upload and be in #ubuntu-release if the reviewer has questions
<ogra_> (all uploads get reviewed anyway from now on)
<janimo> ogra_, ok, just joined that channel
<ogra_> makes sense prior to milestones and during freezes
<ScottK> lamont: Speaking of stuff you're fond of ...  What are the chances of fpc on armel bootstrapping this cycle?
<lamont> well, I did say I'd see about throwing it against the wall again to see if this time is any different than the last 3 times
<ScottK> OK.
<lamont> of course, if it does bootstrap, it'll just fail to run on most of the buildds, I'm guessing
<mdz> seb128, any luck with the retracer?
<seb128> mdz, the amd64 is running
<mdz> seb128, great, I guess it will catch up soon then
<seb128> mdz, but there is quite some backlog from the weekend so it might take another hour before getting yours
<mdz> ack
<seb128> pitti, I disabled the job which consolidates the db for now to get the retracing going btw
<seb128> pitti, I will try to restart it manually once we clear the backlog
<pitti> seb128: ah, thanks
<bdrung> geser: DMB meeting?
<pitti> doko: FYI, I uploaded linphone and kino fixes, and will do a vdr sync after the buildd backlog settled down; then these three are fixed
<GunnarHj> doko: Hi Matthias, there is a rumor that you're patch pilot today. ;-)
<kirkland> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Beta-2/Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: kirkland
<kirkland> GunnarHj: hi, i'm on pilot duty, too, fwiw
<GunnarHj> kirkland: Hi Dustin, it's worth a lot. :)
<GunnarHj> kirkland: There are two things I'd appreciate your help with. First I'm wondering if it's possible to commit only one of the revisions (322) from https://code.launchpad.net/~gunnarhj/gdm/profile/+merge/56426, or should I create a separate MP for it? (Rev. 323 is pending furter discussion.)
<kirkland> GunnarHj: reading ...
<kirkland> GunnarHj: hmm, I echo seb128's question ... you should easily be able to: . $HOME/.profile || true
<kirkland> GunnarHj: and . $HOME/.xprofile || true
<apw> cjwatson, about?  seeing any reports of loss of graphical boot?  my first test box i updated seems to go from purple to black with a cursor ?
<GunnarHj> kirkland: Think I have to test it again, to recall why I made another conclusion...
<kirkland> GunnarHj: so if you just do:
<kirkland> Guest24406: . $HOME/.profile || true
<kirkland> GunnarHj: the || true will catch the error that you're testing for with -f (file existence)
<kirkland> GunnarHj: and it will also catch any syntax errors in the sourcing of that file
<GunnarHj> kirkland: Will get back to you about that.
<GunnarHj> kirkland: Then there is https://code.launchpad.net/~gunnarhj/language-selector/help/+merge/57109. Is a pure docs change affected by BetaFreeze?
<apw> cjwatson, a quick poke seems to imply that linux_gfx_mode is not keep, ie changing the set to keep gets it back
<kirkland> GunnarHj: https://wiki.ubuntu.com/DocumentationStringFreeze
<cjwatson> apw: first I've heard of it
<apw> cjwatson, i don't see to have a gfxblacklist.cfg
<apw> cjwatson, i don't see to have a gfxblacklist.txt even
<cjwatson> apw: do you have /boot/grub/gfxblacklist.txt?
<GunnarHj> kirkland: I know, but that document is not subject to translation yet (won't be until after the Natty release).
<cjwatson> hm, maybe it falls over if that file's missing
<apw> cjwatson, nope no such file
<kirkland> GunnarHj: ah
<apw> and dpkg can't find one either
<kirkland> GunnarHj: okay, then i'm willing to sponsor that one, if you open a bug for it
<apw> cjwatson, isn't that file from its own  package ?
<apw> cjwatson, this machine just has had an apt-get install ubuntu-desktop^ run on it too, so its in theory complete
<cjwatson> no, it's from grub-gfxpayload-lists, which I forgot to MIR (doing now)
<cjwatson> but grub should tolerate its absence anyway
<cjwatson> bug me
<apw> cjwatson, welll in theory it might be the right behavour in the absense of the file ...
<cjwatson> I think on balance I'd rather default on
<apw> cjwatson, ok touching that in seems to fix the issue
<apw> cjwatson, i assume you want a bug against grub2 ?
<cjwatson> yes
<apw> cjwatson, also  ... i have a feeling that something other than drm is switching off the display, contributing to the length of the 'black with no backlight' phase
<apw> does that ring a bell at all ?
<apw> plymouthd when it starts or something?
<kirkland> GunnarHj: can you get me a bug number for the language-selector fix?
<cjwatson> apw: no bells ringing there
<GunnarHj> kirkland: Sure, just give me two minutes.
<apw> cjwatson, bug #757603, want it assigned ?
<ubottu> Launchpad bug 757603 in grub2 (Ubuntu) "graphical boot is disabled when the gfxblacklist.txt is missing" [Undecided,New] https://launchpad.net/bugs/757603
<cjwatson> I'll grab it
<apw> ack
<GunnarHj> kirkland: Done. Used an ongoing bug on i18n documentation.
<pitti> doko, mterry, didrocks: we have two urgent MIRs for beta-2, bug 754661 and bug 757600; does any of you have some time to review them?
<ubottu> Launchpad bug 754661 in python-psutil (Ubuntu Natty) "[FFe] [MIR] python-psutil" [High,Confirmed] https://launchpad.net/bugs/754661
<ubottu> Launchpad bug 757600 in grub-gfxpayload-lists (Ubuntu) "[MIR] grub-gfxpayload-lists" [Undecided,New] https://launchpad.net/bugs/757600
<mterry> pitti, sure
 * mterry takes first, will take second if no one else does
<pitti> mterry: cheers
 * didrocks still triages unitish things
<didrocks> kees: answered on bug #755146, can you please have a look once you have time for it?
<ubottu> Launchpad bug 755146 in compiz (Ubuntu) "compiz crashed with SIGSEGV in g_source_unref() (dup-of: 740897)" [Undecided,New] https://launchpad.net/bugs/755146
<ubottu> Launchpad bug 740897 in compiz (Ubuntu) "compiz crashed with SIGSEGV in g_source_unref()" [Medium,Confirmed] https://launchpad.net/bugs/740897
<seb128> didrocks, njpatel suggested that's a duplicate of the ccsm crash earlier
<didrocks> seb128: ok, let's hope so :) weird that we still have a missing unref in sources, I checked everything apart from the dash, will have another look
<seb128> kees, did you get your compiz crashes when using ccsm?
<kirkland> GunnarHj: #?
<stgraber> SpamapS: ping
<GunnarHj> kirkland: Sorry, bug 742857
<ubottu> Launchpad bug 742857 in language-selector (Ubuntu) "i18n matters ought to be properly documented" [Undecided,In progress] https://launchpad.net/bugs/742857
<didrocks> seb128: from the ubuntu-devel mailing list: " crashed when clicking launcher for Terminator while Terminators were running"
<kirkland> GunnarHj: cool, pushed, uploaded
<kirkland> GunnarHj: let me know about the gdm one
<seb128> didrocks, ok so maybe njpatel was wrong ;-)
<didrocks> seb128: that's why I'm pinging kees :-)
<didrocks> seb128: well, the issue will also result in ccsm being uncheck
<GunnarHj> kirkland: Thanks. I will (in a few minutes).
<GunnarHj> kirkland: Please see my latest comment on https://code.launchpad.net/~gunnarhj/gdm/profile/+merge/56426
<mterry> cjwatson, about grub-gfxpayload-lists, I don't see any existing blacklisted IDs and it doesn't seem to install a dpkg trigger, so is this package currently a no-op?
<cjwatson> mterry: tseliot was thinking of adding entries to fglrx/nvidia packages, although I'm not sure whether he actually has yet
<cjwatson> mterry: rightly or wrongly (perhaps wrongly) the current design is that packages that install blacklist files should call update-grub-gfxpayload
<cjwatson> (I wouldn't mind a bug to triggerise that, although I don't think it's necessary for natty)
<mterry> cjwatson, sure, OK.
<tseliot> cjwatson, mterry: both fglrx and nvidia-current install such blacklist file (currently empty though)
<cjwatson> right - I want to have the facility in place though
<mterry> pitti, both approved
<pitti> mterry: thanks
<dholbach> https://wiki.ubuntu.com/UbuntuAppDeveloperWeek starting in 15 minutes in #ubuntu-classroom
<abhinav-> dholbach: will the IRC logs be available ?
<sladen> abhinav-: irclogs.ubuntu.com
<james_w> cjwatson, Can't exec "unxz": No such file or directory at /usr/share/perl5/Dpkg/IPC.pm line 261. <- That's from the xz work I assume? It implies that the updated dpkg is installed, but an xz package is missing?
<dholbach> abhinav-, yes, they'll be also put on https://wiki.ubuntu.com/UbuntuAppDeveloperWeek afterwards
<abhinav-> dholbach: cool. Thanks :)
<seb128> mdz, your bug got retracers, it's an overlay scrollbar issue
<mdz> seb128, thanks. when apport filed it, it was tagged ayatana-scrollbar (before even being retraced), but was still filed on rhythmbox for some reason
<mdz> is that how it's supposed to work?
<seb128> mdz, the tag just means that the scrollbar binary is installed
<mdz> oh
<seb128> it doesn't mean the bug is due to those
<cjwatson> james_w: is that on a DC machine?
<mdz> I thought it might have been because of ?? () from /usr/lib/liboverlay-scrollbar-0.1.so.0
<james_w> cjwatson, yeah, jubany
<mdz> but that makes more sense
<cjwatson> james_w: current versions of dpkg pre-depend on xz-utils
<mdz> seb128, isn't the scrollbar binary package installed by default though?
<seb128> mdz, right, I need to talk to ken about that
<cjwatson> james_w: one of the versions floating around the -cat archives might be suitable for jubany; I'd suggest asking IS
<seb128> mdz, we should add something to reassign to overlay-scrollbar if liboverlay-scrollbar is in the stacktrace
<james_w> cjwatson, ok, thanks
<mdz> seb128, yeah, similar to the nautilus->ubuntuone rule
<seb128> mdz, well in fact I just checked I was wrong, it does add the tag if the scrollbars are in the ProcMaps, but it just tell you that the application which crashed had those loaded
<seb128> not that it crashed in there
<mdz> ah
<kees> didrocks, seb128: I have no idea where the 755146 crash came from, honestly. the other one (755167) was totally a crash while in ccsm.
<didrocks> kees: ok, so "known and prioritized issue"
<kees> didrocks: cool, thanks!
<kees> didrocks: after turning off focus-follows-mouse, I have had 0 more problems.
<kees> I don't like not using FFM, but it does keep me from having unity crash :)
<didrocks> kees: yeah, ffm is not supported from the start :/
<kees> didrocks: if that's the case, unity should refuse to run if FFM is on. ;)
<didrocks> kees: there were a discussion about this 2 monthes ago, but some people argued it was working, so we didn't touch it
<kees> didrocks: does the unity (or compiz) apport hook report the state of FFM?
<didrocks> kees: no, and yes, nice suggestion :)
<didrocks> kees: I'll add that
<didrocks> thanks :)
<kees> didrocks: cool; that should really help weed out stuff
<didrocks> right
<kirkland> GunnarHj: okay, another message, back at you ;-)
<SpamapS> stgraber: pong, I read your analysis of the console issue. Makes sense to me.
<stgraber> SpamapS: can you post the boot.log file after you switch to that lsb-base-logging.sh ? assuming you still have the VM around
<SpamapS> stgraber: I do (I have 2 like it actually). Booting them now. :)
<stgraber> SpamapS: cool, thanks
<GunnarHj> kirkland: That's indeed more elegant than my function. :)
<GunnarHj> kirkland: Just a detail: Can't we drop the "|| true" part then? To me it appears to be superfluous. Or what am I missing?
<kirkland> GunnarHj: no, that part is essential to catch the (. ~/.profile) failure
<kirkland> GunnarHj: wanna update that merge?
<GunnarHj> kirkland: Yes, I'll do that. But let's first finish the "|| true" talk. Just submitted a new comment on https://code.launchpad.net/~gunnarhj/gdm/profile/+merge/56426
<GunnarHj> kirkland: To me it appears as if the parentheses protect the main process from stopping irrespective of what you put inside them.
<kirkland> GunnarHj: interesting, it does seem that way to me
<SpamapS> stgraber: boot.log uattached
<kirkland> GunnarHj: my tests agree with that
<stgraber> SpamapS: thanks. I'm currently working on fixing the apparmor part of it, it's calling a function I didn't make plymouth aware yet. Fixing this one should give a slightly better output.
<stgraber> SpamapS: for memcached that's probably as good as it's going to be until someone changes its init script
<GunnarHj> kirkland: Ok, then I'll update the merge and get back to you.
<kirkland> GunnarHj: perfect
<kirkland> smoser: looking at https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/726572
<ubottu> Ubuntu bug 726572 in cloud-initramfs-tools (Ubuntu Natty) "[MIR] cloud-initramfs-tools" [Undecided,In progress]
<kirkland> smoser: looks like kees gave you your +1 for MIR
<kirkland> smoser: nice ;-)
<kirkland> smoser: i'll move it over
<smoser> yeah, can you commit it to seed ?
<smoser> seed "uec"
<smoser> and, kirkland, thank you for doing work for me :)
<kirkland> smoser: sure
<kirkland> smoser: you do work for me all the time;  it's the least I can do :-)
<SpamapS> stgraber: are the lsb log messages completely suppressed?
<SpamapS> stgraber: I don't see any calls to plymouth update
<stgraber> SpamapS: nope, they still go through the console as usual, it's just that instead of showing the first half of the message, then wait and show the "[ OK ]" part, I wait until I know if it worked or failed to show the whole line
<stgraber> the problem with apparmor is that it's calling log_action_msg which does a simple "echo" so it gets printed immediately and so appears before the line saying that apparmor is starting :)
<stgraber> which makes sense because that line is technically printed before the call to log_end_msg, it just looks weird ...
<kirkland> smoser: done
<stgraber> SpamapS: plymouth is basically grabbing everything that gets displayed on the console and writes that in boot.log. So you just need to be careful to always echo full lines to the console.
<ScottK> kirkland: If you're still patch piloting, I'd appreciate it if you would look at Bug #757540.
<ubottu> Launchpad bug 757540 in ttf-kacst-one (Ubuntu) "Missing many Glyphs to support Uyghur (Uighur) Language" [Undecided,In progress] https://launchpad.net/bugs/757540
<kirkland> sconklin: sure
<kirkland> ScottK: ^
<ScottK> Thanks.
<kirkland> ScottK: i'm tackling a likewise-open double merge at the moment, will look at yours next
<ScottK> kirkland: Thanks.
<superm1> janimo, i wasn't even aware that you had uploaded deltas to mythtv until ScottK pointed it out.  could you try to remember to submit a merge request for the VCS next time so it's not missed?
<janimo> superm1, I thought maintainers are notified on upload
<janimo> superm1, I almost never notify debian or upstream vcs explicitley unless it is a bugreport
<superm1> i didn't see anything come through my mail about it, hm wonder why
<superm1> the maintainer is a mailing list, is that maybe why?
<janimo> for are there are changes to amany7 packagesa and explicitly doing that for each is a lot less efficient than relying on the fact that LP mails out notifications
<janimo> superm1, not sure why, maybe not all maintainers are notified by LP. Failing that I thought package updates even syncs from Debian do not go over ubuntuX changes without at least some notification that there is an ubuntu delta
<janimo> s/for are/for ARM/
<superm1> for this particular package it's not in debian
<micahg_> janimo: I don't think maintainers are notified on upload
<micahg_> at least in Ubuntu :)
<janimo> micahg_, that is a misfeature of LP I'd say
<janimo> I know I get mails for packages I happened to have uploaded first to ubuntu
<janimo> and my name sis still in mainatiner field
<superm1> i think if it's an explicit person listed as a name in the maintainer field they're notified
<janimo> superm1, mythtv has a 'maintainer'/owner in Ubuntu
<superm1> mailing lists/teams probably aren't because of the potentially sending out so much upload spam
<superm1> think about all the stuff with ubuntu-motu on it
<janimo> for packages which I know this is the case I am relying on the fact they follow the package closely - KDE is another example
<janimo> instead of filing bugs/debdiffs I make uploads but I am happy to post debdiffs in the future
<janimo> if that lessens the chances of miscommunication
<superm1> whatever is convenient for you, bug debdiff, email, vcs merge request, ping in irc, just somehow someone in ~mythbuntu getting notified would be good
<janimo> superm1, ok
<kirkland> ScottK: uploaded;  was a little bit of a pain as AnAnt had only included a tarball of his debian directory, rather than a merge proposal, or a debdiff;  also, i had to repack the upstream tarball
<ScottK> kirkland: Thanks.
<kirkland> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Beta-2/Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots:
<kirkland> jdstrand: slangasek: kees tells me you've had your thinkpad overheat and shut down recently?
<kirkland> jdstrand: slangasek: I've had it twice in 2 days
<ScottK> kirkland: Thanks to that upload, people who speak Uyghur will be able to read Ubuntu in their native script.
<kirkland> ScottK: cool
<jdstrand> kirkland: bug #751689
<ubottu> Launchpad bug 751689 in linux (Ubuntu) "Thinkpad x201* overheats due to slow fans when on 'auto'" [Undecided,Confirmed] https://launchpad.net/bugs/751689
<kirkland> jdstrand: thanks
<ScottK> dpm: Is there some reference on ubuntu.com about it being an Ubuntu project goal/value that everyone be able to use Ubuntu in their own language?  I thought I remembered that, but I can't find it.
<dpm> ScottK, on a session right now, let me come back to you later
<ScottK> Thanks
<GunnarHj> kirkland: https://code.launchpad.net/~gunnarhj/gdm/profile/+merge/57218 ready for you. Added a comment on the MP.
<dpm> ScottK, is this what you were looking for? -> http://www.ubuntu.com/project/about-ubuntu/our-philosophy
<slangasek> kirkland: yes, filed a bug against the kernel for this: bug #746924
<ubottu> Launchpad bug 746924 in linux (Ubuntu) "kernel default cpufreq governor fails to take action when system is overheating" [Undecided,Confirmed] https://launchpad.net/bugs/746924
<ScottK> dpm: It was.  I missed the language bit when I read it.  Thanks.
<psusi> slangasek: that's the job of the ACPI bios
<slangasek> psusi: the bios didn't change, the kernel did
<slangasek> and the bios doesn't control cpu frequency in Linux, the kernel does
<dpm> ScottK, you're welcome :)
<psusi> slangasek: the bios specifies acpi tabeles that are supposed to monitor thermal zones and do things like start fans and limit the cpu speed in response to heat.  the kernel cpufreq govenor has never responded to heat afaik
<psusi> unfortunately, most bios vendors don't bother actually complying with the acpi spec in this area
<psusi> the cpufreq govenor has no way of knowing which hwmon temperature to respond to, and how it should respond, even if you have an mwmon temperature sensor, which is why acpi bios is supposed to provide the correct tables establishing the linkages
<slangasek> psusi: ok, so why has this regressed between maverick and natty?
<psusi> why do you think it has?
<slangasek> psusi: because I can tell the difference between my machine overheating and shutting down and it not overheating and not shutting down
<psusi> that doesn't mean that it used to lower the frequency when it got hot, it could just be that you weren't getting hot before
<slangasek> yes, it may not have been lowering the frequency, I'll grant you
<slangasek> but the behavior has regressed since maverick
<psusi> something could have changed to generate more heat, but I'm fairly certain that cpufreq has not and can not respond to high temp by lowering the frequency.  Have you tried booting back into the older kernel to make sure it isn't something changing in userspace, or maybe a clogged vent or something?
<stgraber> psusi: it doesn't seem very likely that slangasek, kirkland, jdstrand and I all happened to have clogged vent issue starting with natty ;)
<kirkland> :-D
<jjohansen> in general the natty kernel seems to run a little hotter
<kirkland> stgraber: yeah, on both of my thinkpads, too
<slangasek> no, I do need to reboot to the maverick kernel to check it out; that's on my todo list for this week
<kirkland> it could just be global warming at work, too
 * jjohansen is unsure if that is because of less lock contention == work work being piped throguh or something else
 * jjohansen needs to dig but we had a bug in maverick where things ran hot too
<jdstrand> psusi: my vent is not clogged
<jdstrand> psusi: I disassembled the laptop and applied new thermal grease and blew out the fan and vent in an effort to fix this
<jdstrand> the natty kernel does run hotter
<jdstrand> my guess is the lack of big kernel lock, but I have no idea
<jdstrand> maverick's fans run just as slow though, and is the kernel is only about 8C cooler when CPUs/threads are fully utilized
<jdstrand> s/and is/and/
<psusi> how close is that to the critical trip?
<psusi> i.e. is that 8C difference the difference between shutdown and not?
<jdstrand> psusi: critical is 100C here
<jdstrand> psusi: I hit that pretty frequently in natty, less so in maverick
<jdstrand> psusi: I am now using an updated thinkfan that will actually kick the fans up to speeds that will keep it cool enough-- I have not gone higher than 86C since and that is with a lot of taxing
<chrisccoulson> jdstrand, my laptop runs much hotter in natty too
<chrisccoulson> and the battery life is absolutely horrendous
<chrisccoulson> it's less than 1 hour in natty. my battery has never been great, but it's dropped through the floor now ;)
<jdstrand> psusi: so imho there are too issues-- 1) on at least the x201 the kernel is not spinning the fans up high enough and 2) natty in general seems to run hotter
<jdstrand> (all in the bug)
<jdstrand> psusi: I don't see the bug in backscroll, it is bug #751689
<ubottu> Launchpad bug 751689 in linux (Ubuntu Natty) "Thinkpad x201* overheats due to slow fans when on 'auto'" [Critical,Confirmed] https://launchpad.net/bugs/751689
<slangasek> jdstrand: do you think I should mark 746924 a dupe of that one?
<slangasek> kirkland: "real-life physical damage" - er, it shouldn't unless the acpi tables are wrong?
<slangasek> I'm not sure the cause is slow fans in my case though
<kirkland> slangasek: let's just say I quit using my laptop on my lap
<kirkland> d-:
<slangasek> I guess I should check that out, though I can't use /proc/acpi/ibm/fan in natty anymore to do so...
<psusi> yea, the fan spinning faster when temp goes up is also what the acpi bios is supposed to do, but from what I have seen, vendors don't bother implementing
<slangasek> kirkland: oh right, because if it were better at dissipating heat, it'll be just fine to blow all the exhaust on you ;)
<jdstrand> I looked up the i7 in intel docs and it tends to run hotter than other systems, and don't think 100C will hurt the cpu (ie, when the kernel shuts down), but that won't be good for the thermal grease or other components
<kirkland> slangasek: i'd rather it blow 50C exhaust than 98C exhaust
 * slangasek prepares to argue the point with equations and diagrams
<jdstrand> slangasek: I don't know if it is the same issue or not...
<kirkland> iwconfig is reporting Bit Rate=144.4 Mb/s at this coffee shop ... that's um, impressive ...
<jdstrand> slangasek: why can't you use /proc/acpi/ibm/fan anymore?
<psusi> hrm... thinkfan eh?  I'll have to look more clusely at this.. looks like it may be a better replacement for fancontrol
<jdstrand> options thinkpad_acpi fan_control=1
<kirkland> slangasek: yeah, /proc/acpi/ibm/fan looks fine for me
<jdstrand> slangasek: drop that into /etc/modprobe.d, works fine here
<slangasek> jdstrand: oh, I thought /proc/acpi/ibm had gone away, hmm
<kirkland> kirkland@x201:~$ cat /proc/acpi/ibm/fan
<kirkland> status:         enabled
<kirkland> speed:          3274
<kirkland> level:          auto
<jdstrand> kirkland, slangasek: to manipulate it though, you need to load with fan_control=1
<slangasek> ack
<kirkland> jdstrand: right
<jdstrand> I have a thinkfan patch btw
<jdstrand> http://people.canonical.com/~jamie/thinkfan_0.7.1-2ubuntu1~jdstrand1.debdiff
<jdstrand> kirkland, slangasek: thinkfan if you don't know is a daemon that will adjust fan speed based on temperature using /proc/acpi/ibm/fan
 * slangasek nods
<jdstrand> '127' is valid on my x201s
<jdstrand> and puts the fan in disengaged mode, which keeps it from overheating (86C is the highest I've seen since using it)
<kirkland> jdstrand: interesting
<jdstrand> and that debdiff adjust thinkfan to not barf on '127'
<kirkland> jdstrand: i'd be willing to test that, if it would help get it into natty
<jdstrand> kirkland: thinkfan is universe. I consider this just a workaround. the kernel should be fixed
<kirkland> jdstrand: totally agree;  but i'm willing to use a workaround, at this point
<jdstrand> kirkland: oh yeah, by all means, use it yourself. you have a x201s?
<kirkland> jdstrand: just a plan old lower resolution x201
<kirkland> jdstrand: but i do have the i7 proc
<kirkland> jdstrand: i have a much older x61 running Maverick that I've seen it on more and more lately
<jdstrand> kirkland: be sure to read the docs, etc, but you could use this as a starting point for /etc/thinkfan.conf: http://paste.ubuntu.com/592803/
<kirkland> jdstrand: that x61 is a server for me, so it really sucks when it goes down;  i don't notice it immediately, until i need something off of it
<stgraber> jdstrand: x201s with i7 L640 ?
 * jdstrand nods
<jdstrand> stgraber: yep
<jdstrand> model name: Intel(R) Core(TM) i7 CPU       L 640  @ 2.13GHz
<stgraber> jdstrand: cool, I can use your config as-is then :)
<jdstrand> hehe
<jdstrand> also, you can adjust the bios to disable cores and/or threads which (unsurprisingly) helps quite a bit too
<psusi> slangasek: can you compare powertop readings between maverick and natty?  I wonder if you can see the higher power usage, and maybe identify what is using it
<slangasek> psusi: it only happens when I'm running the system at full throttle, there's nothing to look at in powertop that would be meaningful AFAICT
<psusi> slangasek: the overheating only happens at full throttle, but it seems likely that it is just generally hotter all the time
<psusi> and even under load, there might be too much noise to identify the cause, but confirming the higher power drain would still be informative
<psusi> it would rule out say, the fan spinning more slowly
<slangasek> sure, I'll look into it
<psusi> slangasek: I also wonder if you are seeing this printk in your logs when overheating: CPU%d: %s temperature above threshold, cpu clock throttled (t\
<psusi> otal events = %lu)\n"
<slangasek> psusi: I have such log entries from 3 days ago, yes
<stgraber> psusi: here I'm only getting this: http://paste.ubuntu.com/592821/ can't find any reference to "cpu clock throttled" in my log
<psusi> hrm... well I found that in arch/x86/kernel/cpu/mcheck/therm_throt.c, which looks like it is checking intel MSRs to notice overheating... but aside from printing the message to the log, it doesn't look like it does a damn thing about it
<slangasek> hah, good show
 * psusi grubles about lack of acpi standard compliance
<psusi> this whole file looks like an attempt to workaround broken acpi bios by using the processor specific registers directly
<slangasek> psusi: so if I'm seeing those messages, does that imply ACPI is being bypassed and not allowed to do its thing?
<psusi> slangasek: I don't think so... I think that like most other systems I have looked at, your acpi bios does not bother properly handling thermal events in accordance with the standard...
<psusi> I think that basically nobody does, and this code was written to allow the kernel to do something about it despite acpi not working right... but I can't work out just how this is supposed to work
<psusi> slangasek: see under acpi, the bios is supposed to define a thermal_zone that represents the temperature in a given area, such as that of the cpu... most venders I have looked at do this, so you can read the acpi temp
<psusi> but they are also supposed to define a fan object that allows for monitoring and control of any fans, as well as a relationship between the fan(s) and thermal_zones, including when they should be ramped up..
<psusi> also a relationship between the cpu and the tz so that it can be throttled... but from what I have seen, nodboy botheres with all of this
<psusi> from what I can see, they just stop at the tz and have it signal critical temp, time to shut down... no fan and no throttling
<slangasek> psusi: so my ACPI implementation definitely has exposed under /sys information about four cooling devices and associated temperature trip points; unfortunately they all seem to have a trip point set higher than the critical temp at which emergency shutdown occurs (127.5Â°C vs. 100Â°C)
<slangasek> I also, under the current kernel, can't find where the emergency shutdown limit is set
<psusi> hrm.. interesting.... I think it was set by the thermal_zone
<slangasek> under the last kernel I had booted, these limits were *different8
<slangasek> the last natty kernel
<psusi> you have a 4 core cpu?
<slangasek> it was 100 and 92-ish
<slangasek> yes
<psusi> hrm... yea, I would expect a well behaved bios to have the tz crit at 100 for shutdown, and each cpu core counts as a cooling_device which should be linked to the tz to engage throttling at say, 92
<slangasek> ok, here we go
<slangasek> $ cat /sys/class/thermal/thermal_zone0/trip_point_*
<slangasek> 100000
<slangasek> critical
<slangasek> 127500
<slangasek> passive
<slangasek> so the cooling devices all trigger on the latter trip point, which is higher than the critical point
<slangasek> say what
<psusi> yea, that looks borked
<psusi> bbiab, need to head home
<LLStarks> hi, i'm wondering whether it's too late to draft up proposals for uds-o. i'd like to present a grub2-gfxmenu implementation to cjwatson and other interested parties.
<jdong> kees: random question: I don't suppose SSP can be disabled on a per-function basis, can it?
<kees> jdong: no, and if you've got that level of knowledge, why not fix the function? :P
<jdong> kees: haha sadly the brokenness is the stack canary actually affects performance in the codepath.
<jdong> kees: and I already had to eat my hat for claiming it wouldn't!
<kees> jdong: ugh. what code? it's usually very minor. anything that has strings on the stack usually doesn't have a measurable difference when adding SSP
<jdong> kees: it's an interrupt service routine on ARM; only discovered the performance discrepancy after porting it to an environment where -fstack-protector is default
<jdong> I mean of course I can just change the buffer type to be one that -fstack-protector doesn't care about :)
<kees> jdong: in the kernel?
<slangasek> mvo: I was pleasantly surprised to see all the multiarch fixes going into the package management infrastructure the past couple of weeks... I really expected multiarch to be enable-on-your-desktop-at-your-peril for this cycle, and was surprised when update-manager started working for me again :)
<mvo> slangasek: yeah, its pretty cool, the full stack has support now, even in synaptic we have basic support (and aptdaemon too) and you can click on foo:i386 and watch the resolver churn and try to come up with a solution. its quite cool
<slangasek> indeed :)
 * mvo sends hugs to donkult and juliank for their great work on this
<lifeless> \o/
<mvo> bedtime for me now, see you all tomorrow
 * mvo waves
<micahg_> pitti: so, I discovered what happened to the pidgin symbols, it seems they were intentionally dropped upstream due to portability concerns, I also found that this seems to cause a problem for dockmanager which is a new package in natty, so no inherent regression
<pitti> micahg_: ah, that explains it at least
<micahg_> pitti: and that probably should've had an FFe, sorry about that
<psusi> slangasek, so you said your thermal zone has only critical and passive trip points?  no active?  and the passive is higher than critical?
<slangasek> psusi: yes
<psusi> slangasek, that shouldn't change with kernel version, but have to checked if it is like that in maverick?
<psusi> because that does look like broken acpi bios
<slangasek> no, I haven't checked
<slangasek> regardless, broken acpi is the world we live in - Ubuntu still needs to behave appropriately in the face of it
<psusi> then you need to come up with specific workarounds for every piece of broken hardware
<syn-ack> I hate it when a former employer makes it impossible to verify that you worked there because they're that much of a jerk
<jcastro> kees: I need you to add some people to ~ubuntu-drivers when you get a chance, only TB folks can do so
<kees> jcastro: oh? for UDS planning? I thought all that got sorted out already.
<jcastro> kees: we're missing jdstrand and jasonwarner
<jcastro> kees: and probably iain-farrell too for the Design track
<kees> jcastro: shouldn't they be part of uds organizers?
 * jcastro looks
<jcastro> ok weird, what's the difference between a track lead and a driver? ok, yeah, uds-organizers makes sense
<jcastro> kees: whatever lets people schedule but not also allow them to like upload glibc or something. :p
<azeem> it's like rhythm and lead guitar
<kees> jcastro: I've added jdstrand jasoncwarner and iain-farrell to uds-organizers now
<jcastro> looks good!
<jdstrand> does that mean I can't upload glibc anymore? :P
 * jdstrand doesn't actually ever touch glibc ;)
<psusi> slangasek, heh, I can't even get my netbook to its 85c passive trip point.. seems to top out at 50
<kees> jdstrand: that would be funny. have uds-organizers block membership in core-dev ;)
<jdstrand> :)
<slangasek> psusi: you need a more powerful processor then! :)
<psusi> slangasek, indeed... it's only a 1.3 ghz 10 watt celleron ;)
<jdstrand> slangasek, kirkland: for giggles, I updated my bios. when I went into my bios after to check on things, I noticed something called Advanced Thermal Management. Thinking that sounded promising, I moved when on AC from 'Maximum Performance' to 'Balanced'. I don't know if it will fix anything or not yet, I just did it
<slangasek> jdstrand: do you have similar-looking trip points under /sys/class/thermal/thermal_zone*/ ?
<jdstrand> it seems like as soon as the temp gets around 83, it does something because it drops down 5-10 degrees or more every now and again, but I don't know if that is just the state of my builds or what
<jdstrand> $ cat ./trip_point_*
<jdstrand> 100000
<jdstrand> critical
<jdstrand> 91500
<jdstrand> passive
<slangasek> right, that's what I had last time I looked
<slangasek> now my passive is higher than my critical which is screwy
<jdstrand> interesting-- when compiling 3 kde4libs at the same time, it never goes above 83, and as soon as it gets there, it drops to 75 or so (this is with thinkfan mind you-- but before it would go up to and stay at 86C)
<jdstrand> balanved may be worthwhile
<jdstrand> (anecdotal)
<psusi> jdstrand, what's the fan doing during this time?
<psusi> jdstrand, also it would be helpful to run stress for an even full load instead of something unpredictable like a compile
<jdstrand> psusi: well, I am using thinkfan atm, and its above my threshold so it is disengaged
<jdstrand> re stres> yes, hence the 'anecdotal' :)
<psusi> jdstrand, can you read the actual fan speed?  maybe with lm-sensors?
<jdstrand> it is 6425
<jdstrand> its disengaged-- I setup thinkfan to monitor the temp and go full-speed about 75
<psusi> jdstrand, so when the temp drops does the fan speed go up?  or is the cpu being throttled?
<jdstrand> s/about/at/
<jdstrand> psusi: right, I think the cpu is being throttled with this new 'balanced' thermal management setting in the bios
<psusi> jdstrand, did the trip_point values change as a result?
<jdstrand> psusi: I didn't look before, so I don't know
<psusi> jdstrand, well if the trip point is 91.5 then it shouldn't be throttling until you hit that
<psusi> so my guess is that the fan speed is going up
<jdstrand> the fan speed is not going up
<jdstrand> is is at ~6400
<jdstrand> I am monitoring both temp and fan at the same time
<jdstrand> 6400 is max fan speed
<psusi> jdstrand, both before it hits 83 and while it is dropping to 75?
<jdstrand> psusi: yes. thinkfan is setup up to be 'disengaged' at 75 and higher
<psusi> jdstrand, then the big question is whether this happens with stress -c instead
<jdstrand> fan speed is steady-- cpu meter is pegged to the top, temp is fluctuating between 75 and 83
<jdstrand> well, what I need to do is that and disable thinkfan and see what is happening
<psusi> jdstrand, also, how about the frequency?  do you keep an eye on that?
<jdstrand> not currently
<jdstrand> I was trying to see where that is
<jdstrand> oh
<jdstrand> /proc/cpuinfo
<jdstrand> yeah, it just went from 2134.000 to 1199.000
<psusi> jdstrand, add the cpu frequency scaling applet to panel
<jdstrand> this advanced thermal management thing is a bios deal
<jdstrand> I don't have a panel, I am using unity :)
<jdstrand> but, I can't stay longer
 * jdstrand has an appt
<jdstrand> this likely works fine: watch 'cat ./cpuinfo |grep MHz'
<jdstrand> yep, got to 82 then dropped to 1199
<jdstrand> temp went to 72 and cpu went up to 2134
<jdstrand> neat
<jdstrand> ok, gotta go
<psusi> hrm... weird...
<jdstrand> I don't clean to know how 'advanced thermal management' works btw...
 * jdstrand -> really gone
<jdstrand> s/clean/claim/
#ubuntu-devel 2011-04-12
<mtaylor> ScottK: re: debbug#621045/bug#752164 - I just uploaded a fixed package to mentors.debian.net but it doesn't seem to be showing up
<mtaylor> ScottK: but I did push the packaging branch to lp:~mordred/debian/sid/python-drizzle/trunk ... I've got to run out for the night, but if it happens to either show up on mentors or you feel like bzr bd -S ing that branch and uploading to debian for me... I wouldn't complain :)
<mtaylor> ScottK: if not, I'll track it down tomorrow
<poolie> o/ mtaylor
<mtaylor> hey poolie
<poolie> brb
<ScottK> mtaylor: I replied in the bug.  DPMT svn is the best place for it.
<Jerub> g'day. this bug is marked as closed/fix-released: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/630748
<ubottu> Ubuntu bug 630748 in Linux "iwlagn degrades quickly during normal wifi session" [High,Confirmed]
<Jerub> but i can replicate it on the same hardware as the original bug reporter's hardware with the very latest natty debs
<lifeless> #ubuntu-kernel
<Jerub> thakns
<linuxtech> Is UCK - Ubuntu Customization Kit the tool used to create the official Ubuntu, Kubuntu an other recognized derivatives?
<G> Jerub: for what it's worth, it's happening everywhere, and I once saw an Intel bug about it
<Jerub> G: i know it's not an uncommonly reported problem, the reason i'm following this up is that it's been marked as 'fix-released' but it's not fixed.
<TheMuso> linuxtech: No its not.
<TheMuso> linuxtech: The official Ubuntu flavours are built with a combination of some custom scripts written by Canonical and an oldish version of debian-cd.
<linuxtech> I think this might be it. lp:ubuntu-cdimage .
<TheMuso> Yes but thats just one part of it.
<TheMuso> https://launchpad.net/debian-cd and launchpad.net/livecd-rootfs are the others.
<linuxtech> Thanks.
<abhinav-> i have a bug fix for bug 757635 . If I send it upstream, will I get launchpad karma ? :D (its a 4-5 line patch)
<ubottu> Launchpad bug 757635 in tomboy "Selecting all text in search box and hitting Delete key triggers the deletion of note" [Medium,Confirmed] https://launchpad.net/bugs/757635
<didrocks> good morning
<mdke> pitti: morning. I am about to upload a new version of gnome-user-docs with some updated documentation. With apologies for the delay, but the documentation at the moment simply doesn't reflect the new Unity desktop so it seems to us unavoidable
<mdke> pitti: one favour. We're using gnome-user-docs for the documentation this cycle, so that ubuntu-docs can be dropped from the seeds. Could you take care of that?
<robert_ancell> diwic, hey, is the sound test working for you with the latest natty?
<diwic> robert_ancell, let me check
<diwic> robert_ancell, yes it is (we released my patch into it)
<robert_ancell> diwic, hmm, so that's strange, it's gone back to the old behaviour for me.
<pitti> Good monring
<diwic> robert_ancell, what's the old behaviour?
<robert_ancell> diwic, of not playing any sound when you do the test
<pitti> mdke: oh, sure; for dropping ubuntu-docs, do we need to update anything else, such as yelp: links in existing packages? (jockey comes to my mind) or were these copied to g-u-d?
<robert_ancell> diwic, I thought it was your patch, as it was using the correct sounds when I installed the freedesktop theme, but even if I roll back to the old package it still doesn't work for me
<robert_ancell> canberra-gtk-play works correctly, and other sounds effects seem fine
<robert_ancell> pitti, are you running the latest natty?
<pitti> robert_ancell: always
<robert_ancell> pitti, can you go to sound preferences, make sure window and button sounds are disabled, then check the speaker test works?
<mdke> pitti: ah, good point. Yelp is fine and up to date, but I hadn't thought of packages which use ubuntu-docs for their help
<diwic> robert_ancell, do you have the freedesktop theme installed or not?
<robert_ancell> diwic, I do, but uninstalling it makes no difference
<diwic> robert_ancell, ok
<mdke> pitti: perhaps don't drop it while I have a think about that! I think jockey is the only one but will check
<robert_ancell> diwic, was there are change needed for ubuntu-sounds?  It hasn't updated and it doesn't provide a test sound
<pitti> robert_ancell: I have set "no theme" for "sound theme" (disabled all), and the speaker test works, yes; I get a "thud" sound
<pitti> mdke: ah, we might move the lecture about drivers to jockey itself perhaps
<robert_ancell> pitti, could you install sound-theme-freedesktop and see if it says "left channel" etc instead of making the thud?
<diwic> robert_ancell, well, seems like not everybody agreed to the idea of a longer and more intense sound and preferred the "thud" sound so nothing was changed
<pitti> robert_ancell: it does (in English, though)
<robert_ancell> diwic, ok, looks like my system has got messed up somewhere, and it is fixed correctly.  Sorry for the noise!
<robert_ancell> pitti, thanks
<diwic> pitti, thanks for the testing
<pitti> you're welcome
<mdke> pitti: I think that would be the ideal solution
<diwic> robert_ancell, ok, can you now help me to convince upstream that there is a bug :-)
<mdke> pitti: although possibly some help about this already exists in gnome-user-docs that could be used, i will raise a discussion about it
<robert_ancell> diwic, yeah, I've totally messed up the upstream report, sorry!
<mdke> pitti: as a note to self we also have usb-creator that uses ubuntu-docs. Thanks for thinking of this issue!
<diwic> robert_ancell, you might know the gtk settings system better than I, where/how do we actually set the gtk-sound-theme-name property to "ubuntu"?
<robert_ancell> TheMuso, ^^ do you know?
<mdke> pitti: nb the new gnome-user-docs is a bit larger than the old one due to the presence of screenshots, I have also raised as a discussion whether we can trim it down in the next day or so
<diwic> robert_ancell, there is a theme_name property in gconf /desktop/gnome/sound, what is that set to on your system? It's "ubuntu" here.
<robert_ancell> diwic, yeah, I get the same, and interestingly the default is "freedesktop".  So something must set it somewhere
<robert_ancell> diwic, I wonder if it picks Ubuntu because there is no freedesktop theme installed by default
<diwic> robert_ancell, also, is it really that key that translates into gtk-sound-theme-name?
<diwic> robert_ancell, the names are a bit different
<robert_ancell> diwic, it's in /usr/share/gconf/defaults/16_gnome-session-canberra
<robert_ancell> in package gnome-session-canberra
<mdke> pitti: the package is uploaded, I'll followup these issues on the ubuntu-doc mailing list and hopefully solve them later
<robert_ancell> gtg, later all
<mdke> afk
<pitti> mdke: ok; if we can remove ubuntu-docs, we can use the extra space for g-u-d
<dholbach> good morning
<ion> that
<abhinav-> dholbach: good morning. I have a fix for bug 757635 . Should I propose it for merging ? I have sent the patch to the upstream developers as well.
<ubottu> Launchpad bug 757635 in tomboy "Selecting all text in search box and hitting Delete key triggers the deletion of note" [Medium,Confirmed] https://launchpad.net/bugs/757635
<dholbach> abhinav-, sure
<abhinav-> thanks :)
<ev> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Beta-2/Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: ev
<ev> now accepting patches to merge in exchange for modest bribes
<TheMuso> diwic: libcanberra sets the theme.
<diwic> TheMuso, so we have disabled the dependency on module-raop, but what about those who already got it installed - is there a way we can get it out of their systems? (An option could be to actually fix the crash bug...)
<TheMuso> diwic: Yes that is one way of solving it, but that is the joy of a dev cycle. Many packages are added as deps and removed at a later date, its not uncommon.
<TheMuso> diwic: I think atm we can simply suggest to users that they can remove the raop package as a workaround if they get any crashes. Otherwise there is no problem being left there on user systems if no issues arrise.
<pitti> siretart: do you have a particular interest in x264/mplayer on powerpc? x264 failed to build there, and thus we have some uninstallable packages (mplayer, etc.)
<pitti> siretart: see http://people.canonical.com/~ubuntu-archive/nbs.html
<pitti> siretart: if not, I'll just remove them and declare it broken
<pitti> remove the NBS libx264-98 I mean
<seb128> cjwatson, quite some users seem to run into bug #756297 (just pointing it in case that's useful information, not sure if you notice the retracer activity or not)
<ubottu> Launchpad bug 756297 in grub2 (Ubuntu) "grub-mount assert failure: *** glibc detected *** grub-mount: free(): corrupted unsorted chunks: 0x09530568 ***" [Medium,New] https://launchpad.net/bugs/756297
<ohsix> TheMuso: is it reported upstream? if not colin & arun would probably like to know
<dpm> hi ev, I've heard you're patch piloting today :-). May I ask you to have a look at  bug 757468? The patch seems trivial and it's a really visible string
<ubottu> Launchpad bug 757468 in Ubuntu Translations "Cancel button in the gdm login screen is not localized" [High,Triaged] https://launchpad.net/bugs/757468
<ev> dpm: will do!
<dpm> awesome, thanks ev!
<AnAnt> Hello, will the notification area be added to Unity or not ?
<RAOF> AnAnt: It's already there.
<AnAnt> RAOF: ?
<RAOF> AnAnt: Start up, say, Steam :)
<AnAnt> RAOF: I just tried it now (and another friend), and we don't see it
<AnAnt> steam ?
<RAOF> However, it's guarded by a whitelist; wine is on the whitelist, so Steam shows up.
<cjwatson> seb128: I've noticed that grub-mount bug, but I can't reproduce it myself and haven't yet managed to untangle anything fixable from the traceback
<cjwatson> seb128: if you look at the comments in bug 756297, you'll see that I already replied asking for more information
<ubottu> Launchpad bug 756297 in grub2 (Ubuntu) "grub-mount assert failure: *** glibc detected *** grub-mount: free(): corrupted unsorted chunks: 0x09530568 ***" [Medium,New] https://launchpad.net/bugs/756297
<cjwatson> (which hasn't been provided)
<seb128> cjwatson, right, I saw your comment but I was not sure if you added it before it had duplicates and were considering it as being a corrupted fs issue from one user
<seb128> cjwatson, I prefered to point it just in case
<cjwatson> seb128: oh, no, grub-mount is brand spanking new code and so it's not entirely surprising that it might have bugs
<cjwatson> I only introduced it because I was caught between two impossible situations in os-prober and this was a way out
<seb128> cjwatson, ok anyway as said I just pointed it because it showed up in my daily retrace log grepping for common crashers
<seb128> cjwatson, thanks
<cjwatson> yep, appreciate the heads-up
<cjwatson> I guess I'll trawl through all the dups today and see if any of them has anything useful
<AnAnt> RAOF: will it remain guarded by the whitelist ?
<AnAnt> RAOF: anyways, where is that whitelist ? is it configurable ?
<pitti> RAOF, tseliot: as nvidia 173 and 96 are uninstallable, is there hope that nvidia will update these for the current X.org ABI? if not, we might just as well remove them to avoid confusion?
<tseliot> pitti: they will be updated but we don't know exactly when
<pitti> tseliot: ah, good
<pitti> Riddell, ScottK: would you mind if I upload a kubuntu-meta which drops nvidia-glx-{96,173}? they are uninstallable right now
<pitti> and nvidia-glx-180 doesn't exist any more and should be removed
<pitti> doko: was openjdk-6 ever meant to actually build on armel? or should we just ignore the uninstallability of it in http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html ?
<cjwatson> pitti: that's what openjdk-6b18 is for
<pitti> ah, that just doesn't build jre-lib/-source
<pitti> so I guess "ignore"
<pitti> cjwatson: so the nvidia drivers are expected, the java bits as well, evolution/armel is building; no idea about usb-creator, it's arch:all
<doko> pitti: yes, ignore. too lazy to change the architecture field
<pitti> doko: ack, thanks for confirming
<Daviey> cjwatson, Hi - do you have any more ideas with Bug #728088?  Is there anything we can do to help?
<ubottu> Launchpad bug 728088 in debian-installer (Ubuntu Natty) "iscsi root (amd64) with or without auth fails to boot" [High,Incomplete] https://launchpad.net/bugs/728088
<Riddell> pitti: go for it
<cjwatson> Daviey: give me a recipe for reproducing it in kvm that doesn't involve a hardy server ...
<cjwatson> Daviey: I suspect it isn't server-dependent anyway.  FWIW my setup is an ietd on my host system with a 1GB disk attached
<cjwatson> (currently)
<pitti> Riddell: seeds updated, rebuilding meta now
<Daviey> cjwatson, ok, thanks
<ev> dpm: uploaded; waiting for review
<dpm> ev, oh awesome, thanks!
<ev> dpm: any time
<davidgiluk> I've been looking at an ARM ftbfs bug 745861 and have fallen into an MPI bare trap - any MPI people around?
<ubottu> Launchpad bug 745861 in petsc (Ubuntu) "petsc version 3.1.dfsg-10ubuntu1 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/745861
<FauxFaux> A bare trap sounds strangely erotic.
<davidgiluk> oops yep; bear trap even!
<janimo> a beer trap would appeal to the kernel team
<mdz> tjaalton, around?
<mdz> tjaalton, I just helped silbs provide a fresh set of logs for bug 747205 using apport-collect, but I want to confirm which ones you actually wanted
<ubottu> Launchpad bug 747205 in libdrm (Ubuntu) "[arrandale] Black screen on boot, associated with GPU lockup (ESR: 0x00000001 IPEHR: 0x7a005502)" [High,Triaged] https://launchpad.net/bugs/747205
<mdz> tjaalton, oh, I see you just wanted Xorg.0.log and dmesg. you have those now
<tjaalton> mdz: oh cool, thanks
<AnAnt> is there a way to override dconf settings in a package ?
<AnAnt> is it by installing a conf file in /usr/share/GConf/ ?
<seb128> AnAnt, you can add a .override in /usr/share/glib-2.0/schemas
<seb128> AnAnt, the GConf files are to convert gconf settings to gsettings ones, it happens once for upgrades
<AnAnt> seb128: I thought /usr/share/glib-2.0/schemas contains the schemas, not overrides
<seb128> they have both it seems
<AnAnt> I see
<AnAnt> does the instructions in http://www.omgubuntu.co.uk/2011/03/how-to-hide-or-show-app-tray-applets-in-ubuntu-11-04/ still work ?
<AnAnt> ie: gsettings set com.canonical.Unity.Panel systray-whitelist ['app1', 'app2', ... ]
<kklimonda> I don't think it's a good idea to override whitelist in the package, unless it's a local package, and not the one that goes to archive.
<AnAnt> kklimonda: it won't go to archive, it's for a derivative distro
<kklimonda> also, I wonder what would happen if more than one package tried to override the same list.
<AnAnt> kklimonda: they can use that script: http://www.fewt.com/2011/03/whitelist-utility-script-to-allow-apps.html
<AnAnt> thing is that I tried to override the white list locally, but nothing happened
<AnAnt> the apps that use notification area still don't show up
<kklimonda> maybe try restarting?
<AnAnt> kklimonda: I did logout & login again
<AnAnt> funny this is that removing skype for example does work (after a logout & login), but adding apps does not work
<AnAnt> ah, it works
<kirkland> jdstrand: i'll give that a try
<kirkland> jdstrand: in case you didn't know, byobu can monitor both your fan speed and cpu temp constantly
<jdstrand> kirkland: you mean the 'balanced' thing?
<kirkland> jdstrand: yeah, sorry
<jdstrand> kirkland: I just disabled thinkfan (/etc/default/thinkfan) and am running just on 'auto' and 'balanced' now
<AnAnt> thanks !
<kirkland> jdstrand: cool
<kirkland> jdstrand: i'm going to checkfor a bios update
<jdstrand> kirkland: I need to put it through its paces of course
<jdstrand> kirkland: yeah, I did a bios update-- but I don't know that it was strictly required-- it was just what prompted me to look around in the bios again
<kirkland> jdstrand: oh? i'll check mine before i update, then
<kirkland> jdstrand: i'm distupgrading now, will reboot shortly
<jdstrand> kirkland: it was under the 'Power' menu here
<mdz> tjaalton, if you want to do more detailed debugging with 747205, I'm available in one hour
<jdstrand> kirkland: re byobu> cool. to fully monitor 'balanced' you'll also want to look at the cpu freq scaling. I don't know the best way to do that, but a quite crude method I am using right now is: watch 'cat /proc/cpuinfo |grep MHz'
<kirkland> jdstrand: okay, no bios update, and i did see those power options
<kirkland> jdstrand: i switch from advanced -> balanced in AC/Power mode
<kirkland> jdstrand: i was already on balanced for battery
<kirkland> jdstrand: the last time my machine overheated and powered off, though, i was on battery
<jdstrand> kirkland: interesting
<kirkland> jdstrand: but the time before that i was on AC (and docked in my docking station)
<kirkland> jdstrand: so I've experienced it both on battery and AC in the last 3 days
<jdstrand> kirkland: yeah, that was the setting I had too (battery/balanced, ac/perf, now balanced on both)
<kirkland> jdstrand: anyway, i've enabled the cpu_fan and cpu_temp monitors in byobu and i'm watching them closely now
<jdstrand> ok, well, we may still need thinkfan then...
<kirkland> jdstrand: i'm going to run without thinkfan for now, and let you know
<jdstrand> I'm doing the same
<kirkland> jdstrand: i have a bunch of work today to do in KVM's, so I'll stress it from a KVM perspective
 * jdstrand goes to fire up concurrent kde4libs builds
<ogra_> mvo, around ?
<tjaalton> mdz: good, I'll check if upstream is available and ask what they need (now that dmesg & xorg log are ~useless)
<mvo> ogra_: yes
<ogra_> mvo, i have a pytjon-apt prob, it seems enable_component just ignores deb-src lines ....
<ogra_> mvo, using a script like http://paste.ubuntu.com/592844/ results in a sources.list like http://paste.ubuntu.com/593101/
<ogra_> according to the doc it should also add the components to the deb-src lines
<mvo> ogra_: hm, sounds like a bug, but should be easy to fix
<ogra_> mvo, ah, will file it, do you think we can get it done before release ? else armel users end up with the entries missing (its harder to change after release)
<mvo> ogra_: depends how much debugging on the db-modified problem I'm currently working on goes, but it should be possible, the bug is probably straightforward
<ogra_> mvo, https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/758732
<ubottu> Ubuntu bug 758732 in python-apt (Ubuntu Natty) "enable_component() does not enable components for deb-src lines" [Medium,New]
<ogra_> oh, ubotu is back !
<mvo> thx
<GunnarHj> kirkland: Good morning, Dustin. Did you see that I updated the gdm MP (bug 678421)?
<ubottu> Launchpad bug 678421 in gdm (Ubuntu) "Error in ~/.profile halts the X startup" [Low,In progress] https://launchpad.net/bugs/678421
<zul> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Beta-2/Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: ev, zul
<kirkland> GunnarHj: i did, i'm going to try and get to that today
<GunnarHj> kirkland: Ok, thanks!
<zul> chrisccoulson: ping can you have a look at bug #723830 i dont know enough about seamonkey to comment about it
<ubottu> Launchpad bug 723830 in seamonkey (Ubuntu) "seamonkey-2.0-bin assert failure: *** buffer overflow detected ***: /usr/lib/seamonkey-2.0.11/seamonkey-2.0-bin terminated" [Medium,New] https://launchpad.net/bugs/723830
<chrisccoulson> zul - yeah, will take a look in a bit
<zul> chrisccoulson: thanks
<siretart> pitti: I don't have a machine to test it. I imagine that it's not particulary hard to fix, and TBH, I'd even expect it to be fixed in a later upstream version
<siretart> pitti: but currently, I'malso  pretty short on time to work on that
<pitti> siretart: so shall we just remove the NBS library and leave the remaining 5 rdepends broken on powerpc? (sounds fine to me)
<pitti> siretart: I just didn't want to kill it before at least asking you
<siretart> pitti: TBH, I think that's a reasonable approach for right now. and who know, it might be eventually processed in debian as well and maybe some porter manages to fix it
<pitti> *nod* thanks
<tjaalton> mdz: so, if the bug happens only after logging in, it might be another compiz crasher
<tjaalton> mdz: to verify that, try logging in using the 2d classic session, and attach the monitor
<stgraber> mvo: want me to look at bug 758732 ? I don't have much on my todo list for the day (yet) :)
<ubottu> Launchpad bug 758732 in python-apt (Ubuntu Natty) "enable_component() does not enable components for deb-src lines" [Medium,New] https://launchpad.net/bugs/758732
<Daviey> jhunt, What would cause an "initctl emit xyz" to seemingly wedge?
<mvo> stgraber: sure, that should be a straightforward one, please go ahead :)
<jhunt> Daviey: prolly a job that has a "start/stop on xyz" that is taking some time to do its thing.
<Daviey> jhunt, 10 mins?
<jhunt> Daviey: Have you tried: http://upstart.ubuntu.com/cookbook/#establish-blocking-job
<Daviey> jhunt, Hmm..no  -sounds like what i need.
<Daviey> thanks
<jhunt> Daviey: np - let me know how it goes.
<slangasek> doko: ecj1 seems to be broken on armel (https://launchpadlibrarian.net/69105779/buildlog_ubuntu-natty-armel.libidn_1.18-1multiarch1_FAILEDTOBUILD.txt.gz)
<Daviey> jhunt, Well i won't be able to tell now until i reinstall and do an upgrade test
<tjaalton> hmm, apport really should have an option to attach a single file to an existing bug, or does it already?
<tjaalton> would be handy to tell people to run 'sudo foo | apport-collect --attach 213489' or such
<highvoltage> is it a feature or bug that I'm in / by default when opening a new gnome terminal?
<JanC> that sounds like a bug  ;)
<highvoltage> ok, I wasn't sure maybe it was an ayatana decision or something
<JanC> highvoltage: is $HOME set in that terminal?
<highvoltage> JanC: it's my home directory
<ion> The process that launches the terminal was perhaps started in /
<highvoltage> it was started from unity-2d
<stgraber> ogra_,mvo: I have a fix for the python-apt bug: http://paste.ubuntu.com/593137/
<mvo> stgraber: great, thanks a bunch
<stgraber> mvo: I'm going to just upload a new python-apt with that change. Are you maintaining the package in Debian ? if so, can you push the fix there too ?
<mdz> tjaalton, that would be useful, though it might fit better someplace other than apport
<mdz> like ubuntu-dev-tools or something
<mvo> stgraber: I will push it to debian, could you merge it into lp:~ubuntu-core-dev/python-apt/ubuntu please?
<stgraber> mvo: sure
<tjaalton> mdz: yeah
<mdz> tjaalton, did you notice the xrandr output? it shows VGA1 disconnected
<tjaalton> mdz: but it was with the vga disconnected?
<tjaalton> ah
<tjaalton> with --auto
<tjaalton> though, if it's disconnected there's much --auto will do :)
<tjaalton> +not
<mdz> tjaalton, oh, right, it was disconnected indeed
<mdz> I was looking for the LVDS1  and Screen status
<mdz> both of which look reasonable
<tjaalton> yep
<tjaalton> actually the old x logs don't show the vga at all
<tjaalton> so interesting to see if xrandr would show it
<smoser> anyone know how to make 'ubuntu-bug' not launch a browser ?
<smoser> i'im assuming it will work if DISPLAY is not set. but i want to have DISPLAY set, just want to copy and paste the url (ie, i dont want to login to launchpad in the browser it will spawn)
<jdstrand> kirkland: I just noticed that 'balanced' is not enough too. fan level 7 might be (it is faster than 'auto'). see my comments in the bug
<jdstrand> kirkland: it is almost good enough though
<charlie-tca> smoser: will the email interface allow you to file a bug?
<stgraber> mvo: is there any reason to keep the oneiric task on bug 745532 now that it'll be fixed in natty ? (not really sure why it was added in the first place)
<ubottu> Launchpad bug 745532 in pam (Ubuntu Oneiric) "fails to restart (not running) gdm on maverick->natty upgrade" [Undecided,New] https://launchpad.net/bugs/745532
<cnd> jcastro, I'm playing with bzr bd for daily build recipes, and I'm wondering how I can nest the current packaging branch but delete any patches in it
<smoser> charlie-tca, i could do that, but i was just wanting to use ubuntu-bug to have it use apport-collect and such also
<mvo> stgraber: no, just close it
<cnd> jcastro, do you know, or know who would?
<jcastro> cnd: oh, no clue on that one. that's never come up for me before
<jcastro> cnd: I think someone on deryckh's team was working on recipes
<cnd> jcastro, our packaging includes patches cherry-picked from the trunk
<jcastro> cnd: rockstar was working on build recipes but I think he moved to ubuntuone
<cnd> jcastro, I'm testing a dailydeb recipe right now, but I can't figure out where bzr dailydeb comes from?
<cnd> I assumed from bzr-builddeb, but that doesn't appear to be the case
<cnd> jcastro, nm, didn't read close enough
<cnd> it's bzr-builder, not bzr-builddeb :)
<jcastro> cnd: "hey, man.  I would say abentley, thumper, or jelmer can help you there."
<jcastro> cnd: ^^ there are the bd pros
<cnd> jcastro, thanks!
<jcastro> cnd: when they sort it make sure they put that on the wiki page/help thing they have
<jcastro> actually it's surprising no one's asked that before
<cnd> jcastro, will do
<juliank> stgraber: Was there really a reason to mess up the python-apt ubuntu branch with one commit that changes things, but has the message "releasing version 0.7.100.3ubuntu4"?
<juliank> This should have been two commits, one fixing the bug, and one for the releasing part.
<juliank> And a few hours two late, otherwise it would have been in the Debian upload as well
<stgraber> juliank: woops, indeed. How big a deal is it that it's not two separate commits ? I can uncommit, commit the python change, then commit the changelog entry if that helps. (though I usually don't like uncommiting stuff that are already on LP ...)
<juliank> stgraber: Now it's too late.
<juliank> stgraber: Was it really that urgent anyway? It's only two hours old, and not really more important than the complete mismatch of sizes on ARM that I fixed this morning
<cjwatson> you *can* uncommit stuff already on LP; it only matters if somebody's branched
<juliank> cjwatson: nobody said anything different
<cjwatson> sure, I was just clarifying
<juliank> The rest is going to be merged after beta 2 then, bringing python-apt bug count down to 3
<seb128> juliank, great work ;-)
<stgraber> juliank: "14:50 < ogra_> mvo, ah, will file it, do you think we can get it done before release ? else armel users end up with the entries missing (its harder to change after release)" seemed relatively urgent as we usually want minimum delta between beta2 (or RC) and release (wasn't aware you were working on another upload, I should have checked)
<juliank> stgraber: mvo wanted to merge my changes after the beta 2 freeze. Anyway, I now merged your fix into the debian-experimental branch on bzr.debian.org for next tuesday's upload to Debian
<stgraber> juliank: thanks
<mvo> stgraber, juliank: yeah, I plan to merge/cherrypick more of the fixes from debian-experimental, its looks really good and safe. but after the freeze
<pitti> mvo, tremolux, anyone: I have the "pygtk -> pygi" app dev week session in 10 minutes, in case you want to join for next cycle's "happy pygi porting" :)
<dpm> pitti, all set for the UADW talk in 10?
<pitti> dpm: thumbs up
<dpm> pitti, I see you answered the question even I asked it!
<tremolux> pitti: ah, nice!
<pitti> dpm: just catching up on https://wiki.ubuntu.com/Classroom/ClassBot
<dpm> even *before
<dpm> cool :)
<dpm> pitti, yeah, it's mostly !q and then !y or !n
<pitti> dpm: with /msg ClassBot, I figure?
<dpm> yeah
<pitti> dpm: or rather, I just open a /query to ClassBot and type there?
<dpm> pitti, classbot will do it for you. You can then type there as well
<nigelb> pitti: Hi, could you join #ubuntu-classroom?
<nigelb> (the bot's complaining you aren't there)
<pitti> nigelb: heh, I just did
<nigelb> pitti: oh, and #ubuntu-classroom-backstage might be a good idea too :)
<mvo> pitti: we definitely want to join the fun
<pitti> -ETOOMANYCHANNELS, -chat as well..
<nigelb> yeah :)
<ogra_> bug 758910
<ubottu> Launchpad bug 758910 in ubiquity (Ubuntu) "oem-config-remove-gtk crashed with SIGSEGV in gdk_window_enable_synchronized_configure()" [Undecided,New] https://launchpad.net/bugs/758910
<nigelb> pitti: any troubles with the bot? :)
<pitti> nigelb: worked like a charm! very useful indeed, I didn't have that on my last talk yet
<nigelb> pitti: we've had it for some time
<pitti> I didn't do a talk in the last cycle
<c2tarun> can anyone please tell me how can I find that which is my boot partition? please reply soon, its urgent
<sladen> c2tarun: cat /proc/fstab
<c2tarun> sladen: there is no such file or directory :(
<sladen> c2tarun: cat /etc/fstab
<c2tarun> sladen: http://pastebin.com/mieA1E3W how can I find which is the partition?
<sladen> c2tarun: the line that contains " / " (/ == root).  And immediately above is a comment line that says "/ was on /dev/sda1"
<sladen> c2tarun: since you have no /boot mounted, I would assume (unless you have a very, very, complicated setup) that /dev/sda1 is also your boot partition
<slangasek> doko: fwiw I have a fix here for ecj to get ecj1 rebootstrapped and usable on armel... but it fails to build on armel with a bus error
<micahg> slangasek: multiarch is an official tag now, I documented it here: https://wiki.ubuntu.com/Bugs/Tags, feel free to fix up the definition if I got it wrong
<slangasek> micahg: fixed the wiki link, otherwise LGTM thanks!
<slangasek> (the /Tuples document is obsolete and not used)
<micahg> ah, ok
<psusi> pitti: so you can't just import Gtk because there isn't actually a python library for it?  You have to import from gi.repository because it dynamically builds the library from the introspection data?
<pitti> psusi: right
<pitti> psusi: well, you can do import gi.repository.Gtk of course
<pitti> it's the same namespacing as e. g. os.path
<Respawner> hello
<Respawner> what is the difference (in natty) between libgtk-3-{0|dev} and libgtk3.0-{0|dev} packages?
<Respawner> I would like to know why libgtksourceview-3.0-dev depends on libgtk-3-dev and not on libgtk3.0-0dev
<micahg> one is correct, one is not
<arand> Respawner: libgtk3.0-{0|dev} doesn't exist in natty, it seems..
<cjwatson> kees: we've found another problem caused by the changed kernel permissions; stgraber says it breaks LTSP
<micahg> Respawner: the former is correct, the latter was the preliminary names before Debian decided on the naming scheme
<cjwatson> kees: bug 759115
<ubottu> Launchpad bug 759115 in ltsp (Ubuntu) "ltsp thin client kernel error - Could not find kernel image: vmlinuz" [Critical,Triaged] https://launchpad.net/bugs/759115
<kees> cjwatson: yup, known, and being fixed.
<cjwatson> I know, I'm just wondering how many more
<kees> yeah, I'm not sure what the threshold should be. but this implies ltsp wasn't tested after beta1.
<hallyn> slangasek: hey, i'm looking for pam-related explanations - do you have a minute?
<slangasek> hallyn: sure
<hallyn> slangasek: basically, courier-imap-ssl, through its own authlib, causes pam_cap.so to be loaded,
<hallyn> slangasek: pam_cap.so is not linked against -lpam,
<hallyn> slangasek: which is not supposed to be a problem, but dlopen is failing due to pam references
<Respawner> arand, micahg: ok this one "libgtk-3-{0|dev}" is ok but this one "libgtk3.0-{0|dev}" is not then?
<hallyn> slangasek: well, i'm still waiting through the courier-authlib source trying to figure out a good place to instrument to try and figure out where it all goes wrong...
<hallyn> (so i might learn more later...)
<arand> Respawner: The latter doesn't exist in natty, afaik..
<Respawner> arand: yeah you're right in it is not in the repo (anymore?) but it was installed on my system
<arand> gnome3 PPA or something?
<Laney> RAOF: cyphermox: Sorry on behalf of the DMB for being naff. We'd like to offer to process your applications by email if you want it. Let me know.
<Respawner> arand: no
<cyphermox> Laney, sure
<micahg> arand: no, it was the original gtk+3.0 in natty
<hallyn> slangasek: (s/waiting/wading) in other words, i'm hoping to be able to phrase a more intelligent question later :)
<LLStarks> cjwatson, is it too late to write up a blueprint for uds-o? i'd like to layout a plan for grub2-gfxmenu implementation.
<cjwatson> LLStarks: no, but what is needed isn't a plan, but implementation effort
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/other-foundations-n-cd-boot
<LLStarks> is it feasible for oneiric or is the focus right now on perfecting btrfs in grub?
<slangasek> hallyn: hmmm, yes, pam_cap.so should link against libpam.  Is that built from a separate source package?  I thought we had proper linkage for all libpam-modules
<hallyn> slangasek: the libcap maintainer insists that it shouldn't need to be
<hallyn> slangasek: the thing is, the caller is already linked against libpam...
<cjwatson> LLStarks: those are different strands of development.  I do hope to get it done but I entirely failed to do it for natty, so who knows.  Self-directed and self-motivated assistance would be welcome
<slangasek> hallyn: the libcap maintainer is mistaken :)
<hallyn> slangasek: if you also think it needs to be linked then we can just accept the patch from debian...
<hallyn> ok
<slangasek> hallyn: upstream maintainer or Debian maintainer?
<hallyn> upstream
<hallyn> andrew morgan
<slangasek> hallyn: haha
<slangasek> who used to be the upstream PAM maintainer too
<hallyn> right :)
<hallyn> that's why i was trying hard not to argue
<slangasek> anyway, yes, he's mistaken - if nothing else, DSOs need to link against the libraries they reference in order to get proper resolution of versioned symbols
<slangasek> and libpam uses versioned symbols
<hallyn> so in that case i wonder if we shoyld just sync debian's libcap2
<hallyn> d'oh.
<hallyn> already happened.  just need to sru.  what is going on with me today
<hallyn> ooooh.  bc when i looked at it last i hadn't applied the debian/patches/
<hallyn> no
<slangasek> hallyn: btw, I can tell you without even looking at courier-authlib itself that the problem here is that your executable is not linked against libpam, the only thing linked against libpam is a DSO which is itself dlopen()ed by the application; in this case, libpam's symbols aren't available at the global level for subsequent dlopen()s (as done by libpam of the modules) to reference
<slangasek> so you have application -> dlopen("my_pammy_mod.so") -> libpam.so -> dlopen("pam_cap.so")
<slangasek> this is a very familiar problem to me :)
<hallyn> so wouldn't RTG_GLOBAL or wahtever help that?
<hallyn> RTLD_GLOBAL :)
<hallyn> so i'm still confused about the state of the package - debian sid doesn't have the fix, but i saw the fix... maybe i was looking at experimental before?  i dunno
<slangasek> RLTD_GLOBAL never helps, it only hides the hurting
<slangasek> RTLD_GLOBAL, either
<hallyn> slangasek: but i assume you'd say we should still link libcap2 against -lpam?
<LLStarks> cjwatson, quick question. btrfs on / still requires ext4 /boot?
<hallyn> btrfs on non-/ was a disaster for me just yesterday
<slangasek> hallyn: for anything that's going to open large numbers of non-cooperating libraries, RTLD_GLOBAL must be avoided because colliding function names between any two of those libraries will cause cross-DSO segfaults
<slangasek> hallyn: yes, pam_cap.so needs to be linked against -lpam
<hallyn> slangasek: sound sensible (re RTLD_GLOBAL)
<hallyn> slangasek: ok.  do you think that needs to be pushed before natty release?
<hallyn> slangasek: (given that this is a rarely used module)
<slangasek> hallyn: I wouldn't call it critical to fix before release... it's an upload to main to fix a module in universe.  maybe a good candidate for a 0-day SRU
<hallyn> ok sounds good, thx
<cjwatson> LLStarks: it should work fine now
<cjwatson> LLStarks: upstream went through a sample btrfs filesystem created on Ubuntu and made sure it could read everything in it correctly
<cjwatson> LLStarks: (as in, should work fine without a separate /boot)
<LLStarks> have all problems from the maverick cycle been resolved?
<cjwatson> I don't want to say anything you're going to quote me on :-), but certainly lots of btrfs-related stuff from maverick has been resolved
<cjwatson> the main known caveat is that btrfs inside an encrypted device doesn't work so well
<LLStarks> nice. thanks.
<SpamapS> checking for PCRE library location... configure: error: Could not find libpcre.(a|so) in /usr
<SpamapS> is this because of multiarch? PHP seems to FTBFS every time.. :-/
<SpamapS> hmm maybe my chroot needs something... buildd's found it just fine
<SpamapS> checking for PCRE library location... /usr/lib/x86_64-linux-gnu
<mdke> pitti: the conclusion I think is that we will keep ubuntu-docs to provide the application specific help but also as help for those using the "Classic" desktop, and ship gnome-user-docs for the Unity based desktop (we are removing many screenshots to get the package size back down)
<pitti> mdke: ah, thanks; so we'll strip down ubuntu-docs too
<mdke> pitti: not really, it stays more or less as it was for Maverick
<SpamapS> hmm.. so.. one can't run 'debuild' and get the DEB_HOST_MULTIARCH variable set properly...?
<mdke> pitti: I'll upload a new ubuntu-docs very shortly - I guess that it is too late for beta? I saw that my gnome-user-docs from this morning hasn't been accepted yet so I assume the freeze is in full effect
<pitti> mdke: I held it back because you said you'd ponder the situation some more, and this morning it seemed we'd need bigger changes in jockey/usb-creator etc. to go with that
<pitti> and there was also the size issue
<mdke> pitti: ah, understood
<mdke> the size issue was a good reason to hold it back
<mdke> pitti: if I upload a new one tomorrow morning with the size issue corrected, I'll leave it up to you as to whether to go with it for beta
<pitti> mdke: we'll build new images in about two hours, but I'm happy for it to go into the archive, so that you can get it with upgrades (and we can test it better)
<mdke> pitti: sounds good, thanks
<slangasek> SpamapS: debuild sets DEB_HOST_MULTIARCH, but packages aren't supposed to rely on environment set by debuild
<SpamapS> slangasek: php does currently
<slangasek> whoops
<SpamapS> tho I understand that its a hack. :-P
<cjwatson> easy to fix,  DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
<SpamapS> the config.m4's reference it
<cjwatson> (and 'export' that if it's being used somewhere other than debian/rules)
<slangasek> sorry, you know how it goes, you start touching the php package and you can't *help* but introduce bugs
<SpamapS> I'll include that in the bug fix I'm preparing then
<SpamapS> slangasek: its like trying to renovate the bathrooms in a house of cards.
<cjwatson> slangasek: just like keyboard handling
<SpamapS> I'm sure it will be better in php... 6 .. ohh.. :/
<SpamapS> good news.. they have made it possible to build multiple SAPI's at once now.
#ubuntu-devel 2011-04-13
<doko> slangasek: ecj, had it seen here, couldn't reproduce it locally
<cnd> my system currently won't run unity; all unity windows are invisible
<cnd> however, the daily build works
<cnd> daily iso that is
<cnd> so I'm trying to figure out why that would be
<cnd> I don't have any relevant ppas installed
<cnd> I was wondering if there was a way to tell apt to reinstall *everything*
<RAOF> cnd: Yes - âsudo aptitude reinstall ~nâ
<RAOF> Note that will fail if you've got a locally installed package :)
<cnd> RAOF, do you know if there's a way to check for any packages that are locally installed?
<cnd> that's the first thing I want to try, but I don't know how to do it
<RAOF> cnd: Well, that aptitude line will tell you about the locally installed packages it can't reinstall :)
<cnd> ahh, before it starts?
<cnd> RAOF, should aptitude be barfing all over my console?
<RAOF> Yeah - that actually says âreinstall all packages in the archiveâ, and relies on aptitude only reinstalling packages that you've actually got installed.
<RAOF> It does, however, say ânot reinstalling $FOO; not installedâ for each binary package FOO in the archive :)
<cnd> ahh :)
<broder> why not do aptitude install ~i?
<broder> err, reinstal
<RAOF> broder: Because I didn't know about that :)
<broder> :)
<cnd> what's the difference?
<broder> ~i matches "all installed packages"
<broder> so aptitude reinstall ~i says "reinstall all packages that are installed"
<cnd> ahh
<cnd> well, I only had one manually installed package: linux-image-2.6.34-2-generic
<cnd> hmmm.. maybe it only tells me about manually installed packages one at a time...
<cnd> RAOF, is there a faster way than running aptitude reinstall every time to find one missing package at a time?
<RAOF> There almost certainly is, but I'm not aware of it.
<broder> cnd: is the issue that you're missing a dependency?
<broder> because just running apt-get install -f should fix that
<cnd> broder, the issue is that unity works when I test a daily iso build
<cnd> but it doesn't work quite right when I run it in my real installation
<cnd> the unity windows are transparent
<cnd> I've tried all the easy things like reinstalling the mesa libs
<cnd> and all the unity related stuff
<poolie> could someone please review and approve my sru  of bzr for bug 707075?
<ubottu> Launchpad bug 707075 in bzr (Ubuntu Lucid) "[sru] lp-propose fails with a 404 error" [Undecided,New] https://launchpad.net/bugs/707075
<cnd> RAOF, aptitude show ~i/natty | grep Unable
<cnd> spits out lines like:
<cnd> Unable to find an archive "natty" for the package "openoffice.org-core"
<RAOF> Oh, yeah.  Removed from the archive / renamed.  Joy!
<cnd> it's hacky
<cnd> but it works :)
<calc> anyone know how to get the old scrollbar back in ubuntu classic?
<TheMuso> calc: remove liboverlay-scrollbar I think.
<calc> TheMuso: ok thanks
<TheMuso> nop
<TheMuso> m[
<achiang> is there any way to see an older debdiff of a package that doesn't have a bzr branch in LP?
<achiang> package is phonon (4:4.7.0really4.5.0-0ubuntu3) natty; urgency=low
<achiang> and i can see the ubuntu2 -> ubuntu3 debdiff, of course
<achiang> but i'm quite interested in what the ubuntu1 -> ubuntu2 change was
<RAOF> Launchpad keeps those changes (and, indeed, all the source packgages)
<RAOF> Check out launchpad.net/ubuntu/+source/phonon/natty
<achiang> RAOF: hm, 404?
<achiang> https://launchpad.net/ubuntu/natty/+source/phonon
<RAOF> Hah.  Sorry, https://launchpad.net/ubuntu/natty/+source/phonon
<RAOF> Oh.  Yeah.  You found it :)
<achiang> RAOF: cool, and i found the debdiff i was after
<achiang> thanks!
<alkisg> I'm suspecting that early in the boot process, shell's job control is broken, so `command &` in early initscripts doesn't execute "command" at all. I'm trying to debug it now with a Lucid LTSP client, but it's difficult and time consuming.
<alkisg> Has anyone heard of such a problem?
<SpamapS> alkisg: no but it sounds very interesting
<alkisg> In an LTSP initscript we have this: (ntpdate $TIMESERVER && hwclock --systohc --${HWCLOCK:-utc} --noadjfile) &
<alkisg> And it sometimes works, sometimes not
<alkisg> If we remove the &, it always works
<alkisg> Currently I tried: (echo "CALLING NTPDATE $TIMESERVER"; ntpdate $TIMESERVER && hwclock --systohc --${HWCLOCK:-utc} --noadjfile || echo "DONE NTPDATE $?") &
<alkisg> I got the output of the first echo, but not the second one
<alkisg> (not even in boot.log)
<SpamapS> heh
<SpamapS> you're doing this inside initramfs ?
<alkisg> No, in an initscript
<alkisg> /opt/ltsp/i386/etc/rcS.d/S32ltsp-client-setup
<SpamapS> alkisg: ah, hm. I'd expect it to work quite reliably then.
 * alkisg tries some ntpdate parameters, and also to replace ntpdate with a big "sleep" to see if that would work...
<soren> alkisg: & works even when busybox complains about lack of job control.
<soren> alkisg: You just can't ctrl-c or ctrl-z and such.
<soren> alkisg: What do you have before and after that (ntpdate... ; hwclock) &  call?
<alkisg> soren: thanks, indeed the problem wasn't in spawning the process, but there's something killing the spawned process
<alkisg> So far I have the following tests:
<alkisg> (echo "CALLING SLEEP 2"; sleep 2; echo "DONE SLEEP $?") & ==> I don't get the second echo
<alkisg> (ntpdate -p 1 $TIMESERVER && hwclock --systohc --${HWCLOCK:-utc} --noadjfile) & ==> with the -p 1 parameter, "get one sample only", it works because it finishes quickly before something kills it
<soren> Something outside must be killing it.
<alkisg> So now I'm trying to find out what kills those processes
<soren> Hence my question: What's before and after that call?
<soren> CAn you pastebin the whole script?
<alkisg> It's a collection of scripts, of course I can pastebin them but they're many
<alkisg> That line is inside a function in a separate line from the rest of the initscript
<alkisg> To make a clear test case, I can write another initscript
<alkisg> With just that single line in it
<alkisg> *..in a separate FILE, not line
 * alkisg gets the kids to school and will continue testing with a simple initscript in 30'...
 * soren applies caffeine in mean time
<coolmego> any ideas on how to make a graphical boot like suse in ubuntu
<coolmego> kmlmb
<coolmego> ksbmklbnknm;mnlmnmkmnkmnmgmnnknmfnfoknkfpoknfknogoposkgkskg]
<RAOF> Indeed.
<coolmego> lol
<coolmego> :)
<StevenK> RAOF: Where is the MPRIS plugin for Do hiding?
<RAOF> StevenK: http://cooperteam.net/MPRIS.dll
<RAOF> I could give you source, too, if you wanted.4
<RAOF> I haven't got around to launchpadding it :)
<RAOF> (Just dragging the dll onto Do's plugin preferences window will install and enable it)
<StevenK> RAOF: It doesn't seem to?
<RAOF> Hm.
<RAOF> It should have added âplayâ, âpauseâ, etc actions...
<StevenK> * (Do:2050): WARNING **: Missing method get_Session in assembly /home/steven/.local/share/gnome-do/plugins/addins/MPRIS.dll, type DBus.Bus
<RAOF> Awesomesauce.
<StevenK> RAOF: That's from .xsession-errors
<RAOF> What version of Do?
<StevenK> RAOF: 0.8.3.1
<RAOF> Ah, you're on Maverick?
<StevenK> Yeah
<RAOF> Heh.  I've built it against Natty, and it's probably picked up the libdbus1.0-cil dep (rather than libndesk-dbus1.0-cil)
<RAOF> StevenK: http://cooperteam.net/do-plugin-mpris.tar.bz2 ; extract that, install mono-xbuild, and run âxbuildâ in the MPRIS directory.
<StevenK> RAOF: Done. Where does that stuff the .dll?
<RAOF> bin/Debug/MPRIS.dll
<StevenK> RAOF: Ah ha. Same install procedure?
<RAOF> Yup.
<RAOF> (You might have to rm ~/.local/share/gnome-do/plugins/addins/MPRIS.dll first; I'm not sure if we overwrite)
<didrocks> good morning
<RAOF> Aloha didrocks!
<StevenK> RAOF: Neat, that gives a stacktrace in .xsession-errors
<didrocks> hey RAOF :)
<RAOF> StevenK: Cool!  What's the stacktrace?  I may have mis-coded the dbus paths; I was testing against banshee :)
<StevenK> RAOF: It is complaining that it can't find dbus-sharp. I can't find the package, either
<RAOF> But it built for you?
 * RAOF is confused.
<StevenK> RAOF: http://pastebin.ubuntu.com/593448/
<RAOF> StevenK: Could you remove the bin/ directory and re-run xbuild?  I'm not convinced that it *actually* built.
<StevenK> RAOF: Would you like the output from xbuild?
<RAOF> StevenK: Yeah, why not?
<StevenK> RAOF: http://pastebin.ubuntu.com/593451/
<RAOF> Oh.  Right.
<RAOF> Ahem.
<alkisg> soren, SpamapS: I created a simplified initscript to reproduce the problem: http://pastebin.com/cdkgbtmu
<alkisg> Indeed, any processes spawned to the background by that iniscript is forcibly killed after a few seconds, but I don't know what kills them.
<RAOF> StevenK: Yeah.  dbus-sharp doesn't actually exist in Maverick, but it's a drop-in replacement for ndesk-dbus.  Try âsed -i s/dbus-sharp/ndesk-dbus/g MPRIS.csprojâ and then xbuild again ;)
<StevenK> RAOF: Based on the tracebacks, it seems it still wants dbus-sharp
<StevenK> steven@liquified:~/Desktop/MPRIS% grep -r dbus-sharp .
<StevenK> Binary file ./bin/Debug/MPRIS.dll matches
<StevenK> :-(
<RAOF> Ok.  pkg-config fail.  It needs to be ndesk-dbus-1.0 and ndesk-dbus-glib-1.0.
<RAOF> MPRIS.csproj is just an awful xml file, it should be hand-editable.
<RAOF> Or, I could fix it locally and throw it up for you.
<StevenK> RAOF: The <Package> bits already say that, the <Reference> needs to change too?
<RAOF> StevenK: Bah.  New do-plugin-mpris on cooperteam.  This should build and work for you :)
<pitti> Good morning
<soren> alkisg: Try adding an S99 script that writes "the end" to the same file as that test script.
<soren> alkisg: ...and see if that actually markes the end of it.
<alkisg> soren: trying...
<alkisg> ok
<soren> alkisg: If so, I have a guess as to what's going on.
<RAOF> Hm.  Note to self: suspend, rather than shutdown, your machine so that the >1hr fsck.btrfs that happens each boot doesn't annoy you so much.
<StevenK> RAOF: Do.Universe.Common.RunAction "Run" encountered an error in Perform: System.Exception: org.freedesktop.DBus.Error.ServiceUnknown: The name org.mpris.MediaPlayer2.quodlibet was not provided by any .service files
<RAOF> StevenK: Win!  It's built, installed, and is running!
<RAOF> StevenK: Now... you've got the quodlibet mpris plugin installed, right? :)
<StevenK> RAOF: I doubt it
<RAOF> StevenK: Ah.  Well, install it and then the Do end should work!
<StevenK> RAOF: Apparently, I did, it just doesn't turn up in Quod :-(
<RAOF> :(
<RAOF> Does quodlibet appear on the bus?
<pitti> +  * Added xfce4-indicator-plugin to desktop
<pitti> superm1: ^ that smells like a FFE? has this been discussed anywhere, and should get into beta-2? (would mean a rebuild)
<pitti> superm1: hm, mythbuntu-default-settings also introduces the dependency; isn't that a little redundant?
<alkisg> soren: In that file, I got: "start 4[Enter]start 2[Enter]stop 2[Enter]the end"
<soren> Just as I thought.
<alkisg> I guess something kills all child processes of rcS initscripts at the end of that boot phase. But is this a correct behavior?
<dholbach> good morning
<soren> alkisg: I'm trying to work that out.
<soren> alkisg: Oh, hang on.. What's you script called?
<alkisg> soren: I put the names on the headers
<alkisg> S33spawn-test -> ../init.d/spawn-test
<alkisg> S99finish-test -> ../init.d/finish-test
<soren> Ah, ok.
<alkisg> soren: here's the finish-test, if you need it: http://pastebin.com/XHCrgtxS
<soren> alkisg: I'd file a bug against upstart. I don't really know if it's a bug, but that's probably the best way to get the discussion going.
<soren> alkisg: For now, you can probably get out of it by using nohup.
<alkisg> soren: thank you for both suggestions
 * alkisg tries nohup...
<ev> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Beta-2/Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: zul
<alkisg> soren: thanks again, I filed the bug here: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/759568
<ubottu> Ubuntu bug 759568 in upstart (Ubuntu) "Processes spawned by initscripts are forcibly killed if delayed" [Undecided,New]
<dholbach> james_w, regarding the history-differs ubuntu branches: why do we have conflicts in some of them? what do you think is the best way to treat those? there's like 3 left now
<seb128> ntfs-config might be worth dropping from natty, it seems to not work without hal and just trigger apport seeing bugs on launchpad
<seb128> or it needs fixing, well pointing it in case someone is interested to check on this one
<avinashhm> Hi, my minicom output gets garbled once in a while .. its using ttyUSB4 .. if i restart my computer , this is proper again .. Is there any way to enumberate ttyUSB4 as a different ttyUSBx ?
<Riddell> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Beta-2/Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: zul, Riddell
<czajkowski> ara: would you know who to poke about https://bugs.launchpad.net/ubuntu/+source/json-glib/+bug/756426
<ubottu> Ubuntu bug 756426 in json-glib (Ubuntu) "unable to set double (fixed upstream)" [Undecided,New]
<doko> is Andreas Moog here on the channel?
<chrisccoulson> doko - yes. he's Ampelbein
<doko> Ampelbein: if you want to make priorities for build failures, just leave the ld-no-add-needed reports for now. It's disabled for the final natty release
<Riddell> lifeless: you're into samba, have you tried usershare with natty?  I can't get it to work except with guest ticked, authentication doesn't want to work
<AnAnt> Hello, how can I add software categories in Unity's application browser ? I've got extra-xdg-menus installed , yet I don't see the Electronics category for example
<Ampelbein> doko: ok, I will focus on the other buildfailures. thanks.
<chrisccoulson> how can we get ubot5 in to #ubuntu-mozillateam? our bot seems to have gone AWOL
<chrisccoulson> dholbach, do you know? :)
<chrisccoulson> seb128 suggested you might ;)
<dholbach> chrisccoulson, tsimpson should be able to help
<chrisccoulson> dholbach, thanks
<Pici> chrisccoulson: If you ask in #ubuntu-irc, someone should be able to help you (if tsimpson hasn't already).
<chrisccoulson> Pici, thanks
<mdeslaur> chrisccoulson: your bot is using chromium now...sorry :)
<Daviey> cjwatson, Having an interest in debootstrap, i wondered if you had thoughts on bug 740167?
<ubottu> Launchpad bug 740167 in debootstrap (Ubuntu) "LXC natty guest failing to configure properly" [High,In progress] https://launchpad.net/bugs/740167
<cjwatson> Daviey: I'll have a look
<Daviey> cjwatson, thanks.
<hallyn> cjwatson: hi,
<hallyn> cjwatson: we're trying to decide whether the kernel fix for kvm's INT mis-push needs to go into natty release
<cjwatson> I'm agnostic on the subject
<hallyn> cjwatson: what exactly was going wrong for you that made you track that down?
<slomo> doko: hey, is debian/ubuntu's gcc 4.6 patched to ignore -Werror for the new compiler warnings (variable assigned but not used, etc)?
<cjwatson> I mostly just left the milestone the way it was when I thought it was a gfxboot bug
<cjwatson> hallyn: see the start of the bug report :)
<cjwatson> it causes translations to go missing in the CD boot menu
<hallyn> right
<hallyn> ok, thanks
<cjwatson> so I spent half a day or so debugging that and eventually tracked it down to this
<cjwatson> I guess I don't know how much else it affects
<cjwatson> it was a surprise to me that the breakage caused by it seemed to be so limited, but I guess the kernel doesn't use real mode a whole lot
<apw> cjwatson, so the bug is affecting the CD boot menu ... i guess that is the tip of the iceberg, so we probabally want it fixed for release
<lfaraone> pitti: when you have a chance can you sync bug 759830? (fixes CVE-2011-1500 and other bugs)
<ubottu> Launchpad bug 759830 in pithos (Ubuntu) "Sync pithos 0.3.8-1 (universe) from Debian unstable (main)" [High,Confirmed] https://launchpad.net/bugs/759830
<ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1500)
<superm1> pitti, yes i suppose you're right, i'll file one, it should make it by gold but beta 2 isn't urgent
<pitti> superm1: ah, good to know
<pitti> superm1: btw, new mythbuntu rebuild still oversized despite the mythtv fix
<superm1> i was surprised no one filed a bug on it yet
<superm1> gah, still really?
<doko> slomo: yes
<slomo> doko: hah great, thanks for confirming :)
<superm1> well that doesn't make sense, I don't see anything to blame for installing it in http://people.canonical.com/~ubuntu-archive/germinate-output/mythbuntu.natty/
<slomo> doko: when will you drop that patch?
<doko> slomo: before a release
<cjwatson> hallyn: should I steal bug 740167?  I seem to be half-way through it now ...
<ubottu> Launchpad bug 740167 in debootstrap (Ubuntu) "LXC natty guest failing to configure properly" [High,In progress] https://launchpad.net/bugs/740167
<hallyn> cjwatson: sure be my guest :)
<RoAkSoAx> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Beta-2/Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: RoAkSoAx, zul, Riddell
<hallyn> cjwatson: I was tempted to stay up last night and track it down further, bc boy did it bother me.  But then I'd be tired and cranky today :)
<cjwatson> hallyn: heh, in fact there's a to-do comment for exactly this
<cjwatson>         # XXX: I can't think how to deal well with dependency resolution and
<cjwatson>         #      lots of Packages files. -- aj 2005/06/12
<hallyn> yeah i saw that, and felt sort of bad for him :)
<hallyn> but come on, it's 2011 no2 :)
<hallyn> now even
<cjwatson> ah, if only bugs got magically easier over time ;)
<hallyn> it's like budget cuts - when there's time to address them we find better things to do
<cjwatson> I guess I just need to cat all the component Packages files together
<cjwatson> and be a bit careful about edge cases
<cjwatson> ... actually, surely I can just look through each of them independently
<hallyn> i was just going to keep separate 'tocheck' and 'checked' pkglists and walk tocheck one by one, adding dependencies to tocheck, until done...  not as magic as what it's trying to do now, but hopefully reliable
<pitti> lfaraone: done
<lfaraone> pitti: thanks! :)
<euroford> hi all
<euroford> I'm developing a gwibber plugin for Sina
<euroford> I meet a package problem
<euroford> Sina has some icon file, and how could add them to the gwibber package
<euroford> the sina patch is ready
<superm1> pitti, i don't see any reason why mythtv-themes is getting installed, it's got no rdepends and it's not called out in any of the seeds
<superm1> any other ideas?
<pitti> so ubunt2 still has Task: mythbuntu-backend-master, mythbuntu-backend-slave, mythbuntu-desktop, mythbuntu-frontend
 * pitti apt-get updates
<pitti> superm1: the task headers are gone
<pitti> superm1: might be that it would have needed one more publisher cycle
<pitti> superm1: I can trigger a rebuild in about 30 minutes if you want
<superm1> pitti, yeah that would be good
<pitti> superm1: ok, will do then
<pitti> superm1: seems it didn't yet get any testing anyway, so at least we wouldn't lose that
<pitti> a smoketest would be  good, though
<pitti> to see if there are other issues
<mdeslaur> cjwatson, pitti: I was told you two should see bug #759804
<ubottu> Launchpad bug 759804 in ubiquity (Ubuntu) "after fresh install, jockey thinks nvidia binary driver is in use" [Undecided,New] https://launchpad.net/bugs/759804
<cjwatson> ev did most of the jockey integration in ubiquity
<mdeslaur> ev: ^
<pitti> oh, is the nivida driver installed in ubiquity through jockey now?
<pitti> mdeslaur: did you have the nvidia-current package installed?
<mdeslaur> pitti: the package was installed, but dkms didn't have any modules built for it
<mdeslaur> pitti: I installed while checking the "3rd party" checkbox...I'm not re-trying without it
<mdeslaur> s/not/now/
<ev> yes it is
<ev> when you check the 3rd party software box
<ev> as requested by dx, I believe
<mdeslaur> ev: ah, well that may explain the problem...the dkms modules aren't being transferred to the installed system
<ev> it does jockey-text -C
<ev> I thought it did it in the chroot...
 * ev digs
<Sarvatt> the blacklist isn't either
<Sarvatt> since nouveau is still getting used
<pitti> mdeslaur: right, the current handler skips the "is module loaded" check, as we leave that to the nvidia-common alternatives setup
<tjaalton> has it been discussed before to install SSSD by default, replacing pam_{unix,ldap,krb5,winbind,ccreds}.so, nscd et al.. ? i was thinking of writing a topic for oneiric
<ev> yeah, it effectively does: chroot /target jockey-text -C --no-dbus
<pitti> mdeslaur: ah, ignore me, it does check if the module is loaded
<pitti> mdeslaur: so lsmod|grep nvidia doesn't show the module as loaded?
<mdeslaur> pitti: I am currently reinstalling, I'll check in a bit
<pitti> mdeslaur: I don't see how used() could return True if "nvidia" isn't loaded
<Sarvatt> there's no trace of the kernel module at all, jockey doesn't know about it and its not in lspci, there is a blacklist blocking nouveau installed in the package too that isn't getting used since he's using nouveau
<mdeslaur> actually...ProcModules.txt in the bug doesn't have nvidia loaded
<pitti> mdeslaur, ev: could it be that it does copy the actual .ko, but doesn't copy the dkms meta information?
<pitti> ah
<Sarvatt> err dkms doesn't know about nvidia-current, not jockey sorry
<Sarvatt> his dkms status was blank
<superm1> it should still be the dkms in the chroot used to build it i would think
<pitti> hm, so I'm really stunned; I have no explanation, would it be possible to get ssh on an affected box?
<pitti> (all intel here, sorry)
<mdeslaur> pitti: sure...I can set that up
<pitti> mdeslaur: FYI, I have an O planning meeting in 9 minutes, then another call/dinner/release management, so no hurry
<mdeslaur> pitti: yeah, I need to reinstall the laptop back to the broken config anyway, so it'll take a while
<psusi> slangasek: is there a reason NOT to dup bug #746924 against #751689?  Jamie seems to have come up with a good test case as well
<ubottu> Launchpad bug 746924 in linux (Ubuntu Natty) "kernel default cpufreq governor fails to take action when system is overheating" [High,Confirmed] https://launchpad.net/bugs/746924
<slangasek> psusi: I asked jdstrand and he thought it might not be the same bug; I have no preference
<slangasek> I know how to undupe if it turns out to not be fixed for me :)
<mantiena> Hi ev
<ev> hi
<mantiena> When is the final date for fixing ubiquity and ubiquity-slideshow-ubuntu translations? According to the Natty release schedule deadline is tomorrow, do you have any plans to update ubiquity-slideshow-ubuntu and ubiquity translations from launchpad after April 14 ?
<cjwatson> anything after tomorrow is not guaranteed
<cjwatson> you may get it, you may not
<cjwatson> do not plan on it
<cjwatson> (sorry, I just realised you were talking to ev, didn't mean to interrupt)
<ev> quite alright
<ev> mantiena: I've been doing translations pulls with each ubiquity upload. I'll do an upload of both with the most recent translations tomorrow.
<mantiena> I've finished the ubiquity translation today, tomorrow I plan to make final tests with real installation, can you tell the hour in UTC until I can make fixes (if I found any problems in translation)
<mantiena> ev, cjwatson: I've finished the ubiquity translation today, tomorrow I plan to make final tests with real installation, can you tell the hour in UTC until I can make fixes (if I found any problems in translation)
<cjwatson> no, sorry
<cjwatson> exact hours just encourage people getting stuff done with five minutes to spare
<cjwatson> besides I don't know that either ev or I plan things that closely
<mantiena> :)
<ev> indeed
<pitti> ev, cjwatson: I followed up to bug 759804; it seems that it installs nvidia/dkms/builds the module just fine, but after that it purges all kernel images (with dkms) and installs -pae
<ubottu> Launchpad bug 759804 in ubiquity (Ubuntu) "after fresh install, jockey thinks nvidia binary driver is in use" [Undecided,New] https://launchpad.net/bugs/759804
<pitti> ev, cjwatson: can this happen the other way around?
<pitti> i. e. first install the final kernel, then call jockey -C?
<pitti> mdeslaur: ^ FYI
<pitti> added installer syslog now; off for dinner, bbl
<ev> ahh, I wonder if we're missing a bit of intelligence in traverse_for_kernel
<ev> but yes, this does upon first glance look like an ordering issue
<pitti> ev: btw, does installing -pae also install the matching kernel headers?
<pitti> ev: jockey tries to install them as well, but it uses uname to install for the currently running one
<pitti> so I suppose that won't catch that it's going to be run for -pae
<ev> just trying to deepen my understanding
<ev> it's been a while since I've dug into base-installer and friends
<jono> mvo, ping?
<davmor2> mvo: don't answer it's a jono trap
<jono> davmor2, ?
<jono> davmor2, you are so weird :-)
<davmor2> jono: just playing dude :)  mvo knows better than to pay any attention to me unless I've spotted a bug :)
<jono> :-)
<ev> okay, I think I've got a rough patch to test with
<Laney> stgraber: I don't think I'll have time today to start the email processing. Would you be able to do it?
<stgraber> Laney: I'm quite busy today too, if I have time it'll probably be quite late tonight.
<Laney> ok
<Laney> geser bdrung maco cody-somerville: ^^^ if any of you have some spare time
<stgraber> Laney: oh, actually, I won't even be home tonight :( so really unlikely I'll find the time ...
<RoAkSoAx> barry: ping
<mdz> pitti, cjwatson, kees, Rick's summary regarding Unity is on technical-board@
<mdz> it was stuck in moderation :-/
<RoAkSoAx> barry: I'm gonna go ahead and upload bug #747236 if that's ok with you
<ubottu> Launchpad bug 747236 in apache-openid (Ubuntu) "ftbfs with python2.7" [Undecided,Triaged] https://launchpad.net/bugs/747236
<pitti> superm1: http://cdimage.ubuntu.com/mythbuntu/daily-live/20110413.2/
<pitti> superm1: amd64 is much better, but missed the limit by a hair
<pitti> ev: thanks!
<superm1> pitti, oh man, just can't win! :)
<ev> well, we'll see how that goes
<ev> it was entirely cowboyed
<ev> I'll give it a try if others don't report back
<ev> anyone know what might create /home/buildd?  I'm digging through the obvious candidates but coming up empty
 * pitti greps http://archive.ubuntu.com/ubuntu/dists/natty/Contents-i386.gz
<pitti> ev: hm, nothing in Contents.gz, so not a package
<superm1> i wonder why amd64 is so significantly larger than i386 though; 651 vs 700, I feel like there shouldn't be such a delta
<pitti> superm1: indeed; we usually have two or three more langpacks on i386, but not 50 MB
<ev> pitti: thanks the same
<pitti> superm1: did you already compare the manifests?
<pitti> ev: I keep trying to remember teh package which builds teh livefs chroot
<ev> livecd-rootfs?
<superm1> pitti, yeah, believe it or not, i386 has two more packages than amd64, geode and i740
<pitti> ev: ah, that one; no obvious weird mkdir there, though; where do you see this?
<ev> pitti: it's a laptop in the possession of the design team, though I could've sworn I saw it somewhere else
<ev> came up in user testing
<superm1> looks like the pool on amd64 has libc6-i386 and lib32gcc1 pulled in on amd64
<superm1> but that's only about 3.4 megs
<mvo> jono: pong
<jono> mvo, just a quick q: I noticed that for Volleybrawl in the paid apps section of the USC, it has 14 ratings but no reviews, is that a bug?
<jono> wasn't sure if I should file a bug
<mvo> jono: hm, I see that here, what language are you using? what is lsb_release -a displaying?
<jono> mvo, :
<jono> jono@forge:~$ lsb_release -a
<jono> No LSB modules are available.
<jono> Distributor ID:	Ubuntu
<jono> Description:	Ubuntu Natty (development branch)
<jono> Release:	11.04
<jono> Codename:	natty
<jono> mvo, I wasnt sure if there are just ratings but no reviews
<mvo> jono: hm, odd, that should work
<jono> but I wasnt sure if you could just leave a rating
<seb128> jono, do you use en_GB?
<mvo> jono: there is one know bug in the current archive version, it will raise a error after the review, but the review will make it through
<jono> seb128, my keyboard and language is set to US
<seb128> ok
<jono> because I am 'merican now
<jono> :-)
<seb128> just curious if it would list GB reviews only and there was none
<seb128> it's a bit confusing when you use a non english locale and there is no review in your language
<seb128> you get the scoring but no comment
<jono> mvo, seb128 other reviews appear fine
<jono> it is just for Volleybrawl
<jono> thought it might be something specific to that repo
<superm1> pitti, okay well i ditched some stuff from the pool by modifying the seed, i'm confident we should be under size limit now.   whenever  that is made effective can you queue a rebuild again?
 * hallyn hates context-free patches
<hallyn> -p ftw
<mvo> jono: works for me (but I use the version that is currently in the frozen queue of natty). I use en_DK
<kiwinote> mvo: looks like this is an issue with the ReviewLoaderJsonAsync, with the threaded loader from trunk it works fine
<jono> mvo, when will I get the new version, post-Thurs?
<mvo> kiwinote: yeah, I moved that to a spawner now, third iteration to get it right :) (hello btw :)
<kiwinote> mvo: there was a tmp issue in the current version in natty which causes the json loader to be used, tremolux fixed it in rev 1694
<kiwinote> hi ;)
<mvo> jono: you could use bzr get lp:software-center; cd software-center; PYTHONPATH=. ./software-center
<mvo> kiwinote: yeah, I noticed that on monday morning, the fix I put in for the multiprocess/accessiblity crash did not actually work and I fixed it now in a different way in trunk
<pitti> superm1: would you mind asking in #u-release? I need to disappear soon
<superm1> sure
<mdz> pitti, cjwatson, Keybuk, kees, do you think we should have a one-off TB meeting to look at Unity as of beta 2?
<pitti> good night everyone, need to run now
<Keybuk> mdz: I think it would be useful, even if just to give a public airing
<mdz> rickspencer3, I guess I was hoping for a more targeted list of bugs
<mdz> I don't want to trawl through all of the bugs on compiz looking for which ones are unity-related
<rickspencer3> mdz, well, compiz is tightly bound with Unity
<mdz> and I'm quite certain there are unity-related bugs filed on packages other than unity and compiz
<mdz> rickspencer3, yes, but compiz is also used in the classic desktop
<rickspencer3> Unty doesn't crash that much, it's usually copiz
<rickspencer3> *compiz
<rickspencer3> mdz I'm trying to help here, but I'm not sure what other report we can run
<mdz> rickspencer3, as I understand it, unity runs as a plugin to compiz, so it's a pretty blurry line
<rickspencer3> we have incoming bugs in compiz and unity
<rickspencer3> these get triaged and the ones that the team thinks are the biggest threats get moved onto the milestone list
<rickspencer3> mdz, well, Unity may trigger compiz bigs that GNOME 2.3.x does not
<mdz> rickspencer3, yes. those are the ones I want to know about
<mdz> rickspencer3, https://launchpad.net/unity/+milestone/3.8.8 won't have any of those bugs
<rickspencer3> why not?
<mdz> or will it?
<mdz> well, because it's only upstream unity bugs
<mdz> I assume that if the bug is in compiz code, it won't be filed on unity upstream
<mdz> is that a wrong assumption?
<Sarvatt> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/740126 is one that only happens in unity and not classic gnome with compiz
<ubottu> Ubuntu bug 740126 in compiz (Ubuntu Natty) "compiz hangs randomly several times per day" [High,Confirmed]
<Sarvatt> whoops, sorry, mdz: ^^
<rickspencer3> mdz well, I would expect that they would open a bug task on Unity so that they can track those bugs in the milestone
<rickspencer3> mdz the issues with xorg that I know of are invariant to Unity
<mdz> rickspencer3, Sarvatt's bug is a counterexample
<mdz> specific to unity, but not filed on unity upstream
<rickspencer3> mdz, right
<mdz> there's a "unity" tag on it, is that a useful way to filter bugs?
<rickspencer3> mdz could be, I haven't been deep in the bug workflow
<rickspencer3> but there are only 9 bugs with that tag, it looks like
<ScottK> rickspencer3: It's not a normal triaging practice to also open bug tasks against packages (e.g. unity) when the bug is triggered by using that package but is in a different package (e.g. compiz).
<mdz> rickspencer3, who should I be asking?
<rickspencer3> mdz, well, didrocks, I guess would be a good goto person
<rickspencer3> or seb128
<mdz> getting late for them today
<rickspencer3> yes
<mdz> wow, bug 685552 has a lot of duplicates
<ubottu> Launchpad bug 685552 in unity (Ubuntu) "Compiz crashes when (en|dis)abling a plugin (ccsm) aka compiz crashed with SIGSEGV in sigc::signal_base::impl()" [High,Confirmed] https://launchpad.net/bugs/685552
<kees> mdz: it could be worth a public meeting, sure.
<mdz> and no indication of a fix on the horizon
<mdz> I wonder why it has so many duplicates if it's only triggered by tweaking in ccsm
<seb128> sorry I disconnected
<seb128> what was the question?
<mdz> I wouldn't expect most users to fiddle with that
<seb128> ScottK, yes it's normal
<mdz> seb128, I'm just wondering where I can get a comprehensive list of bugs which are specific to Unity
<ScottK> OK.
<mdz> regardless of which package
<seb128> they use "unity" to track their milestones for any of the unity components
<seb128> mdz, https://bugs.launchpad.net/unity
<seb128> mdz, they "also affect unity" on any of the unity shell components
<seb128> that doesn't cover the indicators but you probably don't count those for unity anyway I guess
<mdz> seb128, does that imply that bug 740126 (which Sarvatt mentioned was unity-specific) should have a unity task open?
<ubottu> Launchpad bug 740126 in compiz (Ubuntu Natty) "compiz hangs randomly several times per day" [High,Confirmed] https://launchpad.net/bugs/740126
<davmor2> jono: mvo: If it helps I see the reviews but I'm using trunk
<seb128> mdz, likely yes
<seb128> mdz, would it only to have them being able to track it on one of the unity milestones
<seb128> mdz, do you look for specific informations? I'm doing sort of daily stats on what bugs get duplicates from the retracer logs
<seb128> mdz, well not "stats" just a list that I review and I ping dx about issues that raise there
<seb128> but I could probably share those lists if useful
<mdz> seb128, I'm looking for an overview on behalf of the TB per https://lists.ubuntu.com/archives/technical-board/2011-April/000816.html et al
<seb128> mdz, ok, I'm happy to help if you need extra details
<mdz> seb128, if you say that the unity bug list should have everything on it, then that's good enough for now, thanks
<seb128> ok
<seb128> yes it does that's how they track their work ;-)
<seb128> kees, hey
<seb128> kees, it does for bugs like bug #760025, didrocks has a script which is running daily which does "also affect unity" when there is a bug on any of the unity components
<ubottu> Launchpad bug 760025 in nux (Ubuntu) "compiz crashed with SIGSEGV in nux::WindowCompositor::RenderTopViews()" [Undecided,New] https://launchpad.net/bugs/760025
<seb128> kees, that one is fix commited btw, the fix will land in natty after beta2
<kees> seb128: nice!
<seb128> kees, do you want me to reply to your email to say that?
<kees> seb128: for completeness, yeah, might as well, in case anyone else is reading that thread without this IRC context.
<kees> rickspencer3: I've replied to the TB thread now too.
<seb128> kees, ok
<seb128> kees, btw in case you didn't read what I told mdz before I do daily stats and review on the retracer logs, I'm happy to help you guys having a better overview of natty crashers if you need one
<kees> siretart: what's up with the ffmpeg/libav split?
<kees> seb128: cool, thanks.
<mdz> is this at all normal?
<mdz> mdz       1827  1.3 15.7 2221876 483528 ?      Sl   Apr10  62:04 compiz
<Sarvatt> mdz: not at all, https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/758248
<ubottu> Ubuntu bug 758248 in nux (Ubuntu) "memory leaking in compiz" [High,Triaged]
<mdz> Sarvatt, I just filed bug 760161
<ubottu> Launchpad bug 760161 in compiz (Ubuntu) "Very high memory usage" [Undecided,New] https://launchpad.net/bugs/760161
<Sarvatt> (also limited to a unity session I believe)
<mdz> this is with a classic session
<bdrung> bdmurray: re #760140 - what version did you test? the archive version or the version from vorlon's branch?
<bdmurray> bdrung: the version from vorlon's branch
<bdmurray> bdrung: oh must of mispasted
<bdrung> then it makes sense :)
<cjwatson> TheMuso: I'm removing hal from ubuntustudio-desktop; I hope that's OK
<cjwatson> TheMuso: (bug 760008)
<ubottu> Launchpad bug 760008 in debian-installer (Ubuntu Natty) "amd_64 studio install fails" [High,Triaged] https://launchpad.net/bugs/760008
<cjwatson> TheMuso: the ubuntustudio.natty/audio-common seed inherits from desktop.  Should ubuntustudio-generation and ubuntustudio-recording Depends: ubuntustudio-desktop to match that?
<cjwatson> TheMuso: hm, and in fact all the other ubuntustudio tasks likewise
<RoAkSoAx> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Beta-2/Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: zul, Riddell
<cjwatson> TheMuso: hal> or not - see #ubuntu-release and the commit log
<TheMuso> cjwatson: No, because we want users to be able to install audio packages without pulling in the entire desktop and theme if they so wish.
<TheMuso> cjwatson: and re hal, it can be removed. If its not done already, I can take care of it.
<TheMuso> oh... read the log, hrm ok.
<Daviey> cjwatson, I don't know if you are around, but jamespage1 has encountered an oddity with initial language selection... http://inky.ws/g/96 I cannot reproduce it, http://erk.daviey.com/language-natty-first-screen.png .. both in KVM and md5sums match.
<Daviey> both i386.
<jamespage1> Daviey, cjwatson: just did a quick check on amd64 and get the same result.
<Daviey> jamespage1, what command line are you using to launch kvm?
<jamespage1> Daviey: using virt-manager
<Daviey> jamespage1, ok... can you reproduce it spawning from the console?
<jamespage1> Daviey: I'll take a look
<seb128> rickspencer3, kees, mdz: http://paste.ubuntu.com/593780/
<seb128> rickspencer3, kees, mdz: the list of the retracers log for the week for bugs which had > 1 duplicate
<seb128> rickspencer3, kees, mdz: it's count, bug number, title, components
<seb128> rickspencer3, kees, mdz: if that's of any use to you
<rickspencer3> seb128, am I interpreting it correctly in that the long tail seems to be mostly not related to Unity or compiz?
<seb128> rickspencer3, yes
<kees> seb128: thanks, it's pretty enlightening. seems like the ones at the top could really use attention. this might be a good report to keep on handy all the time.
<seb128> rickspencer3, out of some exceptions which are fix commited since
<rickspencer3> seb128, are there any Unity specific crashers on that list that are not fixed or currently targeted to be fixed?
<seb128> kees, the unity stack with > 5 are mostly with a fix ready
<rickspencer3> a quick read, they all appear to be fixed, but that's just from my recognition
<seb128> rickspencer3, the ccsm one and maybe or two weird compiz ones like bugs on compiz --replace
<seb128> they still plan to fix the ccsm one by natty if they can
<seb128> but it's not a crash in normal use situation
<seb128> it's when tweaking with options with something not installed by default
<rickspencer3> yeah, thought fixing it would be nice
<seb128> so it's not really a stopper
<seb128> indeed
<seb128> it will be fixed in a sru if not in natty
<kees> seb128: sounds good
<pitti> kees: ah, I haven't tried auto-raise with FFM
 * pitti waves good night
<cjwatson> TheMuso: hmm, well, perhaps the other tasks shouldn't be inheriting from desktop then?
<TheMuso> cjwatson: I guess not, I wasn't the one who set that up, at least I don't remember doing it.
<cjwatson> Daviey: I didn't see the exact same symptoms, but it could easily be caused by bug 747090
<ubottu> Launchpad bug 747090 in Ubuntu Translations "wrong return address sometimes pushed for INT in kvm (not qemu)" [Low,Triaged] https://launchpad.net/bugs/747090
<cjwatson> Daviey: try with qemu -no-kvm, or on bare metal?
<Daviey> cjwatson, ah, good thinking - will advice jamepage tomorrow to try.
<cjwatson> Daviey: that's certainly known to affect gfxboot's language presentation in other ways, and to behave at least somewhat inconsistently
<Daviey> yeah
<Daviey> hopefully it is just that.
<slangasek> hrm. did bazaar.launchpad.net just go away?
<lifeless> I think so
<lifeless> chasing
<slangasek> k
<cjwatson> and the librarian, by the looks of things
<lifeless> network layer issue
<lifeless> is are on it
#ubuntu-devel 2011-04-14
<ScottK> lifeless: would that affect build status on the web u/i?
<lifeless> build logs and build progress tails
<broder> would the LP networking issues keep me from being able to do a maverick -> natty upgrade?
<james_w> broder, probably not
<james_w> broder, were you seeing issues, or just asking before you did it?
<broder> james_w: do-release-upgrade -d is claiming "No new release found"
<james_w> hmm
<james_w> is there a debug mode?
<james_w> finding out which url it is hitting would be useful
<broder> not that i've found yet
<broder> looks like it's something on changelogs.ubuntu.com
<broder> which is...not responding for me
<james_w> that sounds right
<broder> my path to changelogs.u.c looks very similar to my path to bazaar.launchpad.net, so i'm going to assume it's the same outage
<james_w> broder, confirmed
<james_w> I'd guess it would be sorted soon
<lifeless> it should be plugined in again soon
<broder> no worries; it just means my timing is amazing :)
<sladen> broder: update-manager -c -d   isn't it?
<sladen> broder: force a check && force checking for development version
<broder> sladen: possibly. i've just always done it with do-release-upgrade from the console. either way, i'm pretty sure they both try to hit changelogs.u.c
<sladen> broder: yes  http://changelogs.ubuntu.com/meta-release IIRC, bug changelogs.u.c appears to be down
<psusi> so it looks like dconf is a replacement for gconf, and it looks like it's libraries are now installed by default, so why are the gconf xml files still around?
<TheMuso> psusi: Because there are still lots of components of the desktop that use gconf, i.e because they were left at their GNOME 2.32 versions.
<smoser> is it known that changelogs.ubuntu.com is down ?
<psusi> TheMuso, so dconf isn't a drop in replacement?  the apps have to be modified?
<broder> smoser: yes. see twitter.com/launchpadstatus - it's affected by that, afaik
<TheMuso> psusi: Correct.
<TheMuso> Dconf is a backend for glib's gsettings framework.
<TheMuso> I believe gsettings can have multiple backends, even gconf, but I am not sure if that backend is maintained any more, very likely not.
<psusi> that's what I thought, so apps use gsettings and gsettings can be switched from gconf to dconf as the backend can't it?
<TheMuso> yes, don't know how its done though.
<TheMuso> And yes so far as I understand things.
<ohsix> i miss my changelogs
<freeflying> hi guys, I'm wondering if its possible to remove an upload from repository
<ScottK> freeflying: It's extremely difficult and virtually never done.
<ScottK> The only time I'm aware of it having been done was when the package turned out to be illegal to ship.
<micahg> freeflying: what's the reason?
<freeflying> micahg: ubuntu-chinese-meta is being generated from ubuntu-chinese.natty seeds automatically, but its been modified manually
<micahg> freeflying: so, it should just be fixed in the seeds in reuploaded, no?
<micahg> freeflying: and ScottK did those uploads, so I'd suggest some communication if there were problems :)
<ScottK> freeflying: The content of the packages is exactly what's in the seeds.  All I did was stop trying to build armel and powerpc packages that would inevitably fail.
<ScottK> freeflying: The parts I changed aren't automatically generated.
<poolie> hi guys, just to let you know, because of fallout from the switch failure launchpad is apparently not processing apport reports at the moment (bug 760393)
<ubottu> Launchpad bug 760393 in Launchpad itself "apport bug stuck in "please wait while bug data is processed"" [Undecided,New] https://launchpad.net/bugs/760393
<freeflying> micahg: I have talked with ScottK, and he made the revert upload, but it make me a littlte bit hard to generate it from seeds
<freeflying> micahg: need to modify changelog everytime, thats why I'm asking for a remove :)
<siretart> kees: libav seems to be me (and I'm following the development pretty closely) the clearly better branch to follow, so we've switched to libav
<siretart> kees: or are you talking about the libav-source package? that's to avoid the source code and therefore patch duplication issue with libav-extra
<pitti> Good morning
<robert_ancell> Is anyone else getting issues doing a dput?
<mok0> robert_ancell: yes
<pitti> robert_ancell: see http://identi.ca/launchpadstatus
<robert_ancell> mok0, gpg errors?
<pitti> LP still being fixed
<mok0> robert_ancell: it reported a problem with my GPG signature, but accepted the pacakge anyway :-/
<robert_ancell> ah, nasty
<ricotz> robert_ancell, you mean an error about the changes-file?
<dholbach> good morning
<didrocks> good morning
<mvo> robert_ancell: looks like various other machines are down as well (changelogs.ubuntu.com for a start)
<robert_ancell> ricotz, "Changes file must be signed with a valid GPG signature: Verification failed 3 times: ['General error', 'General error', 'General error'] : Permission denied"
 * robert_ancell is glad he's not a sysadmin
<dholbach> could it be that Launchpad is not allowing new ubuntu bugs via apport in?
<elmo> dholbach: yes
<dholbach> thanks elmo
<ricotz> robert_ancell, exactly what i got, but the upload worked anyway ;)
<trojanware> which dbus service broadcasts info whenever a friend logs in?
<trojanware> using empathy
<pitti> Daviey, smoser: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt recently grew an universe->main for lxc; seems this was seeded recently? seems a little late now?
<ttx> pitti: afaik it's needed so that you can use uec-images directly as an LXC container (so lxc is installed by default on it)
<ttx> pitti: (not judging if the feature is worth the lateness or not)
<pitti> cjwatson, ev: what's the condition for installing the PAE kernel?
<elmo> pitti: the 32-bit server kernel is PAE
<pitti> right, I mean desktop
<elmo> so that's one condition
<pitti> I want to document bug 759804 for the release notes
<ubottu> Launchpad bug 759804 in ubiquity (Ubuntu) "Installation of -pae kernel happens after jockey -C, causing removal of built DKMS modules" [High,New] https://launchpad.net/bugs/759804
<pitti> but as only few people get it, I suppose it only installs that if you have more than e. g. 4 GB of RAM?
<ev> pitti: 32-bit system with more than 3GB of RAM
<pitti> ev: thanks
<ev> sure thing
 * popey hugs kees 
<popey> kees: glad it's not just me that misses FFM in unity :(
<ev> pitti: I stand corrected.  It used to be 3GB, it's 4 now.
<pitti> ev: thanks for checking
<ev> (lp:~ubuntu-core-dev/base-installer/kernel/i386.sh:32)
<ev> no problem
<soren> popey: You're not alone at all. I managed to coerce compiz into doing ffm, but the globalmenu makes it a bit annoying.
<popey> it does
<ev> simulating a machine with nvidia and > 4GB of RAM now to test the fix
<tjaalton> https://blueprints.launchpad.net/sprints/uds-o only shows ten blueprints, and https://blueprints.launchpad.net/ubuntu/oneiric shows nine
<tjaalton> surely there are others already?
<tjaalton> oh, the rest are just proposed
<pitti> TheMuso: still awake by any chance?
<pitti> who usually tests ubuntustudio images? LP is back up, and the uninstallability is fixed on the latest images
<pitti> posted to the tracker
<smoser> pitti, regarding lxcguest in uec seed. that is bug 727200.
<ubottu> Launchpad bug 727200 in lxc (Ubuntu Natty) "[MIR] lxcguest in main" [Undecided,In progress] https://launchpad.net/bugs/727200
<smoser> fwiw, lxcguest has been in the images since before beta1.
<smoser> it was just added via build command rather than seed.
<pitti> smoser: ah, good
 * pitti promotes
<pitti> ogra_: linux-tools-omap4 wants  to go to universe, is that ok?
<mdz> I just rebooted and logged into a fresh session, and got a "you have logged in using a different language" dialog suggesting replacing "/home/mdz" with "/home/mdz/Downloads"
<ogra_> pitti, heh, good question
<pitti> mdz: hm, xdg-user-dirs should perhaps check if a particular dir is now your $HOME instead of a subdir..
<pitti> mdz: apparently you set the downloads folder to ~ at some point
<mdz> pitti, perhaps, yes
<pitti> ogra_: we can also just seed it to supported
<jibel> TheMuso, ping
<seb128> mdz, those checks usually happen when you change your locale, did you do that?
<mdz> seb128, no
<mdz> at least not intentionally or knowingly
<seb128> mdz, the directories are in .config/user-dirs.dirs
<mdz> seb128, I clicked "update" and that file has the /Downloads path now as expected
<seb128> ok, weird
<seb128> it's supposed to compare .config/user-dirs.locale with your locale and do those checks only if you changed locale
<seb128> it's to rename the directory to whatever words they are in the local you use
<null1> hai people
<pitti> ogra_: so perhaps we should just seed it then; not much harm having it in main, I guess?
<ogra_> pitti, i have to find out what it adds over linux-tools
<jibel> hey all, natty beta 2 candidates on powerpc need smoke testing, anyone ?
<ogra_> but yeah, seeding to supported is probably safe in any case
<jibel> if you want to help, the images are on the tracker http://iso.qa.ubuntu.com/qatracker/build/all/notcompleted
<pitti> ogra_: oh, hang on
<pitti> ogra_: linux-tools-omap4 is shown as uninstallable in http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html
<pitti> ogra_: so I guess it actually should live in universe
<ogra_> grmbl, the description of the packages is really pointelss to decide it
 * ogra_ grumbles towards the kernel team
<pitti> ogra_: do you mind if I demote it? then c-m is empty and done for natty
<pitti> and it'll fix the uninstallability, too
<ogra_> pitti, well, it might be needed for something, i'd really like to hear from the kernel team first
<ogra_> apw, ^^^ any comment ?
<pitti> ogra_: nothign in main depends on it, anyway, but sure
<apw> ogra_, wassup ?
<ogra_> apw, linux-tools-omap4, whats that and what for do we need it ?
<ogra_> i.e. does it provide anything linux-tools doesnt provide and is what it provides essential enough to have the package in main
<apw> it is the package which is used to get the kernel version tied tools for omap4, it in theory should pull in the perf tool
<apw> it is the version of the tools for omap4, rather than for regualr arm, as the kerenel is variant and the tools are variant specific
<apw> it cirtainly is not world ending if it is in universe
<ogra_> k
<apw> it is a debugging thing, not on any criticial path
<ogra_> pitti, go ahead then
<ogra_> apw, thanks !
<pitti> good
<pitti> thanks
<ogra_>  This package provides the architecture dependant parts for kernel
<ogra_>  version locked tools for version 2.6.38-1207 on
<ogra_>  DESC.
<apw> heh nice, hopeless, sigh
<ogra_> apw, i think there is a bug in the scripts creating the description
<apw> yeah does look like it doesn't it.
<pitti> linux-ti-omap4-tools-2.6.38-1207 is uninstallable, too
<apw> i am looking at the mess that is that tree so, i'll have a look at the same time
<ogra_> be careful afaik cooloney is in the middle of rebasing it
<ogra_> or at least he tries to
<ogra_> pitti, well, thats the actual binary, the former one was just the meta
<ogra_> pitti, drop it too
<pitti> that's being held in main, though
<pitti> hmm
<pitti> only by linux-tools-omap4
<pitti> ok, demoting
<ogra_> yeah
<mok0> Will we have beta2 today?
<ogra_> thats what the scedule says
<Daviey> pitti: just saw your message.  Yes, it is my understanding that it has already been included in the cloud images.
<Daviey> Has been for some weeks now.
<pitti> Daviey: all good now, MIR was approved, and I promoted it
<Daviey> pitti: yeah, kees approved it a few days ago?
<TheMuso> pitti,jibel pong
<pitti> TheMuso: jibel is already testing the studio ones
<TheMuso> pitti: I am no longer involved with studio. I still help from time to time, but am no longer a primary contributor.
<pitti> ah, ok
<jibel> TheMuso, hi, any chance to smoke test the latest builds on powerpc ?
<TheMuso> jibel: I have already tested ubuntu powerpc alternate and desktop.
<jibel> TheMuso, Ubuntu Alternate and Desktop
<TheMuso> jibel: THose tests should show up as done, unless there has been a rebuild...
<jibel> TheMuso, I know but it's been rebuild yesterday, and we'd like to ensure that there no regression
 * TheMuso sighs
<TheMuso> I'm on it.
<jibel> TheMuso, awesome! thanks
<TheMuso> Well I know that the desktop tasks will fail already, since I filed a bug about an install error which has not yet been fixed...
<ogra_> TheMuso, can you remove the maverick omap4 config files from alsa-libs ? do you need a bug for that ?
<TheMuso> ogra_: Don't think so. What files are you referring to exactly?
<ogra_> the init files
<TheMuso> you mean alsa-utils? Sure, why don't you need them?
<ogra_> i'm pretty sure they get in our way with UCM
<TheMuso> ah ok.
<ogra_> they were for the hacked up kernel in maverick
<TheMuso> Right. Maybe for the sake of paperwork if you could file a bug if possible accessing launchpad, please do.
<ogra_> k, no prob
<ogra_> TheMuso, we also noticed that on our headless images the initialization seems to work fine on natty ... but not on the netbook ones
<TheMuso> ogra_: no idea there, same code.
<ogra_> (headless doesnt ship any userspace audio stuff)
<TheMuso> still no idea.
<TheMuso> ogra_: What hardware?
<ogra_> omap4 pandaboard
<ogra_> (arm)
<TheMuso> hrm ok
<TheMuso> so lets remove those files from alsa-utils and see how things go I guess.
<ogra_> the funny thing is that headless doesnt ship any alsa packages by default ... dmesg shows the asoc devices properly initializing
<ogra_> on netbook we ship alsa-libs/-utils and there the kernel fails to initialize the devices
<TheMuso> How does it fail?
<ogra_> dmesg shows messages about "no backend routing" for all devices iut tries to init
<ogra_> i need to collect logs and will attach them to the bug
<TheMuso> ok
<ogra_> its just very intresting that it seems to work fine without any userspace intervention
<TheMuso> yep
<TheMuso> Have you tried manually removing the init files?
<ogra_> not yet, will do so
<TheMuso> thanks.
<ogra_> TheMuso, bug 760571
<ubottu> Launchpad bug 760571 in alsa-utils (Ubuntu Natty) "please remove maverick omap4 init scripts from the package" [Medium,Triaged] https://launchpad.net/bugs/760571
<TheMuso>  ogra_ thanks
<Riddell> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Beta-2/Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: zul
<TheMuso> ogra_: Ok in the queue, it was a simple patch so it was easy to remove.
<diwic> ogra_, TheMuso, hi - anything you need me for? I was ill yesterday so couldn't do much.
<TheMuso> diwic: Nothing other than my PPA has been updated with the udev patch you recommended. Only thing is with the lp issues in the last 12 hours or so, I am not sure if its actually published/built.
<diwic> TheMuso, ok
<ogra_> diwic, make sound work please :P
<ogra_> nothing beyond that *g*
<juliank> Aren't bug 676790 and bug 675641 virtually the same bug?
<ubottu> Launchpad bug 676790 in apt (Ubuntu) ""Building dependency tree" is very slow with compressed apt indexes" [Low,Triaged] https://launchpad.net/bugs/676790
<ubottu> Launchpad bug 675641 in apt (Ubuntu) "apt compressed indexes seriously slow down synaptic" [Low,Triaged] https://launchpad.net/bugs/675641
<juliank> Having both affecting APT isn't that useful, we could reassign  675641 to synaptic, or mark one as a duplicate of the other
<cjwatson> it only needs a synaptic task if synaptic needs a change in order to fx it (IMO)
<cjwatson> juliank: bug 135284 - Kickstart certainly is used, why close the bug?
<ubottu> Launchpad bug 135284 in pkgsel (Ubuntu) "Unknown maximum list size in kickstart's ks.cfg %packages" [Undecided,Triaged] https://launchpad.net/bugs/135284
<cjwatson> I mean, maybe it's not sensible to fix it in apt, but it shouldn't be closed just because it's old, especially if part of that reasoning is a misconception that Kickstart isn't used
<juliank> cjwatson: I close bugs older than 3 years first, instead of doing an Incomplete->Invalid ping-pong.
<cjwatson> then can I reopen with no reasoning?
<juliank> cjwatson: Is it reproducible?
<cjwatson> honestly, closing for that reason is pretty frustrating to me.
<cjwatson> I have no idea, IMO the onus is on the person closing the bug ...
<cjwatson> it's pretty clearly described
<juliank> cjwatson: I've run some fairly large apt-get install command lines and never experienced any problems.
<juliank> (certainly more than 10)
<cjwatson> if the reason is that it's been fixed, then that's a good reason to close it
<cjwatson> but I've reopened because "this bug is old" isn't
<tkamppeter> pitti, hi
 * cjwatson will try to set up a reproducer
<juliank> cjwatson: The correct procedure would be "This bug is very old and hasn't seen recent updates. Can you still reproduce this issue?" and setting to Incomplete. But given the amount of changes we had in the last 4 years, it's not reproducible in 99% of the cases, so going to Invalid and asking to reopen if it can be reproduced saves a lot of time
<tkamppeter> mvo, hi
<juliank> And yes, our package argument handling is fairly rewritten compared to 4 years ago IIRC
<mvo> hi tkamppeter
<cjwatson> I have no problem with people closing bugs because "we've completely rewritten this part of the code and believe it's probably fixed".  That's completely different from "this bug is four years old and has gone mouldy"
<tkamppeter> mvo, it is about aptdaemon and the Lintian checks, bug 712377, an additional relaxiong is needed. See https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/712377/comments/36
<ubottu> Ubuntu bug 712377 in aptdaemon (Ubuntu Natty) "Opening a known good *.deb with software centre, fails to install as lintian errors cannot be overidden" [High,Fix released]
<mvo> tkamppeter: ok, I have a look
<tkamppeter> mvo, currently installation of manufactutrer-suypplied printer drivers with software-center is blocked.
<cjwatson> in this case, it's filed on an installer component too, and apt/Invalid + pkgsel/Triaged means "apt is doing just fine, this is an installer bug"
<mvo> tkamppeter: thats fine
<tkamppeter> mvo, can that get fixed for the final Natty? Thanks.
<mvo> tkamppeter: yes
<mvo> hey axp2 :)
<axp2> hi
<axp2> how are you mvo?
<tkamppeter> mvo, Note that these packages are LSB-based packages so they depend only on "lsb" which is supposed to pull in all needed dependencies.
<juliank> cjwatson: Well yes, it should definitely be doable on the APT side without problems. I kept the pkgsel side open, as that's completely not my territory
<juliank> But no problem.
<cjwatson> juliank: how would one best pass a very large number of arguments to APT, when it goes over the system command-line length limit?
<cjwatson> APT doesn't provide a "read list from file" option, and using dpkg --set-selections as mvo suggests is ... clunky
<juliank> cjwatson: Well, that's a complete different topic. The solution for this is to pass the selections to dpkg and run apt-get install -f
<cjwatson> pkgsel has no realistic way to know how to split up the list in a way that'll work
<cjwatson> juliank: that's the topic of the bug, now that I've read it in more detail
<cjwatson> not completely different at all
<juliank> cjwatson: The problem was that it was below the system limit; that is, a bug in APT, preventing it from working correctly with the maximum number of arguments
<cjwatson> would it not be a reasonable wishlist to have it take the list from a file?  I'm concerned that dpkg + install -f wouldn't be quite the same - for example, wouldn't apt-get be entitled to remove one of the packages you set to install in order to fix it?
<juliank> The other thing would be a feature request
<juliank> cjwatson: Just tell me what format you want, and I'll write it (we could also just support a format where each command-line argument is on a single line)
<juliank> cjwatson: And apt-get seems to handle apt-get install $(apt-cache pkgnames) quiet well
<juliank> 32941 arguments
<juliank> I mean it does not install anything, but it parses the command-line correctly and finds the broken packages
<cjwatson> hm, OK, perhaps the system length limit is higher than I thought!
<pitti> hey tkamppeter, how are you?
<cjwatson> I'm just setting up a Kickstart file to install everything on the server CD, to see what it dodes
<cjwatson> *does
<cjwatson> juliank: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/135284/comments/8
<ubottu> Ubuntu bug 135284 in apt (Ubuntu) "Unknown maximum list size in kickstart's ks.cfg %packages" [Wishlist,Triaged]
<juliank> cjwatson: Actually, once you remove all depends/conflicts/etc, it seems to hang before the files should be downloaded. But there's another bug about Acquire being very very slow somewhere that explains this
<juliank> And it continues after some time
<tkamppeter> pitti, fine, I have found a proble which needs to eb solved for Natty, https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/712377/comments/36 software-center does not install prionter drivers. I have informed mvo and he is looking into that.
<ubottu> Ubuntu bug 712377 in software-center (Ubuntu Natty) "Opening a known good *.deb with software centre, fails to install as lintian errors cannot be overidden" [Undecided,In progress]
<juliank> "252 upgraded, 32574 newly installed, 0 to remove and 0 not upgraded."
<juliank> cjwatson: Works perfectly, takes some time to get to download, but download starts and proceeds normally.
<cjwatson> juliank: great, thanks - glad to hear it
<cjwatson> if it works in pkgsel, we should be able to just close it, since there'll be no need for the new feature
<juliank> cjwatson: Agreed
<tkamppeter> pitti, another problem is that clicking arch-independent DEB files in Firefox (_all.deb) are considered as unknown file format (no association with software center). This should also be fixed for Natty.
<tkamppeter> mvo, ^^^
<juliank> I need to reboot now, I have about 230 mount points that I can't unmount.
<cjwatson> juliank: 'umount -l' can sometimes help ...
<cjwatson> too late
<Jerub> i was going to suggest fuser
<fabbione> hey guys
<fabbione> does anybody remember Daniel Stone irc nick name by any chance?
<ogra_> daniels
<pitti> hey fabbione
<fabbione> ogra_: thanks
<fabbione> hey pitti
<ogra_> :)
<tkamppeter> pitti, mvo, I have reported bug 760644 on the fact that for architecture-independent .deb files Software Center does not get opened when clicking them in firefox, did I select the correect packages?
<ubottu> Launchpad bug 760644 in firefox (Ubuntu) "Architecture-independent .DEB packages (_all.deb) not connected to software-center" [High,New] https://launchpad.net/bugs/760644
<mvo> thanks tkamppeter, sounds like something for chrisccoulson if its firefox
<tkamppeter> mvo, I do not know whether the file type/program associations are in Firefox.
<juliank> If anyone wants to debug something with pselect(), take a look at bug 341777
<ubottu> Launchpad bug 341777 in apt (Ubuntu) "jockey-backend crashed with signal 5 in pselect()" [Medium,New] https://launchpad.net/bugs/341777
<juliank> (I'm not a select() and signals freak)
<chrisccoulson> mvo / tkamppeter - firefox is using gio to lookup the default handler
<tkamppeter> chrisccoulson, what does it mean for the package assignment of bug 760644?
<ubottu> Launchpad bug 760644 in firefox (Ubuntu) "Architecture-independent .DEB packages (_all.deb) not connected to software-center" [High,New] https://launchpad.net/bugs/760644
<cjwatson> juliank: OK, closed now, sorry for doubting you :-)
<juliank> cjwatson: I'm on a magic close/merge mission this week, as we just have way too many open bugs to even start working on them. (python-apt had 40, now has about 7, out of which 3 are unfixed; apt had about 40 bugs closed, merged, or reassigned)
<juliank> Thus in total, we went from 300 to 200 bugs this week.
<juliank> mvo: ^
<mvo> nice
<ogra_> scary, you will make us all jobless !
<tkamppeter> mvo, see also comments #41 and #44 on bug 712377.
<ubottu> Launchpad bug 712377 in software-center (Ubuntu Natty) "Opening a known good *.deb with software centre, fails to install as lintian errors cannot be overidden" [Undecided,In progress] https://launchpad.net/bugs/712377
<zul> pitti: hi there is a regression in the last samba lucid  sru with winbindd segfaulting i just uploaded a fix for it, its waiting to be accepted
<pitti> zul: ah, thanks
<zul> pitti: np
<chrisccoulson> mvo - is application/x-deb actually registered with shared-mime-info?
<mvo> chrisccoulson: it should be, haven't checked, but gdebi was using it as well
<kiwinote> mvo: it seems to be a consequence of http://bazaar.launchpad.net/~software-store-developers/software-center/trunk/revision/1535.1.16 (there's a bug open on apturls in firefox too) - I recall testing it quite well, so either I over looked a corner case, or I had some local config or so
<chrisccoulson> yeah, it seems to be
<chrisccoulson> hmmm
<mvo> kiwinote: ohhh, thanks
<chrisccoulson> mvo / tkamppeter - i'll have a look at this issue. for some reason, firefox thinks that the content type isn't registered (according to glib)
<chrisccoulson> mvo - do you know who looks after apt.ubuntu.com too?
<mvo> chrisccoulson: IS is all I know, sorry
<chrisccoulson> mvo - thanks
<juliank> jibel: I still can't see the APT portion in bug 513460 - DescURI() for a local package (obsolete) should be empty
<ubottu> Launchpad bug 513460 in apt (Ubuntu) ""Generate package download script" create empty files (in the case of "generate scrip" only one line: "#!/bin/sh")." [Low,Triaged] https://launchpad.net/bugs/513460
<juliank> mvo: We're now actually at 178 bugs in apt, starting from about 250 this morning
<jibel> juliank, IIRC all the calls to DescURI() after the obsolete package returns an empty record. should verify if it still exists and retitle the report or file another one.
<jibel> Tm_T, hi, the latest builds for Kubuntu on powerpc are untested. Could you smoke test them and ensure that nothing broke since the previous builds ?
<janimo> pitti, regarding bug 760431 I subscribed ubuntu-release as the freeze exception wiki page indicates
<ubottu> Launchpad bug 760431 in clutter-1.0 (Ubuntu) "fix cogl pkgconfig file" [Undecided,New] https://launchpad.net/bugs/760431
<janimo> I uploaded last night
<maco> Laney: ewww gmail is merging all the application processing threads into one lump :(   <3 kmail in this instance
<Laney> heh
<Laney> gmail: because nobody ever uses the same subject for different converstaions!
<Laney> anyway, yeah, please pitch in with questions :-)
<sconklin> @patch in
<udevbot> Error: "patch" is not a valid command.
<maco> sconklin: pilot i think
<sconklin> maco: thanks
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Beta-2/Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: sconklin, zul
<Daviey> sconklin, I had a dog called patch once.
<sconklin> my mom had a dog named patches
<sconklin> I've had plenty of patches that were dogs
 * dholbach hugs sconklin
<pitti> hallyn: hey
<bdrung> mdeslaur: re bug #760685 - do you want debdiff for maverick and lucid from me?
<ubottu> Launchpad bug 760685 in vlc (Ubuntu) "Lucid Lynx is not getting VLC security updates" [Undecided,Invalid] https://launchpad.net/bugs/760685
<pitti> hallyn: I reject your libvirt maverick uploads; http://launchpadlibrarian.net/68469973/libvirt_0.8.3-1ubuntu15_source.changes has a typo in the changelog (two #), and http://launchpadlibrarian.net/68475451/libvirt_0.8.3-1ubuntu16_source.changes isn't built with including the previous changelog
<mdeslaur> bdrung: I just published updates for lucid, maverick and natty
<tkamppeter> pitti, I have severe problems with CUPS and I want to ask you for help. It segfaults rather often and Apport is not able to create symbolic stack traces. Bug 751770.
<ubottu> Launchpad bug 751770 in cups (Ubuntu) "cupsd crashed with SIGSEGV in dbus_connection_get_is_connected()" [Medium,New] https://launchpad.net/bugs/751770
<bdrung> mdeslaur: yes, i should read all my mails before asking questions :)
<pitti> hallyn: so either please reupload as 15 with a merged changelog, or as ubuntu16 with building with -v0.8.3-1ubuntu14.1
<bdrung> mdeslaur: natty too? i uploaded 1.1.9-1ubuntu1 to natty
<tkamppeter> pitti, also bug 754567, it seems that it crashes at different points in DBus library functions.
<ubottu> Launchpad bug 754567 in cups (Ubuntu) "cupsd crashed with SIGSEGV in dbus_message_iter_append_basic()" [Medium,New] https://launchpad.net/bugs/754567
<mdeslaur> bdrung: ah, well your package will supersede mine
<hallyn> pitti: I reject your rejection!
<hallyn> pitti: will do, thanks :)
<hallyn> hm, hopefully launchpadlibrarian can give me the source back, bc i've deleted the bzr trees
<hallyn> pitti: is there any way for you to check whether there are pending upates for lucid's libvirt?
<hallyn> pitti: i thought iw as waiting for two lucid-proposed updates, but now i'm wondering whether i thought the maverick ones were for lucid, and i should have just gone ahead with my next lucid-proposed libvirt push
<debfx> ScottK: it might be a good idea to add bug reporting guidelines for the *-backports launchpad projects stating what is needed for a request to be approved
<ScottK> debfx: I'm a little busy today.  If you can propose text, I'd be glad to copy/paste it in.
<pitti> hallyn: http://people.canonical.com/~ubuntu-archive/pending-sru.html doens't show a libvirt for lucid
<hallyn> pitti: thanks
<pitti> hallyn: however
<pitti> hallyn: there is one in the review queue which hasn't been accepted into -proposed yet: https://launchpad.net/ubuntu/lucid/+queue?queue_state=1
<pitti> hallyn: should I review that, or do you want to update that as well with another change? (then it's better to have just one upload instead of two)
<hallyn> how do i update that with another change?
<pitti> hallyn: I reject the upload, you add the extra stuff and reupload
<hallyn> pitti: the only problem with that is, as with this maverick one, that i lost my bzr trees
<hallyn> pitti: so it'd be easier to have that go through to the -proposed bzr tree so I can build on top of that
<pitti> hallyn: you can also download the source from that queue page if you want
<pitti> hallyn: but I'm fine with reviewing/accepting it, then we test that first, and update again once it's in -updates
<hallyn> pitti: let's go that route while i figure out how to undo my mess with the maverick version
<hallyn> pitti: thanks
<pitti> hallyn: ack, will do
<tomreyn> hi
<tomreyn>  according to https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/737137 cmake in natty should be able to find the libraries in /usr/lib64/x86_64-linux-gnu since cmake 2.8.3-3ubuntu4. I'm on cmake 2.8.3-3ubuntu7 and it does not seem to find them here...
<ubottu> Ubuntu bug 737137 in cmake (Debian) "find_library fails to locate multiarch libraries" [Unknown,New]
<tomreyn> i'm not really a developer, though, so I may be misinterpreting things.
<tomreyn> My real issue is that I run into errors like "No rule to make target `/usr/lib/libz.so', needed by `source/game/glestadv'.  Stop." on natty when I did not run into these on maverick. And this seem to be because the libraries are not found by cmake in /usr/lib64/x86_64-linux-gnu
<ScottK> slangasek: ^^^
<tomreyn> ...and because they no longer exist in /usr/lib (where they did exist on maverick)
<pitti> tkamppeter: I'll have a look
<hallyn> pitti: given http://launchpadlibrarian.net/68469973/libvirt_0.8.3-1ubuntu15_source.changes, how can I get the source?  I've tried dget'ing the .dsc with several prepended launchpadlibrarion urls, but haven't gotten it right yet
<pitti> hallyn: open the expander on the queue page, there you see the .dsc, .diff.gz, etc.
<debfx> tomreyn: sounds like either the libz path is hardcoded and not checked or (more likely) cmake has cached the old path
<slangasek> tomreyn: cmake itself can find libraries in the multiarch directory, but there may be upstream-specific or library-specific cmake rules that are looking for a hard-coded path
<slangasek> for instance, bug #751940
<ubottu> Launchpad bug 751940 in cmake (Ubuntu) "Problem with cmake module FindGTK2.cmake in Ubuntu >= 11.04 (Natty Narwhal)" [Medium,Triaged] https://launchpad.net/bugs/751940
<hallyn> pitti: got it, thanks
<slangasek> tomreyn: at a glance, I don't see anything in /usr/share/cmake-2.8/Modules/FindZLIB.cmake that should break with the current zlib packages; can you point me to the source you're trying to build, so I can test here?
<dpm> hi allison_, all set for your appdeveloper week session later on?
<pitti> zul: are these landscape-client SRUs ok to go after the currently -proposed ones? if so, I'll just keep them in the queue until they got verified
<pitti> zul: if not, they'd need to be reuploaded with -v to include the previous proposed update
<zul> pitti: *sigh* ok ill do that
<tomreyn> slangasek: i'm sorry, in the case of libz it was indeed my mistake, not having deleted the local cmake cache. but i ran into this issue with other libraries lately. let me see if this still happens.
<pitti> zul: i. e. the current -proposed pacakges shouldn't be released like that?
<slangasek> tomreyn: ok - if you are seeing problems after the cache flush, please let us know so we can get those addressed
<zul> pitti: there was  a bug fix in the last ones i uploaded they were the .1 packages
<pitti> zul: ok, I'll reject them then, to clear the way for your reuploads?
<zul> pitti: ok thanks
<tomreyn> slangasek: i must have installed the cmake update since i last flushed the cache, it no longer happens now. sorry to have wasted your time.
<bdrung> bryceh_: re bug #755841: what's the fastest way to reload the -intel driver? log out and sysrq+k?
<ubottu> Launchpad bug 755841 in xserver-xorg-video-intel (Ubuntu) "[sandybridge] video tearing" [Undecided,Incomplete] https://launchpad.net/bugs/755841
<slangasek> tomreyn: not a waste, thanks for the input :)
<pitti> mvo: your apt-clone upload drops the .bzr-builddeb/ dir, is that really intended?
<pitti> hm, seb128 uploaded shared-mime-info which fixes the b-deps, but drops the Multiarch: field
<pitti> I guess that's not right
<pitti> slangasek: ^
<slangasek> it is not right :/
<slangasek> need me to fix?
<pitti> I'll reject it then
<pitti> slangasek: I think seb128 can handle it; probably some bzr vs. other bzr fight here :)
<slangasek> well, the package has no Vcs-Bzr field
<pitti> or he just downloaded a previous version and forgot about your's or so
<mvo> pitti: its a side effect of bzr-buildpackage I believe, I think the previous upload was done differently, its still in bzr
<pitti> mvo: ah, ok
<pitti> accepting then
<mvo> thanks!
<bryceh_> bdrung, if it's just the xserver-xorg-video-intel driver, then just logging out and back in is sufficient (I usually do sudo service gdm restart, though)
<bryceh_> bdrung, if you need to reload the kernel intel drm driver, then rebooting is probably the simplest way, although you could also remove and reload the kernel module (maybe)
<SpamapS> pitti: ping, trying to figure out if this diff is flawed because it makes the version lower than a previous rejected proposed upgrade: http://launchpadlibrarian.net/69370270/vsftpd_2.2.2-3ubuntu7.1_2.2.2-3ubuntu6.2.diff.gz
<Tm_T> jibel_: about ppc testing, just got home so about to download and give them a test run (:
<ohsix> hrm just actually tried the kinetic scrolling; that's great
<pitti> SpamapS: right, that's hard to read; I think in this case it's better to download the current version from archive and the version from the queue and debdiff it
<bdrung> bryceh_: thanks
<SpamapS> pitti: roger.
<shadeslayer> btw i don't see UDS Oneric Ocelot in the Android app for Conventionist ( refer http://summit.ubuntu.com/mobile/ )
<Daviey> pitti, trying to get an idea of where the inconsistency of that SRU is...  is it merely the -proposed bzr branch being including a nuked upload?  or archive -proposed pocket (approved or unapproved)?
<Daviey> I was sure i checked the unapproved queue before uploading, which is causing me great confusion.
<bigcx2> hey all, i have a question about bumping a package version in natty
<bigcx2> i have a package i got via apt-get source
<bigcx2> i made some changes to it
<bigcx2> and ran dch -i
<bigcx2> which gave me:
<bigcx2> dch warning: no orig tarball found for the new version.
<bigcx2> and then when i go to build with dpkg-buildpackage
<bigcx2> it errors with:
<bigcx2>  dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found
<bigcx2> what gives??
<slangasek> bigcx2: you've bumped the upstream version number but you haven't provided a new upstream tarball to go with it
<bigcx2> slangasek: if i copy the old orig.tar.gz to the new version # should that be sufficient?
<slangasek> it would solve the error but would be a wrong change
<slangasek> you shouldn't change the upstream version number in debian/changelog unless there's a new upstream version
<slangasek> what are the previous and new version numbers?
<bigcx2> this is just for a "in-house" use package
<bigcx2> i'm moving from 0.1 to 0.2
<slangasek> "0.1" and "0.2" are not version numbers that would trigger this error
<slangasek> because they're native version numbers, so 3.0 (quilt) would cause a different error message entirely ;)
<Daviey> pitti, If it was just the LP generated diff, It looks like it was a case of bug 680911.
<ubottu> Launchpad bug 680911 in Launchpad itself "Diff generation in the proposed pocket should consider the updates pocket even when there are previous proposed publications." [Low,Triaged] https://launchpad.net/bugs/680911
<bigcx2> slangasek: hm, either way that's what i'm getting lol
<bigcx2> if i copy the old tarball to the new version
<bigcx2> it stops complaining
<bigcx2> and it seems to do the right thing...but i added a script in the new package, and i get this now:
<slangasek> bigcx2: the version number in debian/changelog should have an upstream part and a "Debian revision" part, separated by a dash; changing the part before the dash causes this error, changing the part after the dash is safe and what you want to be doing if there isn't actually a new upstream version
<bigcx2> slangasek: ok
<bigcx2> executable mode 0755 of 'test.sh' will not be represented in diff
<slangasek> right
<bigcx2> i'm glad it makes sense to you :)
<slangasek> if you need it executable, you need to set the execute bit at package build time, via debian/rules or a change to an upstream makefile
<bigcx2> hm, things have certainly changed last time i built a package !
<bigcx2> it's just a script i'm installing with dh_install
<bigcx2> so there is no makefile
<bigcx2> so just chmod in debian/rules?
<slangasek> ok, then it's fine that it's not executable in the diff - you just need to make sure you're setting the permissions you want via debian/rules when installing, yes
<bigcx2> dh_fixperms?
<slangasek> bigcx2: yes, if it's installed to /usr/bin, dh_fixperms is sufficient
<bigcx2> slangasek: thanks!
<speakman> Is there any "GNU Autotools to .deb" utility available?
<speakman> Or; how to make a .deb out of a GNU Autotools project?
<cjwatson> for autotools, debian/rules can normally just be /usr/share/doc/debhelper/examples/rules.tiny
<cjwatson> and construct the rest of debian/ as usual
<cjwatson> in fact, with the current version of dh_make in natty (not older releases), 'dh_make' should do it
<cjwatson> (dh-make package)
<speakman> oh, sounds awesome! too bad I'm not on natty :(
<cjwatson> well, autotools is very packaging-friendly, so just about any auto-package-this tool will do it.  an older version of dh_make should be fine, it just won't automatically use the nice minimal rules format
<speakman> ok
<cjwatson> you can always replace it with /usr/share/doc/debhelper/examples/rules.tiny, 'echo 7 >debian/compat', and make sure you're build-depending on debhelper (>= 7)
<cjwatson> that kind of little niggle should disappear once we stop needing to worry about lucid :)
<speakman> what's the best docs about debhelper?
<cjwatson> its man pages
<speakman> ok
<speakman> how do I specify configure rules?
<cjwatson> with the tiny rules format:
<cjwatson> override_dh_auto_configure:
<speakman> ok
<cjwatson>         dh_auto_configure --with-blah
<cjwatson> (that's a hard tab at the start, this being a makefile)
<slangasek> isn't that -- --with-blah?
<speakman> I guess it's only --prefix which dh_make probably sets correctly anyway?
<cjwatson> you don't need it for basic stuff like --prefix, though - that's figured out for you
<cjwatson> slangasek is as usual correct
<speakman> great, thanks :)
<cjwatson> also, if you use override targets, build-depend on debhelper (>= 7.0.50)
<speakman> hm, why isn't dh_make a part of debhelper?
<cjwatson> it's maintained and developed independently
<azeem> different author
<cjwatson> and it's not needed at build time, only for people wanting to use it to create initial packaging
<speakman> ok
<speakman> Do I have to ./configure the package prior to dh_make ?
<slangasek> no
<cjwatson> no.  dh_make just gives you template packaging; you edit it to give yourself a source package; you then build that source package
<cjwatson> (and you then forget about dh_make)
<cjwatson> most people just copy from the last package they did once they've done a few, rather than using dh_make. :-)
<cjwatson> but it cuts down on how much you need to absorb at first
<speakman> Hm. It always get my email address wrong. Where does it get it from?
<cjwatson> http://manpages.ubuntu.com/manpages/natty/en/man8/dh_make.8.html and search for e-mail
<speakman> and what about these .ex files? emacsen? manpage? I've got neither
<cjwatson> delete them if they aren't necessary
<cjwatson> dh_make spits out a *template* - you're supposed to edit it
<speakman> ok, is there a good newbie site how to build deb packages using db_make? :)
<cjwatson> probably but I have no idea where it might be. :-)
<speakman> (very old-time debian and later ubuntu user, but never done any packaging :D )
 * cjwatson last used dh_make in 1999
<speakman> ok
<speakman> doing manually is better?
<cjwatson> I'm not making a value judgement - I do it manually because I've been doing it for 12 years and find it easier that way, but I'm sure it isn't easier to do it manually if you're new to the business
<speakman> i see
<speakman> rm *.EX && rm *.ex did the trick ;)
<speakman> http://www.debian-administration.org/articles/337
<cjwatson> some folks around here have been working on some simpler auto-packaging tools, but I'm afraid I don't have links to hand
<speakman> ok, sounds neat though :)
<ion> Also, be sure to use dh7-style debian/rules.
<speakman> ok?
<speakman> so, where to read about debian/rules styles? :D
<cjwatson> that debian-administration guide seems not unreasonable in general outline; some details have changed in the last five years, of course, but that essentially amounts to having to do less work
<cjwatson> man dh
<ion> See /usr/share/debhelper/dh_make/debiann/rules.dh7
<ion> Thatâs what youâll want to start with.
<speakman> thanks!
<cjwatson> ion: (see above where I pointed speakman to /usr/share/doc/debhelper/examples/rules.tiny already.)
<ion> Ah :-)
<speakman> debian/compat is set to 7 by dh_make
<speakman> hm can I examine my newly built .deb file somehow? :D
<cjwatson> debc
<speakman> (without ar-extracting it and so on..)
<speakman> oh, devscripts took it's space...
<speakman> debc: can't ready mypackage_1.0-1_amd64.changes!
<cjwatson> read its man page, think, work out what you missed
<speakman> dpkg -c mypackage....deb did the trick ;)
<cjwatson> sounds like you did 'cd ..' before running debc.  don't.
<cjwatson> (perhaps.)
<speakman> hm?
<speakman> I'm in the source tree, not debian/
<cjwatson> well, in that case you must have run 'debian/rules build && fakeroot debian/rules binary', rather than 'debuild -b'
<cjwatson> (briefly, the latter is the same as the former except that it also generates a .changes file, which is useful for tools like debc)
<cjwatson> again, read man pages - all the commands I'm mentioning have good ones)
<speakman> debuild -b made debc work also
<speakman> Section: unknown - is that ok for a "non-public" package?
<cjwatson> doesn't matter for that
<speakman> ok
<speakman> Thanks alot guys, I think I know enought for creating my own packages :)
<cjwatson> you're welcome
<speakman> How well does alien convert it to rpm?
<speakman> does RH based system has the same paths?
<speakman> (not really sure it will be running on ubuntu or rh)
<maxb> I'm running a natty upgrade, and something very weird is happening in the "Calculating the changes" phase. It's taking ages, and by tailing /var/log/dist-upgrade/apt.log, I can see it appears to be visibly writing its output character by character.
<speakman> and to make a new "version" I just edit debian/changelog right?
<speakman> and then debuild -b again?
<speakman> and one final thing; can I make i386 binaries on a amd64 machine?
<speakman> do you guys use pbuilder?
<speakman> https://wiki.ubuntu.com/PackagingGuide/Complete#Prerequisites
<maxb> I think nearly everyone who does serious packaging work uses pbuilder, unless they've chosen to assemble a full sbuild setup instead
<OdyX> "full sbuild" isn't very hardâ¦
<speakman> https://wiki.ubuntu.com/PackagingGuide/Complete is *really* good btw!
<speakman> If I'm the maintainer of the project I'm packaging, should I keep the debian/* files in the GIT repo?
<maco> usually its recommended to have a separate branch for that
<speakman> oh good point
<maco> https://code.launchpad.net/gally <-- see i have a code branch & packaging branch
<speakman> rebasing it or merge when new changes are available?
<maco> and then i get daily builds from lp by having a recipe that drops the packaging branch inside the code one for during the build
<maco> i'm upstream
<maco> regarding i386 (really i686 in ubuntu) on amd64:  yes, you can make a 32bit pbuilder
<speakman> maco: thanks alot, that was helpful :)
<maco> speakman: have you seen pbuilder-dist?
<speakman> no? where?
<speakman> is CDBS to prefer?
<Tm_T> jibel: Kubuntu PPC runs as expected
<Riddell> Tm_T: great
<jibel> Tm_T, Nice! did you test desktop, alternate or both ?
<Tm_T> only live
<Tm_T> I can try if alternate boots and jazz, if needed
<Tm_T> actually, I'll see if it boots ->
<ScottK> barry: Bug #761131 looks like something up your alley.
<ubottu> Launchpad bug 761131 in winpdb (Ubuntu) "winpdb 1.4.6 fails, needs upgrade to version 1.4.8" [Undecided,New] https://launchpad.net/bugs/761131
<barry> ScottK: let me see if i can whip something up
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Beta-2/Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: zul
<speakman> no orig.tar found when running pdebuild
<speakman> How do I tell pdebuild the package is native and doesn't have any orig.tar.gz ?
<maxb> speakman: um, you should not need to - it should be defined correctly in the .dsc
<speakman> maxb: but how do I create a dsc?
<speakman> thought it was made by "debuild -S" but that failed due to lacking orig.tar (which is odd, since this is a "native" package - there is no "upstream" tar gz really)
<maco> speakman: what version did you put in changelog?
<maco> a native package has no "-"
<speakman> 1.0-1
<maco> yeah, no
<maco> just 1.0
<maco> -1 would imply it has an upstream and that this is a debian package of it
<maco> as opposed to distro-IS-upstream (which is what native is for)
<speakman> oh
<speakman> ok, now there is no -1 anymore. But still missing .orig.tar file when debuild -S
<maco> is this source format 3?
 * speakman has no idea what source format is :D
<maco> do you have a source directory with a file inside it named "format"?
<speakman> but it says "3.0 (quilt)"
<maco> there ya go!
<speakman> :)
<speakman> is that wrong
<speakman> +
<barry> ScottK: https://code.launchpad.net/~barry/ubuntu/natty/winpdb/bug-761131/+merge/57787
<maco> http://wiki.debian.org/Projects/DebSrc3.0
<ubottu> Ubuntu bug 57787 in partman-base (Ubuntu) "Obscure scary warning in installer." [Low,Triaged]
<maco> speakman: ^
<maco> speakman: this is part of the "debian has a new packaging format that results in everybody forgetting at least one step for the first year they use it" thing ;-)
<speakman> maco: should i change to 3.0 (native) ?
<maco> if it is truly a native package
<speakman> what is a truly native package? :D
<maco> what is it you're packaging, anyway?
<speakman> correct
<speakman> It's a  miniproject
<ScottK> barry: I'm out the door, so you'll need to find a different sponsor.
<maco> well like i said, native is just for if the distro is the upstream
<speakman> I'm the maintainer and so on, there is no "upstream" or any tarballs or such
<maco> well you'd be upstream then ;-)
<barry> ScottK: no worries.  ~ubuntu-branches should see it
<maco> is it ubuntu-specific?
<speakman> it ALL worked when changed to "native"
<speakman> not very, it's a simple C program
<speakman> no dependencies or anything
<speakman> pure libc :)
<maco> if it's something thatd make sense to include in other distros, then that sounds like you are the upsteam maintainer of your own project and the packages for it in each distro into which it's included would be regular packages instead of native ones
<speakman> and finally pdebuild worked too :)
<speakman> now wonder where it put its results... hmmm
<maco> ~/pbuilder i think
<speakman> nope
<speakman> this particular project will never be incorperated into any distros :D
<speakman> /var/cache/pbuilder/result/ seems to be where to find the builds :)
<ohsix> hm https://bugs.launchpad.net/ubuntu/+source/evince/+bug/661732 this is still happening on natty; what can be done
<ubottu> Ubuntu bug 661732 in evince (Ubuntu) "evince crashed with SIGSEGV in ev_pixbuf_cache_set_selection_list() if clicked after map, but before resize or initial paint (dup-of: 651931)" [Undecided,New]
<ubottu> Ubuntu bug 651931 in evince (Ubuntu) "evince crashed with SIGSEGV in clear_job_selection()" [Medium,Fix committed]
* slangasek changed the topic of #ubuntu-devel to: Beta-2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: zul
<speakman> 64
<speakman> no, 42. sry
<chrisccoulson> tkamppeter, i figured out what's causing bug 760644 btw
<ubottu> Launchpad bug 760644 in firefox (Ubuntu) "Architecture-independent .DEB packages (_all.deb) not connected to software-center" [Medium,Confirmed] https://launchpad.net/bugs/760644
<chrisccoulson> this code is so fragile in firefox, and nobody wants to touch it with a barge-pole though ;)
<chrisccoulson> the issue is that the link there has an unregistered mimetype, and it falls back to looking up a handler using the file extension, and that is completely broken :(
#ubuntu-devel 2011-04-15
<NCommander> cjwatson: ping, I heard a rumor that you had ideas on improving soyuz's handling of binary packages to help decrease archive skew
<bradm> I'm still seeing bug 727620, causing X to not start reliably on my laptop, anything I can do to help wrt debugging etc?
<ubottu> Launchpad bug 727620 in xserver-xorg-driver-ati "[Radeon HD 5650 and 5470] Driver crash during recovery boot and in normal boot (Regression from 2.6.38-3 to -4)" [High,Confirmed] https://launchpad.net/bugs/727620
<ScottK> bradm: Ask in #ubuntu-x.
<azm> .
<azm> the whole ubuntu ppa thing and lauchpad is blind and complicated
<azm> why it must take so manu clicks till I find clickable .deb package I can download?
<azm> i know i could sound silly..
<ScottK> azm: Just to confuse you further (sorry), PPA support is in #launchpad, not here.
<azm> ScottK, oh sorry
<ScottK> No problem.
<pitti> Good morning
<tjaalton> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta-2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: tjaalton, zul
<didrocks> good morning
<\sh> hey didrocks good morning
<didrocks> hey \sh
<\sh> didrocks: btw..good that I catch you...I just had a small glitch with terminator and grouping all terminal windows (super  + g) , unities launcher catches the super key first...how can an app overrule this when it has the focus?
<didrocks> \sh: yeah, the window manager spec seems to specify that the super key should be reserved to it. So, compiz is grabbing the super key and keeping itâ¦
<didrocks> \sh: we tried to change that behavior in compiz. However, this breaks a lot of things, so will be for oneiric
<\sh> didrocks: ok, so the only workaround for now is to change the super key shortcuts to something different locally ...
<\sh> looks like that is something for the release notes ;)
<didrocks> \sh: unfortunately yes :/
<dholbach> good morning
<tkamppeter> chrisccoulson, any chance to fix bug 760644? Should I perhaps change the mime type on the server?
<ubottu> Launchpad bug 760644 in firefox (Ubuntu) "Architecture-independent .DEB packages (_all.deb) not connected to software-center" [Medium,Confirmed] https://launchpad.net/bugs/760644
<chrisccoulson> tkamppeter, it's not going to be fixed for release i'm afraid. even though i know where the problem is, and it's probably going to be a small fix - this code is so fragile and lacking in test cases that it's too risky to make even the smallest change at this stage :(
<Tm_T> jibel: Riddell: Alternative seems to run just fine aswell
<mdz> cjwatson, pitti, do you have anything to add to the TB thread regarding unity? it's in an indeterminate state
<cjwatson> NCommander: http://ftp-master.debian.org/wiki/projects/arch-all-tracking/
<cjwatson> NCommander: (no reason to do it any differently)
<dbarth> mdz: ping? hi Matt, do you still observe the memleak problem like yesterday?
<chrisccoulson> tkamppeter, i've left a comment on bug 760644, which explains how you might be able to work around it server-side for now :)
<ubottu> Launchpad bug 760644 in firefox (Ubuntu) "Default handler lookup by extension fails" [Medium,Confirmed] https://launchpad.net/bugs/760644
<mdz> dbarth, I installed smspillaz' valgrindable version and was running it under valgrind for part of the day
<mdz> I have not been able to reproduce the leak yet though
<dbarth> mdz: thanks for the info; let us know if it comes back
<pitti> mdz: from my POV it works well enough to keep it as the default; TBH, the inconsistent scrollbars and the limited systray worry me more than unity itself
<cjwatson> mdz: TBH, I've only just got round to fixing the bits of stray gconf configuration that made it impossible for me to run unity on this system
<pitti> I had to run unity --reset at least three times during natty to get back to the full working state
<cjwatson> mdz: so it's a bit hard to form a coherent opinion, but I've seen worse.  While it doesn't affect me personally, I think I share pitti's opinion that the systray policy is a bit ... absolutist, though
<cjwatson> (configuration> in the past I had found that compiz was unusably slow on this machine, and elected to run metacity, but done so by a variety of fairly large hammers in gconf; those hammers were getting in the way.  I don't think it'll be a typical problem)
<pitti> I have this running on three machines now, my wife's laptop (and she's quite happy with it), my own laptop, and the spare mini 10; but then again that's all intel, so my impression might be biased too much on the positive side
<jibel> Tm_T, thanks for testing, I've updated the result on the tracker.
<Tm_T> glad to be of any help
<cjwatson> my wife is totally "as long as there's an option to make it just the way it was before, I don't care what you do with the new stuff"
<Andy80> hi
<Andy80> can I give my "little 2 cents" about Unity?
<Andy80> I've tested it on a netbook. Well... the idea in general is not bad. In particular the unified menu can make you save lot of vertical space, but trying to find an application or even worse Settings is a pain :\
<Andy80> I also have more concrete ideas about how to design it.... could it be usefull if I would make a (hand-made) draw and put it somewhere? Just to show these concepts...
<cjwatson> Andy80: http://unity.ubuntu.com/getinvolved/ has pointers for where to contribute this kind of feedback
<Andy80> cjwatson: going to read it, thanks :)
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> pitti, it is about bug 744751, this is probably trivial to fix. Where the version number of the driver should appear, the package name appears instead. Can you quickly fix that for Natty?
<ubottu> Launchpad bug 744751 in jockey (Ubuntu) "Jockey displays the package name instead of version on the driver selection dialog" [High,Confirmed] https://launchpad.net/bugs/744751
<tkamppeter> pitti, Youji Saito from Epson is asking for that.
<tkamppeter> mvo, hi
<mvo> hey tkamppeter
<pitti> tkamppeter: I've seen the bug, probably easy to fix, yes; I'll get that done next week
<tkamppeter> mvo, about bug 712377, thanks for the quick fix on software-center, but I (and Epson) would like to have that the LSB-based driver packages get installed without warning, as it is irritating for users who want to just set up a printer or who want to install a commercial software package which is LSB-based.
<ubottu> Launchpad bug 712377 in software-center (Ubuntu Natty) "Opening a known good *.deb with software centre, fails to install as lintian errors cannot be overidden" [High,Fix released] https://launchpad.net/bugs/712377
<mvo> tkamppeter: that should be fixed as well now, isn't it?
<mvo> tkamppeter: I removed the libc check
<tkamppeter> mvo, users would really get irritated if they get a "bad package" warning in such cases. Can you remove "missing-dependency-on-libc" from data/lintian-checks? Or at least not give any warnings if the package either depends on "lsb" or has "lsb" in its release number (considering this an LSB package)?
<mvo> tkamppeter: that should already be removed in current natty
<tkamppeter> mvo, I will try. Now I was only reporting from Olaf Meeuwissen's comment of 7 hours ago.
<tkamppeter> mvo, updating ...
<mvo> thx
 * cdbs ponders over how users would react to the results of lintian checks on the debs they install
<kklimonda> cdbs: they wouldn't know what to do with such results.
<pitti> are they displayed to users?
<cdbs> kklimonda: yeah, and that's why lintian isn't meant for end-users
<cdbs> pitti: I dunno
 * cdbs checks it for himself
<pitti> they should certainly not be
<cdbs> pitti: I wasn't able to replicate, but AFAIK I heard some users of complaining about the error on some AskUbuntu question and that user had the lintian result with him
<cdbs> so maybe the answer is yes, but its hidden in some 'More Details' thing
<tkamppeter> perhaps the lintian-check should be removed from the software-center altogether?
<cjwatson> perhaps the broken packages should be fixed.
<pitti> this is for installing third-party .debs, not ubuntu packages, isn't it?
<cdbs> cjwatson: you can't do anything with proprietary debs such as Skype and *those* drivers
<cdbs> pitti: yeah
<cjwatson> cdbs: I don't see how that means a warning isn't appropriate, given that packages with automatically detectable errors may well cause real problems latere
<pitti> but anyway, there should be a (rather small) subset of lintian errors whicht it shold just reject, and install the rest IMHO
<cjwatson> *latere
<cjwatson> ARGH.  you know what I mean
<seb128> cdbs, you can push those vendors to push whatever they distribute
<seb128> to "fix"
<pitti> TGIF!
<cdbs> Is today the world typo day?
<seb128> it has been a busy week ;-)
<cdbs> seb128: If the entire community couldn't get nVidia to release hardware specs, then how can I, as a tiny developer, get Skype to fix their debs? :)
<tkamppeter> mvo, I have updated and tested now, the warning still appears, the user is still irritaded by the "Bad Quality" and on "More Details" one sees that it is because of the "missing-dependency-on-libc".
<tkamppeter> mvo, or do I have to kill or restart something after the update?
<seb128> cdbs, different topic, those who care enough to ship a deb probably want it to work fine for the users who getit
<cdbs> hmm
<kklimonda> pitti: do you have a list of checks that should make a package fail?
<kklimonda> (fail to install)
<pitti> no, I don't
<cdbs> fsstnd-dir-in-* is a bad lintian E: tag
<pitti> I'm not very convinced of this approach to begin with, TBH
<cjwatson> lintian has an ftpmaster mode which is used by Debian to autoreject packages
<pitti> it's not any worse than using upstream shell scripts for installing
<pitti> and if they are missing a changelog or copyright file, who cares
<pitti> the real messy bits are weird postinst scripts, and catching them with lintian is hard
<seb128> I don't think it's meant to display errors on any lintian warnings
<cjwatson> changelog or copyright> well don't make those tags fatal then :-)
<seb128> but it can at least catch some stupidities
<cjwatson> or even warned-on
<pitti> cjwatson: they are certainly fatal for Debian ftpmaster mode?
<cjwatson> I wasn't suggesting we use the same set
<azm> hi, how can I get this error fixed: configure: error: glib-2.0 not found or version too old (must be >= 2.8)
<cjwatson> but if you're going to perform checks on packages, there is no reason to reinvent all the infrastructure in lintian for performing checks on packages
<azm> p0lease
<cjwatson> azm: Build-Depends: libglib2.0-dev (>= 2.8)
<kklimonda> cjwatson: sure, I'm just wondering how many lintian checks can be treated like "unrecoverable" errors.
<cdbs> I think it must be better to warn the user, in general, about third-party debs before installation, apart from lintian checks (which can be done after this message)
<mvo> tkamppeter: let me check, the check should be disabled, but maybe something went wrong
<azm> cjwatson, does that mean higher then 2.8
<azm> ?
<cjwatson> cdbs: that's a bit pointless IMO, they already know it's third-party because they asked for it - a general nag about that won't help
<cjwatson> azm: yes, please see the policy manual for more details
<azm> cjwatson, but in repos there is only 2.26
<cjwatson> azm: 2.26 is higher than 2.8
<azm> oh
<cjwatson> it's not a simple character-by-character comparison
<mvo> we use a modified version (relaxed) of the ftpmaster mode, I think its useful e.g. to warn about uid != 0 in debs or other crazy stuff
<azm> well that is confusing
<cjwatson> azm: it models real version numbers
<tkamppeter> mvo, I have software-center 3.1.26.3.
<azm> cjwatson, ok, thanks for help
<tkamppeter> mvo, and aptdaemon  0.41+bzr641-0ubuntu1
<mvo> tkamppeter: hm, that sounds right. what was the bugnumber again?
<tkamppeter> mvo, bug 712377
<ubottu> Launchpad bug 712377 in software-center (Ubuntu Natty) "Opening a known good *.deb with software centre, fails to install as lintian errors cannot be overidden" [High,Fix released] https://launchpad.net/bugs/712377
<mvo> tkamppeter: thanks, downloading now
<mvo> tkamppeter: thanks, I can reproduce it, working on it now
<tkamppeter> mvo, I have now installed s-c 3.1.26.4 from Launchpad and this does not help, too.
<mvo> tkamppeter: uploaded a fix now, thanks !
<exarkun> pitti: I would like to see https://bugs.launchpad.net/apport/+bug/755025 fixed sooner rather than later.  How can I help?
<ubottu> Ubuntu bug 755025 in Apport "apport generates bug reports against the twisted project instead of a more relevant project" [Undecided,New]
<tkamppeter> mvo, fix is in s-c 3.1.26.5? Did not appear yet on Launchpad.
<mvo> tkamppeter: aptdaemon is uploaded but in the queue
<tkamppeter> mvo, I have found this one on Launchpad now, downloading ...
<tkamppeter> mvo, which version number?
<mvo> tkamppeter: 0.41+bzr645-0ubuntu1
<tkamppeter> mvo, this did not arrive in LP yet ...
<GunnarHj> seb128, kirkland, pitti: FYI: After some talk with Dustin and Martin about bug 678421 I summarized my gained insight in a couple of bug comments. Thought that some of you may want to give the issue a second thought when things have slowed down a bit after the release.
<ubottu> Launchpad bug 678421 in gdm (Ubuntu) "Error in ~/.profile halts the X startup" [Low,In progress] https://launchpad.net/bugs/678421
<seb128> GunnarHj, hi, thanks for your work on that
<seb128> we will
<GunnarHj> seb128: Hello, great, looking forward to see where it lands.
<tkamppeter> mvo, are sure that you have uploaded the new aptdaemon? It still did not make it into LP. Can you perhaps attach a patch to the bug report?
<mvo> tkamppeter: its currently in the frozen queue, all uploads need manual approval
<seb128> tkamppeter, https://edge.launchpad.net/ubuntu/natty/+queue?queue_state=1&queue_text=
<seb128> http://launchpadlibrarian.net/69487314/aptdaemon_0.41%2Bbzr645-0ubuntu1_source.changes
<tkamppeter> mvo, thanks, found the change in the BZR
<mvo> tkamppeter: you can run bzr-buildpackage from the ubuntu-natty branch
<mvo> tkamppeter: that will give you a updated deb in ../build-deb
<tkamppeter> mvo, I have maually applied your fix in /usr/share/aptdaemon/lintian-nonfatal.tags now and it works. Thank you very much.
<tkamppeter> Who is the developer of computer-janitor, c-j considers all the third-party printer driver packages as to be deleted.
<tkamppeter> barry, hi
<barry> tkamppeter: hi
<tkamppeter> barrym are you the maintainer of computer-janitor? It has a severe problem.
<tkamppeter> barry ^^
<barry> tkamppeter: one of them.  what's the problem?  have you submitted a bug report?
<tkamppeter> barry, bug 761728
<ubottu> Launchpad bug 761728 in computer-janitor (Ubuntu) "Computer Janitor wants to delete third-party packages" [High,New] https://launchpad.net/bugs/761728
<tkamppeter> barry, it uninstalls manufacturer-supplied hardware drivers and other software manually installed by the user, and to assure that it buries these packages in an unsorted list. Can you fix this for Natty.
<tkamppeter> barry, bug 704385 and bug 458872 are other examples of the same problem.
<ubottu> Launchpad bug 704385 in computer-janitor (Ubuntu) "ran computer janitor lost turboprint (dup-of: 458872)" [Undecided,New] https://launchpad.net/bugs/704385
<ubottu> Launchpad bug 458872 in computer-janitor (Ubuntu) "Don't mark for removal manually installed packages" [Medium,Triaged] https://launchpad.net/bugs/458872
<ubottu> Launchpad bug 458872 in computer-janitor (Ubuntu) "Don't mark for removal manually installed packages" [Medium,Triaged] https://launchpad.net/bugs/458872
<tkamppeter> barry, this is a severe problem and Natty should not get released with it.
<barry> tkamppeter: i'll try to reproduce in a vm, but this will very likely not be a computer janitor issue per se, but an update manager or dpkg issue.  c-j is just a front-end on things.
<barry> tkamppeter: one thing you can try:
<barry> does 'sudo apt-get autoremove' also try to delete those packages?
<tjaalton> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta-2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: zul
<tkamppeter> barry, no, 'sudo apt-get autoremove' wants to remove only 12 packages, c-j, around 100.
<barry> tkamppeter: interesting.  okay, thanks for pinging me about it.  i will look into it
<tkamppeter> barry, try the instructions to reproduce in my bug report.
<barry> tkamppeter: bug 458872 may be the core issue
<ubottu> Launchpad bug 458872 in computer-janitor (Ubuntu) "Don't mark for removal manually installed packages" [High,Triaged] https://launchpad.net/bugs/458872
<tkamppeter> barry, not that people are complaining that they are loosing paid software by that.
<barry> yep
<tkamppeter> barry, so I would consider it release-critical.
<abhinav-> dholbach: Hi, is it so that a merge proposal wont be noticed by the sponsors unless the bug has been triaged ?
<dholbach> abhinav-, every merge proposal for lp:ubuntu/... will be noticed
<abhinav-> dholbach: oh , I guess then perhaps it is because of the feature freeze
<dholbach> abhinav-, which one is it?
<abhinav-> dholbach: https://bugs.launchpad.net/ubuntu/+source/tomboy/+bug/757635
<ubottu> Ubuntu bug 757635 in tomboy (Ubuntu) "Hitting delete key while focus in search box triggers deletion of note" [Undecided,In progress]
<abhinav-> dholbach: ^
<dholbach> seb128, ^ do you have an idea who would be qualified to make a decision about that one?
<seb128> dholbach, what sort of decision? is that upstream as well?
<dholbach> seb128, forwarded, yes
<dholbach> abhinav-, we had patch pilots in the last days who could have noticed this one, but I guess everybody was fixing their own bugs for beta2
<dholbach> seb128, if/how it can be included
<seb128> can you join on #ubuntu-desktop
<seb128> ?
<seb128> I will ask rodrigo to check on it
<abhinav-> dholbach: yes, I noticed, its been a busy week :)
<abhinav-> seb128: yes sure
<dholbach> thanks seb128, abhinav-
<hallyn> skaet: hi, I'm wondering whether you might want to consider forcing bug 760464 into natty release.  it's just a nag - a once-per-boot printk.  But if we're goign to be getting a lot of automated apport bug reports from syslog-ng users, it seems worth it
<ubottu> Launchpad bug 760464 in syslog-ng (Ubuntu) ""WARNING: at /build/buildd/linux-2.6.38/kernel/printk.c:288 do_syslog+0xa4/0x4c0()" shown after syslog-ng installation" [Low,Triaged] https://launchpad.net/bugs/760464
<skaet> hallyn,  thanks for flagging,  yeah it could become annoying.
<ScottK> hallyn: A lot of it depends on how invasive the change is (I didn't look at the bug), so if you think it should get in, I'd get it uploaded and someone from the release team will review it.
<hallyn> ScottK: change is very minimal
 * skaet agrees with ScottK
<ScottK> Then I'd get it uploaded.
<skaet> hallyn, if its a minimal change,  yes please submit a fix.
<hallyn> by 'get it uploaded' you mean just ask someone to dput the package to the archive?
 * skaet is waiting for ScottK to answer since hallyn's question was addressed to his remark  ;)
<smoser> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta-2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: smoser, zul
<smoser> zul, i dont think you're supposed to still be pilot. might want to pilot out if that is the case
<zul> uh...
<zul> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta-2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: smoser
<zul> thanks
<cjwatson> apw: text-free boot seems to have stopped working for me - I have 'set gfxpayload=keep' and vt.handoff=7, but I'm getting a black screen (without text) between GRUB and Plymouth.  Is this just me, or does it need investigation?
 * dholbach hugs zul and smoser
<seb128> slangasek, is there any reason bug #758804 should not go in natty?
<ubottu> Launchpad bug 758804 in bluez (Ubuntu Oneiric) "Add support for ST-Ericsson CG2900 Bluetooth chip" [Medium,Triaged] https://launchpad.net/bugs/758804
<seb128> slangasek, the diff seems pretty safe if someone tested the hardware works once added to the list
<hallyn> SpamapS: do you have your coredev privs yet?
<seb128> james_w, sorry to ask again but was is the issue that leads to spam the sponsoring queue with those merge requests on the autoimports vcs?
<seb128> james_w, or rather what do people do wrong?
<cjwatson> bdmurray: did you get anywhere with reproducing bug 709363?
<ubottu> Launchpad bug 709363 in ubiquity (Ubuntu Natty) "swap partition disappeared during installation" [High,Incomplete] https://launchpad.net/bugs/709363
<cjwatson> Daviey: I still have no idea how to reproduce bug 728088 - perhaps the server team could fix this one, if they can reproduce it during ISO testing?
<ubottu> Launchpad bug 728088 in debian-installer (Ubuntu Natty) "iscsi root with or without auth fails to boot" [High,Confirmed] https://launchpad.net/bugs/728088
<cjwatson> (I doubt it's in debian-installer, since the logs suggest networking being torn down during boot)
<Daviey> cjwatson, Yeah... Something which is blurring me, is a syslog of an install where a certain network interface lost networking mid install.. So i'm not certain it's not something during d-i, but i agree it's likely not.
<cjwatson> Daviey: certainly not impossible, but that's not what's being reported in that bug
<cjwatson> (can't be d-i, d-i doesn't start apparmor etc.)
<cjwatson> Daviey: unless you're referring to the thing I mentioned in comment 5 - but I think a link there is probably tenuous
<cjwatson> Daviey: can anyone on your team consistently reproduce this?
<Daviey> cjwatson, Oh yes - the reason i'm comparing as i wondered if it was the same bug
<Daviey> cjwatson, I did reproduce it a while ago, but not on b2.  I will do this.
 * cjwatson nods, thanks
<hallyn> Daviey: would you mind taking a look at, and consider sponsoring, http://people.canonical.com/~serge/syslog-ng_3.1.3-3ubuntu1-package.tgz
<smoser> mvo, you have a minute to look at bug 761689
<ubottu> Launchpad bug 761689 in sudo (Ubuntu) "sudo overwrites sudoers after dist-upgrade" [Critical,Confirmed] https://launchpad.net/bugs/761689
<smoser> i can set you up a system to look at prior to upgrade if you'd like
<Daviey> hallyn, on it.
<hallyn> Daviey: thanks
<tgardner> SpamapS, can you stroke the natty unapproved upload queue and enable linux-ti-omap4 for building?
<mvo> smoser: sure
<mvo> smoser: do you have a /var/log/apt/term.log from this?
<smoser> mvo, you should be able to get to ubuntu@ec2-174-129-62-113.compute-1.amazonaws.com
<smoser> using launchpad keys
<Daviey> hallyn, http://pb.daviey.com/iT7u/raw/ the patch is clean, but i'd like to know what the impact is - and how many people have reproduced it.  This will be a new delta.
<hallyn> Daviey: so far I know of two bug reports
<hallyn> Daviey: if they install the package on a maverick system, it'll fail bc that capability won't exist
<hallyn> now, i suppose we could alternatively patch our kernel to remove the capability warning.  but then we'll just end up getting bit later on by any other syslog alternatives which haven't been converted
<Daviey> hallyn, what, what - did you mean s/maverick/natty ?
<hallyn> no i meant maverick
<hallyn> on natty no problems
<kirkland> bryceh_: can you do your dictionary magic to tell ubuntu that oneiric is really a real word?  :-)
<Daviey> hallyn, Why would they be installing a natty package on maverick, more so - why do we care?
<hallyn> Daviey: i'm just letting you know :)
<Daviey> hallyn, Hmm.. I think i'm getting confused what the bug is, and what the impact is.
<hallyn> Daviey: the capability which i'm adding is a new one which was carved out of cap_sys_admin, if that helps
<bdmurray> cjwatson: Oh, no I actually haven't tried.
<yofel> cjwatson: btw, thanks for the grub color fix :)
<mvo> smoser: ok, this will need sudo to look at apt.log (tight permissions)
<hallyn> Daviey: the syslog priv was split out of cap_sys_admin.  THe kernel warns once when someone tries to use syslog without having cap_syslog, so as to warn syslog userspace software authors to update
<hallyn> Daviey: so the impact is just that we're going to get a lot of apport bug reports from the printk
<smoser> mvo, its not been upgraded yet
<smoser> so you can sudo passwordless
<mvo> awsome
<cjwatson> yofel: no problem, let me know if derivatives need help using it
<smoser> so put a back door in if you'd like
<Daviey> hallyn, Ahh! i understand. Can you forward the patch upstream, and i'll flip the patch header?
<hallyn> Daviey: yeah - they'll need to do something more baroque upstream,
<hallyn> Daviey: since they will have to support older systems
<hallyn> (joining the m-l now)
<smoser> mvo, not going to work. "Installing verbatim /etc/sudoers"
<smoser> ubuntu user does not have a password
<mvo> smoser: thanks, yeah, that message is the problem
<smoser> you want a fresh instance ?
<smoser> it'll take 2 minutes
<mvo> smoser: please
<ohsix> cjwatson: can you reproduce this with the given steps? it's still going on in natty https://bugs.launchpad.net/ubuntu/+source/evince/+bug/661732
<ubottu> Ubuntu bug 661732 in evince (Ubuntu) "evince crashed with SIGSEGV in ev_pixbuf_cache_set_selection_list() if clicked after map, but before resize or initial paint (dup-of: 651931)" [Undecided,New]
<ubottu> Ubuntu bug 651931 in evince (Ubuntu) "evince crashed with SIGSEGV in clear_job_selection()" [Medium,Fix committed]
<mvo> smoser: I think I know whats going on fix should be simple, let me double check just to be sure (and sorry for the trouble this caused)
<smoser> mvo, no problem. i actually dont know why we didn't see it before.
<cjwatson> ohsix: um, are you sure that's the right bug number?
<smoser> i've certainly launched instances and dist-upgraded... or maybe i have only done so with forcing dpkg to use old confs
<smoser> (dont' know if your changes would respect that)
<ohsix> cjwatson: yea that's the one i reported; it was marked dup to something else, and if you follow it to the upstream bug report you'll see its a mess, that one has the steps i can reproduce it with 100%, and the crash location
<smoser> mvo, ubuntu@ec2-204-236-203-39.compute-1.amazonaws.com
<cjwatson> ohsix: so, um, why me?  I have nothing to do with evinc
<cjwatson> e
<james_w> seb128, on a call, but https://wiki.ubuntu.com/DistributedDevelopment/UnderTheHood/Importer#Collisions gives some background
<seb128> james_w, thanks
<ohsix> cjwatson: no reason in particular, i asked about it earlier and nobody spoke up
<cjwatson> ohsix: sorry then, I have too many bugs already without seeking out more
<seb128> james_w, I somewhat doubt those are collisions though
<ohsix> :[ just need independent confirmation
<james_w> seb128, sure, they are likely bugs
<seb128> james_w, it happened on random uploads which are not things maintained in the vcs, i.e it's likely nobody pushed anything, some seem just normal dput uploads
<hallyn> Daviey: heading out for some breakfast with the kids.  let me know if you have any other questions.
<mvo> smoser: thanks, uploading a fix in a sec
<smoser> mvo, i'll move to using sudoers.d in oneiric.
<NCommander> cjwatson: thanks
<mvo> smoser: no worries, I was a bit too careful in my initial fix for this
<Daviey> hallyn_afk, ok, great o/
<pitti> ev: thanks for the jockey -k patch, I'll integrate it (I'll change some details, but will keep the CLI interface)
<ev> wonderful, thanks!
<jdstrand> Daviey: not sure how you'd want to handle this accounting issue in bug #580319, but dhcp3 is no longer in natty (we have isc-dhcp instead). I have no idea if isc-dhcp is affected, I just saw this in passing
<ubottu> Launchpad bug 580319 in upstart (Ubuntu Natty) "dhcp3-server launches before upstart brings all interface, thus failing to start" [Medium,Triaged] https://launchpad.net/bugs/580319
<Daviey> jdstrand, That is on my hit list.
<Daviey> jdstrand, will follow up after the release meeting
<jdstrand> Daviey: k. just fyi on my end
<NCommander> cjwatson: thanks, I'll make sure this makes it into a spec and the Soyuz guys see it. If we can reduce archive skew, it will make our lives considerably less painful
<Daviey> jdstrand, pah, just read up - nobody has confirmed if we are seeing it with isc-dhcp after me asking.
<brendand> is it meant to be the case that cpuinfo has no core id and physical id fields if there is only 1 cpu?
<brendand> despite that /sys/devices/system/cpu/cpu0/topology/core_id and physical_package_id exist
<SpamapS> hallyn_afk: yes I do, did you need something sponsored?
<SpamapS> tgardner: I am not an archive admin yet, so no. :-P
<slangasek> seb128: if you want to take it for natty, I don't object, I just didn't think it warranted a freeze exception
<seb128> slangasek, well "freeze exception", things are reviewed from the queue and the diff seems trivial enough to not be a lot of work
<Abhinav_> Is this the right place to discuss about natty beta2?
<seb128> slangasek, the merge request is against the wrong vcs though, lp:~ubuntu-desktop/bluez/ubuntu is the correct one
<ScottK> Abhinav_: If you need help with it, #ubuntu+1 is the right channel.
<slangasek> seb128: heh - right, sorry.
<Abhinav_> ScottK, thanx :)
<seb128> slangasek, do you want me to upload it or do you do it?
<ScottK> seb128: If you upload it, he can review it.
<slangasek> seb128: you are welcome to upload it - I wasn't going to upload it myself because I think it's too low-priority for me to take up the release team's time with reviewing, but yeah, if you upload it I can review it :)
<seb128> ok, doing that
<seb128> well it's like a 30 seconds review and it enable extra hardware to work
<seb128> so seems worth getting in
<slangasek> hardware that can only be used with a Linaro kernel, not with any of the official Ubuntu images :)
<ScottK> pitti: We're starting the first python transition in Debian today and I am told python-distutils-extras needs an upload.  Do you mind an NMU or would you prefer to handle it?
<seb128> slangasek, oh ok, I didn't get that part
<seb128> slangasek, so yeah can wait next cycle...
<smoser> cjwatson, does this look fine for removing '/boot/grub' from packaged grub-legacy-ec2? http://paste.ubuntu.com/594539/ . just make the dir on post-inst before calling update-grub-legacy-ec2 (which needs it)
<cjwatson> smoser: just use 'mkdir -p /boot/grub' - no need for a test
<cjwatson> (and that way it also works if e.g. /boot is mysteriously missing or something)
<cjwatson> but yeah, otherwise fine
<smoser> true. i just check because stat faster than fork.
<smoser> but i dont really care.
<jhunt> could someone queue-jump my 'upstart-testing' ppa build possibly?
<jhunt> SpamapS: I believe I've nailed the chroot bug.
<cjwatson> jhunt: done
<jhunt> cjwatson: thx!
<hallyn_afk> SpamapS:  (no thanks, Daviey's on it)
<hallyn> Daviey: could you give me your opinion on bug 726099 ?
<ubottu> Launchpad bug 726099 in libvirt (Ubuntu) "libvirtd assert failure: *** glibc detected *** /usr/sbin/libvirtd: realloc(): invalid next size: 0x00007f289004d5e0 ***" [Medium,In progress] https://launchpad.net/bugs/726099
<hallyn> Daviey: it's going to hit some natty users, but arguably the big boxes won't be upgrading until 12.04, and libvirt will restart anyway, so it may be ok for fix after release
<Daviey> hallyn, Has 9028-change-locking-for-udev.patch  been pushed to upstream?
<SpamapS> jhunt: awesome.. should I install from the ppa then?
<jhunt> SpamapS: go for it!
<SpamapS> I do need to try and build php w/ sbuild.. now would be an excellent time to have chroot support so it doesn't die when it tries to start mysql server. :)
<hallyn> is that what it's called?
<Daviey> hallyn, your new patch
<hallyn> Daviey: huh.  yeah, i sent it upstream
<Daviey> hallyn, Has it been commented / applied?
<hallyn> Daviey: yup, http://libvirt.org/git/?p=libvirt.git;a=commit;h=2879582847303297965e0c441edbe7daca07872c
<Daviey> hallyn, Doesn't seem we have had any feedback from your test packages, *ideally* someone could confirm it resolves the issue.
<hallyn> Daviey: right, i'm wondering whether we can interpret the lack of feedback as a lack of re-occurance of the problem :)
<hallyn> let's try asking again
<hallyn> pinged
<smoser> cjwatson, should bug 655616 be in incomplete ? I'm just trying to avoid other patch-pilots spending time reading it if you've got a handle on it.
<ubottu> Launchpad bug 655616 in mountall (Ubuntu Lucid) "Press S or M does not work for more than one partition on error" [Medium,Triaged] https://launchpad.net/bugs/655616
<Daviey> hallyn, that sounds like a good idea...  it doesn't seem to be Critical importance, but enough to warrant an SRU post release.  Patch being in upstream adds confidence.
<hallyn> Daviey: ok - i'm having trouble figuring out how bad it is to have bugs in the release and fixed right after release, vs. having the fix on the cd
<hallyn> Daviey: i'd assume everyone just updates while installing anyway right?
<hallyn> (since it's an option in the installer)
<Daviey> hallyn, If it has an ack that it resolves the issue, I would suggest uploading it.. but cut off is early next week... after that, it's possibly post release SRU.
<SpamapS> jhunt: alright, rebooting now. :)
<Daviey> hallyn, The release team might disagree with me... but if it affects the majority of use cases, and causes woe - then it's suitable to still be upload.  If it is an issue during installation, first boot, it certainly needs uploading.
<Daviey> hallyn, 4/21 (0900 UTC) is when it becomes a real tough ride to get things in.  In this case, I would say upload it - as soon as you get an ack it's good.  Ideally early part of next week.
<hallyn> Daviey: but it appears to be a rare occurance.  People who report it say it happens every few weeks (every 10 boots or so)
<hallyn> i just worry that 'every 10 boots' out of N natty users will be painful :)
<hallyn> Daviey: ok, thanks, let's see if anyone responds
<Daviey> hallyn, lets revisit it Tuesday and see if things have developed.
<SpamapS> jhunt: test case passed! :-D
<hallyn> Daviey: sounds good
<cjwatson> smoser: um, I guess so.  I'm not working on it at the moment, but my review comments stand
<slangasek> cjwatson: xkeyboard-config name changes make baby Jesus jpf
<smoser> do branches like this one: https://code.launchpad.net/~barry/ubuntu/natty/pyopenssl/bug-758037/+merge/57494
<ubottu> Ubuntu bug 57494 in linux (Ubuntu) "USB removable media undetected (dup-of: 54419)" [Undecided,New]
<ubottu> Ubuntu bug 54419 in linux-source-2.6.15 (Ubuntu) "usb change between 2.6.15-23 and 2.6.15-26 breaks working setup" [High,Won't fix]
<smoser> get automatically merged ?
<smoser> err... get automatically *marked* as merged. given that the fix was uploade dto the archive.
<barry> smoser: it should :/
<barry> often though the branch itself will not get marked as merged though.  i usually have to go through and clean up my branches after the fact
<jcastro> till_: have you sorted your UDS travel yet? I'm just cross checking the list
<Andy80> jcastro: hi :) do you think I will find someone interested helping me to implement this https://blueprints.launchpad.net/authpuppy/+spec/sms-authorization ? Or UDS is related only to Ubuntu development?
<jcastro> UDS is only for ubuntu development
<jcastro> (cool idea though)
<Andy80> ok, thanks :)
<Andy80> yeah... it would be nice to have this feature. With my linux user group, we are creating a free wifi network around the city (using Ubuntu of course ;) ). But... it's off-topic here, sorry :)
<till_> jcastro: come again?
<jcastro> till_: you're coming to uds right?
<till_> what is UDS?
<till_> haha
<till_> and why would i come? :)
<ScottK> jcastro: I suspect you wanted tkamppeter.
<till_> probably :)
<jcastro> oh sorry, wrong till, my bad.
<sladen> pitti: per your analysis that 'humanity-icon-theme' is a bug-fix, I've sponsored it
<tkamppeter> jcastro, id you want to talk with me?
<jcastro> tkamppeter: yeah, are you all set wrt. UDS?
<tkamppeter> jcastro, I dfid not book flights yet, as I never got an offer from this agency.
<tkamppeter> jcastro, still around?
<jcastro> yeah
<nigelb> jdstrand: hi, figured your rss troubles :-)
<nigelb> jdstrand: ..and fixed i :)
<nigelb> *it
<jdstrand> nigelb: oh? what is happening?
<jdstrand> well, I know what is happening
<jdstrand> I don't know how to fix it
<nigelb> jdstrand: the atom feeds were updating timestamp when edited, the rss feeds were fine
<jdstrand> ah!
<nigelb> :)
<jdstrand> nigelb: so did you change my planetubuntu feed to use rss?
<nigelb> yes
<nigelb> just pushed
 * jdstrand hugs nigelb 
<jdstrand> nigelb: thank you!
 * nigelb hugs  jdstrand :)
<nigelb> np :)
<jdstrand> needless to say, I was fairly embarassed when I learned what was happening
<nigelb> heh, this reminds me I need to update the wiki page for planet about it
<jhunt> SpamapS: a delayed thanks :)
<tkamppeter> jcastro, some weeks ago as I got the message that I can come, the agency (I think BTS) got also notified with me CCed and they told they will look for flights for me and I never got an answer. Therefore I did not book. Looks like that I should better book soon.
<jcastro> tkamppeter: yes please, it only gets more expensive the longer we wait. :)
<ScottK> slangasek: Do you know of anyone that might look into Bug #762082?  It just caused an FTBFS on armel of amanda.
<ubottu> Launchpad bug 762082 in dump (Ubuntu) "Fails to install (configure) on armel" [Undecided,New] https://launchpad.net/bugs/762082
<slangasek> ScottK: eep
<slangasek> ScottK: looking
<ScottK> Thanks.
<slangasek> with my armel and also my "touched dpkg last" hats
<ScottK> Excellent.
<ScottK> The amanda build log is remarkably unhelpful.  What's in the bug is from a local install in a natty chroot on a karmic armel box.
<slangasek> dpkg 1.16.0~ubuntu7?
<ScottK> I updated the chroot immediately before I tried it.
<ScottK> Let me check.
<ScottK> Yes.
<ScottK> 1.16.0~ubuntu7
<barry> mvo: any chance you're still around?
<mvo> barry: ye
<barry> mvo: hi.  guess what's reared it's ugly head today?  bug 458872
<ubottu> Launchpad bug 458872 in computer-janitor (Ubuntu) "Don't mark for removal manually installed packages" [High,Triaged] https://launchpad.net/bugs/458872
<barry> mvo: when you get a chance, which doesn't have to be today, i'd love to chat with you about this
 * mvo reads
<mvo> barry: sure, we can talk about this. let me reply in the bug
<barry> mvo: sounds good, thanks
<tkamppeter> jcastro, OK.
<mvo> barry: I agreed with what you said in the bugreport, its not a regression in any way, the long term solution should be to record if it was a install via dpkg or not
<barry> mvo: do you think Regved's approach is sound (even if the implementation needs work)?
<mvo> barry: TBH I don't understand it, or rather I think the result is/will be that all installed packages are considered "dpkg" installs (so its equivalent of just turning the plugin off)
<barry> mvo: ah, gotcha.  i know it's late on a friday for you, but perhaps on monday we can talk about a long term strategy, and i can work on that for oneiric.  what do you think?
<slangasek> ScottK: ah, the segfault comes from the use of --verbose
<slangasek> ScottK: so you can work around this by dropping the --verbose - I don't know why a maintainer script would use that anyway
<ScottK> OK.  Sounds like a bug worth pursuing though.
<slangasek> yep
<ScottK> OK.  I'll do the workaround and leave the pursuing to you.
<mvo> barry: sounds good to me
<mvo> barry: yeah, monday is good, I want to finished some stuff today but its indeed getting late here
<barry> mvo: awesome, thanks.  i'll update the bug and we'll chat on monday.  have a great weekend!
<ScottK> slangasek: Uploaded.  I'd appreciate it if you'd give it the "Meh, Universe." push when it gets in the queue.
<slangasek> ack
<ScottK> Thanks.
<mvo> barry: thanks, you too
<enrylinux> sera
<enrylinux> speak italian
<ScottK> mterry: Is  gedit-developer-plugins a bugfix only update?
<mih1406> Hi, I am a c++ dev and want to participate on any project that interests me but I do not know how?
<enrylinux> kubuntu 11.04 da live non parte
<enrylinux> beta 2
<mterry> ScottK, I don't think so, I believe it may have added a feature or two.  You're saying that universe is under a bugfix freeze now?  /me reminds himself of the calendar
<ScottK> mterry: Yes.  Feature freeze happens for the whole archive at the same time.
<ScottK> You'd just have got away with it if Main wasn't frozen because it wouldn't have needed a manual accept.
<ScottK> mterry: I'm reject it and you can file the FFe.
<slangasek> enrylinux: la lingua di questo canale Ã¨ l'inglese e non Ã¨ canale di supporto; a tentare en #ubuntu-it?
<mterry> ScottK, I see that in https://wiki.ubuntu.com/FeatureFreeze now...  Has it always been that way, or have I just always not read the fine print?  :)
<slangasek> enrylinux: migliore, en #ubuntu-it+1 (http://wiki.ubuntu-it.org/GruppoIrc/Canali)
<mterry> I recall separate Feature freezes
<ScottK> It's always been that way.
<ScottK> For at least a couple of years anyway.
<ScottK> I think prior to Hardy it wasn't.
<ScottK> There used to be a separate, new package freeze.
<mterry> ScottK, well, thanks for the catch.  Sorry to try to slip one by ya  :)
<ScottK> No problem.
<mih1406> Hi, I am a c++ dev and want to participate on any project that interests me but I do not know how?
<slangasek> mih1406: what project interests you?
<mih1406> slacker_nl, where can I find projects that needs a dev to help them
<mih1406> any c++/gtkmm projects is fine
<slangasek> I'm not personally aware of any gtkmm projects worked on by the Ubuntu team
<slangasek> the Kubuntu team does a lot with C++ of course, but not gtkmm
<mih1406> is gtkmm dying? as i read before?
<achiang> hello, is apport expected to work for X server crashes?
<tjaalton> achiang: yes
<achiang> tjaalton: ah, cool, so you're in X, it crashes, you go back to gdm, you log back in, and then you see the apport screen?
<tjaalton> achiang: something like that
<achiang> tjaalton: thank you. (this is ARM, but i expect it should still all work)
<tjaalton> yes, i don't think the platform has any meaning
<achiang> thanks!
<tjaalton> you're seeing crashes and apport doesn't catch them?
<achiang> no, we haven't actually tried yet, but i just wanted to know the expected behavior of apport
<dobey> who do i need to subscribe to merge proposals to get some uploads into 11.04 release?
<dobey> ubuntu-release?
<dobey> smoser: or should i just bug you? :)
<ScottK> dobey: Bug fix or new features?
<dobey> ScottK: bug fixes only
<ScottK> ubuntu-sponsors
<dobey> ScottK: and tarball releases with version bump.
<ScottK> Still ubuntu-sponsors
<dobey> ok
<dobey> done. i hope all my uploads get in
<ScottK> slangasek: If you don't delegate stuff like that how are you ever going to manage to not be TIL dpkg.
<bdmurray> slangasek: what's that enter passphrase bug you commented on today?
<slangasek> ScottK: well hopefully it'll become a sync in oneiric :)
<slangasek> bdmurray: bug #566818
<ubottu> Launchpad bug 566818 in plymouth (Ubuntu Natty) "Cryptsetup passphrase prompt during boot: every character typed repeats the prompt" [Medium,Confirmed] https://launchpad.net/bugs/566818
<slangasek> ScottK: anyway, I'm happy to delegate fixing the compiler bug ;P
<bdmurray> slangasek: bug 728109 looks like a dupe to me
<ubottu> Launchpad bug 728109 in debian-installer (Ubuntu) "unlocking encrypted LVM: console messed up" [Undecided,New] https://launchpad.net/bugs/728109
<slangasek> agreed and dupified, thanks
<slangasek> (dupinated?)
<bdmurray> slangasek: you stole my karma!
<slangasek> heh
<slangasek> mental note: let bdmurray be the one to push the button
<ScottK> He looks kind of scary.  Good idea.
<SpamapS> I'm seeing "Awaiting Approval" on my uploads today, are we frozen?
<slangasek> yes
<slangasek> ^^ /topic :)
<SpamapS> For some reason I thought that wouldn't happen for a week. :p
<slangasek> that had been the thinking earlier on; see latest u-d-a mail from skaet for the current plan
<SpamapS> Alright, so if its not milestoned to ubuntu-11.04 + Critical, its not going in?
<slangasek> SpamapS: for packages in main, the bar is high - but probably not yet so high as 'critical'
<firefly2442> Does Ubuntu have a team that creates and examines metrics associated with the data that is available?
<bryceh> a metrics team?  no
<firefly2442> Specifically, I'm thinking of how developers are communicating, what they are communicating about, bug fix data, and all these inter-relationships?
<bryceh> the developers are communicating about a very wide variety of things
<firefly2442> yes, I know Ubuntu is quite large and there are many developers working on it, I'm interested in trying to datamine this to find out how it can be improved (make sure the right people are communicating, making it easier for new users to join, etc.)
<firefly2442> Is there a mailing list that might be appropriate for a discussion of this?
<firefly2442> ubuntu-devel-discuss perhaps?
<bryceh> yeah maybe
<bryceh> guess it depends a lot on the specifics of what you're interested in
<firefly2442> yeah, it's kind of involved, maybe an email to this mailing list would help
<firefly2442> thank you
<bryceh> sure, good luck
#ubuntu-devel 2011-04-16
<bdmurray> kirkland: could passwd somehow warn about bug 579876?
<ubottu> Launchpad bug 579876 in ecryptfs-utils (Ubuntu) "encrypted home directory isn't mounted if password changed by another user" [High,Won't fix] https://launchpad.net/bugs/579876
<kirkland> bdmurray: would take some pam hackery, should probably talk to slangasek
<kirkland> bdmurray: i could probably make pam_ecryptfs say something
<bdmurray> that seems nicer than hoping people find an answer in Launchpad
<slangasek> does pam_ecryptfs stack before or after pam_{unix,krb5,fwibble} for password changes?
 * kirkland checks
<kirkland> slangasek: that's common-password?
<slangasek> yes
<kirkland> slangasek: ecryptfs is last
<slangasek> hmm, ok
<kirkland> slangasek: if old password is empty, i was thinking i could throw a warning message
<slangasek> and how's it marked?  optional, requisite, etc?
<kirkland> password        optional        pam_ecryptfs.so
<slangasek> yeah, I'm thinking you could downright abort the stack instead, if you wanted :)
<kirkland> slangasek: i deliberately did not, in the beginning
<kirkland> slangasek: more and more people are complaining about this
<slangasek> well, I guess giving no option for root to change the password would get a different set of people complaining
<slangasek> a prompt that has to be explicitly acked might be the best
<slangasek> so pam_ecryptfs will never prompt for a password of its own in the event that the login credentials don't match the ecryptfs creds?
<kirkland> slangasek: correct
<slangasek> should it?
<CardinalFang> Hi all.  I have a package for upload that fixes a bug found in integration testing.  May I have an uploader take a look?
<CardinalFang> https://code.edge.launchpad.net/~cmiller/ubuntu/natty/desktopcouch/1.0.7-0u2/+merge/57972
<CardinalFang> The new ubuntuone-control-panel-gtk exposed a race condition when desktopcouch is used ever for the first time.
 * CardinalFang winks sexily at kees and kenvandine.
<jcastro> kees: can you add ~hughhalf to ~uds-planners?
<CardinalFang> I attached a debdiff to the bug report, in case someone doesn't like source-package branches.  https://bugs.edge.launchpad.net/ubuntu/+source/desktopcouch/+bug/760236
<ubottu> Ubuntu bug 760236 in desktopcouch (Ubuntu) "desktopcouch answers DBus before plugins are completed" [High,In progress]
<CardinalFang> smoser, hi.  I see you're named patch pilot.  ^~1h ago, can this make it today?
 * CardinalFang steps AFK to retrieve food.
<kenvandine> CardinalFang, i'll look
<dtigue> hey i updated to beta 2 today and now my top status bar has turned a light grey color and will not change back to the nice dark color it used to be
<kenvandine> CardinalFang, sponsored
<soreau> Hey guys, ubuntu upgrades installs new kernels but it never removes older kernels, leaving a mess of grub list after awhile. Is there some way (a one-liner?) to remove all but the currently running kernel (and related packages for those kernel versions)
<soreau> Sorry, did I miss a response?
<dtigue> i know you can remove the kernals not needed in synaptic
<dtigue> kernels
<soreau> Yes but that gets old after awhile
<soreau> In specific, I'm looking for a one-liner that automatically removes all but the currently running kernel
<soreau> Or even a gui way to automatically do it
<soreau> I'm thinking maybe there's some clever way to do it with aptitude or apt-get
<dtigue> im sure there is but i dont know it
<dtigue> sorry
<ion> Remove linux packages from aptitudeâs âdonât autoremoveâ patterns.
<soreau> ion: How can you do that?
<ion> Aptitude settings
<CardinalFang> kenvandine, thank you, sir!
<soreau> ion: How to get to aptitude settings
<Sarvatt> soreau: /etc/apt/apt.conf.d/01autoremove
<soreau> Ah ok
<kenvandine> CardinalFang, np
<soreau> Sarvatt: ion: I removed linux-image line from /etc/apt/apt.conf.d/01autoremove and ran apt-get update but apt-get autoremove still doesn't show anything to remove
<soreau> Is there a special command needed to make it recognize the change?
<Sarvatt> it'll just affect future upgrades
<dtigue> so has anyone else seen the top panel go to a light grey color after updating to beta 2??
<soreau> Sarvatt: Well that's not exactly what I needed :P
<CardinalFang> soreau, do you have "linux-image-generic" installed?
<CardinalFang> soreau, if so, this should do it:  $ dpkg -l linux-image-[0-9]\* |egrep ^ii |while read status pkg cdr; do sudo dpkg -P $pkg; done
<CardinalFang> The most recent, a dependency of a metapackage, will fail to be uninstalled.
<soreau> CardinalFang: Well that worked to remove the linux-image packages, but not linux-headers. I tried the same command with linux-headers-[0-9]\* but it didn't work
<soreau> or hmm.. maybe it did
<soreau> What does 'pi' mean in dpkg -l output?
<soreau> the output from the command said it wasn't removing any header packages due to dependency problems
<soreau> dpkg: dependency problems prevent removal of linux-headers-2.6.35-23: \n linux-headers-2.6.35-23-generic depends on linux-headers-2.6.35-23.
<soreau> all say the same
<ion> You don't want to use dpkg like that. Use aptitude instead. It'll handle dependencies.
<soreau> ion: How though?
<soreau> dpkg man page doesn't even tell what 'rc' 'ii' 'pi' etc mean
<CardinalFang> soreau, it's in the header of the output.
<soreau> CardinalFang: That's not too intuitive because 1) most times you're grepping dpkg -l and 2) the terminal default is only 200 lines scrollback
<soreau> and 3) it doesn't explicitly explain what the letters mean
<CardinalFang> soreau, I'm just telling you where you can find what "pi" means.  Purge wanted.  Now Installed.
<soreau> Ah ok
<soreau> So the package manager took note the packages were attempted to be removed
<soreau> So how can I remove header and header-generic packages too
<soreau> Ah hm
<soreau> This seems to be working 'dpkg -l linux-image-[0-9]\* |egrep ^ii |while read status pkg cdr; do sudo dpkg -P $pkg; done && dpkg -l linux-headers-[0-9]\* |egrep ^ii |while read status pkg cdr; do sudo aptitude purge -y $pkg; done'
<soreau> Hmm, seems to remove headers for currently running kernel too
<soreau> Well hm
<soreau> If there is a 'pi' package, how to make it go back to 'ii'?
<soreau> Seems a simple reinstall does the trick
<SMG1> hello, can anyone help me, "My Computer" does not open when clicked and no drives show up on the left pane of windows, but they show up in gparted and disk utility.
<SMG1> hello, anyone
<holstein> SMG1: is that a support question?
<SMG1> yes
<holstein> 11.04?
<holstein> you can try #ubuntu like the topic suggests
<holstein> or #ubuntu+1 for 11.04
<holstein> or #ubuntu-beginners if those are too busy or too slow
<jbicha> quit
<ohsix> smoser: where can i get someone to advocate something upstream? an important feature has been removed from a package and they will not budge on adding it back, ubuntu could easily patch it back in with a few hundred line patch; but as i understand it that is usually not done
<ohsix> smoser: no technical justification or anything has been made for its removal (btw, it's proxy support for transmission)
<ohsix> smoser: or can transmission be pinned back to 2.11
<ohsix> man i miss not knowing anything about this crap, was much easier just to throw my hands up; now i know where to contact the people and how to read the code, just pisses me off more often than not :[
<kees> jcastro: added!
<ohsix> https://bugs.launchpad.net/ubuntu/+source/evince/+bug/651931 does this need an SRU to get into natty?
<ubottu> Ubuntu bug 651931 in evince (Ubuntu) "evince crashed with SIGSEGV in clear_job_selection()" [Medium,Fix committed]
<ohsix> https://bugs.launchpad.net/bugs/629258 would be nice if this was a papercut again :\ i've got 4 machines that never show more than "estimating ..."
<ubottu> Ubuntu bug 629258 in DeviceKit-Power "Battery life estimation never comes around" [Medium,In progress]
<bradm> ohsix: my laptop has had that estimating battery bug for a while :-/
<ohsix> its pretty clear cut if you drill down in the bug
<ohsix> chech the output of upower --dump for energy-rate, aiui hal would estimate it if the battery didn't report it, so when hal went away so did the number
<bradm> would make sense to remove the "estimating" if it can't do it anymore, I guess
<ohsix> well if the estimao\tor was back in there for batteries without rate readings then the battery historty would be stored/calculated as normal
<ohsix> and i think i saw it mentioned that there used to be an interpolator in upower too but it was never used
<ohsix> the battery applet doing statistics should work without the data present tho, so it doesn't compound the error
<bdrung> doko_: i finally fixed lintian (now tested on i386 too)
<Tapis> hi
<Tapis> Is there an "easy way" to change the Kernel of an existing .iso in order to make the installation via ubuntu-installer with a newer Linux Kernel ?
<sladen> Tapis: https://help.ubuntu.com/community/LiveCDCustomization  FSVO "easy"
<sladen> Tapis: basically unpack the CD, replace the kernel packages, re-pack
<sladen> Tapis: (the kernel for the LiveCD is stored outside of the Squashfs IIRC
<Tapis> i don't want to change any other packages, or "customize" the .iso, i want to make the ubuntu-installer use another Kernel during the installation, for a spÃ©cific hardware ( i've already got the my-new-kernel.deb )
<Tapis> so, i do this way, i can install my-new-kernel.deb and repack the .iso, and everything sould be fine ?
<Tapis> ( thanks for your help sladen, can you just "confirm" what i've just say )
<dobey> Tapis: it sounds like you'd need to rebuild the squashfs for the Live system; and sladen was telling you how to change the package that would be installed during install (but not booted on the image)
<Tapis> dobey: ok, so sladen' proposition is not compatible with what i want to do, i want my .iso boot with my custom kernel in order to make ubuntu-installer use this custom Kernel
<Tapis> dobey: is there any documentation about this ? i found some in the debian wiki, about rebuild debian-installer, make the .iso image, but it's not very documented and complete
<sladen> Tapis: https://help.ubuntu.com/community/LiveCDCustomization
<sladen> Tapis: mount -o loop image.iso .../somewhere
<sladen> Tapis: cd .../somewhere && do_stuff_like_replace_the_kernel
<Tapis> yes, i already understand that, but dobey said that it's for INSTALL a custom kernel with ubuntu-installer, not BOOT on this custom kernel FOR the installation ( what i want to do )
<dobey> well i mean only copying the .deb will only let you install it, not boot the cd from it. there's a lot more to do for that. read the wiki page
<dobey> rebuilding the live image isn't as easy as copying the .deb over, modifying the manifest, and repacking the .iso
<dobey> but it's doable, and i'm sure the wiki pages will point you in the right direction
<Tapis> ok ok... i've already find some documentation on debian wiki, i know it's doable to build from scratch a custom .iso, but i wanted to know if a "easy way" was possible from an EXISTING .iso
<sladen> Tapis: ------>  https://help.ubuntu.com/community/LiveCDCustomization  <-----
<Tapis> anyway, thanks dobey and sladen for the help, i'm going to RTFM and try to do this
<sladen> Tapis: if you're wanting to change the boot kernel, but not the installed kernel, it's  in /install/vmlinuz  on the CD
<Tapis> sladen: ok, i've already find this, well...if this way works, it's perfect ! :)
<sladen> Tapis: if you're wanting to change the installed kernel, then it's a couple of steps easier to do on the alternate CD and is in  pool/main/l/linux/linux-image*.deb
<Tapis> sladen: no, i don't care about the installed kernel, i can do this later, i just want to replace the "booted kernel"
<sladen> Tapis: if you're wanting to change the installed kernel on the main/LiveCD, then it's slightly harder because you need to unpack, mount, chroot, dpkg -i the .deb, resquashfs, rebuild the .iso
<Tapis> ok
<Tapis> thanks again sladen and dobey
<Tapis> bye everyone
<ScottK> mdz: There are four josm uploads in the queue are they all the same?
<ScottK> mdz: Unping.  Accepted.
<hyperair> jcastro: ping. do you know who i can direct my complaints about paste.ubuntu.com to?
<hyperair> s/complaints/bug reports/
<LLStarks> is there any chance the apt-sync/delta-deb proposal will actually be mentioned at uds-o?
<ScottK> Yes
<soreau> Hey guys, I am confused by driconf GUI. There used to be a lot of options but now there is almost none, even in expert mode. Is there some additional package that needs to be installed?
<mdz> ScottK, yes, sorry for the noise
<mdz> ScottK, the first three seemed to be rejected with "550 Changes file must be signed with a valid GPG signature: Verification failed 3 times" but apparently they went through?
<ScottK> mdz: Yes.  It's an LP bug that they are aware of.
<ScottK> lifeless: ^^^
<ScottK> Apparently Soyuze and the Ubuntu keyserver aren't always on speaking terms.
<mdz> ScottK, thanks for accepting the fix
<infinity> Shocking.
<ScottK> No problem.
<infinity> (Both the bug, and spelling Soyuz with an 'e'...)
<ScottK> I know how to spell it, just not how to type.
<infinity> ScottK: I probably should get a t-shirt made up with that on it.
<ScottK> ;-)
 * infinity is annoyed that when he does a quick LP bugs search for "ftbfs", the first two that pop are the qemu firmware arch:all affinity bugs from, like, 3 decades ago.
<infinity> Maybe I should just fix soyuz instead of looking for packages to fix.
<slangasek> infinity: want to teach soyuz to have a policy for multiarch build-dependencies? :)
<infinity> slangasek: Oh?
<infinity> slangasek: Elaborate?
<slangasek> infinity: well, if someone could fix it so those qemu firmware packages no longer had to be arch: all, that would solve the problem
<infinity> slangasek: Err, but multiarch only helps you there if you can actually emulate the arch on another.
<slangasek> although that may not be multiarch build-dependencies in this case, but simply cross-arch dependencies, for which I suppose the policy might not need to live in soyuz
<infinity> slangasek: Can i386 actually build ppc and sparc binaries in the current state of the world?
<slangasek> infinity: not at all - I was suggesting that you make openbios-sparc an Architecture: sparc package, and have qemu depend/recommend/whatever openbios-sparc:sparc
<infinity> slangasek: And yeah, none of that would actually need soyuz support, per se.  launchpad-buildd/sbuild support, but that's much less hassle.
<slangasek> (something to be coordinated with Debian, to be sure)
<slangasek> oh, but we don't have sparc in the archive anymore, so I guess that wouldn't work, hmm
<infinity> slangasek: Oh.  THAT solution is entirely packaging toolchain.  Done.
<infinity> slangasek: (Except for that)
<slangasek> we do have an armel cross-toolchain in the archive these days; could do the same for powerpc and sparc I guess
<slangasek> except that I was hoping we'd soon be able to convert that toolchain over to use multiarch instead of rebuilding libs :)
<infinity> Oh, yeah, sparc's completely gone now.  That bug should just be closed then.
<infinity> Given that we insist on building from source at SOME point in the process, we really can't maintain a sparc binary...
<slangasek> might still be the preferred solution for powerpc though
<infinity> For PPC, the multi-arch thing sounds clever, but how does that work at the apt level?  I haven't looked.
<infinity> Does it just do magic to find other arches, or do you need to specify them in sources.list?
<slangasek> well, that's part of the question - what would we want a buildd to allow a package to pull in from other architectures as part of a build?
<infinity> And if the former, does Ubuntu's apt have extra magic on top of the magic to deal with archive/ports?
<slangasek> you specify your supported archs in /etc/dpkg/dpkg.cfg, then frob /etc/apt/sources.list if needed
<slangasek> no magic for archive/ports
<slangasek> if we were going to do that, I would want that to be in a front-end for managing sources.list, not in apt itself
<infinity> buildds need no knowledge of this, at least in this use case.
<infinity> openhackware-whatever is a binary dependency of qemu, not a build-dep.
<slangasek> but we need to have a policy (and hopefully align with Debian on that policy) about what buildds should be allowed to grab from foreign archs for building
<slangasek> yeah, if we go that route that's true
<slangasek> but then the question is, do we allow packages in the archive to have dependencies on $package:$foreignarch
<infinity> Suggests/recommends, seems sane for certain cases like this.
<infinity> Would allow us to finally make PALO arch:hppa too. :P
<slangasek> yep, openhackware is somewhat to the side of the other cases where we're going to need policy
<slangasek> ultimately I'd like to see multiarch obsolete all our biarch/triarch toolchains
<slangasek> but the mechanics are TBD
<infinity> (Though, I find it entertaining that Ubuntu dropped hppa eons ago, and still has PALO in the archive, thanks to the weird arch:all hack)
<infinity> slangasek: Anyhow, returning to the meat of the discussion, can you think of a legit use-case for needing multi-arch build-depends?
<slangasek> infinity: if we want to drop gcc-multilib, then... everything that currently build-depends on gcc-multilib :)
<slangasek> i.e., no more lib32gcc1+lib32gomp1+libc6-dev-i386 pulled in - just libgcc1:i386, libgomp1:i386, libc6-dev:i386
<slangasek> might still call the metapackage gcc-multilib, but it would stitch it together differently
<infinity> Okay, but aren't most of those in existence currently because we don't have multiarch. :P
<infinity> As in, we need to be able to do cross-arch builds specifically to produce those packages.
<infinity> s/don't/didn't/
<infinity> This netbook doesn't have deb-src lines.  Hrm.  I should get me a Sources.gz
<slangasek> so you're saying we should drop the out-of-the-box support for building 32-bit code on 64-bit installs?  Sounds to me like a regression for users
<infinity> But yeah, from what I recall, gcc-multilib kinda existed to be able to produce those icky pseudo-multiarch packages on non-native builds.  That use-case goes away with multi-arch, where all builds can be native again.
<infinity> No?
<slangasek> if we enable i386 multiarch by default on amd64, sure, we probably don't need it for the archive anymore; we still have to sort through if that's sane in all cases; but that still doesn't help users who want to do 32-bit compiles with gcc -m32
<infinity> Oh, hrm.  gcc -m32 will still insist on lib32 madness?
<infinity> Can't that just be... Fixed?
<slangasek> packages currently shipping 32-bit code in amd64 packages include such things as fakeroot, mknbi, mkvmlinuz, valgrind
<slangasek> fixed> to do that we have to decide we're going to allow it to depend on :i386 packages
<infinity> I mean, I'm not saying this will all resolve itself in 6-12 months, but I had assumed multiarch would, ultimately, make all this non-native binaries in native packages mess go away.
<slangasek> well, it might - but is it better to get rid of the biarch lib packages as a first step along that path?
<infinity> And yeah, I would find allowing gcc to depend on libc6:i386 to be less disgusting that having it depend on libc6-i386_amd64.deb which, suprise, isn't an amd64 deb at all!
<slangasek> sure - but once we allow such a dep, do people start abusing the facility
<infinity> Probably.  That's why we have policy.  And fascist ftpmasters.
<infinity> So, yes, a discussion about what that policy should be would be worth getting into.
<slangasek> :)
<infinity> Though, to be fair, I'm not sure I see too many abuse vectors, except for the guy who thinks that having a "firefox32" metapackage that just depends on "firefox:i386" is a good idea.  And that's easily noticed and wrist-slapped.
<slangasek> a large part of it might just be "how do we make sure the buildds do what we meant when resolving build-deps/deps"
<slangasek> oh I couldn't find the flex you asked for so here's one for mipsel, hope that's ok
<infinity> Is that how apt deals with it?
<slangasek> if you enable mipsel in your multiarch config, and you don't specify which arch you want the package for, and you don't have pinning in place that prevents it, yeah
<infinity> But it would be simple enough to make sbuild more pedantic.  It (still) doesn't use apt's resolver for initial build-dep parsing.
<infinity> And there's also pinning, yes.
<infinity> Combine a non-auto pin for !native with explicit requests for package:arch as found in build-deps, and you should probably get the behaviour you wanted.
<slangasek> yep, could be
<infinity> (Although, I would be inclined to argue, perhaps, that the non-auto pin priority for non-native should actually be the baked-in default in apt...)
<infinity> Much like the special-casing for experimental.
<infinity> Any explicit request, whether a manual "apt-get install foo:arch" or a binary dependency on foo:arch would override that pin, but I think accidentally fulfilling a package request with a non-native one just feels... Wrong.
<slangasek> how do you think that should work for the nspluginwrapper package here, then?  https://launchpad.net/~vorlon/+archive/multiarch/+packages
<slangasek> ah, you would want nspluginwrapper Depends: nspluginviewer:i386
<slangasek> could work
<slangasek> I don't think the :i386 syntax has been implemented yet, but that's a minor concern
<infinity> slangasek: Yeah, that would be what seems most sane to me.
<infinity> slangasek: Cause that is explicitely saying "I want the i386 version of this", not "fulfill with whatever you happen to find".
 * slangasek nods
<infinity> Granted, in the grand scheme of multiarch utopia, where the developer might not know that my s390 system can execute alpha code, but nothing else, I guess there's an argument for the auto-fallback.
<infinity> Meh.
<infinity> Oh course, as the owner of that bizarre s390/alpha setup, I'm not sure I'd expect much sympathy from defaults, and could fiddle with stuff myself. :P
<infinity> And I suspect the nspluginviewer case is going to be the norm anyway.  You generally want multiarch because binary X only works on foo, not because it's built for 5 architectures, but not your own.
<infinity> (I do still expect the uber-nerds to have a system with various binfmt hooks to run 8 or 9 architectures on one, just cause they can)
<slangasek> what, you mean like qemu-user-static+binfmt-support gives you out of the box? :)
<infinity> Hey, I'm old skool.  Last time I did it, I had to do it by hand. :P
<infinity> Well, there's our buildd solution right there.  Just build enormous amd64 machines, install every toolchain for every arch, and qemu-user-static.
<infinity> Oh, and then audit the archive and fix the 20,000 packages that call "gcc" instead of gcc-linux-$arch
<infinity> HTH.
<slangasek> thbbt :)
<infinity> None of this fixes openbios-sparc on Ubuntu, mind you.  The only two possible solutions at this point are "drop it from the archive" or "build it on Debian and massage it in with blinders on", cause Ubuntu's multiarch can't support architectures we don't ship.
<infinity> There's value in option 2, since you might still want a sparc VM on an Ubuntu machine.  It's icky, though.
<infinity> (Though that same icky solution is how we have palo in the archive by accident, it was built on the Debian uploader's machine and synced)
<infinity> slangasek: Err, looking at your multi-arch PPA... Why would the arch:all ca-certificates need a Multi-Arch: foreign stanza?
<infinity> slangasek: Doesn't arch:all sort of imply the same thing that MA:foreign specifies?
<slangasek> infinity: because of arch:all packages like python
<slangasek> i.e., arch-specific dependencies masked by an arch:all metapackage
<slangasek> the only way to be reliably backwards-compatible with existing packages is to require M-A: foreign for arch: all as well
<infinity> slangasek: So, that means that (nearly) all arch:all packages need MA:foreign?
<slangasek> if we care enough to add it, probably
<infinity> slangasek: Except for those metapackage-to-pull-in-native-package cases...
<slangasek> but it's really only interesting for packages that are arch: all and have libs as revdeps
<slangasek> infinity: round-one spec is here, fwiw: https://wiki.ubuntu.com/MultiarchSpec
<infinity> slangasek: That's what I was reading to figure out what MA:foreign meant before I asked about the redundancy. :P
<slangasek> ah, buried in there somewhere is the explanation of MA:foreign+arch:all
<lifeless> pitti: yo
<infinity> slangasek: Ahh, I see the note about why arch:all needs the foreign, except... I still don't buy it. :P
<infinity> Oh, wait.  I was thinking at the apt level, not the dpkg level.
<infinity> "To avoid breaking this assumption, Architecture: all packages will, at least initially, be treated as equivalent to packages of the native architecture for all dependency resolution."
<infinity> I read that to mean "since the arch:all package exists in Packages.gz for all your architectures, you still win", but it literally means "all occurences of foo_all.deb will internally be treated as foo_native.deb", doesn't it?
<slangasek> yes
<infinity> Yeah, fair enough.  Seems like an odd way to do it, mind you, since it would be trivial at the higher (ie: apt and friends) level to feed it to dpkg as non-native.  But that breaks the "dpkg -i *deb" use-case.
<infinity> So, I suppose I understand why you specced it that way.  Just looks like a lot of busy-work to make all the legitimately arch:all packages have the new stanza.
<infinity> slangasek: Oh, we still haven't gotten to the co-installable headers stage yet?  We might be slightly premature in discussing buildd impact, then. :P
 * infinity is wishing he hadn't missed the last year of discussion on this.
<slangasek> infinity: linux-libc-dev is coinstallable in the archive; discussions on debian-policy; that spec is based on a two-year-old UDS session, I've not been updating it for topics that were deemed out of scope at the time
<slangasek> libc6-dev is not coinstallable in the archive solely because some packages get upset when they can't find crt*.o in /usr/lib
<infinity> slangasek: Oh.  You're going to make me read -policy to catch up with the current state of things?  Well, at least it's not -legal...
<slangasek> heh
<infinity> slangasek: What gets grumpy about crt*.o?  And could that be temporarily worked around with an arch:all (oh hey, look, a weird use-case for all being considered native-only) package that ships symlinks? :P
<infinity> Or, rather, creates symlinks.  Shipping wouldn't work.
<infinity> But whatever.
<slangasek> emacs got grumpy.  We didn't look farther - already in feature freeze at that point and it was an unintended side-effect, so rolling back was considered Prudent
<slangasek> we can tackle that again soon enough in oneiric
<infinity> And yeah.  Agreed.  Trying to do this sort of thing on a 6-month release schedule has its drawbacks.
<infinity> (Side note: is anyone expected to be able to successfully type oneiric with reasonable frequency?)
 * slangasek shrugs :)
<infinity> Maybe I'll get one of those gamer keyboards, so I can macro it.
<lifeless> one^Xl
<arand> infinity: I've adopted "oo" as the name to use for this cycle..
#ubuntu-devel 2011-04-17
<smoser> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta-2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots:
<ohsix> anyone around to provide some advice? would ubuntu carry an "up" ported patch to restore functionality? the project has stonewalled on proxy support after removing it making transmission useless for a lot of people, but its far and away the best client otherwise https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/713604
<ubottu> Ubuntu bug 713604 in transmission (Ubuntu) ""Proxy" tab feature removed" [Wishlist,Won't fix]
<ohsix> also, can anyone give me pointers on how to get started preparing a patch to revert the changes & restore the functionality?
<ohsix> how can i get debuild to be louder about why a patch application failed, trying to prepare a revert for what i mentioned earlier
<ohsix> the patch works fine outside of debian/patches
<ohsix> hm nm it says already
<ohsix> how are you supposed to prepare patches? will quilt rebase them? i've been preparing them against the unpatched source
<infinity> ohsix: Generally, assuming there's a patch target, you can "debian/rule patch", then prepare your patch against the patched sources, and toss it in the end of the quilt series.
<infinity> ohsix: There are automated tools to do that sort of thing, but I never remember them. :P
<ohsix> yea i was using quilt wrong
<ohsix> <3 quilt, should have just read the documentation again instead of assuming i'd remember everything
<ohsix> i'm supposed to edit debian/channgelog if i'm ultimately providing a debdiff, no?
<ohsix> or whatever tool that does that for me
<ohsix> guess the patch will do for now
<mdke> could anyone help me with this error message  when running dput - I haven't had it before and I don't think I've changed anything
<mdke> http://paste.ubuntu.com/595059/
<mdke> the package appears to have uploaded successfully actually, perhaps I don't need to worry about it?
<sladen> ohsix: yes, describe your change in debian/changelog and link to the '(LP: #NNNN)' bug report in the same patch
<ohsix> sladen: ok thanks
<sladen> ohsix: if there isn't already and entry.  Add one above, bump the number and change the target 'natty' to 'UNRELEASED'
<ohsix> hm you wouldn't know offhand why svn merge -c <rev> might look like it's including stuff other than what is in the rev you selected?
<ohsix> will it do that if theres no other revision to merge to? how can i get it to just act as if the rev never existed than papering over it to the next possible rev
<sladen> ohsix: is it including .svn/.bzr ?
<sladen> ohsix: or rebuilt translations?
<ohsix> no nothing like that, i'm just trying to make a patch to be proposed for inclusion in a package, it restores something upstream removed, i'm not the maintainer of the package or anything; and i'm poking at svn to get it to give me the 3 reverts i need to make it happen
<ohsix> say, something in rev 4 is ending up in my revert of 3 and i can't tell why
<sladen> ohsix:  debuild -S  to build a source package with your changes
<sladen> ohsix: debdiff ../package_1.2.3.{4,5}.dsc | less -S      to get the .debdiff
<ohsix> well it was an svn question, svn diff -r 3:4 shows the right diff, but svn merge -c 4 seems to include 5, 6 and some other rev into the revert
<iulian> mdke: It currently sits in the unapproved queue.  No need to upload it again.
<ohsix> ahh nm there's a conflict and it was bringing in extra versions to resolve it
<bambee> Hello, anyone has noticed introspection errors with python-dbus (see http://paste.ubuntu.com/595083/) ? I get the same error with language-selector too
<ohsix> how do you name versions in a ppa that you want to supersede the ubuntu version, but not "replace" it, like say 2.13-0ubuntu8 is the current archive version, i'm guessing calling it 2.13-0ubuntu9 is inappropriate
<arand> ohsix: use "~"
<ohsix> ok i did that already, thanks
<ohsix> i was just asking because the ppa browser page still said there was a newer version with the extra version
<sladen> ohsix: 2.13-0ubuntu8~ppa1
<arand> ohsix: The ordering is 8,  9~1, 9, afaik, I think it will also pick up proposed packages as "newer".
<ohsix> does it need a number at the end? i named it 2.13-0ubuntu8~proxy
<arand> Works as well, however if I remeber correctly that will make it a version below ..ubuntu8, the ~ decreases...
<ohsix> ah
<ohsix> so will i need to reupload when the 9 version comes around? or can i supersede them all
<arand> Well you can use any version number, though it's recommended to allow superseeding by security updates..
<ohsix> k
<arand> ohsix: If you use 8~proxy now I think that will be seen as a lower version than just 8.
<ohsix> is this somewhere in the debian handbook
<arand> I remember reading it somewhere, but can't find it atm...
<ohsix> me too :\
<ohsix> found it
<ohsix> For example, the following parts are in sorted order from earliest to latest: ~~, ~~a, ~, the empty part, a.
<ohsix> how long typically is "awaiting publication" for freshly finished builds on ppas
<ohsix> arand: it did make it an older version D:
<ohsix> arand: https://bugs.launchpad.net/launchpad/+bug/559074 D:
<ubottu> Ubuntu bug 559074 in Launchpad itself "Documentation for PPA package naming is inconsistent" [Low,Triaged]
<arand> ohsix: Matter of <15min from my exparience.
<ohsix> ok sorted this version business
<ohsix> arand: thanks for your input
<mdke> iulian: thanks. I will ignore the error message then for now!
<ohsix> is there a way to keep private notes for things on launchpad? like information i want to remember next time i update the ppa, without stashing it locally
<bloops1> is there a way to test a build of g++ locally without installing?
<ohsix> install it into a prefix other than /usr
<bloops1> yes I did
<bloops1> then when I call the g++ executable it complains about
<bloops1> not being able to execute cc1plus
<bloops1> there is a cc1plus binary in the same directory
<ohsix> how did you set the prefix, at configure time or at install time? it needs to know about its own prefix and you need to have it in your PATH
<bloops1> wait, I didn't set the prefix.
<bloops1> it installed in src_directory/host-x86.../gcc
<bloops1> ok can set the prefix now or do I have to make again?
<ohsix> that's just where the target ended up, install phase puts it somewhere else; i haven't ran gcc out of tree, you might be able to execute it in place just by changing your PATH
<bloops1> how do I change my PATH? can you point me to some docs?
<bloops1> i don't think it's there at http://gcc.gnu.org/install/
<ohsix> the PATH is a list of directories your shell searches for things to run
<bloops1> oh I see.
<bloops1> ohsix: it worked after adding to PATH. but then it couldn't find the include files.
<bloops1> ohsix: I gave up and did make install
<ohsix> how difficult is it wiring something up that needs to be ran at boot, before rw remounts; trying to figure out how i can cobble together an fsnotifyd type thing that osx has for time machine, in order to do something like it
<ohsix> theres a chicken & egg problem with changes if it's not done early
<ailo_> I'm trying to figure out what is causing gtk themes to not work on Ubuntu Studio Natty. I would file a bug report, but I'm not sure which package or packages are involved
<ailo_> Where could I look for errors?
<ailo_> The theming is only partly working
<ailo_> Panels and desktop right-click menu falls back on the basic gtk theme
<ailo_> While windows like nautilus will use the chose theme
<ailo_> Also, Icons cannot be changed,
<ailo_> This is on a fresh install of Ubuntu Studio Natty
<ailo_> This apparently only happens on some systems
<ivan_> hii
<mr_pouit> bah, "550 Changes file must be signed with a valid GPG signature" apparently means "waiting for approval"â¦
<lifeless> no
<lifeless> its a bug with the uploader
<lifeless> when a sysadmin is here - about 1.5 hours - we'll get it kicked again
<lifeless> and the root issue should fixed this week
<mr_pouit> ah, okay
<lifeless> the bug doesn't stop the package being handed off to the backend
<mr_pouit> archive admins, sorry if there are 12 thunar uploads in queue :s
<lifeless> that then correctly validates the upload
<iulian> Ouch.  There are only 9, not 12.
<iulian> Or probably the other 3 are on their way.
 * iulian shrugs.
<mr_pouit>  :(
#ubuntu-devel 2012-04-09
<ScottK> cyphermox: It looks like updating network-manager-openconnect from Debian before release might be a good idea.  Would you mind having a look at it?
<ScottK> micahg: Would you please have a look at the most recent Debian blueman upload in relation to your Ubuntu upload?  It looks like there might be some useful things to pick up, but I'm getting lost in it due to differing tarballs between the two distros.
<micahg> ScottK: tarball diff is bad, I pulled what was upstream...I will have a look
<ScottK> micahg: Thanks.
<krnekhelesh> I have a question,...if a package does not have debian/source/format folder ... I am guessing quilt cannot be used
<krnekhelesh> if so, how do I generate a patch?
<krnekhelesh> previously I did quilt push -a, but now quilt can no longer be applied
<jtaylor> try edit-patch, if it has a common patch system it will use it
<jtaylor> if its your package, just change it to 3.0 quilt
<krnekhelesh> ok..I am trying to patch something in ubuntu software center
<ScottK> krnekhelesh: Quilt can be used, but you have to integrate it into debian/rules.
<juliank> krnekhelesh: That's a native package, they don't have patch systems
<ScottK> I think he meant a package he found via software center, not software center itself.
<ScottK> (but I could be wrong)
<krnekhelesh> ScottK: No I am talking about the Ubuntu Software Center itself
<ScottK> OK. Then what juliank said.
<krnekhelesh> ScottK, juliank: I am trying to add keywords to the .desktop file
<krnekhelesh> once I am done, do I just commit it instead of creating any patches?
<krnekhelesh> juliank: since it is a native package, do I add the keywords to the .desktop and then commit the whole package instead of creating patches?
<juliank> krnekhelesh: It depends on what you want. If you want to contribute, you'd usually take the bzr branch of software-center, do your commits, and then push it somewhere and request a merge.
<krnekhelesh> juliank: thnx, I get it now...this is what I normally do but in other non-native packages I was requested to create patches...that's why I asked
<cyphermox> ScottK: yes, it was the plan
<ScottK> OK.  Thanks.
<cyphermox> ScottK: I'm not well today but I'll try to finish filing the FFes for the vpn plugins, would you be able to review them?
<cyphermox> I already have bug 973775 for vpnc
<ubottu> Launchpad bug 973775 in network-manager-vpnc (Ubuntu) "[FFE] network-manager-vpnc 0.9.4.0" [Undecided,New] https://launchpad.net/bugs/973775
<ScottK> cyphermox: Yes.
<cyphermox> Thanks.
<hyperair> ScottK: ping.
<ScottK> hyperair: pong
<hyperair> ScottK: banshee-community-extensions just got 2.4.0 released (the one in precise is 2.2.0, the previous stable). should i request an FFe for it, or should i just cherry-pick the bugfixes over?
<hyperair> there's a new extension included
<ScottK> I think an FFe is reasonable.  Up to you.
<hyperair> okay, thanks.
<bdrung> !dmbping
<hyperair> ScottK: bug #977236 â here be the FFe
<ubottu> Launchpad bug 977236 in banshee-community-extensions (Ubuntu) "FFe: Merge banshee-community-extensions 2.4.0 from Debian Unstable" [Undecided,New] https://launchpad.net/bugs/977236
<ScottK> hyperair: Approved.
<hyperair> thanks
<cyphermox> broder: ping?
<gizero> During install I chose custom partitioning. When creating a partition the textfield for the size was not editable, instead one has to use + - buttons to change the size megabyte for megabyte. Is that a temporary solution for some problem, or is it meant to be that way? It takes ages to change size that way; I have to hold down the - sign several minutes to get to the small partition size I wanted.
<mneptok> gizero: have you checked Launchpad to see if others have reported the same issue?
<gizero> mneptok, No, I haven't.
<mneptok> gizero: that's probably the best place to start
<gizero> Considering that + - buttons have been added I'm sort of afraid that this is one of those "it's more user friendly this way" Ubuntu deals:-)
<mneptok> gizero: i can assure you that no such buttons exist in the -alternate installer. AFAIK, the text-mode debian-installer doesn't see a lot of tweaking in Ubuntu.
<ScottK> jbicha: Would you be able to have a look and see if gedit-latex-plugin should be updated from Debian?
<jbicha> ScottK: yes we should sync it from Debian
<ScottK> jbicha: Would you please see if there's an FFe needed and request it, if so?
<smoser> cjwatson, around ?
<smoser> our recent cloud-images build shave become unable to boot.
<smoser> we see : error: no such device: 00000000-0000-0000-0000-TEMP0FS0UUID.
<smoser> looking at the menu entry we see:
<smoser>  search --no-floppy --fs-uuid --set=root 00000000-0000-0000-0000-TEMP0FS0UUID
<slangasek> smoser: that's not a template that I find anywhere in the grub2 or grub-installer code; it would appear that this was the actual UUID of the filesystem at the time grub was installed?
<smoser> slangasek, digging/
<smoser> well, slangasek i just opened bug 977357
<ubottu> Launchpad bug 977357 in grub2 (Ubuntu) "12.04 cloud-images do not boot (no such device: 00000000-0000-0000-0000-TEMP0FS0UUID)" [Undecided,New] https://launchpad.net/bugs/977357
<smoser> it has more information.
<smoser> oh gah!
<gema> can anyone help me finding all the binaries that were previously installed by ia32-libs? my understanding was that I could install ia32-libs-multiarch and get it, but it doesn't seem to be there
<gema> or point me to some documentation that actually says how to use it
<sbeattie> binaries, meaning libraries contained therein? dpkg -L ia32-libs-multiarch should do it
<gema> they are not there, sbeattie , for precise AMD64
 * sbeattie looks
<sbeattie> oh, weird. That would seem to be a bug to me.
<gema> sbeattie: you see it too, right?
<sbeattie> gema: yes, I see that the package is empty.
<gema> sbeattie: ack
<sbeattie> gema: looking further, though, apt-cahce show ia32-libs-multiarch shows a bunch of dependencies
<sbeattie> I *think* because it's an i386 package, the dependencies will pull in the :i386 versions of those dependencies
<sbeattie> gema: I'd verify with slangasek whether that's how it's functioning now.
<gema> sbeattie: it's not functioning, java is not finding the binaries
<sbeattie> which java?
<gema> sbeattie: proprietary jvm that comes with an altera product
<gema> doesn't really matter
<gema> sbeattie: we seem to be breaking compatibility with all the products out there that ship their own jvms
<gema> sbeattie: I will discuss with jibel tomorrow
<gema> after looking a bit deeper into it
<gema> sbeattie: thanks
<slangasek> smoser: glad you got it sorted :)
<micahg> slangasek: any chance of having Bug #929219 fixed for final?
<ubottu> Launchpad bug 929219 in eglibc (Ubuntu Precise) "chromium-browser crashed with SIGSEGV in __nscd_get_mapping()" [High,Triaged] https://launchpad.net/bugs/929219
<slangasek> micahg: yes, it's on infinity's list for this week
<micahg> excellent
<penguin42> micahg: Interesting, I've had some chromium startup crashes - I've never had it fail if I start it from a terminal, only if I start it from the panel button and then only sometimes
<slangasek> I suppose I should set the rls-p-tracking tag on that
<micahg> slangasek: please :)
<slangasek> (done)
<micahg> penguin42: I have had it crashed in both ways, also I"m not sure this will fix all of the crashes, but should fix a nice portion of them
<infinity> micahg: It's on my list, but I can't, for the life of me, reproduce it, which makes it hard to test various upstream and distro patches that purport to fix it. :/
<infinity> micahg: Can you reliably reproduce it?
<infinity> micahg: If so, I'll use you as a testing guinea pig this week, if that's cool.
<micahg> infinity: no, I can't reliably reproduce
<micahg> if I launch it from a new session though, I usually get a crash the first time (not sure if it's every time)
<broder> cyphermox: pong. this is re: vpnc?
<infinity> micahg: Well, scratch reliably.  Can you reproduce it at all, and to the point where you're fairly sure you could determine if it were fixed? :P
<infinity> micahg: (I can't actually reproduce it AT ALL, so it's not even a matter of launching 1000 times in a loop and calling it fixed, cause I could do that today without changing anything)
<micahg> infinity: first launch in a new session doesn't crash for yoá»§
<infinity> micahg: Nope.
<infinity> micahg: Also, way to compose.
<infinity> á»§
<infinity> I had no idea that character even existed.
<slangasek> is that a breath mark?
<micahg> xchat seems to have compose on for me and I can't turn it off
 * micahg should just restart the app
<cyphermox> broder: yup.
<cyphermox> broder: where you waiting for some kind of upstream input to upload or something?
<broder> that would certainly be nice. i also just switched jobs though so free time has been at a bit of a premium
<cyphermox> the n-m-vpnc parts landed today, the NM stuff landed a few weeks ago
<cyphermox> oh ok
<cyphermox> I can always take it from there
<broder> that might be best
<cyphermox> ok
<cyphermox> broder: you tested it and things were good?
<broder> yep
<cyphermox> awesome.
<cyphermox> if I can ask, what config where you using on the VPN boxes, so I can replicate and test it here? I've been having some issues triple-checking this on my ASA
<broder> uh, not totally sure - our IT guy told me in an e-mail but i don't have access to that anymore. i think it was just split-dns foo.com, bar.com or whatever
<broder> where foo.com and bar.com weren't the actual domain name
<cyphermox> alright, then that's pretty much what I'm using
<cyphermox> broder: thanks
<cyphermox> broder: ok, checks out on my end as well (just being thorough)
<mintsoup> Is this a good place to ask about the panel notifications in unity (notify-osd?)? Where is the code for this? Looking in the Unity bzr repo, I don't see an obvious directory in the plugins/unityshell dir.
<azeem_> notify-osd is its own project and independent of unity, AFAIK
<mintsoup> azeem_: thanks--found the appropriate launchpad
#ubuntu-devel 2012-04-10
<hyperair> could a core-dev please sponsor Bug #976120
<ubottu> Launchpad bug 976120 in liferea (Ubuntu) "liferea is built without libindicate support in Precise" [Undecided,Confirmed] https://launchpad.net/bugs/976120
<umang> Hi, on the beta 2 release notes, it says "Both of these reduces power consumption and thus battery lifetime." It sounds as though they should say "Both of these reduce power consumption and thus increase battery lifetime." (or just life).
<umang> https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview/Beta2
<umang> I can't make changes, but I hope someone in this room can.
<pitti> Good morning
<ajmitch> hi pitti
<dholbach> good morning
<dholbach> can somebody of the kernel team have a look at bug 975392?
<ubottu> Launchpad bug 975392 in kernel-package (Ubuntu) "Sync kernel-package 12.036+nmu2 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/975392
<jibel> slangasek, there's a regression with msttcorefonts and the package downloader introduced in update-notifier bug 977812
<ubottu> Launchpad bug 977812 in update-notifier (Ubuntu Precise) "package downloader doesn't follow redirects" [High,Triaged] https://launchpad.net/bugs/977812
<soren> win 37
<soren> doh
<dholbach> tumbleweed, heya - I just read the log of the DMB meeting - are you going to process the applications by mail now?
<tumbleweed> we have always been able to. Although we haven't done any since I joined. Apparently it never worked very well
<tumbleweed> people don't reply with votes, or something like that
<henrix> pitti: hi! not sure if you're the right person to contact about this... just received an email w/ subject "linux-lts-backport-natty_2.6.38-0~12~oneiric1_source.changes rejected"
<henrix> pitti: it states that File linux-lts-backport-natty_2.6.38-14.58~lucid1.tar.gz already exists in PPA for Cycklon, but uploaded version has different contents.
<pitti> "Cycklon"?
<pitti> henrix: sounds like a LP regression then; different PPAs ought to be able to have different origs
<henrix> well, that's what it says
<henrix> so, shall i just send an email to launchpad-users@lists.launchpad.net?
<dholbach> tumbleweed, hum, it just wasn't quite clear to me what's going to happen with the applications of yesterday
<Laney> we should email them to do it next time
<tumbleweed> dholbach: the applicant wasn't present, and there wasn't quorum. But yes, we should probably mail the applicant and mention that we rescheduled him
<dholbach> ivoks, you might want to add your application as well :-)
<dholbach> tumbleweed, alrightie
<dholbach> thanks a bunch
<sabdfl> pitti, rickspencer3 sent me scrollback on your upgrade testing
<sabdfl> superb!
<pitti> sabdfl: thanks!
<pitti> sabdfl: that's the first release ever where we got that right
 * pitti bounces
<ivoks> dholbach: :)
<rickspencer3> jibel, ^ very nice contribution from the QA team :)
<jibel> rickspencer3, thanks  \o/
 * pitti hugs jibel
<pitti> we could never have come that far without you and all that jenkins work
 * jibel hugs back pitti 
<seb128> http://pastebin.ubuntu.com/923047/ (retracers bugs with >=3 dups sorted by count of duplicates since the start of april)
<seb128> (just for info if some are interested)
<pitti> ah, thanks; I see an udisks bug there whic is already fixed
<seb128> pitti, yeah, I don't filter out closed bugs, most of the top bugs have been fixed already
<pitti> no, I mean it was an unclosed duplicate, I duped it now
<infinity> seb128: Interesting report.  I can't speak for most upstreams, but I wonder if there might be value in snagging all the telepathy-*/mission-control bugs and bundling up the list for an email to the telepathy list.
<infinity> seb128: (Not that I checked bug statuses, maybe they're all fixed already)
<seb128> infinity, yeah, I will mention it to kenvandine ;-)
<infinity> pitti: And congrats on the upgrade testing success!  Does this mean I have nothing to do this month? ;)
<pitti> infinity: there are still some conffile questions, and http://people.canonical.com/~ubuntu-archive/nbs.html :)
<infinity> pitti: (I know :P)
<infinity> pitti: I'm pretty sure I'll keep myself more than busy from now until release.
<infinity> And then drown myself in gin the night after...
<pitti> heh, sounds like a plan! although I'd prefer Vodka
<infinity> seb128: Oh, speaking of desktop things, do we have someone working on libical?
<infinity> It's making outdate.txt a sad Panda.
<seb128> doh
<seb128> infinity, it's supposed to be me, I keep hopping that Debian would fix the bug since they have it too but no dime :p
<infinity> A man can dream.
<infinity> As long as it doesn't fall off your radar, I'll pester occasionally. ;)
<seb128> infinity, thanks for the reminder
<smoser> just going to rhtrow htis out htere and ask if anyone knows.
<smoser> i have an ext4 filesystem in a file image (mkfs.ext4 -F foo.img).  It has some files in it.  is there a way to essentially "trim" the image ?
<smoser> i've done mount -o loop, dd if=/dev/zero of=/mnt/file.img, rm /mnt/file.img, umount /mnt
<smoser> and that largely works.
<smoser> but reading 'e2image' i got the impression it could do it, but i think i'm wrong.
<smoser> (a copy rather than in-place update would be acceptable here)
<soren> smoser: Yeah, there is.
<soren> smoser: Let me see if I can remember where it is..
<soren> smoser: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/e2fs-zero.py
<smoser> soren, thanks.
<soren> smoser: It always gave me the heeby jeebies.
<smoser> well, yeah.
<smoser> dd if=/dev/zero seems less prone to error :)
<soren> smoser: Which is why I never integrated it into vmbuilder.
<smoser> but in my case, and yours, data loss is not really a big deal.
<soren> ..and instead built the fs outside the image and then copied everything into the image.
<soren> smoser: WEll...
<soren> smoser: The problem is that any data loss isn't obvious.
<soren> It might not reveal itself until much later and will be extremely hard to debug.
<smoser> true.
<smoser> i would think that e2fs upstream would probably take an e2image patch that also copied data.
<soren> ...and back when vmbuilder has the new hawtness, the state of the art was still to use VM's much like real machines: Long-lived, persistent resources.
<smoser> http://patchwork.ozlabs.org/patch/142316/
<smoser> well, fun...
<smoser>  http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.42.2 seems to imply that we should probably sync e2fsprogs from debian.
<smoser> anyone want to look at bug 978012 ?
<ubottu> Launchpad bug 978012 in e2fsprogs (Ubuntu) "Please merge e2fsprogs 1.42.2-2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/978012
<cjwatson> mvo: can you think of any reason why bug 922949 might not be an apt bug?  all ubiquity is doing here is running 'apt-get -d -y --force-yes -q -o Dir::Cache=/target/var/cache/apt upgrade'
<ubottu> Launchpad bug 922949 in ubiquity (Ubuntu Precise) "installation process can crash due to an issue with one package when choosing "install updates" as part of the install" [High,Triaged] https://launchpad.net/bugs/922949
<cjwatson> mvo: I suppose I could explicitly go through and check all the checksums, but it seems as though apt ought to have done that already
<smoser> slangasek, you're last touched on e2fsprogs, do you have thoughts on bug 978012 ? basically, i'm weary of doing a merge that this point, but the debian maintainer seems like he knows a thing or two about ext filesystems.
<ubottu> Launchpad bug 978012 in e2fsprogs (Ubuntu) "Please merge e2fsprogs 1.42.2-2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/978012
<mvo> cjwatson: let me check that one
<mvo> cjwatson: right, apt should do this - its doing this when getting the data from the network into memory, but after it has written the file it does not do another verification of the resulting deb, maybe this is what should be done too
<cjwatson> mvo: you mean checking that it's been written to disk correctly?
<mvo> cjwatson: yes, exactly
<cjwatson> it's just odd that we're seeing this disproportionately (I think?) during installation
<cjwatson> it seems to be doing something more or less plausible when I just run locally with a test proxy that corrupts stuff on the way through
<mvo> cjwatson: not sure, there are a bunch of bugs for apt itself that have similar symptoms - or is this sometihng that started recently in the installer?
<cjwatson> I don't think it's particularly recent
<mvo> cjwatson: the way its currently working is that there the  hashsum is updated for each bit of data that comes in, but its not checking the final written file
<cjwatson> wait, it *might* be something else, this isn't actually the "download updates during install" bit now that I look at it more closely
<cjwatson> it's langpack installation
<cjwatson> ubiquity installs its own acquireprogress/installprogress implementations there, so it's possible this is ubiquity's fault for omitting some crucial piece of error handling
<cjwatson> or that python-apt is missing something
<mvo> cjwatson: ohhh, thats interessting!
<barry> ScottK: need any help on LP: #879405 ?
<barry> bug 879405
<ubottu> Launchpad bug 879405 in pygobject (Ubuntu) "[FFE] Enable cairo support for Python 3" [Wishlist,In progress] https://launchpad.net/bugs/879405
<barry> or maybe pitti ^^
<mvo> cjwatson: keep me updated if you find out more please
<cjwatson> mvo: will do, still investigating
<pitti> barry: no, I already uploaded it to Debian
<pitti> barry: I just need a review/ack from a fellow release team member
<barry> pitti: cool.  that'll help my list for q :)
<msvb> Hello Chris aka Mr. cjohnston, you wrote me today that you can't find me on Launchpad.
<msvb> â¦but it seems you're not here either. Maybe out to lunch.
<msvb> Depending on the timezone. No idea.
 * ogra_ seriously wonders about all these locale warnings inside chroots recently 
<cjohnston> msvb: Michael?
<msvb> Aha, you are there. Yes, Michael.
<cjohnston> :-)
<msvb> Hope you liked my wild guess of writing ideas in the whiteboard. No idea if I committed a giant faux pas with that.
<ogra_> something weems to have changed that always gets me warnings for LANGUAGE, LC_CTYPE, LC_COLLATE and LC_MESSAGES being set to en_US.UTF-8 ... even though LANG=C was used
<cjohnston> Ok.. So I spoke with Jono... I don't believe that that blueprint/meeting is the correct place to discuss those topics as that blueprint is more on the actual code and development on Summit.. We do both agree though that there should possibly be a meeting to discuss your points, and others.
<msvb> Should I start a new general topic on the issue of welcome strategy or something like that?
<msvb> Is there already a existing topic about these things that you know of?
<cjohnston> That would work..
<cjohnston> Not that I know of.. its still quite early in the planning process
<msvb> I think there's only 15 so far, so as long as I'm not looking in the wrong place then I'll go to it.
<msvb> I must say that I've proposed four track meetings already and this will be the fifth.
<cjohnston> I don't see any in Summit either
<cjohnston> msvb: This one should be against community.
<msvb> Yes, I agree.
<cjwatson> mvo: can't seem to reproduce it here, though - I get FetchFailedException when I run the relevant bits of code manually against a broken proxy
<msvb> Can you tell me if I should use the 'propose meeting' link on the summit.ubuntu.com website or create a new blueprint with sprint or not with sprint and with an attached schedule, or should I do both a blueprint and a meeting proposal?
<cjwatson> ogra_: LANG is overridden by other LC_*/LANGUAGE environment variables
<ogra_> is that new ?
<cjwatson> no, it's been that way for as long as I can remember
<cjwatson> set LC_ALL=C if you want a big-hammer override
<ogra_> i definitely didnt have these errors in the past for LANG=C chroot foo-chroot
<cjohnston> One or the other.. The Propose a Meeting in summit is brand new.. to give the option of moving away from creating a blueprint just to create a meeting
<ogra_> now i get them everywhere
<cjwatson> something may have changed, but it wasn't the environment variable precedence order :)
<doko> pitti: could you approve icedtea-web as well?
<RainCT> didrocks: Hey. Just uploaded Zeitgeist 0.9 to Debian unstable :)
<didrocks> RainCT: awesome, thanks \o/
<mvo> cjwatson: that is consistent with what I saw a while ago when looking at this, I was using a fault-injection proxy and got the expected hashsum errors
<cjwatson> mvo: the only thing I can think of so far is an error somewhere in the complicated circular buffer code in the http method
<cjwatson> but I don't actually have anything definite to show
<cjwatson> if it has something to do with slow writes to disk, though, that might explain why we're seeing this during installation when there's lots of stuff going on
<cjwatson> mvo: does anything check errors from close()?
<cjwatson> mvo: (I'm getting increasingly tempted to work around this by an explicit check in ubiquity, despite what I just said in the bug)
<mvo> cjwatson: close is checked, but it looks like there might be a explicit close missing, let me look at the code some more
<mvo> cjwatson: no, thats not it, its there via explicit destruction
<cjwatson> mm, but what happens if it fails?
<cjwatson> I don't have much evidence that this is actually the problem, though, I'm just guessing
<mvo> it will set the internal _error->Error() state and return, this should be transported back to the parent of the http class, but it might be that this is not working, http://paste.ubuntu.com/923431/ may be worthwhile, let me dig some more
<cjwatson> mm, possibly
<mvo> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise: UI and feature freeze  Archive: frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mvo
 * dholbach hugs mvo
 * mvo hugs dholbach
<dholbach> :)
<cjwatson> mvo: there doesn't seem to be much in python-apt that would make it sane for ubiquity to do its own validation, even :(
<cjwatson> for instance, it doesn't look like there's a way to ask whether a package has already been downloaded to .../archives/ and if so what its filename is
<RainCT> didrocks: Why does bug #962265 have a Zeitgeist task?
<ubottu> Launchpad bug 962265 in zeitgeist-datahub (Ubuntu) "Unity in 12.04 is impossible to use by a newbie because of the empty Dash at start" [High,Triaged] https://launchpad.net/bugs/962265
<didrocks> RainCT: just to track it, the -datahub change is dependeing on the new zg from what mhr3 told dme
<RainCT> didrocks: I don't even see anything file related in the bug description/comments
<didrocks> RainCT: ping him, but he ensured me that if I uploaded -datahub with our incoming distro patch without the new zg, there will be no more event logged
<jkakar> Hi!  Updates from yesterday totally hosed my mouse and wireless on my Thinkpad T61... I ended up reinstalling Beta 2 from scratch (was previously running an upgrade from 11.10).
<jkakar> I poked about Launchpad, but didn't find any related bugs... does anyone know if these issues were reported/have been fixed?
<rbasak> cyphermox: around? Could you please look at bug 956843? I've attached a debdiff. I think it's a candidate for precise, since evolution calendar is fundamentally broken without this workaround, and will cause evolution to randomly crash when using the calendar.
<ubottu> Launchpad bug 956843 in libical (Ubuntu) "Access to freed memory in timezone handling causes crash" [Undecided,New] https://launchpad.net/bugs/956843
<cyphermox> rbasak: oh, I thought we had just fixed that
<rbasak> cyphermox: I'm not aware of anything. Is there another bug?
<cyphermox> I once dreamed of seeing a workaround for this in evo which I would have cherry-picked
<cyphermox> I'll take a look :)
<rbasak> Upstream didn't seem to be aware of this issue when I asked. There is another workaround that is present, but it doesn't work for an edge case which I am hitting.
<cyphermox> fwiw, evo calendar doesn't really crash for me though
<cyphermox> ok
<rbasak> It depends on what timezones you're using in your calendar
<cyphermox> well, it's definitely worth patching the issue anyway
<rbasak> It crashes for me every time without my workaround
<rbasak> It's a fundamental issue with memory management in the libical API. My patch is just (yet another) workaround to make an array big enough to start with that it doesn't need to be extended (because if it does get extended then it starts corrupting the heap).
<rbasak> Thanks for looking!
<cyphermox> ah, I see. we seem to have the workaround for evo but maybe it doesn't catch all the cases
<cyphermox> rbasak: patch looks reasonable to me too and it's acked by upstream, I'll sponsor it in a minute
<rbasak> cyphermox: great, thanks!
<cjwatson> james_w,maxb,vila: I have a UDD branch (openssl) affected by bug 714622, but where I'm actively making use of the ability to merge from the Debian branch.  Just how much does requeue_package.py --full delete?  Would it rewrite history in either the Debian or the Ubuntu branch?
<ubottu> Launchpad bug 714622 in Ubuntu Distributed Development "import fails when lp branch has been push --overwrite'n" [High,Confirmed] https://launchpad.net/bugs/714622
 * maxb tries to remember
<maxb> --full means to delete the importer's memorization of where the tags should point in the various branches
<maxb> I don't recall exactly how it behaves, though, for existing branches when it has no memos
 * maxb tries a --zap-revids=precise instead
<maxb> or would, if the importer wasn't holding a lock on the db
<maxb> james_w: The timeout thing hasn't completely fixed matters - I think the storm refactor is leading to the importer holding open a transaction for far too long at some point
<maxb>  And I think that thing must be the driver (at least in part, since it's still locked up, and only the driver is currently running
<maxb> SIGTERMing the driver
<cyphermox> rbasak: what do you do to make evo crash in ical the most?
<rbasak> cyphermox: I just start evolution. I think it's the contents of my calendar. Something to do with events that use timezones I think. Possibly timezones that don't exist in libical's builtin_timezones array by default. Not sure what timezone that might be.
<cyphermox> d'oh
<rbasak> cyphermox: the problem is heap corruption. The crash may or may not happen. My crashes tend to happen in GUI rendering, so people might just not notice when it corrupts rendering but doesn't actually crash for them. Actually I'd been seeing rendering problems for a while - perhaps that had the same root cause too
<cyphermox> rbasak: I was just curious if there was an easy way to reproduce it so I could test it here
<rbasak> cyphermox: I understand. Sorry, I'm not aware of one. You might try running it under valgrind - that will detect the problem even if it doesn't cause the crash. The valgrind warning I've got in the bug report should go away when the problem is fixed (or worked around)
<cyphermox> rbasak: all good -- sponsored.
<rbasak> cyphermox: thanks!
<rbasak> (OTOH, you might not see the valgrind warning because that only happens when evolution steps on the heap that libical freed, which might not happen in your case!)
<rbasak> This is one of _those_ bugs :-)
<james_w> maxb, that's pretty much the same conclusion that I have come to
<james_w> I don't have any ideas about where that transaction may be yet though
<maxb> james_w: When it is in the process of breaking, you can see a meta.db-journal file present on disk
<maxb> though, so much is in meta.db, that that does not narrow it down much
<cjwatson> maxb: not to rush you or anything, but roughly how long should I expect to wait for lp:debian/sid/openssl to come up to date now that you've stabbed it (i.e. when should I check again)?
<maxb> ugh, it's died again
<maxb> TypeError: tuple indices must be integers, not str !
 * maxb looks into that
<maxb> I will ping you here with a conclusion
<maxb> hmm. looks like --zap-revids=precise... didn't
<maxb> james_w: Hmm, how plausible does it sound that requeue-package is missing a commit after the storm refactor, so that the effects of --full or --zap-revids get rolled back, not applied?
<maxb> Also does anyone know why jubany doesn't let me forward a ssh key to it?
<james_w> maxb, canonical DC machines disallow that globally I believe
<james_w> maxb, commit> possible, but my first suspicion would be a unicode issue that means that it is acting on 0 rows instead
<maxb> That is unhelpful when you want to push local changes to a bzr branch
<james_w> maxb, I bet I missed a unicode() for the argument of --zap-revids
<james_w> but if --full doesn't work either then it may be something different
<maxb> I admit I didn't test --full
<maxb> that was just inference
<maxb> cjwatson: The problem has been overcome and an import is now running
<cjwatson> maxb: cool
<gotwig> hey
<maxb> cjwatson: openssl import complete
<cjwatson> maxb: brilliant, thanks
<ScottK> barry: Looks to me like tumbleweed took care of you.
<barry> ScottK: yep
 * tumbleweed likes easy FFes
 * highvoltage is glad that tumbleweed is on the release team
<highvoltage> (not that I've had any FFes this cycle)
 * highvoltage is tempted to add a "(yet)"
<ajmitch> highvoltage: there's still time
<tumbleweed> :)
<ajmitch> highvoltage: also time to upload fixes, especially for universe :)
<rbasak> cyphermox: hmm, libical FTBFS on amd64, although I had tested it with sbuild. I'll compare the build logs
<cyphermox> ugh
<cyphermox> I also ran it here on amd64 successfully
<highvoltage> ajmitch: *nod*
<cyphermox> rbasak: if you can figure out what is going on there, I'll keep diving into the armel failure.
<rbasak> It used -j8
<rbasak> I wonder if the build system breaks with that and it'll work with -j1
<cyphermox> arf
<rbasak> cyphermox: it's 2200 here, I'll look at it in the morning. I can look at armel too seeing as I have arm boards for this kind of purpose anyway - do you want to pass on how far you got for me to pick up in the morning, or would you prefer to look at it yourself?
<cyphermox> rbasak: I'll give it a shot, then email you with how far I got.
<rbasak> cyphermox: ok great - I'll sync with you tomorrow
<cyphermox> alright
<bdmurray> slangasek: do you have any thoughts on the update-manager task in bug 863509?
<ubottu> Launchpad bug 863509 in update-manager (Ubuntu Precise) "Upgrading Ubuntu to new version deletes previous wallpapers" [Undecided,Confirmed] https://launchpad.net/bugs/863509
<slangasek> bdmurray: not something we should commit to
<bdmurray> slangasek: okay
<bdmurray> slangasek: I also found bug 978124 which seems similar to bug 923220
<ubottu> Launchpad bug 978124 in update-manager (Ubuntu) "upgrading to 12.04 beta2 not completed due to problem with packet skype:386" [Undecided,New] https://launchpad.net/bugs/978124
<ubottu> Launchpad bug 923220 in update-manager (Ubuntu Precise) "update from oneiric to precise blocked on skype:i386 says updater" [High,Fix released] https://launchpad.net/bugs/923220
<slangasek> bdmurray: that's caused by glib2.0 being out of sync across architectures today
<slangasek> ("Rompe on" - ugh, why is half of apt.log translated)
<cjwatson> slangasek: bah, and I thought there was no arch skew problem with glib2.0
<cjwatson> had forgotten about multiarch agan
<cjwatson> *again
<slangasek> yeah... I think we're going to want to start shoving lots of libraries through -proposed anymore after betas
<cjwatson> or fix apt to do a better job of selecting workable library combinations out of what's available to it in the archive
<cjwatson> (NP-complete in general, I imagine, but surely that little detail ought not to bother a resolver :-P)
<slangasek> :)
<cjwatson> oh, mind you, not sure we keep the old non-arch-all binaries
<bdmurray> cjwatson: do you think bug 921889 should be a duplicate of bug 500175?
<ubottu> Launchpad bug 921889 in msttcorefonts (Ubuntu) "package ttf-mscorefonts-installer (not installed) failed to install/upgrade: el subproceso script pre-installation nuevo devolviÃ³ el cÃ³digo de salida de error 128" [High,Confirmed] https://launchpad.net/bugs/921889
<ubottu> Launchpad bug 500175 in aptdaemon (Ubuntu) "Canceling an installation in Software Center crashes debconf with "Use of uninitialized value $reply in scalar chomp at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66,"" [Low,Confirmed] https://launchpad.net/bugs/500175
<cjwatson> bdmurray: Hard to be sure.  Probably.
<bdmurray> cjwatson: because it might be bug 442941 or something else entirely?
<ubottu> Launchpad bug 442941 in ubiquity (Ubuntu Natty) "debconf failed to upgrade from 1.5.27ubuntu1 to 1.5.27ubuntu2: exit status 128 - Use of uninitialized value $reply in scalar chomp at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66" [Medium,Fix committed] https://launchpad.net/bugs/442941
<cjwatson> bdmurray: I left a comment.
<bdmurray> cjwatson: It seems to me like these package install failures are missing some bit of information and are not useful in their current state is that correct?
<cjwatson> Kind of.  I wrote up my thoughts on this failure type in bug 500175 a while back.
<ubottu> Launchpad bug 500175 in aptdaemon (Ubuntu) "Canceling an installation in Software Center crashes debconf with "Use of uninitialized value $reply in scalar chomp at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66,"" [Low,Confirmed] https://launchpad.net/bugs/500175
<cjwatson> Specifically comment 10.
<doko> now I think I did fix all build failures for an openjdk-7 update, and then ...
<doko> cp: writing `/home/packages/openjdk/7/openjdk-7-7~u3-2.1.1~pre1/build/openjdk.build/j2sdk-image/jre/lib/amd64/zero/libjvm.so': No space left on device
<doko> cp: failed to extend `/home/packages/openjdk/7/openjdk-7-7~u3-2.1.1~pre1/build/openjdk.build/j2sdk-image/jre/lib/amd64/zero/libjvm.so': No space left on device
<doko> make[1]: *** [stamps/add-zero.stamp] Error 1
<doko> :-/
 * doko removes a few gcc builds
<slangasek> maxb, james_w: plymouth's UDD branch suddenly got a merge from the package importer today, resetting it back to the state of the last upload; do you know why that would be?
<slangasek> james_w: oh, I see plymouth was one of the ones I asked you about on bug #714622
<ubottu> Launchpad bug 714622 in Ubuntu Distributed Development "import fails when lp branch has been push --overwrite'n" [High,Confirmed] https://launchpad.net/bugs/714622
<slangasek> james_w: so the result seems to have been the exact opposite of what I was looking for ;
<slangasek> ;)
<maxb> hm, this surprises me
<maxb> Ugh, the importer has really made a mess of plymouth
<slangasek> maxb: well, it seems to be easy enough for me to revert by just dropping the latest commit ;)
<maxb> slangasek: yeah, I've done that on the precise branch. Now working on the oneiric branch
<slangasek> maxb: cheers
<maxb> urgh, except I can't uncommit from the oneiric branch, due to what I assume is a bug with branch stacking
<maxb> and it's trampled the natty branch too
<bdmurray> are the apt tasks in bug 659438 still necessary?
<ubottu> Launchpad bug 659438 in apt (Ubuntu) "Installation/Removal fails because of package which could not be located (failure in apt.Cache.required_download)" [High,Triaged] https://launchpad.net/bugs/659438
#ubuntu-devel 2012-04-11
<smoser> slangasek, still around ?
<smoser> i'm asking about e2fsprogs again.
<slangasek> smoser: heya
<smoser> hey.
<smoser> i was about to go to bed.
<smoser> whats up?
<slangasek> smoser: you had a question :)
<smoser> e2fsprogs
<smoser> bug 978912
<ubottu> Error: Launchpad bug 978912 could not be found
<smoser> oops
<smoser> bug 978012
<ubottu> Launchpad bug 978012 in e2fsprogs (Ubuntu) "Please merge e2fsprogs 1.42.2-2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/978012
<smoser> theres a merge conflict in code that you added (i think) otherwise i'd have a mp for you... but basically i think we should take that.  the upstream seems to know a thing or two about ext[234]
<infinity> Doesn't every changelog entry of Ted's urge people to upgrade as soon as possible?
<smoser> well, generally, people do care about their data
<infinity> Oh, I didn't scroll down and see his rationale. ;)
<smoser> :)
<slangasek> smoser: sure, he knows a few things about ext*, but that doesn't mean the new upstream versions are automatically low risk
<slangasek> as for the mp, which code is conflicted?
<smoser> i agree.
<smoser> slangasek, yeah. i didn't go looking for udpates, but was looking for something unrelated and checked to see if it was in latest upstream and saw the update.
<smoser> thats about all i know about e2fsprogs. so i opened bug and asked hopefully people who have more experience there.
<smoser> conflict is http://paste.ubuntu.com/924295/
<slangasek> that's odd, neither of those lines looks like mine :)
<slangasek> I changed the Build-Depends, but those aren't reflected in that paste
<infinity> That may be the first time I've seen a control file in m4.
<infinity> I hope it's the last.
<slangasek> what a sheltered life you've led
<infinity> And I'm happy for it.
<infinity> Don't tell me about none of them moving pictures neither.
<slangasek> dear firefox, when I asked you to die in a fire, I did not mean to suggest you should use my cpu as fuel for your pyre.
<infinity> killall -w firefox && firefox <-- Run every hour when you take a coffee break.
<RAOF> cjwatson: Hey, is there anything special needed to upload grub-gfxpayload-lists?  Bug #971204 would be good to fix, and the lists should be safe to update at this stage, right?
<ubottu> Launchpad bug 971204 in linux (Ubuntu) "graphics fails with setgfxpayload=keep, AMD Radeon" [Medium,Confirmed] https://launchpad.net/bugs/971204
<FourDollars> Setting up whoopsie (0.1.27) ...
<FourDollars> dpkg: error processing whoopsie (--configure): subprocess installed post-installation script returned error exit status 1
<FourDollars> But whoopsie is not listed on http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<slangasek> that's not the sort of problem tracked by that page
<FourDollars> What is precise_probs.html used for?
<slangasek> showing whether the dependencies of packages are satisfiable in the archive
<FourDollars> I see. Thx.
<slangasek> the failure you're seeing at install time is probably bug #978502
<ubottu> Launchpad bug 978502 in whoopsie-daisy (Ubuntu Precise) "whoopsie.postinst crashes silently if /var/crash is missing" [High,New] https://launchpad.net/bugs/978502
<FourDollars> Yes, thx a lot. :)
 * FourDollars is blocked by this bug now. :(
<StevenK> FourDollars: You can edit the postinst directly to unblock yourself.
<FourDollars> StevenK: Yes, that is a good idea. :D
<pitti> Good morning
<mvo> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise: UI and feature freeze  Archive: frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dholbach> good morning
<cjwatson> RAOF: nothing special
<RAOF> cjwatson: Good.  I'll get the reporter to check that I've got the pciid match right, and post the debdiff if you'd like.
<cjwatson> RAOF: as far as I'm concerned, that package is handed over to graphics people who have a clue what's supposed to be in the lists
<cjwatson> I split it off from grub2 partly so I wouldn't have to be a bottleneck on it - so please just go ahead :)
<RAOF> Ok, cool.
<cjwatson> ev: when you're around, bug 978502 needs urgent attention, since it caused more image build failures overnight
<ubottu> Launchpad bug 978502 in whoopsie-daisy (Ubuntu Precise) "whoopsie.postinst crashes silently if /var/crash is missing" [High,Confirmed] https://launchpad.net/bugs/978502
<ev> on it now
<cjwatson> thanks
<doko> seb128, could you have a look at bug 949823? what needs to be done to register .jnlp files with javaws?
<ubottu> Launchpad bug 949823 in icedtea-web (Ubuntu) "icedtea-netx should handle jnlp mime type" [Medium,Confirmed] https://launchpad.net/bugs/949823
<ev> cjwatson: uploaded as 0.1.28
<cjwatson> ev: ta
<jibel> doko, do you think bug 925218 could be SRUed to Oneiric ? It's causing problems in the lab when jenkins and kvm runs on the same server.
<ubottu> Launchpad bug 925218 in openjdk-7 (Ubuntu) "Crash in java.net.NetworkInterface.getNetworkInterfaces() when ifr_ifindex exceeds 255" [Undecided,Fix released] https://launchpad.net/bugs/925218
<doko> jibel, sure
<jibel> doko, thanks. I'll do the nomination than
<seb128> doko, can you pastebin a "gvfs-info somefile.jnlp" where somefile.jnlp is a real file in that format?
<doko> seb128, http://paste.ubuntu.com/924600/
<seb128> doko, gvfs-mime --query "application/x-java-jnlp-file"
<doko> $ gvfs-mime --query "application/x-java-jnlp-file"
<doko> Default application for 'application/x-java-jnlp-file': firefox.desktop
<doko> Registered applications:
<doko> 	firefox.desktop
<doko> 	icedtea-netx-javaws.desktop
<doko> 	thunderbird.desktop
<doko> 	chromium-browser.desktop
<doko> 	gedit.desktop
<doko> 	emacs23.desktop
<doko> Recommended applications:
<doko> 	icedtea-netx-javaws.desktop
<seb128> doko, the recommended one is icedtea-netx-javaws.desktop weird that default is firefox
<seb128> doko, grep "application/x-java-jnlp-file" ~/.local/share/applications/*
<seb128> oh, tjaalton reported that bug :p
<seb128> tjaalton, ^ same questions for you
<doko> seb128, no output
<seb128> I guess I will install icedtea-netx to have a look
<tjaalton> seb128: http://paste.ubuntu.com/924606/ rest is the same as for doko
<seb128> tjaalton, doko: can one of you add a jnlp to the bug?
<seb128> or an url to download one?
<tjaalton> I can do that
<seb128> tjaalton, thanks
<tjaalton> seb128: done
<seb128> tjaalton, thanks
<seb128> tjaalton, doko: I don't understand the bug, seems an issue on the xdgmime,glib,gvfs side, I'm trying to check with upstream
<seb128> tjaalton, doko: not sure why it doesn't pick the recommended application to be default
<jibel> mvo, there are many users reporting that synaptic lost its translation in Precise
<seb128> jibel, wasn't that fixed yesterday?
<seb128> synaptic (0.75.9) unstable; urgency=low
<seb128>   * generate synaptic.pot during the package build to really enable
<seb128>     langpack support
<seb128> jibel, I guess it will need another langpack export to pick the translations back though
<jibel> seb128, I don't know in bug 978738 the reporter says it occurred with the latest update (0.75.9)
<ubottu> Launchpad bug 978738 in synaptic (Ubuntu) "synaptic is not localized anymore since 0.75.9 version update" [Undecided,New] https://launchpad.net/bugs/978738
<seb128> jibel, right, you need a langpack export
<Riddell> Daviey: when I get user support questions in #kubuntu that are server questions, where do I send them?
<Daviey> Riddell: #ubuntu-server
<Riddell> Daviey: that's user support and development?
<Daviey> Riddell: yah.. shared space currently
<Riddell> thanks
<mvo> pitti: can you help me with https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/978738 ? is that just transitional until the next langpack update?
<ubottu> Launchpad bug 978738 in synaptic (Ubuntu) "synaptic is not localized anymore since 0.75.9 version update" [Undecided,New]
<pitti> mvo: was that marked with X-Ubuntu-Langpack: ?
<pitti> mvo: indeed; I followed up in the bug
<pitti> mvo: YAFIYGI :)
<mvo> pitti: thanks, when is the next export scheduled?
<pitti> mvo: we got one yesterday (automatic update)
<pitti> mvo: usually twice a week
<mvo> ok
<mvo> thanks!
<pitti> mvo: we'll build the final packs on Apr 18
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise: UI and feature freeze  Archive: frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
 * dholbach hugs mdeslaur
 * mdeslaur hugs dholbach
<dholbach> :)
<herton> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise: UI and feature freeze  Archive: frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: herton, mdeslaur
<hallyn> slangasek: (haven't tested it yet but) thanks for fixing the vt7 handover bug :)
<smoser> cjwatson, i am not looking for a real solution, but wondered if you might have thoguhts on how i could hack it.
<smoser> during an install of server from mini-iso, we often get squid proxy errors . we know the root cause of those and are looking to fix them.
<pitti> ev: thanks for the updated permanent sandbox branch! merged nwo
<smoser> but one work around would be to get apt and wget to send the header " Cache-Control: max-age=0"
<ev> pitti: yay, thanks!
<smoser> in early command we could convince apt to do that, but at that point, debootstrap has already downloaded and got inconsistent data.
<smoser> (and failed)
<pitti> ev: I'll add support for that to crash-digger, too
<ev> awesome
<pitti> ev: I take it you don't use crash-digger in the whoopsie env?
<smoser> i'm wondering if there would be a dirty way to hook into the installer early enough to affect debootstrap. (i'm realizing now that maybe debootstrap doesnt run in installer, but i thought it did.) or, if its not debootstrap,then whatever it is that does the initial apt metadata download.
<cjwatson> debootstrap does run in the installer.
<ev> pitti: nope, as what we need there is mostly Cassandra code: http://bazaar.launchpad.net/~ev/whoopsie-daisy/trunk/view/head:/backend/process_core.py
<ev> well, that and AMQP
<cjwatson> There aren't really any particularly relevant hooks.  I guess you could hack it with sed -i in a partman/early_command hook.
<cjwatson> Sounds like we ought to add an option to debootstrap to do this, though.
<cjwatson> The neatest hack might actually be, in partman/early_command, move wget to wget.real and replace wget with a script that runs wget.real with the right options.
<smoser> cjwatson, that was my thought.
<smoser> but i was not aware of partman/early_command.
<smoser> and yes, instlaler option would be nice.
<smoser> but i did not consider that an option at this point.
<cjwatson> Hmm.  I don't think our busybox wget configuration supports adding extra headers right now.  You might have to 'anna-install wget-udeb'.
<cjwatson> no, agreed
<smoser> right.
<smoser> still hackable.
<smoser> thanks, cjwatson .
<cjwatson> partman/early_command runs at the start of the partitioner; its main virtue for this is that it runs after all installer components have been retrieved, so you can run sed over stuff in the knowledge that it actually exists.
<smoser> we're chasing the real for this particular issue in RT 52121.
<smoser> cjwatson, wow. 'busybox wget' shows '--header' flag on precise
<cjwatson> oh ok
<cjwatson> smoser: the udeb configuration is different
<cjwatson> $ grep WGET_LONG_OPTIONS debian/config/pkg/{deb,udeb}
<cjwatson> debian/config/pkg/deb:CONFIG_FEATURE_WGET_LONG_OPTIONS=y
<cjwatson> debian/config/pkg/udeb:# CONFIG_FEATURE_WGET_LONG_OPTIONS is not set
<cjwatson> so 'busybox wget' in a real system isn't an accurate guide
<smoser> booo!
<smoser> but thanks. i just assumed it would =. thanks.
<nemo> So, my mom uses Ubuntu One a lot
<nemo> has relied on it for quite a while for note taking, and has built up an extensive number of notes. Hundreds?
<nemo> Just wanted to say I'm a little disappointed w/ you guys for pulling a Google and just killing off a service that people had become dependent on.  You'd think you could at least just hide it for people who aren't using the notes sync :(
<nemo> you know.  do it a bit more slowly
<nemo> or. Maybe, and Google at least does this, give like a 6 month warning period so people can try to find an alternate service without something they rely on vanishing
<nemo> and, yeah, I know that Ubuntu One tomboy sync still works, but without the ability to access notes from work, she's crippled.
<nemo> So now I'm reading the API trying to figure out how hard it would be to reimplement a subset of the functionality you removed :(
<dholbach> nemo, you could try to ask in #ubuntuone
<nemo> ah. figured all the ubuntu devs worked as one hive mind :-p
<apw> cjwatson, so the lts-backport-maverick kernel will be dropping off support with the EOL of maverick proper; this leaves people with that kernel in a bit of a hole.  we'd like to offer them the to either stay where they are, or upgrade to the natty or oneiric lts backports.  is there a clean way to do such things?
<nuclearbob> can anybody help with with a complicated packaging question?
<apw> nuclearbob, i am sure there is someone, but the right someone won't know they are unless you ask
<nuclearbob> apw, I'd like to build two architecture independent binary packages from one source package, and embed one package inside the other
<nuclearbob> I've got a client/server sort of thing, and I'd like to be able to easily install the client from the server
<directhex> "embed one package inside the other" ?
<apw> so you want to include the client.deb as a file inside the server.deb?
<nuclearbob> yes
<dholbach> could the server depend on the client package? :)
<nuclearbob> yes, if necessary
<apw> dholbach, i think he wants the package as a .deb and not installed
<nuclearbob> ideally
<nuclearbob> but if the best way to do it is a dependency, I can try that
<dholbach> apw, I just mentioned it because that's quite straight-forward to do :)
<roaksoax> jdstrand: ping
<nuclearbob> right now the server Provides the client, since the server is a superset of the client functionality
<jdstrand> roaksoax: ?
<apw> dholbach, heh indeed indeed ...
<slangasek> hallyn: you're welcome :)
<roaksoax> jdstrand: i'm working on bug #975436 and I was wondering if you have a good example of how user/group should be created
<ubottu> Launchpad bug 975436 in maas (Ubuntu Precise) "please run maas-pserv and maas-txlongpoll as non-root" [High,New] https://launchpad.net/bugs/975436
<roaksoax> jdstrand: i.e. following http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s-bpp-lower-privs or, as I have seen in many packages, just creating it in postinst without too much code
<jdstrand> roaksoax: otoh libvirt
<roaksoax> jdstrand: cool, will look at it. Thanks
<jdstrand> np
<cjwatson> apw: I'm not sure, really; you could turn it into a dependency-only transitional package, but that doesn't really give people a choice
<cjwatson> apw: perhaps a NEWS.Debian entry for those people who read such things via apt-listchanges
<apw> cjwatson, could we add like a new 'ticky' like you get with exim 'stay with this final kernel/natty/oneiric'
<cjwatson> apw: you're talking a lot of packaging complexity there
<apw> cjwatson, yeah ... i thought you'd be saying that
<cjwatson> I'm wary of that kind of thing when it's *only* going to be tested by a subset of LTS users
<cjwatson> we don't get to try it out in precise first
<apw> no indeed true
<apw> cjwatson, tricky -security would like us to just upgrade them to the natty or later lts, we're rather wary of that as it s a big jump without some kind of warning
<tjaalton> any ideas about a user having "iconv: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory" fail during package updates?
<jdstrand> it is hard to predict what is riskier
<jdstrand> there is risk associated with upgrading, but in my mind, they signed up for it when going with an 18 month lts kernel
<jdstrand> and while most kernel CVEs of late may not be mind-blowing horrible, that doesn't mean that next week/month/year there won't be one
<jdstrand> s/18 month lts kernel/18 month lts backport kernel/
<jdstrand> in fact, it was my understanding that they would have an upgrade path. I may have just been assuming though...
<jdstrand> apw: ^
<jdstrand> and, they opted into it
<jdstrand> if they opted into it, they can probably adjust grub and look at the changelog
<apw> jdstrand, all true
<jdstrand> and if it is on a server, a responsible admin should be looking at the changelog
<jdstrand> before blindly upgrading
<apw> i suspect its those ones where its actually on desktop installs which will wail.  but that also is not necessarily a problem
<jdstrand> it is also not supported
<jdstrand> (for lucid)
<apw> indeed
<jdstrand> so we get to test what happens here before infliciting... err.. applying these updates to precise users
<jdstrand> (not supported for lucid desktop, just to be clear)
<cjwatson> so in that case I guess make the maverick metapackages start depending on the natty ones?
<rbasak> cyphermox: I have a fix for the amd64 ical ftbfs. How's arm coming along?
<cyphermox> not really much further yet, but I'm testing something I'll be able to tell you in 53%.
<rbasak> cyphermox: ok, I've attached a debdiff to bug 978862
<ubottu> Launchpad bug 978862 in libical (Ubuntu) "libical FTBFS on amd64" [High,In progress] https://launchpad.net/bugs/978862
<cyphermox> rbasak: ok, thanks
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise: UI and feature freeze  Archive: frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: herton
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise: UI and feature freeze  Archive: frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: herton, infinity
 * dholbach hugs infinity :)
<arges> infinity, hello. trying to get a package into lucid-backports, haven't seen any activity on it, and not sure what needs to be done.
<infinity> arges: Bug number?
<arges> infinity, ah sure. lp#968612
<infinity> arges: Ahh, I'm not entirely sure what the process is for backports-with-changes, but I'll look this up after coffee and we'll make this work. ;)
<arges> infinity, thanks!
<infinity> (My guess is that the process is me just uploading to backports, but I generally never deal with backports, to educational fun for all)
<ScottK> infinity: The process (loosely) is ubuntu-backporter approves, ubuntu-dev uploads, someone with powerz accepts.
<micahg> arges: sorry, meant to look at that last night, do you need a backport package to do the runtime tests?
<infinity> ScottK: Well, I'm two out of three of that pipeline, I guess I need the first. ;)
 * ScottK looks over at micahg.
<infinity> And micahg's the first.
<infinity> Yes.
<infinity> micahg: If you're on top of this, I'll go pilot other things after my coffee. ;)
<micahg> infinity: yeah, it's not an easy backport though :)
<infinity> micahg: It's not?  The diff looks trivial.
<arges> micahg, yea, when I ran the backportpackage tool it had quite a bit of tests to run
<arges> which i wasn't sure how to run those
<infinity> micahg: Although, if there's a valid reason for the db4.8 versioned build-dep, it might be less scary to backport that too...
<infinity> micahg: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588969 FWIW.
<ubottu> Debian bug 588969 in slapd "slapd 2.4.23-1 fails to start with libdb4.8 4.8.26-1" [Important,Fixed]
<doko> zul, swift ftbfs
<zul> doko: 1.4.8-0ubuntu1?
<micahg> infinity: thanks :)
<doko> zul: yes, https://launchpad.net/ubuntu/+source/swift/1.4.8-0ubuntu1/+build/3396611
<infinity> doko: A new versionw as already uploaded.
<infinity> zul: Although, really?  Just disabling the test suite? :/
<infinity> zul: Also, what's "temporamental"?  Is the test suite travelling through time? ;)
 * ogra_ wipes the coffee off the kbd
<zul> infinity:  swift testsuite assumes that you have like /dev/log /dev/sda, not building in a chroot
<infinity> Every test assumes that?
<zul> a large chunk of them
<infinity> Erm.
<infinity> Ran 1027 tests in 20.421s
<infinity> FAILED (failures=4, errors=48, skipped=191)
<infinity> I'd say the larger chunk of them work just fine.
<infinity> And disabling the 4 that throw the 48 errors wouldn't be hard?
<infinity> Some old adage about babies and bathwater.
<infinity> We like babies.
<zul> infinity:  a large chunk has already been disabled/skipped because of issues with building it in the buildds
<zul> er...running the tests in the buildds
<infinity> Yes, that would be the 191.
<infinity> With 1027 still remaining.
<infinity> And only a few of those failing.
<infinity> I'm not sure why you'd give up now and declare the suite not worth running.
<zul> because i already spent alot of time getting it to run in 1.4.7
<infinity> ...
<infinity> "I made it work in the past, so never again"?
<ogra_> tests are for whimps anyway
<zul> ok im fine with you rejecting it then
<infinity> I'm just saying.  Downalod a build log, grep for 'ERROR:', obtain list of broken tests, double-check in log that they're breaking due to doing Stupid Things, disable.
<infinity> You could even skip the middle part, and it would still be better than disabling the whole suite.
<infinity> (Though, please don't skip the middle part, one or more of the tests could be failing legitimately?)
<infinity> (Which is kinda the point of running a test suite...)
<zul> infinity: right but having it worked before in 1.4.7 and and spending x number of hours on my day off,  testing the build before getting a FFE uploading and having the testsuite fail on some random place in the buildds is a bit frustrating
<infinity> zul: You could make it fail exactly the same place at home.  The buildds aren't special.
<zul> infinity: but it didnt fail there
<infinity> zul: If you're bindmounting /dev in your build chroots, don't.  Environment reproduced.
<zul> infinity: k ill do that next time at least
<doko> ev, do you understand https://launchpadlibrarian.net/101340308/buildlog_ubuntu-precise-armhf.whoopsie-daisy_0.1.28_FAILEDTOBUILD.txt.gz ?
<ev> doko: nothing jumps out. I'll have a look tomorrow.
<infinity> doko: Looks like something went goofy with the build.
<infinity> doko: debian/changelog disappeared...
<doko> infinity, did give it back. it's repeatable
<infinity> Okay, debian/changelog was never created? :)
<infinity> There's a new one in the queue.
<slangasek> bdmurray: I wonder if we should have a bug pattern to treat all package install failures of flashplugin-installer (<< 11.2.202.228ubuntu2) and ttf-mscorefonts-installer (<< 3.4ubuntu3) as dupes of 876298
<bdmurray> slangasek: I'll have a look into how many there are etc...
<slangasek> bdmurray: at least 3 more came in after the upload to precise due to the new version pushed to all releases
<slangasek> bdmurray: oh, though that does mean a version check is insufficient... since the upstream version number is bumped as well for previous releases
<slangasek> so probably has to check the distrorelease
<cody-somerville> lmao
<cody-somerville> I find it funny that 'whoopsie' broke all PES's image builds last night, lol.
<ev> cody-somerville: you're welcome
<ev> :-P
<adam_g> how does one go about getting the ubuntu recommender updated after a binary has moved to another package?
<bdmurray> do you mean command not found?
<adam_g> bdmurray: no, i mean an executable has been moved from one binary package to another in the same source package, but reco[Dmmender still reports the original as the suggested package to install
<bdmurray> right command-not-found is the thing that recommends you install a package if you type a command in a terminal
<adam_g> bdmurray: oh, i see
<bdmurray> there is an update-from-web script in the package that I'm pretty sure updates the data
<trijntje> Do different flavours of ubuntu use different installers? I was testing the localisation of different flavors, and not all flavors were equally translated
<doko> slangasek, see who did approve the hardcoding of the path in opensc.conf? ;p
<slangasek> doko: no, who?
<doko> -- Steve Langasek <steve.langasek@ubuntu.com> Thu, 18 Feb 2010 02:52:33 -0800
<slangasek> isn't that just me hard-coding a different path than the one that was there before? :)
<doko> currently looking
<doko> debian doesn't have a hardcoded path
<doko> at least dlopen now finds the library. uploaded
<ahasenack> hi, is someone from the sru team here? Could I interest you in reviewing #978884 ?
<bdmurray> slangasek: so for precise you'd like the pattern to match a version less than
<bdmurray> 11.2.202.228ubuntu2 - correct?
<slangasek> bdmurray: for flashplugin-installer, yes
<bdmurray> slangasek: right and apport uses re for the patterns
<ahasenack> hi, is someone from the sru team here? Could I interest you in reviewing #978884 ?
<slangasek> bdmurray: right; so in that case, we can probably omit precise entirely from the bug battern
<slangasek> pattern
<slangasek> since there shouldn't be too many more reports coming in against old versions
<bdmurray> okay, works for me
<seb128> infinity, can you kill https://launchpad.net/ubuntu/+source/gnome-keyring/3.2.2-2ubuntu3/+build/3393735 ?
<seb128> it's hanging in the testsuit again :-(
<bdmurray> seb128: what are the chances of bug 942539 getting fixed for precise?
<ubottu> Launchpad bug 942539 in nautilus (Ubuntu) "Ubiquity desktop icon text looks messy" [Medium,Triaged] https://launchpad.net/bugs/942539
<seb128> bdmurray, correctly fixed in nautilus? 1%
<bdmurray> seb128: okay, I was trying to determine if we should hack around it
<seb128> you probably want to workaround it by changing the name adding a return char or something
<infinity> seb128: Yeah, I think our brilliant plan was to try to find a unicode replacement for '.' that looked passably okay but didn't cause a line break. :P
<seb128> infinity, what about the build I pinged you about just before? ;-)
<infinity> seb128: Relayed to webops.
<seb128> infinity, thanks
<seb128> infinity, I though you could do that sort of stuff, dunno why
<seb128> infinity, I'm disappointed
<infinity> seb128: That was the old me, this is the new me.
<seb128> infinity, your new you is boring
<infinity> Ouch.
<seb128> ;-)
<infinity> I think the next eglibc upload might involve some special casing if euid=seb128 ...
<seb128> hum, my turn to say "ouch"?
<seb128> infinity, in some way you still have too much power :p
<infinity> ;)
<ScottK> doko: Would you please fix your strigi upload (it FTBFS)?
<doko> ScottK, it did ftbfs before as well. so if you can tell me what's wrong, then yes
<ScottK> So you uploaded it knowing it FTBFS?
<ScottK> Sigh.
<janimo> ScottK, not sure about strigi but I definitely uploaded more than once knowing it is a FTBFS, in case I had a patch that made the build progress to the next FTBFS spot and fixed the original one
<ScottK> There are certainly cases where this is necessary.
<herton> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise: UI and feature freeze  Archive: frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<doko> ScottK, bullshit. I did see the build failure, tested the fix on armhf, and then did the merge
<ScottK> It wasn't a hard fix.
<jtaylor> doko: why do we have 2 argparse providers again?
<jtaylor> that breaks my builds again ..
<doko> jtaylor, which ones?
<jtaylor> doko: python2.7 2.7.3-0ubuntu1 python 2.7.2-9ubuntu6
<bdmurray> slangasek: so bug 942539 appears fixed but I see no clear indication why
<ubottu> Launchpad bug 942539 in nautilus (Ubuntu) "Ubiquity desktop icon text looks messy" [Medium,Triaged] https://launchpad.net/bugs/942539
#ubuntu-devel 2012-04-12
<slangasek> bdmurray: curious - maybe it's fixed by the freetype upload which changes various bits surrounding font metrics
<roaksoax> jdstrand: still around?
<jdstrand> roaksoax: yes
<ScottK> micahg: Did you ever get a chance to look into blueman?
<roaksoax> jdstrand: quick question about creating a user for MAAS.
<roaksoax> jdstrand: so the daemons already run as 'maas' user, WSGI for MAAS code also runs as 'maas' user. Do we need to create a home dir for the user? or can we not have a home dir?
<micahg> ScottK: not yet
<jdstrand> roaksoax: if it doesn't need a home dir, then no. You can specify /nonexistent as the home dir, but be sure to use --no-create-home
<ScottK> OK
<roaksoax> jdstrand: awesome, thanks
<jdstrand> np
<micahg> ScottK: blueman needs a merge, but the dh_python2 conversion was wrong, I'll file a Debian bug
<micahg> they also transitioned to python-gi
<ScottK> Thanks.
<jsjgruber-x-p> I'm trying to build an app for my ppa that won't build on launchpad, but does with pbuilder-dist lucid . It has a  build-depends as follows:
<jsjgruber-x-p> Build-Depends:
<jsjgruber-x-p>  debhelper (>= 6),
<jsjgruber-x-p>  python,
<jsjgruber-x-p>  python (>= 2.6.6-3~) | python-support
<jsjgruber-x-p> it doesn't build because it can't get the  python without trying to get the python-support instead. Is what I want reasonable?
<micahg> jsjgruber-x-p: #ubuntu-packaging is better for random PPA build failures
<jsjgruber-x-p> ok, thanks
<infinity> @pilot out
* infinity changed the topic of #ubuntu-devel to: Precise: UI and feature freeze  Archive: frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<msvb> Morning folks.
<pitti> Good morning
<ajmitch> morning pitti
<RAOF> Morning pitti
<astraljava> Hi gang, I'm trying to sort out our (Studio) bzr branches in better shape, and Micah kindly pointed out some errors with fields in debian/control. What's the proper URI for Vcs-Bzr field? Should it be 'lp:ubuntustudio-default-settings', 'lp:~ubuntustudio-dev/ubuntustudio-default-settings/UbuntuStudio' or the long form
<astraljava> 'https://code.launchpad.net/~ubuntustudio-dev/ubuntustudio-default-settings/UbuntuStudio'?
<infinity> astraljava: Most seem to use the http:// URI.
<astraljava> infinity: Ok, I'll fix ours to comply with that, then. Thank you!
<smoser> anyone seen this ?
<smoser> walking through installer from yesterday's iso
<smoser> it just hang as soon as i enter the user info and hit continue
<smoser> (i did have encrypted home)
<smoser> er.. did select.
<smoser> walking through installer from yesterday's iso
<dholbach> good morning
<dholbach> RAOF, happy birthday! :)
<msvb> Happy birthday RAOF.
<micahg> what's supposed to replace pcretest in the new multiarch pcre3 packages (this was dropped 2 releases ago)?
<RAOF> dholbach, msvb: Thanks.
<slangasek> micahg: why do you need a replacement?
<micahg> slangasek: I've got package testing for UTF-8 support in PCRE
<slangasek> ah
<slangasek> can you just bundle the source as part of your test?
<slangasek> or put it in the pcre package's own build-time test suite?
<micahg> of the pcretest script?  probably
<slangasek> (cf. the original bug report requesting pcretest, bugs.debian.org/162998)
 * micahg wonders why this works in Debian
<infinity> micahg: Sure.
<infinity> So.
<infinity> Why did GLIB drop that feature, or is the test for it just broken?
<infinity> Cause either that's a glib regression, or goffice is doing something stupid.
<infinity> (Or is it a bug and not a feature that it's looking for?  But then it wouldn't make sense to include pcre if glib isn't buggy?)
<infinity> Confusing.
<micahg> hmm, according to the docs it should be there
<micahg> ah, it's the include most likely has changed
<infinity> micahg: Could it... Yeah.
<infinity> micahg: I was just about to suggest single include madness.
<doko> pitti, ping
<pitti> hello doko
<infinity> micahg: I bet <glib/gregex.h> throws errors.
<doko> pitti, the jockey-gtk crash did hit me yesterday
<pitti> what is "the" jockey crash?
<pitti> doko: is there a bug # for this with details?
<doko> pitti, bug 804662
<ubottu> Launchpad bug 804662 in jockey (Ubuntu) "jockey-gtk crashed with TypeError in _execute_child(): execv() arg 2 must contain only strings" [High,Fix released] https://launchpad.net/bugs/804662
<jamespage> @pilot in
<pitti> doko: can you please file it again? it seems to be a slightly different crash
<micahg> infinity: /me bangs head on desk (I forgot to try a rebuild :), was the single include nonsense)
<jamespage> hmm - guess the bot knew that I'm actually piloting tomorrow
 * jamespage goes for more coffee
<Riddell> < Riddell> shell scriptage help needed: http://paste.kde.org/456044/
<Riddell> that breaks on first line if more than one .pot file exists
<Riddell> how do I get it to test for .pot file existing without breaking on more than one?
<bryceh> Riddell, wouldn't   for file in po/*pot; sed "s/charset...   work?
<slangasek> only if you set shopt nullglob
<slangasek> if no files match po/*pot, you try to sed a file literally named "po/*pot"
<slangasek> Riddell: for file in po/*pot; do if [ "$file" != 'po/*pot' ]; then sed [...]; fi; done
<jussi> so patch pilot bot is missing because the  srever went down yesterday for some unkown reason. I need tsimpson to resstart that one (and tell me how to do it), so whoever the patch pilot today is, please adjust the topic manually.
<Riddell> bryceh: not if the directory is empty
<jussi> jamespage: could you direct my earlier comment to whomever is the patchpilot today?
<bryceh> ls -l po/*pot 2> /dev/null && for file in po/*pot; do echo $file ; done
<Riddell> if [ "$(ls -A po/)" ]; then  this seems to do it nicely
<Riddell> every time I use bash I end up wanting to rewrite in python :)
<slangasek> ah, but that's not bash
<slangasek> if you were using bash, you *could* do shopt nullglob, and then you wouldn't have to check ;)
<smoser> hey, i'm trying to run the installer (several times now) on a new laptop
<infinity> if [ "$1" = deconfigure ]; then
<infinity>     :; # blah, do something useful with ldso
<infinity> fi
<smoser> when i come to the point of adding a new user.
<infinity> This is why I shouldn't read other people's maintainer scripts...
<smoser> as soon as i click continue, ubiquity goes to 100% cpu
<smoser> i'm choosing a separate /home partition and to format it.
<smoser> is this  known?
<RAOF> smoser: Are you perhaps running into bug #966294?
<ubottu> Launchpad bug 966294 in ubiquity (Ubuntu Precise) "Ubiquity loops forever from ubiquity_webcam_play" [High,In progress] https://launchpad.net/bugs/966294
<smoser> RAOF, that could be
<smoser> RAOF, thank you!
<smoser> i removed the ucvideo.ko module
<smoser> (and then rm'd it for good measure)
<smoser> and i'm moving on
<pitti> Riddell:
<pitti> +if [ "$(ls -A po/)" ]; then
<pitti> Riddell: I think it would be more robust to use [ -n "$(ls ..)" ]
<pitti> Riddell: also, there seems to be a missing "fi" in http://launchpadlibrarian.net/101498692/pkg-kde-tools_0.14.2ubuntu4_0.14.2ubuntu5.diff.gz ?
<Riddell> pitti: fix uploaded
<Adri2000> where can I find old isos? (specifically I'm looking for precise beta 1 isos)
<Adri2000> (tried old-releases.u.c but it doesn't have precise isos)
<cjwatson> Adri2000: we archive them to tape I think, but they aren't available anywhere public (or even easily Canonical-accessible)
<jibel> pitti, how much memory is required to setup the virtual device in udisks test ? The test fails with 'cannot allocate memory' when modprobing scsi_debug. The highest dev_size_mb I could set with 2GB of virtual memory was 112
<pitti> jibel: that's a good question, I'm not really sure about it
<pitti> jibel: I would expect that 2.5 GB should be enough then, as it requests 300 MB
<Adri2000> cjwatson: argh :/ ok... (wanted to debug an X regression post beta 1, would have been useful in order to track down the culprit packages)
<jibel> pitti, ok, I'll start with 2.5 and increase until it passes.
<pitti> jibel: merci
<pitti> jibel: I'm preparing a new udisks uplaod with the missing dependencies
<jibel> pitti, ok, thanks. postgresql test failed but it looks like a bug in autopkgtest which expand '+' to '%2B' in the package name
<pitti> yeah, I wondered about that, it didn't even get to the tests there
<cjwatson> yay, precise-adt-ubiquity passed
<stgraber> cool!
<sam-c> hello devs
<pitti> jibel: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-adt-upower/lastSuccessfulBuild/ looks weird -- did that succeed actually, or was this a test environ failure?
<sam-c> when does beta 12.10 start?
<cjwatson> sam-c: https://wiki.ubuntu.com/QReleaseSchedule
<GirlyGirl> sam-c: Its release schedule isn't finalised yet
<cjwatson> the details haven't; you can reasonably expect it not to be too far off the above wiki page though, maybe with a week or two's shift here and there
<jibel> pitti, it succeeded but publication to the public jenkins is slow
<pitti> jibel: ah, I see; great to see it works now!
<jibel> so it syncs results from the parent job first then children jobs many minutes later
<sam-c> thanks lets hope 12.04 is a success!
<pitti> jibel: nice, it's there now
<doko> infinity, will you address bug 929219 before the release?
<ubottu> Launchpad bug 929219 in eglibc (Ubuntu Precise) "chromium-browser, gvfsd-http and others using eglibc crash with SIGSEGV in __nscd_get_mapping() or gethostbyname2_r()" [High,Triaged] https://launchpad.net/bugs/929219
<infinity> doko: Yeah, testing an upload now.
<infinity> doko: Just getting a few more fixes in at the same time.
<doko> thanks
<ev> Am I going blind or is there no mapping (via python-apt) from a package in the cache to the path in /var/apt/cache/archives?
<mvo> ev: there is no obvious one, iirc you need to create a acquire object, load the package into it and then you can get it via the destfilename :/
<ev> ow
<mvo> give me a sec (or some more and I can try to create a short example)
<ev> mvo: cheers
<ev> (background: I'm trying to see if any Conflicts or Replaces are already in /var/cache/apt/archives)
<mvo> I'm not sure I understand, why is this relevant? I guess its something with ubiquity :) ?
<ev> it looks like apt.apt_pkg.parse_depends(candidate.record['Conflicts']) will get me half way there, then presumably apt.apt_pkg.check_dep() with the destfilename version parsed out?
<ev> mvo: apport-retrace speedup...
<ev> mvo: https://code.launchpad.net/~ev/apport/reunpack_to_sandbox/+merge/101643 - we unpack the debs we need for retracing to a sandbox using dpkg -x. With my speedup change we cache this sandbox between runs.
<ev> But now we need to be careful to handle replaces/depends and virtual packages therein
<ev> oh and handling that is easy enough for the simple case. But when the Replaces and Conflicts packages have versions, then I need to parse that out (using parse_depends I guess, as above) and compare that against something in /var/cache/apt/archives - and this is where I'm stuck :)
<mvo> ev: I see, interessting! here is a small example http://paste.ubuntu.com/926289/
<mvo> ev: fetcher.items should always only have 1 entry with this code (auto_fix and auto_inst false) so the loop is not really needed
<glenn> lo
<ev> mvo: is there anything in python-apt that would then rip the version out of that path? So if I was trying to get the versions of all the packages in /var/cache/apt/archives
<ev> I dug around and didn't see anything
<Guest64148> how can i make sure that my package build from, would also use my dependency package from source?
<glenn__> how can i make sure that my package build from source, would also use my dependency package from source?
<glenn__> its a deb file on my hd
<glenn__> is that easy? :)
<glenn__> only thing im finding is the control file
<pitti> apw: do we still need the bcm43xx stuff, given that we automatically install wl these day?
<pitti> s
<jamespage> does the data in the command-not-found-data package normally get updated just before release?
<apw> pitti, not sure they 100% overlap to be honest
<pitti> jamespage: yes, usually before every milestone
<jamespage> pitti, thought that was the case.
<pitti> apw: ah, that was it: https://launchpad.net/ubuntu/+source/linux-firmware/1.77
<pitti> apw: /lib/firmware/phanfw.bin is the biggest file in it (1.8 MB), so that caused quite some growth
<pitti> anyway, I suppose we can't just drop that, but at some point we need a way to split that into smaller packages
<pitti> in 12.10 we'll get bigger images, but we need to squeeze something for 12.04
<apw> pitti, well the problem is they are mostly firmware for things we care about, video, network, camera, that sort of thing
<pitti> yes, I know
<apw> pitti, it is possible that we have some old firmware in here, stuff that can never be loaded
<pitti> right, that's what I thought, hence my question
<apw> pitti, will discuss some potentials for ripping out for now with tim
<pitti> in a 27 MB compressed hog there must be _something_ we can get rid of
<pitti> apw: thanks!
<pitti> I'll have a look at wallpapers
<pitti> sladen: so, wallpapers grew a bit, and by yet unknown means we need to free 1.2 MB
<pitti> sladen: do you want me to shrink down some wallpapers, or do you want to have a look?
<seb128> pitti, it's Cimi who handled that update no?
<pitti> not sure, sladen talked to me about it last
<seb128> ok
<pitti> sladen: e. g. the original Shoes.jpg (1.0 MB) looks exactly the same to my eye as my reduced Shoes2.jpg with 570 kB
<ogra_> micahg, do you care for the lubuntu seeds ? seems audacious is blocking it on armhf and given that nobody seems to be able to fix the gles issue that blocks it i was wondering if you could do an arch specific seed hack to omit the audacious requirement on arm arches for now
<seb128> Cimi, hey
<seb128> <pitti> sladen: e. g. the original Shoes.jpg (1.0 MB) looks exactly the same to my eye as my reduced Shoes2.jpg with 570 kB
<seb128> pitti, ^ meet Cimi, artwork master ;-)
<pitti> Cimi: hello
<Cimi> we both know each other seb128 :)
<pitti> Cimi: so is it you or sladen that I should ask about ubuntu-wallpapers?
<seb128> :-p
<Cimi> pitti, I did the package/compression, sladen uploaded it
<Cimi> pinky, which is the big file to you?
<pitti> Cimi: there is no particular file, I'm just looking at ls -lSr
<pitti> and starting with the biggest one
<pitti> Cimi: trying to reclaim the growth of the latest version
<Cimi> http://paste.ubuntu.com/926344/
<pitti> (assuming that I am pinky)
<Cimi> pitti, they all seem pretty well compressed
<pitti> Sand.jpg compresses less well
<pitti> Cimi: but compressing Shoes.jpg (see above) and perhaps some others would help a lot
<Cimi> pitti, which walls are yoi looking at???
<seb128> pitti, do you look at a different set?
<pitti> apt-get source ubuntu-wallpapers..
<seb128> pitti, there is no shoes or sand in the wallpapers
<Cimi> http://paste.ubuntu.com/926344/
<pitti> ah, we don't ship Shoes in u-w-precise, I see
<seb128> pitti, ubuntu-wallpapers has all the old wallpapers as well but those are not installed by default
<pitti> it's just in the source
<seb128> pitti, they are in i.e -oneiric
<Cimi> u-w is 2.8
<Cimi> less than oneiric
<Cimi> I think I did a great job here
<pitti> Cimi: right, I missed that the source has -oneiric etc.
<pitti> so, any other ideas what we can throw out again?
<Cimi> pitti, we have 2.8 now
<Cimi> pitti, really, how much do you want to shrink here?
<pitti> no, I mean in general, not (just) wallpapers
<pitti> i386 grew by 2 MB since beta-2, and we need to shrink it by 1.2 MB
 * pitti looks at telepathy-salut, that grew by 0.2 MB
<pitti> libreoffice-common grew by 0.6 MB
<pitti> Sweetshark: ^ any idea for a diet?
<Cimi> pitti, ubuntu-wallpapers deb was 2.4MB in oneiric and is 2.4MB in precise
<Cimi> pitti, I did my best to keep the same size
<pitti> Cimi: again, I'm not blaming you for anything
<pitti> Cimi: you did a great job there
<Cimi> pitti, ok
<pitti> I just asked the channel for ideas what we can shrink again :)
<Cimi> pitti, only solution I have is to remove wallpapers
<Cimi> pitti, which works but it's not ideal with the community
<seb128> it's not ideal for Ubuntu users either
<seb128> users like the selection ;-)
<pitti> at this point few things that we can do are "ideal"
<Cimi> seb128, which wallpaper do you like most?
<Cimi> pitti, we're not shipping the gnome wallpapers, right?
 * apw wonders if ubuntu users like to have firmware for their hardware more or less than pretty backgrounds
<apw> pitti, ok we may be able to strip some bnx2 firmware pretty easily but we have near zero way of knowing if thats going to cause problems
<Cimi> apw, I would never sacrifice HW compatibility for stupid walls
<Sweetshark> pitti: hmmm, 3.5.1-1ubuntu5 already seemed to be bigger
<pitti> libreoffice-common (Î 0.6 MB - 3.5.1-1ubuntu1: 20.9 MB   3.5.2-2ubuntu1: 21.5 MB)
<Cimi> maybe libreoffice ships stuff we can compress
<Cimi> pitti, all JPG/PNG can be compressed
<Cimi> even loseless
<Sweetshark> pitti: ha!
<Sweetshark> pitti: it was readding the ugly presentationm templates again!
<pitti> Sweetshark: win!
<Sweetshark> (between 3.5.1-1ubuntu4 and 3.5.1-1ubuntu5)
<pitti> Sweetshark: ah, so that's not the .6 MB from above?
<pitti> oh wait, it could very well be
<sladen> cimi: pitti: wallpapers is ~2.7 MB.  we were 2.5 MB last time, but we snarfed the extra after Kaleo uploaded a u-f-f without shipping Medium
<Sweetshark> yes, it is
<Cimi> sladen, looks like 2.4 from the website
<Sweetshark> pitti: 3.5.2 didnt change from 3.5.1-1ubuntu5 in size.
<Cimi> sladen, unless default wallpaper stais in a separate package from community
<pitti> Sweetshark: that's /usr/lib/libreoffice/share/template/common/layout ?
<sladen> Cimi: yes, default wallpaper is now in u-w, and community wallpapers in u-w-p
<Cimi> sladen, ah ok, found mistake
<sladen> pitti: any new packages, or just bulging at the waist in the existing packaging?
<pitti> sladen: just the latter
<pitti> we added gtk2-engines-pixbuf since beta-2 (0.1 MB)
<Cimi> pitti, I can probably remove the dep from light-themes
<seb128> no you can't
<seb128> it was added for a reason, it spammed xsession-errors with warning without it
<seb128> we still have gtk2 apps
<Sweetshark> pitti: no, /usr/lob/libreoffice/share/template/en-US/presnt/*.otp
<Cimi> seb128, is used by light-themes gtk2
<Cimi> seb128, for old gnome-panel, old gedit, old ubuntuone gtk
<Cimi> seb128, if I remove those, it should stop spamming
<seb128> Cimi, nothing for firefox, tb?
<Cimi> seb128, no
<Cimi> seb128, let me try
<ogra_> hmm, did dpkg --set-selections stop working in precise ?
 * pitti runs through http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.precise/desktop.depends again with a fine comb
 * ogra_ cat get it to install anything
<ogra_> *cant
<ogra_> oh, silly me ... nevermind
<pitti> seb128: I suppose we need rarian-compat still?
<Cimi> seb128, pitti  lp:~cimi/light-themes/remove-pixbuf-dep-shrink-size
<pitti> I thought we need taht?
<Cimi> seb128, you could try removing pixbuf and running apps
<pitti> seb128: it pulls in docbook-xml
<seb128> pitti, is that a runtime thing? I though it was for builds
<pitti> seb128: yes, that's what I was wondering
<pitti> seb128: rarian-compat is explicitly seeded
<seb128> pitti, that seems wrong
<pitti> seb128: the only place where this would possibly be relevant is yelp, right?
<seb128> pitti, yes
<seb128> pitti, will old style documentation
<seb128> pitti, maybe check with jbicha?
<seb128> or maybe mterry knows about it
<pitti> rarian-compat plus docbook-xml are 430 kB
<seb128> I know he has been packaging the new yelp-xsl, etc
<Cimi> seb128, pitti are all documentation packages assets compressed with optipng/optijpeg?
<pitti> Cimi: yes, pkgbinarymangler does that
<Cimi> ok
<pitti> Cimi: for all packages, not just documentation
<pitti> Cimi: we also optimize SVGs
 * mterry reads
<pitti> all that bought us some 8 MB in past cycles
<Cimi> pitti, watch out from PNG
<seb128> mterry, do you know if rarian-compat is a build-time only thing or use by yelp at runtime?
<Cimi> pitti, I tried optipng with something different than -o0
<seb128> mterry, i.e if we need it on the CD
<Cimi> pitti, and was clearly degrading the image
<mterry> seb128, AFAIK just build time.
<seb128> ok, what I though as well
<seb128> pitti, let's try dropping it :p
<seb128> I didn't have scrollkeeper or rarian-compat installed for some months and no issue
<seb128> but I don't use documentation a lot
<pitti> it's a hard dep of ubunt-desktop
<Cimi> seb128, did you have a look at my branch?
 * pitti tries to purge it
<pitti> ... and yelp works just fine
<pitti> seb128, mterry ^
<seb128> pitti, try old style documentations, those which still have an omf
<Cimi> cool
<pitti> ok, I'll unseed it
<seb128> pitti, the new world order doesn't use rarian-compat for sure
<seb128> i.e yelp-xsl yelp-tools are used nowadays
<pitti> e. g. gnome-search-tool
<Cimi> seb128, lp:~cimi/light-themes/remove-pixbuf-dep-shrink-size
<seb128> Cimi, that looks fine to me
<seb128> kenvandine, hey, what do you think about lp:~cimi/light-themes/remove-pixbuf-dep-shrink-size ?
<pitti> seb128: works just fine
<seb128> kenvandine, we are looking for CD space
 * kenvandine looks
<Cimi> seb128, kenvandine only think will break is ubuntuone control panel gtk
<seb128> pitti, ok, I though it was a build time thing so that seems to confirm it, great, kill it!
<Cimi> seb128, buttons will be unthemed
<Cimi> seb128, but "who cares in 12.04"
<pitti> seb128: *happy*
<Cimi> we have the qt one
<seb128> Cimi, we deprecated the gtk panel
<Cimi> seb128, indeed
<seb128> pitti, ;-)
<kenvandine> how much space does it save?
<pitti> kenvandine: 0.1 MB, not much
<Cimi> MP https://code.launchpad.net/~cimi/light-themes/remove-pixbuf-dep-shrink-size/+merge/101735
<seb128> <pitti> we added gtk2-engines-pixbuf since beta-2 (0.1 MB)
<pitti> but it's half of what's left to do, assuming that LibO gets fixed
<Cimi> pitti, my branch also removes some small assets so it should be slightly more
<pitti> ah, nice
<kenvandine> looks fine to me
<kenvandine> we need to get rid of that stuff sooner or later anyway
<Cimi> let's do it now
<kenvandine> Cimi, i approved it
<kenvandine> you merge to trunk and i'll upload
<Cimi> kenvandine, I'll merge
<herton> pitti, hi, now that Maverick is EOL, I think these packages from this tracking bugs will not go anymore to -updates, bugs 967065 and 967066, correct? I'll mark this bugs as invalid if so
<ubottu> Launchpad bug 967065 in Kernel SRU Workflow "linux-ti-omap4: 2.6.35-903.33 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/967065
<ubottu> Launchpad bug 967066 in Kernel SRU Workflow verification-testing "linux-mvl-dove: 2.6.32-425.44 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/967066
<Cimi> kenvandine, when you package, remember to remove pixbuf dep
<hallyn> hey guys - I'm curious, does whoopsie[1784]: segfault at 0 ip 00000000004050a2 sp 00007fff367e5488 error 4 in whoopsie[400000+9000]
<hallyn> mean anything to anyone?
<kenvandine> Cimi, done
<kenvandine> Cimi, is there a bug report related to this?
<Cimi> kenvandine, no
<Cimi> seb128, ^
<Cimi> you love bug reports
<seb128> Cimi, kenvandine: that's fine, just upload ;-)
<kenvandine> just checking
<pitti> herton: ah, thanks
<stgraber> ev: ^ (whoopsie segfault)
<pitti> hah, I found another 330 kB
<pitti> $ cat /usr/share/hwdata/pci.ids /usr/share/hwdata/usb.ids  | gzip -9 | wc -c
<pitti> 334112
<pitti> we can symlink them to the versions from usb-utils/pci-utils
<kenvandine> seb128, pitti, Cimi: light-themes uploaded
<seb128> kenvandine, thanks
<kenvandine> pitti, the .deb is 8K smaller
<pitti> kenvandine: plus teh dropped dep?
<pitti> kenvandine: thanks
<kenvandine> yeah
<pitti> kenvandine: so why was the dep added in teh first place?
<kenvandine> someone added it because it caused messages to get spammed to the console
<seb128> kenvandine, pitti: some of the old gtk2 theming file were using the pixbuf
<seb128> that was leading the .xsession-errors spamming
<kenvandine> it was bug 762167
<ubottu> Launchpad bug 762167 in light-themes (Ubuntu) "missing dependency on gtk2-engines-pixbuf" [Low,Fix released] https://launchpad.net/bugs/762167
<ev> hallyn: you should have a /var/crash/*whoopsie*.crash file
<ev> hallyn: please run ubuntu-bug /var/crash/*whoopsie*.crash and file a new bug
<hallyn> ev: no, it wasn't me
<hallyn> ev: it was in a qemu-kvm bug which had no qemu-kvm msgs in syslog, only whoopsie ones
<hallyn> i've marked it as affecting whoopsie, hold on lemme find the bug # in lp
<hallyn> ev: bug 959964
<ubottu> Launchpad bug 959964 in qemu-kvm (Ubuntu) "qemu-system-x86_64 crashed with SIGABRT" [Medium,Incomplete] https://launchpad.net/bugs/959964
<hallyn> I'm just wondering ifthat points to anything wrong on the host that would explain both qemu-kvm and whoopsie userspace errors
<ev> ah, phew
<pitti> mterry: oh, we need to disable the whole gnome-keyring test suite, not just the test(s) which cause the hang?
<ev> looks like they hit the memory corruption bug in whoopsie from march
<ev> it's not a new one
<pitti> mterry: can you reproduce the hang, actually? I had assumed it was due to the buildds running hardy kernels
<ev> but it wont explain the qemu issue
<hallyn> drat :)
<hallyn> I was hoping the qemu issue was some kernel resource problem causing pthread clone failure
<hallyn> thanks
<pitti> Sweetshark: can you make the change to drop them again?
<mterry> pitti, no I can't reproduce
<mterry> pitti, I disabled the whole suite.  I believe I saw different tests hanging (?)
<mterry> pitti, but it's possible I could have been more targetted
<pitti> mterry: I'm a bit worried about testing SRUs and point releases, on different arches
<pitti> mterry: do you know if this ever affected armel/armhf?
<pitti> if it is only affecting i386/amd64, there is even more reason to believe it's due to the hardy kernel
<mterry> pitti, I only know of it happening on i386, but I don't have the full history of problems with the package
<mterry> pitti, one thing that didn't bother me about it is that the tests were ignored on failure anyway
<mterry> pitti, with || true.  So I didn't figure they were doing us much good to begin with
<pitti> mterry: ah, good point
<barry> doko: https://bugs.launchpad.net/ubuntu/+source/python2.6/+bug/979923
<ubottu> Launchpad bug 979923 in python2.6 (Ubuntu) "Python 2.6 and several virtual packages are still available in 12.04" [Undecided,New]
<seb128> does anyone knows how to make automake not complain about
<seb128> nobase_pkgdata_PYTHON
<seb128> it does "Makefile.am:15: `pkgdatadir' is not a legitimate directory for `PYTHON'"
<seb128> using "nobase_pkgpython_PYTHON" works but I don't want to move those files from /usr/share to /usr/lib just before the hard freeze
<seb128> unping, desrt helped me using a temporary variable :p
<doko> barry, comment added
<barry> doko: thanks
<rbasak> cyphermox: around? I have a fix for the libical arm ftbfs. I've attached a debdiff to bug 979846. Please can you take a look/sponsor?
<ubottu> Launchpad bug 979846 in libical (Ubuntu) "libical FTBFS on arm" [High,Triaged] https://launchpad.net/bugs/979846
<cyphermox> wow, you rock!
<cyphermox> sure, I'll do this now
<cyphermox> thanks a lot for looking into this
<dupondje> doko: around ?
<doko> dupondje, ?
 * ogra_ wonders how you set font sizes etc for gtk-3.0 apps if you dont use gnome nowadays ... .config/gtk-3.0/settings.ini doesnt seem to have any effect 
<dupondje> doko: your still checking opensc? I see you uploaded a fix for it yesterday. Cause I would like to merge the newest version from debian. Cause current version in ubuntu is broken for alot of smartcards
<davmor2> ogra_: You use the force,  go on try concentrate really really hard ;)
<ogra_> haha
<ogra_> well, the only thinng i read everywhere is that .config/gtk-3.0/settings.ini thing
<ogra_> and that should essentially behave like a .gtkrc ... but it seems it doesnt
<doko> dupondje, I wouldn't mind, but you'll need a FFe, and somebody to review and sponsor it
<seb128> ogra_, stop not using GNOME
<ogra_> seb128, lol
<seb128> ogra_, what did you put in there?
<ogra_> ogra@amun:~$ cat .config/gtk-3.0/settings.ini
<ogra_> [Settings]
<ogra_> gtk-font-name = Ubuntu 8
<ogra_> but it uses Sans 11 everywhere
<ogra_> well, in all gtk apps
<dupondje> doko: ok thx! I know, but it could be usefull to have a working version instead of the current :D
 * ogra_ really dislikes our font size chouces on netbooks btw ... way to big for the small screens
<ogra_> *choices
<doko> +1
<dholbach> maybe you two need glasses :-P
<dholbach> oh, too big - nevermind
<ogra_> hehe
 * dholbach maybe needs glasses
<ogra_> :)
 * ogra_ hugs dholbach 
<ogra_> ...and ...
 * dholbach hugs ogra_
<ogra_> @pilot in
<dholbach> yeeeehaw
<ogra_> whats up with the bots recently ?
<seb128> ogra_, with what application did you try?
<ogra_> seb128, firefox and sylpheed
<seb128> ogra_, they are not gtk3
<ogra_> and xchat ...
<seb128> neither
<ogra_> oh
<seb128> it would help if you tried a gtk3 app :p
<ogra_> hmm, well, i care more for the apps i use (like the three above) ... thats all gtk-2 still ?
<seb128> yes
<seb128> gtkrc still work, that didn't change
<seb128> if you want to tweak gtk2
<ogra_> ah, great
<ogra_> thanks seb128
<seb128> ogra_, yw
<ogra_> and sorry for the noise ... i should have checked the deps
<seb128> no worry ;-)
 * doko brings some glasses for dholbach at uds
<dholbach> doko, shot glasses? :-P
<ogra_> stay away from doko if he brings shot glasses ... !
 * ogra_ remembers some bad hangovers caused by that 
 * doko can't remember ...
<ogra_> lol
<dholbach> ogra_, yeah, that's probably wise
 * ogra_ would still like to know whats up with the bot
<stgraber> ogra_: should be added to jono's intro slide, if you want to avoid hangovers, stay away from doko during UDS
<ogra_> @pilot in
<apw> cjwatson, ever heard of any limits to teh size of root and that affecting grub?  we are getting 'out of space' when reading grub.cfg on one of our boxes 'sometimes' after running update-grub
<ogra_> stgraber, only if he has shot glasses with him, otherwise its safe
<apw> cjwatson, yet when we boot by hand the kernels open fine, and the file is fine in /boot/grub/from the booted system
<doko> stgraber, that's the kernel team, can't beat them with hangovers ...
<stgraber> doko: true ;)
<cjwatson> apw: no intrinsic limits, but sometimes there are bugs in grub's fs implementations
<apw> cjwatson, actually the grub.cfg has part of itself at LBA >32bit ...
<apw> cjwatson, see the #ubuntu-kernel for the fibmap
<cjwatson> that would be one plausible reason; either there's an fs impl bug where it isn't 64-bit-clean, or the relevant BIOS calls are failing
<apw> cjwatson, /me suspects the bios ... hmm
<cjwatson> it could well be either
<cjwatson> BIOS or UEFI?
<apw> legacy ...
<cjwatson> the BIOS calls we use are allegedly 64-bit-clean
<cjwatson> but I gather that it's not at all clear whether the BIOS implementors test this
<apw> cjwatson, so the recommendation would be to have a /boot for this machine
<cjwatson> yes, that would be sensible
<apw> cjwatson, do you know what a flag of bios_grub on a partition means?
<apw> 16:21:46      tgardner |  1      1049kB  2097kB  1049kB                        bios_grub                              â awe_
<cjwatson> apw: http://www.gnu.org/software/grub/manual/grub.html#BIOS-installation, subsection on GPT
<cjwatson> but that's for the GRUB image itself, don't confuse it with /boot
<cjwatson> ogra_: it's OK as long as you don't let doko pour
<ogra_> haha, true !
<cjwatson> I was distinctly bleary one morning
 * ogra_ remembers ... though you blamed me for it !
<cjwatson> maybe it was your fault then, I forget :-)
<cjwatson> that might be something to do with the GLASS FULL OF WHISKY
 * ogra_ giggles 
<bkerensa> cyphermox: you around?
<cyphermox> bkerensa: yes
<bkerensa> cyphermox: how did you want me to collect the pulseaudio logs for https://bugs.launchpad.net/bugs/972063
<ubottu> Launchpad bug 972063 in bluez (Ubuntu) "Bluetooth Headset pairs but does not show up in Sound Settings profile" [Medium,Incomplete]
<cyphermox> ah you have two choices
<cyphermox> bkerensa: you can use pacmd and the "set-log-level 3" command to enable logging, then unpair and repair your device
<cyphermox> or kill pulseaudio and start it again fast enough with the logging enabled ;)
<cyphermox> the logs will be in /var/log/syslog
<bkerensa> cyphermox: excellent I have attached those logs to the bug... let me know if you need any more info
<bkerensa> hope to have bluetooth working :)
<vibhav> cyphermox: ping
<cyphermox> vibhav: pong
<vibhav> cyphermox: Most of the bugs we worked on mbpi are fixed, how do we bring them into Ubuntu?
<cyphermox> vibhav: already done. I uploaded a new revision two days ago
<vibhav> ah
<vibhav> thanks'
<ogra_> @pilot in
<stgraber> ogra_: ;)
<stgraber> ogra_: you know you can change the topic yourself, right?
<ogra_> indeed i know that... wanted to know if the bug is back
<ogra_> err
<ogra_> s/bug/bot/
<ogra_> piloting has really bad sideefects
* ogra_ changed the topic of #ubuntu-devel to: Precise: UI and feature freeze  Archive: frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogra_
<ogra_> micahg, did you see my lubuntu ping above ?
<micahg> ogra_: no, let me look
<ogra_> micahg, well, i can quickly repeat... lubuntu-desktop is uninstallable on arm atm, i was wondering if someone from the lubuntu people (assuming you are among them) unseed audacious for armem/armhf to work around that
<micahg> ogra_: I don't personally care for them, but I believe core-dev has commit access, I'd suggest talking to the lubuntu team in #lubuntu to see what they'd like here
<ogra_> i doubt anyone will fix the GLES issues with audacious in time, just undeeding it for arm would at least make the task installable
<ogra_> (and i think arm is a pretty good lubuntu target ;) )
<micahg> ogra_: sounds good, but they might want an alternate in its place, please discuss with them in #lubuntu
<ogra_> in there already :)
<bdmurray> Is there an archive admin who can let my upload of update-manager for oneiric-propsoed through?
<vibhav> bdmurray: Has it been sponsered?
<ogra_> micahg, oh, and also, do you know why there is no metapackage for lubuntu-desktop ? i can only find a task
<micahg> ogra_: it doesn't exist on armhf, I guess no one updated the -meta properly
<micahg> or germinate blew up during generation
<pitti> infinity: OOI, why do we have so many armel PPA buildds?
<doko> infinity, http://people.canonical.com/~doko/tmp/gcc-4.6.debdiff
<jtaylor> doko: will the argparse regression be fixed soon?
<doko> jtaylor, not anymore today, away now
<jtaylor> I'll reopen the bug so its not forgotten
<ogra_> @pilot out
<ogra_> or not :P
* ogra_ changed the topic of #ubuntu-devel to: Precise: UI and feature freeze  Archive: frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<larsduesing> A small question - where to put sort of wishlist/thoughts about getting a package better in Q* ?
<larsduesing> in a "bug"?
<ScottK> Yes.
<yofel> slangasek: where should I put the splash update?
<slangasek> yofel: lp:ubuntu/plymouth, or a merge proposal thereon
<yofel> coming
<slangasek> anyone here understand what's going on with rosetta in bug #978724?  because having to rebuild .pot files at build time is definitely the wrong answer
<ubottu> Launchpad bug 978724 in Ubuntu Translations "update-notifier needs to build translation template" [High,Triaged] https://launchpad.net/bugs/978724
<seb128> slangasek, not sure, I can check with dpm tomorrow, launchpad should the pot which is available at the end of the build
<slangasek> seb128: right, that was my understanding
<slangasek> seb128: is there a better view than https://translations.launchpad.net/ubuntu/precise/+imports?field.filter_status=all&field.filter_extension=pot for finding the files?
<seb128> slangasek, I see nothing weird on https://translations.launchpad.net/ubuntu/precise/+source/update-notifier/+pots/update-notifier/+admin
<seb128> slangasek, different issue but update-notifier has buggy intltool usage
<seb128> https://launchpadlibrarian.net/101084855/buildlog_ubuntu-precise-i386.update-notifier_0.119ubuntu6_BUILDING.txt.gz
<seb128> it has a bunch of
<seb128> "/usr/bin/intltool-merge ../po/da.po ../po/de.po ../po/el.po ../po/es.po ../po/fi.po ../po/fr.po ../po/hu.po ../po/ja.po ../po/pl.po ../po/pt_BR.po ../po/ro.po ../po/sv.po ../po/zh_CN.po
<seb128> Usage: intltool-merge [OPTION]... PO_DIRECTORY FILENAME OUTPUT_FILE"
<slangasek> hmm
<seb128> oh
<seb128> slangasek, debuild clean remove the pot
<ahasenack> hi, can somebody please nominate this bug for lucid, natty and oneiric? https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/978884
<ubottu> Launchpad bug 978884 in landscape-client (Ubuntu) "SRU: release 12.04.3 for lucid, natty and oneiric" [Undecided,Fix released]
<slangasek> seb128: hah
<slangasek> seb128: ok, thanks, I'll fix
<seb128> slangasek, yw
<slangasek> seb128: where do you see that though?  I don't see it in the log
<seb128> slangasek, I noticed that locally when trying to rebuild it, maybe it's not the issue on the buildds
<slangasek> mmk
<seb128> slangasek, oh
<seb128> slangasek, pkgstriptranslations: update-notifier is blacklisted, not stripping
<seb128> slangasek, I wonder if that's due to that
<seb128> slangasek, I bet it is
<slangasek> they shouldn't be stripped
<slangasek> and I didn't think rosetta relied on pkgstriptranslations for pots
<seb128> yeah, me neither
<slangasek> ok, I'll try to dig there, thanks
<seb128> slangasek, I would say, do an upload to a ppa with a ls po at the end of the build just to see if the pot is still there
<seb128> slangasek, I will check with dpm tomorrow, but it's weird indeed
<seb128> slangasek, meanwhile I can upload the current template if you want using the web ui
<slangasek> seb128: oh!  that would be swell, thanks
<seb128> slangasek, done
<slangasek> ta!
<roadmr> hey! does anyone have a minute to have a look at this merge request? it's been reviewed by translators, the release team and is marked as sponsored. https://code.launchpad.net/~roadmr/ubuntu/precise/checkbox/0.13.7/+merge/101783 thanks!
<bkerensa> cyphermox: did you see anything odd in that log?
<micahg> ahasenack: I'm reluctant to give you the tasks without SRU approval as there's no Microrelease exception from what I can see
<micahg> ahasenack: you probably should apply for this for landscape: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<bdmurray> where does details in system settings come from?
<stgraber> bdmurray: gnome-control-center I'd guess
<bdrung> doko: more multiarch fun: bug #980351
<ubottu> Launchpad bug 980351 in openjdk-6 (Ubuntu) "package openjdk-6-jre 6b24-1.11.1-4ubuntu1 failed to install/upgrade: './usr/share/applications/openjdk-6-policytool.desktop' is different from the same file on the system" [Undecided,New] https://launchpad.net/bugs/980351
<doko> bdrung, https://launchpad.net/ubuntu/precise/+queue?queue_state=1
<bdrung> thanks
<maxb> Is there anyone who can moderate my ubuntu-devel@ email, subject "Request for advice - subversion FTBFS in precise
<maxb> ? - it's a little bit time critical since it's discussing things to be done before release
<micahg> maxb: have you talked to Daviey yet about 1.6.18, does it fix the issue?
<maxb> micahg: No, it does not fix the FTBFS
<maxb> So, fixing the FTBFS becomes something we probably want to do anyway, whether or not we get 1.6.18 in
<micahg> indeed
<maxb> I'm uncertain whether an upstream fix for the FTBFS for 1.6.x will be forthcoming or not, or whether the advice will be to stick with APR << 1.4.6 if you care about the testsuite for 1.6.x
<maxb> And even if there is an upstream fix, it will likely be in the form of a *massive* patch adding sorting of results all over the testsuite
 * micahg wonders why Debian wouldn't have the same issue
<maxb> micahg: I expect they will
 * maxb goes looking for a Debian rebuild test
<bkerensa> mpt: What is your proposal for Bug #962974
<ubottu> Launchpad bug 962974 in landscape-client (Ubuntu) ""Management Service" is gratuitously vague" [Undecided,Confirmed] https://launchpad.net/bugs/962974
<maxb> Can't find a recent Debian full archive rebuild by googling, but I'm sure the same problem holds true
<ahasenack> micahg: landscape-client has an exception: https://wiki.ubuntu.com/StableReleaseUpdates#Landscape
<micahg> ahasenack: ah, ok, I"ll give you the tasks then :)
<ahasenack> micahg: thanks
<micahg> ahasenack: done
<ahasenack> micahg: thanks a lot
<micahg> ahasenack: sorry, I would've done it yesterday had I remembered it had an exception
<ahasenack> micahg: np
<ahasenack> I'm persistent :)
#ubuntu-devel 2012-04-13
<bkerensa> slangasek: Would iputils have some reason for lacking manpages?
<slangasek> bkerensa: packages may lack manpages for many reasons :)
<slangasek> bkerensa: but I don't see what you mean here; iputils-ping has manpages, as does iputils-tracepath
<pitti> Good morning
<bkerensa> slangasek: <blkperl> [03:38:01] where did steve go. (in loco channel)
<hyperair> bug #930938 â i can has sponsor please?
<ubottu> Launchpad bug 930938 in xserver-xorg-input-synaptics (Ubuntu) "Kinetic 2-finger scrolling no longer works after upgrade to 12.04" [Undecided,Confirmed] https://launchpad.net/bugs/930938
<RAOF> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise: UI and feature freeze  Archive: frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: RAOF
<RAOF> Huh, not final freeze yet?  This piloting session is going to be more interesting than I thought :)
<pitti> ev: did you see the whoopsie FTBFS due to test failure on arm?
<dholbach> good morning
<RAOF> hyperair: Did you test that debdiff?  Is the infinite-scrolling that I see *really* the behaviour you want? :)
<hyperair> RAOF: yes i did. what infinite scrolling?
<hyperair> RAOF: or do you have CoastingFriction set to 0 by any chance?
<RAOF> I've got whatever are the defaults; presumably that includes CoastingFriction set to 0
<hyperair> can you do synclient -l | grep CoastingFriction?
<hyperair> it should be 50 by default
<RAOF> 50, apparently.
<hyperair> hmmm
<hyperair> lemme check
<RAOF> Yet if I do a 2 finger scroll in evolution it never stops.
<hyperair> hmmmmm yeah you're right
<hyperair> it doesn't stop in evince either
<RAOF> (And also carries over if I do alt-tab, which is stupidly wrong behaviour that's stupid and wrong and is why this needs to be in gtk)
<hyperair> =(
<hyperair> it's in gtk.
<hyperair> partilaly
<hyperair> partially*
<hyperair> for some reason the kinetic scrolling doesn't kick in
<hyperair> i checked via gdb
<hyperair> RAOF: do you get infinite scrolling without the patch? (very slow infinite scrolling, if you do a really fast flick)
<RAOF> No.  I get a couple of ticks of extra scroll, and then it stops.
<hyperair> hmm
<hyperair> oaky
<hyperair> i guess we can't include this patch then
<RAOF> Yeah, I'll nak it.
<RAOF> Although if you find that there's a follow-up patch or two which actually implements sane behaviour, we could still get that in :)
<hyperair> sure
<RAOF> Oh, man, that behaviour is terribly annoying.
<hyperair> RAOF: okay, it looks like priv->scroll.coast_speed_y is getting set to an absurdly high value. it's not that it scrolls forever, it just takes forever to stop.
<hyperair> RAOF: but you can stop scrolling by touching the touchpad, so it's not like it's not easily worked around
<RAOF> Right, but that's not exactly the most elegant default behaviour.
<hyperair> RAOF: it's a good stopgap that removes the regression from oneiric until gtk gets proper kinetic scrolling
<RAOF> Urrr...
<hyperair> er, i really meant the fixed patch
<hyperair> which i'm working on now
<hyperair> i think i've naild this
<hyperair> nailed*
<RAOF> :)
<RAOF> Ah, ok.
<RAOF> That makes more sense.
<hyperair> :)
<hyperair> should i merge this into the patch, or make this a separate patch?
<RAOF> You probably want to make a separate patch, because you'll be sending it upstream, right?
<RAOF> :)
<RAOF> And the initial patch you've added is a cherry-pick from upstream.
<mpt> bkerensa, I made two suggestions in the bug report: "Landscape" or "Landscape Administration". I didn't include "Service" because three words ("Landscape Management Service") would wrap to three lines, making the window taller, and because "Service" doesn't add any meaning.
<bkerensa> mpt: ok I will fix my merge proposal and resubmit then should I ping you for review or just let sponsors handle?
<hyperair> RAOF: it's not a cherry-pick actually, it's not committed yet
<mpt> bkerensa, I guess my review wouldn't hurt, and it would take all of ten seconds :-)
<bkerensa> mpt: https://code.launchpad.net/~bkerensa/ubuntu/precise/landscape-client/fix-for-962974/+merge/101839
<bkerensa> mpt: diff preview is still updating but only change was from Landscape Management Service to Landscape Administration
<mpt> bkerensa, reviewed, thanks :-)
<bkerensa> k
<hyperair> has anyone noticed that killall doesn't function with long process names any more?
<jamespage> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise: UI and feature freeze  Archive: frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage, RAOF
<hyperair> RAOF: okay, it works. and i've uploaded the fixed patch.
<hyperair> bug #930938
<ubottu> Launchpad bug 930938 in xserver-xorg-input-synaptics (Ubuntu) "Kinetic 2-finger scrolling no longer works after upgrade to 12.04" [Undecided,Confirmed] https://launchpad.net/bugs/930938
<bkerensa> mpt: I dont think we will get a exception for the merge though
<RAOF> hyperair: whot's said that he's committed it :)
<jamespage> RAOF, any specific areas you are focussing on from the sponsorship report this morning?
<RAOF> jamespage: I was looking at the top of the queue and picking off things which looked reasonable, but mostly I've been testing hyperair's synaptics patch.
<jamespage> RAOF, OK - just wanted to make sure I was not looking at the same stuff as you
<RAOF> I'm looking at 805509 and 930938
<RAOF> And then it'll probably be time to stop :)
<ev> pitti: yes - jumping on a porter box and digging at it is on my list for today :)
<ev> re whoopsie arm failure
<jamespage> RAOF, guess as final freeze was yesterday we need to limit sponsoring to high priority + for main and universe>
<RAOF> I'm clearly timezone deficient; I haven't seen final freeze annoncement.
<jamespage> hmm
<pitti> well, the topic says "Archive: frozen"
<pitti> but if that's too confusing, lets change it
* pitti changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage, RAOF
<brendand> does anyone know what the gconf key is to prevent the screen from turning off?
<dupondje> jibel: care fixing https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/946709 ? :) i'm updating my 'devbox' and got this bug ...
<ubottu> Launchpad bug 946709 in update-manager (Ubuntu) "Upgrade 11.10 ->12.04 fails with "Couldn't configure pre-depend libc6 for libnih1, probably a dependency cycle."" [Undecided,Confirmed]
<dupondje> if you need some debugging :)
<Whoopie> jamespage: do you have time to discuss bug 898003? The new package is to avoid a regression in precise.
<ubottu> Launchpad bug 898003 in usbip (Ubuntu) "usbip source is maintained in kernel tree now" [Undecided,Confirmed] https://launchpad.net/bugs/898003
<jamespage> Whoopie, lemme just read the bug report
<Whoopie> jamespage: sure, thanks
<Whoopie> jamespage: I didn't attach a debdiff as it's 2 MB because the whole folder structure has changed in version 1.1.1.
<brendand> or is it gsettings now?
<jamespage> Whoopie, not sure I understand why you have dropped usbip-source - is the kernel module no longer required?
<Whoopie> jamespage: it's in kernel staging and enabled since 3.2.0-22.35 in the ubuntu kernel.
<jamespage> Whoopie, right - I think I understand then
<jamespage> Whoopie, I think that overall the approach you have taken looks sensible
<jamespage> Whoopie, questions:
<jamespage> 1) have you discussed this with the debian maintainer of this package?
<Whoopie> no
<Whoopie> jamespage: have to jump to a meeting, but will be back in 1 hour. If you have further questions, I'll try to answer them all later.
<Whoopie> BTW, I'll contact the debain maintainer.
<jamespage> Whoopie, I'll stick some feedback in the bug report
<Whoopie> jamespage: great, thanks.
<Whoopie> jamespage: but if it's not possible to get it into debian and then sync the package, could it be added to precise?
<jamespage> Whoopie, I think so but we should try to get some agreement on approach from the DM
<Whoopie> ok
<RAOF> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage
<tumbleweed> considering that Debian and Ubuntu ship different kernel versions, there's a fair chance that that package couldn't stay in sync
<tumbleweed> but yes, talking to the debian maintainer is always a good idea :)
<jamespage> Whoopie, you have pretty much change most of the packaging - we would normally try to keep the ubuntu delta to a minimum
<dupondje> is there a way to get more debug info from do-release-update ? :)
<tumbleweed> apt logs?
<jamespage> tumbleweed, agreed - but it should be a temp delta not a permanent fork so discussing with DM is important in this case
<tumbleweed> jamespage: yeah. Or at least the same approach+packaging, but maybe different upstream versions.
<dupondje> nothing usefull in it :( trying to debug why I get "E:Couldn't configure pre-depend libc6 for libnih1, probably a dependency cycle."
<jamespage> tumbleweed, yes - that would make sens
<jamespage> e
<hyperair> RAOF: really? i don't see it in the upstream git tree
<RAOF> hyperair: Yeah, neither do I, actually.
<hyperair> git a commit hash?
<hyperair> *got
<RAOF> No; I just read whot's post on xorg-devel.
<RAOF> Anyway, it's now pushed to precise-proposed.
<hyperair> okay, thanks
<dupondje> slangasek: could you check https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/946709 ? Could be caused by some change you did.
<ubottu> Launchpad bug 946709 in update-manager (Ubuntu) "Upgrade 11.10 ->12.04 fails with "Couldn't configure pre-depend libc6 for libnih1, probably a dependency cycle."" [Undecided,Confirmed]
<shnatsel> pitti: hello! I have a question about https://launchpad.net/~apport. I'm deploying Apport in elementary Project, and it seems we need the same retracing bot; so I have two questions: first, where to find the sources for the bot so we can set it up for our projects, and second, how to make Apport subscribe our bot to the reports instead of ~apport?
<tjaalton> chrisccoulson: hey, do you have time updating enigmail to 1.4.1? it fixes bug 968122
<ubottu> Launchpad bug 968122 in enigmail (Ubuntu) "localization messed up" [High,Triaged] https://launchpad.net/bugs/968122
<chrisccoulson> tjaalton, it will be updated with the regular 6 week releases (ie, with Thunderbird 12)
<pitti> shnatsel: the retracer bot in our DC has no additional code, it just runs straight out of lp:apport
<pitti> shnatsel: you need to supply it with a couple of config dirs, though
<pitti> shnatsel: http://paste.ubuntu.com/927711/ is the crontab which regularly invokes crash-digger for i386 and amd64 and dup checking
<tjaalton> chrisccoulson: ah, ok
<pitti> shnatsel: it's a bit more difficult there as this is a lucid box and we do that in a porter dchroot (which has python-launchpadlib and the other necessary pacakges installed)
<pitti> shnatsel: as for the "apport" subscription, that's currently hardcoded in apport/crashdb_impl/launchpad.py like 174
<pitti> shnatsel: err, "line 174"
<pitti> shnatsel: please feel free to open a bug to make this a config option in /etc/apport/crashdb.py
<pitti> shnatsel: line 178, too
<shnatsel> pitti: thanks a lot!
<shnatsel> I take it nobody ever used a custom Apport bot then? :)
<pitti> shnatsel: either that, or they just changed that locally and didn't tell me :) I wasn't really aware of that hardcoding
<shnatsel> pitti: one more question. Where can I find samples of those config dirs or documentation on writing them?
<shnatsel> those config dirs include bug patters, I presume?
<pitti> shnatsel: it's described in "man apport-retrace"
<shnatsel> pitti: thanks! Will dig :)
<pitti> shadeslayer: no, this is just the config for the apt sources for the sandboxes
<pitti> shnatsel: http://paste.ubuntu.com/927719/
<pitti> shnatsel: those are two configs from our bot
<pitti> shnatsel: they really all look alike
<pitti> shnatsel: the only oddity is that we include ddeb apt sources for previous releases, due to the really hackish way ddebs.u.c. works
<pitti> (long story, just do it :) )
<shnatsel> okay! xD
<maxb> Do the amd64 buildds run multiarch-enabled for oneiric and precise?  (Because debootstrap sets up a new chroot that way, which surprised me)
<shnatsel> pitti: thanks a lot! I'll report back if when deploy it (or fail to)
<pitti> shnatsel: I suggest you check out lp:apport, then create a config dir for a release you are intersted in, and start with manually calling apport-retrace and see how that goes
<pitti> shnatsel: once that works, you can use crash-digger to iterate over all pending bugs
<dupondje> bleh, to bad upgrade from oneiric still fails :(
<shnatsel> one more question: are *-dbgsym packages at ddebs.ubuntu.com the same as -dbg packages in main archive, or that's something different?
<cjwatson> they are different
<cjwatson> *-dbgsym: automatically stripped debugging symbols
<cjwatson> *-dbg: may be debugging symbols in some cases, but can also be entirely separate debugging builds (e.g. python2.7-dbg)
<shnatsel> cjwatson: thanks! So if I make a package with automatically stripped debugging symbols in a somewhat main archive (PPA), shall I call it -dbg or -dbgsym? Also, is it OK for Apport to have only -dbg and not -dbgsym?
<shnatsel> for apport-retrace I mean
<cjwatson> I don't know the answer to your apport question
<dupondje> somebody wants to look at https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/946709 ? :)
<ubottu> Launchpad bug 946709 in update-manager (Ubuntu) "Upgrade 11.10 ->12.04 fails with "Couldn't configure pre-depend libc6 for libnih1, probably a dependency cycle."" [Undecided,Confirmed]
<dupondje> quite annoying, as it blocks my upgrade :(
<cjwatson> If you generate a package in your own packaging rules, it should be -dbg; -dbgsym should only be generated by pkg-create-dbgsym
<shnatsel> cjwatson: thanks a lot!
<shnatsel> pitti: one more question: is it OK for Apport to have only -dbg packages and not -dbgsym?
<pitti> shnatsel: you won't get very good results
<broder> pitti: are you ok with me cherry picking http://cgit.freedesktop.org/upower/commit/?id=6fb36eb5eb85386d2e1c5d9fb760d68053d8afc5 onto upower? (i'm open to doing it as an sru if that's preferable)
<pitti> shnatsel: i. e. for packages which don't have a -dbg, you won't get any symbols, and most likely also stack traces which fail in the middle because of missing symbols, etc.
<pitti> broder: I'd rather apply it to Debian, too, to avoid getting out of sync
<broder> pitti: ok. that would be awesome if you could - i got bitten by the broken behavior a couple of times in the last week before finally hunting down the bug
<pitti> broder: is there a bug # for it? at this point we should have them for release tracking
<broder> would a bts bug as a reminder be easiest?
<broder> no, i haven't done anything yet
<broder> i'll open an lp bug
<pitti> just curious that there is no existing bug at all about it
<pitti> it mighth be against gnome-power-manager, or a different package
<broder> err, there might be. i didn't look - i just figured out what was going wrong
<broder> there are a handful of moving parts that lead to the brokenness
<dupondje> slangasek: around ?
<shnatsel> pitti: I take it Ubuntu ddeb archive has -dbgsym for all packages, so to use -dbg instead I'll have to make sure all my custom packages have -dbg, otherwise retracing will fail?
<broder> pitti: i kind of suspect that any bug that starts with "my laptop doesn't suspend when i close the lid" immediately gets shuffled off to die in kernel purgatory
<pitti> shnatsel: don't you base your project on top of an ubuntu release?
<pitti> shnatsel: if you don't, you need to ensure to build -dbg packages for teh things you care about, yes
<shnatsel> Pici: well, we do... but we need newer libs than are present in Ubuntu sometimes
<shnatsel> Pici: sorry
<shnatsel> pitti: ^
<broder> pitti: bug #980746
<ubottu> Launchpad bug 980746 in upower (Ubuntu Oneiric) "upower does not check dock state on resume from suspend" [Undecided,New] https://launchpad.net/bugs/980746
<shnatsel> reported making apport bot name configurable as bug #980726
<ubottu> Launchpad bug 980726 in Apport "Make bot name subscribed to LP reports configurable" [Undecided,New] https://launchpad.net/bugs/980726
<broder> pitti: thanks for taking a look. i need to go to sleep, but let me know if i can help and i'll look at it tomorrow
<pitti> broder: bug 948485 ?
<ubottu> Launchpad bug 948485 in pm-utils (Ubuntu) "Suspend after undocking laptop doesn't work" [Undecided,New] https://launchpad.net/bugs/948485
<broder> hmm, yeah, sounds like the same bug, though it's hard to tell for sure with the given information. i'll post a followup comment and find out
<infinity> shnatsel: For your custom packages, there's nothing stopping you from also doing dbgsym extraction (ie: by building with pkg-create-dbgsyms installed)
<pitti> broder: hm, that bug could also be a dupe of bug 682262
<ubottu> Launchpad bug 682262 in linux (Ubuntu) "Linux on Thinkpad x61s doesn't suspend when booted in docking station (does if not though)" [Undecided,Confirmed] https://launchpad.net/bugs/682262
<broder> moral of the story: docking stations are evil
<pitti> broder: anyway, I'll cherry-pick it, unless you want do do a debdiff, etc.
<pitti> broder: no, they are awesome!
<broder> only when they work :)
<broder> i don't need to get credit for the upload. whichever is easier and fastest for you to deal with
<pitti> broder: ok, I'll just thank you in the changelog then?
<broder> pitti: works for me
<shnatsel> infinity: will that allow building normal -dbg packages, etc etc? Since we use PPAs as our only repositories we [probably] can't set something as a dependency for all packages, and I have an automated script to enable -dbg packages anyway, so I'd rather patch packaging to enable -dbg than -dbgsym
<infinity> broder: Oh, hey.  Before you go to bed.  What's the name of your lintian host again?
<pitti> shnatsel: no, -dbg must be done manually in the packaging
<broder> infinity: odo.tribbl.es
<pitti> shnatsel: that's why I wrote pkg-create-dbgsym, so that we don't have to modify packages
<pitti> shnatsel: i. e. to build -dbgsym packages for all packages
<pitti> shnatsel: you could do a hack and e. g. upload a debhelper version to your PPA which depends on pkg-create-dbgsym
<pitti> shnatsel: ah, no, scratch that; I don't think PPAs have support for ddebs
<pitti> shnatsel: we have a rather hideous hack to publish them for the normal ubuntu archive, but that's not available for PPAs
<infinity> pitti: I thought the PPA ddeb support was added a while back for OEM?
<dupondje> ia32-libs-multiarch is uninstallable ?
<pitti> is it? so much the better; but they have magic PPAs
<infinity> Oh, yeah, it might not be on for all PPAs.
<pitti> shnatsel: I guess you could just try it with one package and see what happens
<pitti> if LP accepts them, you could at least grab the .ddebs from the LP page
<pitti> I doubt they will be published to the PPA archive, though
<shnatsel> pitti: thanks, I'll keep that in mind if I ever need -dbgsym. I wrote an automated script that enables -dbg packages in packaging, so we can live without -dbgsym for now :)
<pitti> shnatsel: it's mostly adding the -dbg package to debian/control and telling dh_strip about it in debian/rules, so it's indeed not hard
<pitti> shnatsel: if it's only for 5 or so packages, that's definitively easier than trying to write something around LP to get a ddeb archive
<shnatsel> pitti: yes, exactly. It's very simple: http://bazaar.launchpad.net/~elementary-os/elementaryos/packaging-scripts/view/head:/simple-case-add-dbg-package
<pitti> hah
<shnatsel> By the way, regarding magic PPAs - I hear there are some PPAs which can build ARM packages; elementary has an ARM strategy, is there any way they could get access to one? Not now, but someday in the future - we'll probably use custom build farm and repos for testing since those PPAs are non-virtualized or something like that...
<seb128> shnatsel, pitti: launchpad got dbgsym support in some way for ppas, dx-system mentioned it and didrocks said it got enabled for the unity ppa (though that's a non virtual ppa, not sure if that's specific to those)
<infinity> shnatsel: We still only offer ARM PPAs to Canonical employees and specific partners we have contracts with (entirely because they're insecure).  We're working on making them more widely available with virtualized builders, but it's not quite there yet.
<shnatsel> infinity: thanks! Hopefully they will be public by the time elementary needs them :)
<infinity> shnatsel: No idea is that'll be true.
<shnatsel> well, then we'll need a contract with Canonical :)
<shnatsel> never mind, and thanks for all the info
<jamespage> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dobey> Riddell, ScottK: either of you ever hit any instance of bug #334757 before? It's a 3.5 year old bug, and seems to be popping up a lot more with ubuntuone-control-panel and ubuntu-sso-client-qt using pyqt :-/
<ubottu> Launchpad bug 334757 in KDE Bindings "update-notifier-kde.py crashed with SIGSEGV in QSocketNotifier::setEnabled()" [High,Confirmed] https://launchpad.net/bugs/334757
<ScottK> dobey: Not that I recall.  We should move that the python-qt4 in any case then.
<dobey> ScottK: there's a bug against ubuntu-sso-client with the same crash, which has enough duplicates it's starting to cause lp to timeout occasionally :(
<ScottK> dobey: I see there's a reduced test cae in the bug.
<ScottK> case
<ScottK> dobey: Are you subscribed to the upstream PyQt mailing list?
<dobey> yeah, alecu just posted that after looking into the bug against ubuntu-sso-client
<dobey> i am not
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<jdstrand> kees, cjwatson: hmm. I just noticied this: /dev/tty[1-6] went from root:root 0600 to root:tty 0660 between oneiric and precise. I think it is because of util-linux commit 3aa6b68f7e19fa3e1c2bba75bee921a98b7b46af
<jdstrand> kees, cjwatson: and I'm trying to decide if that is a problem
<jdstrand> thoughts?
<infinity> jdstrand: They were root:root at some point?
<jdstrand> infinity: yes, in oneiric
<infinity> And only oneiric?
<jdstrand> oneiric and ealier
<infinity> That's patently untrue.
<jdstrand> well, let me check
<infinity> Says the man looking at a bunch of root:tty TTYs on lucid.
<jdstrand> it is certainly true on lucid
<jdstrand> note I said [1-6]
<infinity> Oh, just the VCs.
<infinity> Check.
<infinity> I'm not sure I see that as a problem.
<infinity> But maybe I'm not sure why they didn't have tty access before. :P
<jdstrand> yes, it was root:root going all the way back to hardy
<jdstrand> I'm not sure it is a problem either, hence the question :)
<jdstrand> kees, cjwatson: fyi, I filed bug 980835 so it doesn't get lost
<ubottu> Launchpad bug 980835 in util-linux (Ubuntu) "tty[1-6] is now root:tty 0660 instead of root:root 0600" [Undecided,New] https://launchpad.net/bugs/980835
<infinity> jdstrand: It goes 600 as soon as you log in anyway.
<infinity> jdstrand: So the tty group only has access to unallocated TTYs, which seems reasonable.
<jdstrand> re 0600> yes. that is why I wasn't sure I cared. I still find it odd that the change was made
<jdstrand> it has something to do with suse wanting to port mingetty stuff to util-linux
<jdstrand> but mingetty doesn't do this (at least not on 11.10)
<infinity> Also, the bit you hilighted has not much to do with it.
<infinity> jdstrand: Note that, until you run a getty, all TTYs are root:tty.  For some reason, agetty used to change them to root:root, and now doesn't.
<infinity> And man, launchpad needs better options for pasting code.
<jdstrand> infinity: that is a good point
<jdstrand> mingetty doesn't do it on precise
<infinity> Doesn't change perms?
<jdstrand> yes
<jdstrand> if I chown and chmod it to root:root 0600 then fire it up, it is unchanged
<jdstrand> I think I don't care based on your observation of the other ttys
<jdstrand> actually, the other ttys are 0620 (like the udev rule says)
<jdstrand> hmm
<infinity> Right, the code you hilighted is making them 660.
<infinity> The code I hilighted (or the removal) is making them remain root:tty.
<infinity> If there's a valid argument for the udev rule being 620, we could make util-linux mirror that.
<jdstrand> I would tend to agree
<jdstrand> it was changed to 0620 in udev (from 0666) back in 2007
<jdstrand> debian bug 244751 discusses this outside of udev (from 2004)
<ubottu> Debian bug 244751 in makedev "/dev/tty[0-9a-z].* should not be world-read/writeable" [Important,Fixed] http://bugs.debian.org/244751
<jdstrand> (when they had 0666)
<lamont> so after the "zomg something bad happened" poppup steals focus and I hit return and lose it, how do I see why it popped up?
<lamont> seb128: I blame you everytime somethinge steals focus at a bad moment.  just sayin'. :D
<davmor2> lamont: /var/crash/ maybe?
<lamont> davmor2: ta
<lamont> /var/crash/_usr_lib_indicator-messages_indicator-messages-service.2501.crash
<lamont>  Segfault happened at: 0x6117c0 <dirname>:      add    %al,(%rax)
<lamont> turns out that the indicator-messages-service hates passwd entries in nssdb
<slangasek> dupondje: hey there
<dupondje> hi :)
<seb128> lamont, seems like worth reporting ;-)
<lamont> yeah - working through that little bit of pain now
<lamont> fortunately, it died again for me, so I have a nice user experience
<dupondje> was able to upgrade my system manually now, but maby its good to have that bug fixed
<slangasek> dupondje: hmm, context?
<dupondje> slangasek: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/946709
<ubottu> Launchpad bug 946709 in update-manager (Ubuntu) "Upgrade 11.10 ->12.04 fails with "Couldn't configure pre-depend libc6 for libnih1, probably a dependency cycle."" [Undecided,Confirmed]
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<bdmurray> Is there some archive admin who could approve my update-manager in oneiric proposed?
<ScottK> Did the SRU team approve it already?
 * dholbach hugs mterry
<barry> mvo: ping
<barry> slangasek: can you approve foundations-q-python-version blueprint?
<mterry> :)
<pitti> barry: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-python-version does not exist
<barry> pitti: oops, typo: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-python-versions
<barry> (plural at the end)
<pitti> barry: for 12.10!
<pitti> barry: accepted for sprint and q
<barry> pitti: awesome!
<pitti> speaking of which, what's Quarreling Quail really going to be called like?
<pitti> sabdfl: ^ :-)
<sabdfl> qqqqqqqq
<sabdfl> well
<sabdfl> qu....
<pitti> we soon need the name to put it into lintian, vim, and a few other places
<barry> pitti: qwazy quahog!
<pitti> barry: that makes baby jesus qwy
<barry> pitti: :-D :-D
<barry> pitti: that is going on my twitterfeed right now
<slangasek> dupondje: 946709> how did you do the manual upgrade?
<slangasek> dupondje: that's a duplicate of bug #850264
<ubottu> Launchpad bug 850264 in apt (Ubuntu Oneiric) "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Triaged] https://launchpad.net/bugs/850264
<slangasek> dupondje: any chance you'd be interested in preparing an oneiric SRU for that?  It's on my list, but I haven't gotten to it yet
<nigelb> pitti: haha, that was awesome :)
<cjwatson> slangasek: did mvo manage to come up with a non-ABI-changing version of that?
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2012-February/034694.html
<cjwatson> oh, wait, maybe that's a different bug
<slangasek> oh phew, I was going to be sad
<dupondje> slangasek: I changed the sources.list, then apt-get upgrade, then upgrade of some other packages, and then dist-upgrade untill it was all set :)
<slangasek> ok
<slangasek> yeah, that would bypass this bug
<dupondje> apt-pkg/depcache.cc: prefer native providers over foreigns even if the chain is foreign.
<dupondje> only this need backport ?
<slangasek> dupondje: I believe so, yes
<hyperair> hmm scrolling using a touchpad is broken in gtkmm 3.0
<hyperair> case in point gnome-system-monitor
<jtaylor> doko: is it still possible to merge numpy -7 for a fix of debian bug 664672?
<ubottu> Debian bug 664672 in python-numpy "python-numpy: testsuite failures in experimental" [Normal,Fixed] http://bugs.debian.org/664672
<dupondje> slangasek: http://bazaar.launchpad.net/~donkult/apt/experimental/diff/2193 -> this is the diff containing the change in depcache.cc, so just backport this :)
<dupondje> going to check that ou
<dupondje> out*
<hyperair> hang on, it's not broken in just gtkmm. it's broken in everything suddenly. weird.
<slangasek> dupondje: sure - any chance you can cherry pick that into a bzr merge proposal against oneiric and subscribe me?
<slangasek> dupondje: (sorry, in the middle of a few other things at the moment so can't pick it up directly without a stack overflow)
<dupondje> i'll check that later :) no much experience with bzr :) else I just do a debdiff
<hyperair> weird, it all works again. i wonder what that was.
<slangasek> dupondje: ok, debdiff is fine too; in that case please just attach it to the bug
<slangasek> jibel: 979350> does that really establish that it's specific to amd64, or just that the memory thresholds are different for i386 vs. amd64?
<slangasek> I'm not convinced that the memory usage of ubiquity itself is the key here
<doko> jtaylor, sure, why not. it's not on any iso image
<dobey> hey all. what user do package builds happen as under pbuilder?
<tumbleweed> the pbuilder user
<cjwatson> file:///usr/share/doc/pbuilder/pbuilder-doc.html#nonrootchroot
<cjwatson> (public service announcement: use sbuild instead)
<infinity> I was waiting for that.
<infinity> cjwatson: You should probably get t-shirts printed for UDS.
<cjwatson> "stop unpacking pointless tarballs: use sbuild"
<dobey> https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#Packaging
<dobey> "sbuild" occurs nowhere on that page :)
<cjwatson> I can't help it if people are wrong
<cjwatson> to be fair, sbuild was probably less usable outside buildd contexts at the time
<dobey> anyway, whatever. the information doesn't help solve my problem :-/
<dobey> which is to say, this: https://launchpadlibrarian.net/100003195/buildlog_ubuntu-lucid-i386.ubuntuone-dev-tools_3.1%2Br60-15~lucid1_FAILEDTOBUILD.txt.gz
 * cjwatson wonders how pbuilder is even relevant, then
<cjwatson> since the buildds don't use it
<dobey> ok, well i don't know that
<dobey> i don't maintai nthe buildds
<cjwatson> I'm telling you now
<dobey> i know i'm pretty smart, but there are actually things i don't know :)
<dobey> ok
<dobey> does sbuild build the packages as root?
<cjwatson> no
<infinity> dobey: So.  The builds run as 'buildd'.
<infinity> dobey: Not that you should hardcode or rely on such a thing.  Your build should just work as any unprivileged user.
<dobey> ok, so still likely not the relevant piece of information to the problem
<cjwatson> it would be less frustrating if you could tell us what would be relevant
<cjwatson> I feel like I'm playing twenty questions here
<dobey> infinity: it doesn't. the exact same build works on all the newer versions of ubuntu
<cjwatson> where's the .dsc for this?
<dobey> i don't know what's relevant. i'm looking at a black hole trying to see what the problem is
<Laney> can someone mash this? https://launchpad.net/ubuntu/+source/gnome-settings-daemon/3.4.0-0ubuntu7/+build/3400563
<cjwatson> I'll be happy to try it locally
<dobey> cjwatson: in the ppa source i guess. it's a lp recipe build
<cjwatson> and then explain how you can try it locally
<infinity> Laney: Mashed.
<cjwatson> dobey: URL please, I have no idea what that build log corresponds to
<Laney> infinity: thanks
<dobey> https://launchpad.net/~ubuntuone/+archive/nightlies/+files/ubuntuone-dev-tools_3.1%2Br60-15%7Elucid1.dsc
<dobey> cjwatson: does sbuild let you specify a ppa to use to satisfy build-deps, for a single build, vs. for all builds as pbuilder requires?
<cjwatson> you could do it with --pre-build-command if nothing else
<cjwatson> er --pre-build-commands
<infinity> dobey: Could it just be that you're doing something incompatible with lucid's squid?
<infinity> dobey: Every other release is 3.1.x, lucid's 3.0... Could relate.  Dunno.
<dobey> infinity: i guess not, as branch lp:ubuntuone-dev-tools on lucid and running ./run-tests with all the build-deps installed, works just fine. it's clearly an environment difference
<cjwatson> hm, maybe not --pre-build-commands, doesn't support shell metacharacters - still, quick to switch back and forward
<cjwatson> dobey: hmm; builds fine in a local sbuild
<cjwatson> so it's not the building tool that matters, I think
<infinity> The lucid chroot could be a bit wonky.
<dobey> hrmm
<infinity> Or it could be that old versions of squid REALLY want external DNS for some reason, or similar issues.
<cjwatson> dobey: you could probably help yourself by having that exception also dump out stdout/stderr from squid
<dobey> cjwatson: well, i was only asking about the user as it was a theory presented where squid couldn't access certain directories.
<dobey> cjwatson: yeah, am having someone fix that as well
<cjwatson> sure - but if squid is failing to start, I expect that it says why on stderr :)
<cjwatson> which would save on speculation
<dobey> sure. thanks anyway. i didn't mean to have it turn into a discussion about pbuilder vs sbuild or further speculation. :)
 * cjwatson nods
<SpamapS> did anything ever come of the effort to backport dh_python2 to lucid?
<SpamapS> I have an ever-growing list of non-backportable packages that require special effort just to get onto lucid.. :-/
<tumbleweed> SpamapS: no
<dobey> SpamapS: dealing with dh_python2 vs. lucid in a package is very easy, actually
<dobey> SpamapS: one second and i'll show you how :)
<dobey> SpamapS: http://bazaar.launchpad.net/~ubuntuone-control-tower/dirspec/packaging-dailies/files
<dobey> SpamapS: see rules and a few | deps in control.
<dobey> or well, i guess the one | dep :)
<dobey>  python-all (>= 2.6.6-3) | python-support (>= 0.6.4),
<slangasek> yes, which means you get to build packages for lucid with all the bugs of python-support :/
<dobey> yes well
<dobey> at least it's not python-central
<dobey> the other option of course is "don't build packages for lucid"
<dobey> can we just EOL it a year early? :)
<dupondje> slangasek: seems like there is more then that patch needed for fixing apt
<dupondje> that patch seems to depend on other patches
<slangasek> dobey: the option we wanted to take was to backport dh_python2
<slangasek> I'm not saying you've done anything wrong, just that the workaround being "easy" doesn't make it a great one
<dobey> slangasek: understood, but it's not done, and waiting until EOL for it to get done isn't helpful either. also if it only ends up in backports and not as an SRU, it will still only have very limited value.
<slangasek> well, we had agreement to SRU it, but
<slangasek> anyway
<tumbleweed> given the progress on it, I'm not expecting it to ever happen
<slangasek> dupondje: are you following through on the other patches?
<dobey> tumbleweed: exactly :)
<SpamapS> dobey: thanks.. I knew about that. But having to introduce a bunch of cruft in new packages just so I can get them back to lucid is pretty annoying.
<dobey> SpamapS: i don't know if i'd call ~5 lines total "cruft" :)
<dobey> but yes, i agree it's not the best thing. but it works quite well
<SpamapS> dobey: and server has 3 years left for lucid, not 1 :)
<dobey> you can of course also have a separate packaging branch for lucid
<dobey> oh, right :(
<SpamapS> dobey: the separate branch is what I do now
<SpamapS> but every time somebody pokes a new package dep into something I want to support on all releases.. I have to branch the packaging or install the workaround you noted
<SpamapS> having precise out will help ease the desire to keep pushing things back to lucid.. but that will take another year really.
<dobey> yes well. i'd say maintaining multiple packaging branches is more cruft :)
<SpamapS> dobey: its cruft that goes away automatically, which I like.
<dobey> *shrug* :)
<cjwatson> barry: any luck with bug 848915 yet?
<ubottu> Launchpad bug 848915 in update-manager (Ubuntu Precise) "Partial upgrade results in cryptic traceback because $DISPLAY is not set" [High,Triaged] https://launchpad.net/bugs/848915
<ScottK> barry: Before we can reliably carry both python3.2 and python3.1 as supported versions, dh_python3 probably needs to grow a way to deal with modules with different code for different python versions.
<barry> cjwatson: nope.  bdmurray did you have some additional information on that one?
<barry> ScottK: yeah, that's what piotr mentioned quite often.
<ScottK> barry: OK.  Since you mention you want 3.2/3.3 for "Q", be sure to write down doing that bit of work too.
<barry> ScottK: i don't think we'll have to worry about 3.1 and 3.2, but 3.2 and 3.3
<ScottK> Agreed.
<cjwatson> barry: I thought we'd agreed a plausible hack to help track it down - did that not yield anything?
<ScottK> 3.1 was a typo
<barry> cjwatson: i've been working on other stuff first.  e.g bug 873468
<ubottu> Launchpad bug 873468 in update-manager (Ubuntu Precise) "Update to latest Release failed for overloaded mirrors with no descriptive error message" [Critical,In progress] https://launchpad.net/bugs/873468
<bdmurray> barry: nope, no info
<barry> ScottK: /me nods
<barry> bdmurray, cjwatson: i'll take another look at 848915 when i finish with 873468
<cjwatson> barry: I'm installing an oneiric desktop now to see if that will help
<cjwatson> glad you're working on 873468 :)
<barry> cjwatson: cool :)
<cjwatson> down to five >=high rls-p-tracking bugs for foundations, counting stuff in -proposed ...
<cjwatson> so the mess that is http://people.canonical.com/~rspencer/rls_bugs.svg isn't all our fault ;-)
<slangasek> SpamapS: so.... we never got to the lvm2 merge, did we
<slangasek> SpamapS: how far did you get with that in practice?  I'm interested to know if the new upstream version fixes bug #874774
<ubottu> Launchpad bug 874774 in cryptsetup (Ubuntu Precise) "could not mount /dev/mapper/cryptswap1" [High,Triaged] https://launchpad.net/bugs/874774
<SpamapS> slangasek: I tried and failed 3 times to resolve the merge
<slangasek> blast
<slangasek> ok
<SpamapS> slangasek: the problem is, we have patches, debian has patches, and upstream has half of most of them applied
<slangasek> yep
<slangasek> any relevant notes from the experience, so that when we try the merge next cycle we might get there?
<SpamapS> its like trying to separate the linguine from the fettucini in a bowl of spaghetti, blindfolded
<cjwatson> see also: why we haven't merged plymouth
<SpamapS> slangasek: I think with a strong, focused effort it will be doable
<SpamapS> Its just my other 40 plates kept falling off their sticks, so I had to keep them spinning and let this one fall
<dupondje> slangasek: we going to get the cryptsetup bugs down :)
<slangasek> dupondje: that's the only one of them I'm worried about right now, and it looks like it might be an lvm2 bug ;)
<dupondje> i'm already happy we don't have the uber prehistoric version we had a month ago :)
<slangasek> yep, just a prehistoric lvm
<dupondje> well thats to late to merge now I guess
<slangasek> quite
<dupondje> we should have ubuntu sid imo :) a rolling release would be cool
<cjwatson> which would somehow magically create effort to merge things ...? ;-)
<dupondje> if you are in the mood for a merge, and then its just FF :p
<slangasek> that's what staging bzr branches are for
<slangasek> pitti: hey, on the 'sudo doesn't preserve proxy vars' saga... do you know if there's a good reason sudo doesn't itself invoke pam_env?
<slangasek> (su does, for comparison)
<xee> Hi, I'd like to as what library gnome uses to display contents of an iphone so well when one is plugged in.
<xee> Unity/Gnome I mean, in default Ubuntu setup.
<dupondje> When are FFe syncs/merges accepted when they are ACK'ed ?
<tumbleweed> dupondje: the ack on the bug just gives you permission to go ahead and sync/upload
<dupondje> tumbleweed: I can't sync/upload myself :)
<tumbleweed> right, so you subscribe the sponsors
<dupondje> slangasek: https://launchpadlibrarian.net/101769525/apt.debdiff
<xee> turns out it's gvfs itself
<xee> thanks
<astraljava> Does anyone have a bit of time to explain to me whether we'd run into problems with adding dssi-host-jack into our seeds, still (we would be Ubuntu Studio). Back in the day it was dropped, and I'm not exactly sure why.Then there was the dssi-vst problem with multiarch ia32-libs, germinate and all that, and since dssi-host-jack builds from the same source, I'm a little unsure whether adding it to the
<astraljava> seeds will cause issues with the image spinning or not.
<astraljava> Furthermore, would it require a FFe?
<astraljava> And yet again, how quick/painless it is to refresh seeds to affect the image spinning?
<astraljava> is it*
<cjwatson> the problem with dssi-vst was that on amd64 it depended on i386-only packages
<cjwatson> I don't see anything like that in dssi-host-jack
<astraljava> cjwatson: That's what I started to realize after reading your mail on ubuntu-release in November last year.
<cjwatson> so I don't see any issue there and I don't think it requires an FFe as long as you have the time to test it; but the package description suggests that it's only an example, so is it really much use?
<astraljava> cjwatson: Ok, so what about the seeds thing, then? I'm asking because one of our apps in the seeds won't run out-of-the-box without any dssi hosts installed. I talked about this with quadrispro, and it seems this would be the sanest solution.
<cjwatson> if you want it as a directly-seeded entry rather than as a dependency of something else, it's a matter of committing to the seeds and then refreshing/uploading ubuntustudio-meta
<astraljava> cjwatson: I actually already put it in the seeds, but then became uncertain because of the whole ia32-libs thing (many hours before) and reverted it.
<cjwatson> you can unrevert it then :)
<astraljava> cjwatson: Right, thank you so much. :) I'll just ask here for the refresh/upload of -meta when it's back in the seeds, then?
<cjwatson> and I can upload ubuntustudio-meta for you once you've done that, although if I do that then another member of the release team will have to deal with approving it
<astraljava> So -release would be a better place to ask, so it's all there for the other member?
<cjwatson> *shrug* I expect they're all here anyway
<astraljava> cjwatson: Ok, rev. 1322 of ubuntustudio.precise has the unrevert fix. :) If you'd be so kind.
<cjwatson> astraljava: running
<astraljava> Thanks!
<cjwatson> barry: stealing assignment of bug 848915
<ubottu> Launchpad bug 848915 in update-manager (Ubuntu Precise) "Partial upgrade results in cryptic traceback because $DISPLAY is not set" [High,Triaged] https://launchpad.net/bugs/848915
<cjwatson> figured you probably wouldn't mind :)
#ubuntu-devel 2012-04-14
<cjwatson> astraljava: uploaded
<astraljava> cjwatson: Most excellent, thank you once again! :)
<astraljava> cjwatson: Are there new images spinned (span? spun?) on Saturday?
 * astraljava forgets these odd tenses
<cjwatson> astraljava: (spun) I'd assume so, all the cron jobs are still switched on
<astraljava> cjwatson: Great (on both occasions)! Thanks.
<vibhav> cyphermox: You there?
<slangasek> SpamapS: build-tested only, but I have a merge of lvm2 now at lp:~vorlon/ubuntu/precise/lvm2/lp.726677 ; I suppose I'll park it there until q opens
<SpamapS> slangasek: \o/ hooray for lvm2
<dupondje> slangasek: maby cryptsetup should depend on udev now that udevadm is used ? :)
<dupondje> slangasek: posted updated patch in https://bugs.launchpad.net/ubuntu/+source/apt/+bug/850264
<ubottu> Launchpad bug 850264 in apt (Ubuntu Oneiric) "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Triaged]
<sladen> kirkland: hahhahhahaha
<sladen> kirkland: I think skaet will have to do a bit of work to match your recent release notes
<infinity> ?
<sladen> infinity: http://blog.dustinkirkland.com/2012/04/kirkland-1204-lts-released-hello-world.html
<infinity> Ahh.
<infinity> kirkland: Congrats.
<vibhav> unseeded packages dont need FFes for bug fixes right?
<bdrung> vibhav: yes
<vibhav> bdrung: Even New Upstream Releases for unseeded packages dont need FFes
<vibhav> ?
<Carlos_Gong> NEED HELP! I am localizing appmenu-indicator, and can't understand the following: "In order to have the application's menu items appear higher in the search results a slight penalty is given to the indicator menu items. " Can anybody give me an example of how exactly does this work?
<shnatsel> pitti: hello again! How do I authenticate Apport to Launchpad? man apport-retrace mentions firefox's cookies.txt, but it's cookies.sqlite in current versions, and I'm not sure LP uses cookies anyway.
<slangasek> dupondje: well, cryptsetup depends: dmsetup which depends: udev, so in practice it's not going to cause problems - but yes, it should preferably declare a direct dependency
<slangasek> dupondje: thanks for the updated patch, I'm looking this morning
<slangasek> kirkland: heh, congrats :)
<slangasek> I am confused that I got bug mail about bug #981648, and this bug appears to no longer exist
<ubottu> Error: Launchpad bug 981648 could not be found
<penguin42> slangasek: I find it interesting that if I search for that bug the 'lost something' message I get includes an OOPS id, where as if I search for the next one it doesn't
<slangasek> fun
<slangasek> well, the only reason I wanted the bug was to close it as invalid :P
<cjwatson> slangasek: "doesn't exist" for bugs is sometimes Launchpad's way of saying "private, and I don't want to leak any information about it", IIRC
<azeem_> launchpad mind trick
<penguin42> cjwatson: Did you get a chance to look at those procps fixes?
<dupondje> slangasek: you think is a good idea to upgrade cryptsetup to the newest upstream version? It has some nice repair function added :)
<cjwatson> penguin42: no, sorry :-/
<penguin42> cjwatson: No worry, they're segs but neither in important cases
<hyperair> can we make libproxy1 or ubuntu-desktop recommend libproxy1-plugin-webkit?
<hyperair> it's quite confusing when pac files just don't work
<Laney> something other than the shared lib should recommend it, yes
<hyperair> and while we're at it, it would be nice to get a sponsor for https://bugs.launchpad.net/glib-networking/+bug/981856
<ubottu> Launchpad bug 981856 in glib-networking (Ubuntu) "glib-pacrunner does not support file:// pac files" [Undecided,Confirmed]
<hyperair> hmmmm
<Laney> it's tiny so perhaps indeed it could be seeded
<Laney> like the other modules
<hyperair> actually come to think of it, how about making glib-networking-services rec/dep on it?
<hyperair> glib-networking-services just contains the pacrunner
<hyperair> the pacrunner dbus daeemon, i mean
<hyperair> which depends upon libproxy's pacrunner.
<hyperair> hmm there doesn't really seem to be a nice way of making libproxy1-plugin-webkit enter glib-networking-service's depends
<fouad_jh> Hi, is there any documentation for the Ubuntu-Core rootfs?
<fouad_jh> Hi, is there any documentation for the Ubuntu-Core rootfs?
<ion> echoâ¦ echoâ¦
<fouad_jh> so quiet in here!
<cjwatson> yes, it's a weekend
<cjwatson> try https://wiki.ubuntu.com/Core
<fouad_jh> Thanks, I have been trying there for sometime, no luck
<fouad_jh> I should get back to here sometime next week then
<fouad_jh> enjoy your evening
#ubuntu-devel 2012-04-15
<slangasek> cjwatson: yeah, so it's possible that the submitter marked it private after filing it and now I can't read it... oh well :P
<slangasek> dupondje: we're certainly not going to upgrade to a new upstream version of cryptsetup before precise is out, no
<ScottK> dobey: Please have someone test the python-qt4 in precise-proposed so we can figure out if it does the job for you.
<Nafallo> infinity: ping ;-)
<infinity> Nafallo: pong.
<Nafallo> infinity: hi. just updated the bug about dovecot-antispam.
<Nafallo> infinity: the package just needs a rebuild against the current version of dovecot basically.
<infinity> Nafallo: How does it fail?  I just tested here and it WFM...
<infinity> Nafallo: (By installing it and enabling it...)
<infinity> Nafallo: Am I missing something special required to reproduce this?
<Nafallo> nafallo@phoenix:/etc$ grep antispam /var/log/syslog | head
<Nafallo> Apr 15 13:51:38 phoenix dovecot: imap: Error: Module is for different version 2.0.15: /usr/lib/dovecot/modules/lib90_antispam_plugin.so
<Nafallo> we use 1:2.0.19-0ubuntu1
<infinity> Apr 15 09:39:05 cthulhu dovecot: master: Dovecot v2.0.19 starting up (core dumps disabled)
<infinity> I get no whining about antispam at all.  Weird...
<Nafallo> hrm. I'm fairly certain I had debug of the plugin turned on when I got that.
<infinity> Are yoy doing something other than just enabling it in mail_plugins?
<Nafallo> ehrm. it does nothing unless you configure it under the plugin { stanza...
<infinity> If it's just a debug message, but not an actual failure...
<infinity> Well, sure, it does nothing, but it loads.
<Nafallo> well, it didn't work... I got that message, rebuilt it against current dovecot, and things are working now :-)
<infinity> Ahh, here we go.
<Nafallo> it has to be built against the dovecot you want to use AFAICT
<infinity> Yeah, it's broken in that regard.  Just found the Debian bug.
<infinity> And syncing a version that actual sets the hard dep.
<Nafallo> hrm. I tried the debian sid version, and our dovecot is newer :-P
<Nafallo> if that's what you're doing...
<infinity> Eh?
<Nafallo> the sid version is for 2.0.18 I think...
<infinity> I'm syncing 2.0+20120225-2, which actually sets sane deps on the version it's built against.
<Nafallo> it's sane for dovecot 2.0.18, not 2.0.19 ;-)
<Nafallo> you're just going to make it uninstallable
<infinity> Nafallo: It's set dynamically at build time...
<infinity> Nafallo: We don't sync binaries, we sync source.
<Nafallo> oh. hrm. I must have misread the source then :-)
<Nafallo> I did grab the source and eyed the control file :-)
<infinity> Depends: ${shlibs:Depends}, dovecot-imapd (>= ${dovecot:Version}),
<infinity>                             dovecot-imapd (<< ${dovecot:Version}.)
<infinity> DOVECOT_VERSION = $(shell V="$$(dpkg-query -W -f='$${Version}' dovecot-dev)"; echo "$${V%-*}"
<infinity> Nafallo: You on amd64?
<Nafallo> i386 for that server
<Nafallo> but yeah, I checked the diff now :-)
<infinity> https://launchpad.net/ubuntu/+source/dovecot-antispam/2.0+20120225-2/+build/3408319/+files/dovecot-antispam_2.0%2B20120225-2_i386.deb
<infinity> ^-- Give that a spin, then.
<Nafallo> totally missed that, and I totally agree with syncing :-)
<infinity> If that fixes it, bug closed.
 * Nafallo waits for mail
<infinity> Which mail would that be?
<infinity> Oh, to test your server. :P
<infinity> nafallo@magial?
<infinity> But spelled right.
<Nafallo> magicalforest.net :-)
<infinity> Yeah, already sent.
<Nafallo> right. now that postfix is "fixed" again, this should work better.
<Nafallo> for some reason postgrey isn't playing ball.
<infinity> I wonder if that's a dovecot or -antispam bug/misfeature.  Cause requiring exact version matches is insane.
<Nafallo> yeah, seems to be working now :-)
<infinity> Right, I'll let you do the bug closure honors, since you tested it. :P
<Nafallo> cheers :-)
<infinity> And sorry about pulling rank.  I get anal when we near release week.
<infinity> And review everything.  Even crap I don't have to. :P
<Nafallo> no worries. I like this fix better.
<Nafallo> I'm avoiding karma ;-)
<infinity> Hah.
<infinity> A bit late for me to do that.
<Nafallo> Depends: libc6 (>= 2.4), dovecot-imapd (>= 1:2.0.19), dovecot-imapd (<< 1:2.0.19.)
<Nafallo> not sure what that dot is doing there... but bother! :-P
<infinity> The dot is there to allow for the next minor version up.
<infinity> Clever hack.  Ish.
<Nafallo> aaah, I see.
<infinity> Or rather, "everything but the next one up"... So, should all for Debian revisions.
<Nafallo> right :-)
<infinity> s/all/allow/
<infinity> I haven't slept in a couple of days.
<infinity> I'm a bit loopy.
<Nafallo> now we just need to remember to rebuild this damn package if we ever upgrade dovecot :-P
<infinity> Yeah.  On every new major, it looks like.
<infinity> So silly.
<infinity> Someone should just fix it (or dovecot, whichever is broken).
<infinity> I'm assuming the plugin is at fault here.
<infinity> I can't imagine that dovecot breaks ABI on every release and forces plugins to rebuild.
<Nafallo> I think this plugin is moving to the dovecot vcs server, so hopefully this can be in the tarball or something.
<infinity> That would kinda defeat the whole point of out-of-tree plugins.
<Nafallo> agreed
<infinity> I guess I should be glad I don't use any plugins, so I don't have to know who to blame. :P
<Nafallo> hah
<Nafallo> well, I guess you don't use mail on your mobile either then ;-)
<infinity> I'm not sure I follow. :P
 * Nafallo declares victory on anti-spam server-side.
<infinity> I do my spam filtering at SMTP time, like a sane person.
<Nafallo> that is server-side ;-)
<Nafallo> and I've got that to now :-)
<Nafallo> and with dovecot-antispam, thunderbird can train dspam for me ;-)
<JanC> Nafallo: do you know about a way to do that with Evolution?
<Nafallo> JanC: I haven't used evolution in years, so I'm rusty.
<Nafallo> JanC: all it is really is thunderbird moving spams into "Junk". with the plugin infinity and I discussed, that's all I need to retrain mail.
<JanC> hm
<JanC> I might want to look into that then
<JanC> or maybe Thunderbird/Mozilla fixed all the bugs that made me switch to Evolution years ago...
<infinity> Thunderbird's fairly shiny, still a bit heavy, though.
<infinity> But don't listen to me, my solution to bloated mail clients is to use mutt.
<JanC> when I last looked, some of those Mozilla/Thunderbird bugs had been open for 10+ years...
<JanC> at least Evolution does things more or less correctly (in between crashes)
<cjwatson> 10+-year-old bugs are a sign of a 10+-year-old project.
<infinity> From the POV of "correct", I find Thunderbird to be a pretty well-behaved IMAP client.
<infinity> I just prefer mutt because it's lightweight.
<JanC> they were 10 years old 2 or 3 years ago  ;)
<cjwatson> Then it's the sign of a 12- or 13-year-old project. :-)
<JanC> cjwatson: sure, but if they hurt everyday use more than Evolution then that's a bad sign IMHO  ;)
<cjwatson> I'm not in a position to judge, since I'm a mutt user too.  I just tend to knee-jerk at the "oh no, it has old bugs" criticism.
<JanC> cjwatson: do you consider a a mail client that doesn't allow you to edit a plain text text mail properly before sending it "usable"...?  ;)
<cjwatson> JanC: I'm not in a position to say whether Thunderbird has that bug in general or whether it's in specific cases, so don't try to draw me into making pronouncements. :-)
<JanC> it has that bug in certain cases (most obviously when replying to a HTML mail), but I consider that a serious bug in every case...
<JanC> it also does things like rewrap plain text mails after you hit the "send" button and such
<kklimonda> JanC: so we just have to make Evolution crash less, and make its interface not suck so badly, and we can go back ? that should be easy ;)
<JanC> kklimonda: and make it use less memory  ;)
<JanC> the interface isn't worse than Thunderbird BTW
<kklimonda> JanC: well, that's easy to fix - just add another memory stick ;)
<JanC> kklimonda: that doesn't make it use less memory  ;)
<kklimonda> JanC: but it can leak more! ;)
<JanC> hehe
<JanC> well, at least there are workarounds for memory leaks (restarting evolution)
<JanC> those workarounds don't exist for the fundamental bugs in thunderbird...
<JanC> (AFAIK)
<JanC> it's inconventient, but not as embarrassing as sending mail that doesn't look as intended  ;)
<penguin42> JanC: GUI Mail clients that get plain text sending right are probably in the minority
<JanC> penguin42: surprisingly, Evolution does
<JanC> AFAIK ;)
<penguin42> possibly, not used it - but as I say, it's rare
<JanC> I never had/saw any problems with it
<JanC> actually, Netscape Mails 4.x did those things correctly too
<JanC> Mail
<JanC> they broke this in the open source Netscape/Mozilla fork
<hyperair> i think open source GUI mail clients tend to get plain text sending right.
<hyperair> it's the proprietary ones that end up with oddities
<kklimonda> JanC: huh, wrt evolution in precise, it seems pretty broken to me - I can't select text in html messages properly ;)
<JanC> kklimonda: I use the html-to-plain-text plugin, so I never see any HTML messages  ;)
<kklimonda> I guess it's a solution of some sort ;)
<JanC> so, maybe Thunderbird works with HTML mail, Evolution works with plain text, pick whatever you want  ;)
<kklimonda> but it looks like something broke - even with plain text emails I don't see them on a white background..
<kklimonda> damn, I can't figure out how to reset settings
<kklimonda> evolution is like a weed, it stores settings just about everywhere ;)
<JanC> kklimonda: it worked for me yesterday (or Friday?)
<JanC> anyway
<JanC> Evolution probably needs refactoring etc.
<JanC> and more than 0.75 developers working on it
<kklimonda> right
<kklimonda> that's the main problem
<kklimonda> if only Canonical.. *whistles*
<JanC> but considering all that, it's a shame Thunderbird can't match Evolution on so many points with probably 20 full-time developers...
<kklimonda> lol
<kklimonda> Thunderbird is actually being actively developed by Mozilla devs?
<kklimonda> I've always thought it was more of a community project
<JanC> there are several Mozilla devs paid to work on it, yes
<hyperair> imo evolution can't match thunderbird on a lot of points, though..
<JanC> and vice versa  ;)
<hyperair> using evolution makes me think that i'm the only one in the world accessing a gmail account over a crappy network.
<JanC> it just depends on what features you need
<hyperair> like proper imap access?
<JanC> evolution has proper imap4 access
<hyperair> so it claims
<hyperair> and so every other mail client i've tried so far claim.
<JanC> although gmail doesn't have proper imap4 servers  ;)
<hyperair> but only thunderbird gets it right
<kklimonda> damn, broken on a guest account too
<hyperair> claws gets completely paralyzed
<kklimonda> how!! it's been only few months since 11.10 and it worked fine..
<kklimonda> argh
<hyperair> evolution.. not as copmletely paralyzed, but almost just as bad.
<JanC> gmail is about the worst e-mail client I ever used  :P
<hyperair> JanC: maybe. and i'm guessing outlook.com's imap isn't perfect either..
<kklimonda> hyperair: the problem is gmail isn't a proper imap server ;)
<hyperair> i like gmail's labels. too bad they don't work that well over imap.
<hyperair> kklimonda: and neither is outlook.com, i suppose?
<hyperair> kklimonda: from my experience nothing handles imap like thunderbird does.
<hyperair> even with my university's mail account
<kklimonda> hyperair: come on, Microsoft added IMAP support only so people can't complain
<JanC> hyperair: I don't know about outlook.com, but the Exchange IMAP4 server is quite good AFAIK...
<hyperair> heh
<hyperair> JanC: except that it didn't work out quite so well via evolution either
<kklimonda> hyperair: have you seen how bad is imap support in outlook? it's obvious they are pushing exchange by making alternatives suck more ;)
<hyperair> really, i leave evolution downloading mail headers through the night
<hyperair> next morning, i click on another folder
<hyperair> and click back
<hyperair> and then...
<kklimonda> hyperair: wow, how many mails do you have? :)
<ScottK> IMAP is a twisty turny maze of RFCs and all look alike, so it's tough to get both a client and a server well implemented.
<hyperair> ...it downloads *EVERY* single mail header *AGAIN*
<kklimonda> weird
<hyperair> evolution and claws both make me feel like pulling my hair out, just because of their crappy imap access
<JanC> kklimonda: outlook being bad doesn't mean exchange is bad  ;)
<JanC> traditional IMAP isn't very useful for mobiles
<hyperair> kklimonda: 40,301 emails, apparently.
<JanC> so thre are extentions for that
<kklimonda> hyperair: and they all sit in your inbox? :)
<hyperair> kklimonda: no hang on, that's the count of gmail conversations. i have no idea how many emails there actually are..
<hyperair> kklimonda: nah, that's in total
<hyperair> the all mail folder
<hyperair> i guess i could unsubscribe, but after that there's no real way of sending mail there from evolution
<JanC> 40k mails is peanuts  ;)
<JanC> you get that after 1-2 months on LKML...  :P
<hyperair> JanC: tell that to evolution, which barfs when fetching them.
<kklimonda> JanC: I use gmane for mailing lists ;)
<hyperair> okay, thunderbird reports 115238
<JanC> I've never seen Evolution barf on # of mails
<JanC> it's slow, yes
<hyperair> good for you
<hyperair> now time out a couple of connections and see how evolution handles them
<JanC> hyperair: you restart it  ;)
<hyperair> see, apparently i'm the only evolution user who lives on a university campus with idiots manning the network.
<hyperair> JanC: ah yes, evolution --force-shutdown. that was my favourite command during that time
<hyperair> that reminds me, it used to hang my gnome-panel clock applet thing due to network calendars
<JanC> my main point is that you can't work around the bugs in Thunderbird, while Evolution has --force-shutdown to   :P
<JanC> to solve things
<hyperair> Â¬_Â¬"
<hyperair> that's not a solution
<hyperair> you force-shutdown, start downloading mail all over again
<hyperair> and then it times out again
<hyperair> and you force-shutdown again
<JanC> hyperair: it's better than nothing, right?
<hyperair> rinse and repeat.
<JanC> I never saw it time-out
<hyperair> JanC: but it *is* nothing. you repeat that process over and over and it never completes.
<kklimonda> hyperair: and how well does thunderbird support calendars? ;)
<hyperair> kklimonda: really well, with lightning
<kklimonda> too bad it's not in main ;)
<hyperair> yeah, too bad.
<kklimonda> (I'm actually surprised that they've decided not to demote evolution to universe, and not promote lightning to main)
<JanC> hyperair: the main point is that Thunderbird doesn't allow me to do what I want, and Evolution does, with an occasional restart
<kklimonda> I guess calendar is not shiney enough to ship it by default..
<JanC> I'd prefer a better mail client of course  :P
<hyperair> that thing ought to be killed with fire. i swear the devs thought that everybody used a rock-solid internet connection that moved blazingly fast.
<hyperair> JanC: what do you want, anyway?
<kklimonda> hyperair: I'm not a huge fan of Evolution but people seem to use it over thunderbird in companies (at least the few I've heard of ;))
<hyperair> kklimonda: that's because thunderbird doesn't have MAPI/Exchange support, right?
<hyperair> (people also tend to use Windows in companies).
<kklimonda> hyperair: it's not like evolution supports it that well ;)
<hyperair> well i suppose evolution in the office is rather bearable, when you think about it..
<hyperair> mail server on the local network..
<hyperair> blazing fast local network..
<kklimonda> :)
<hyperair> actually reliable local network..
<hyperair> see, it's all about the network
<hyperair> evolution behaves like the network is infallible
<hyperair> a few cycles back, it used to turn grey every time a few packets got dropped
<hyperair> recently it's been better, but i just get a crapton of those progress things at the bottom that take forever to time out, and don't progress either.
<JanC> My IMAP server is in Germany, while I'm in Belgium, so I'm not in a LAN  ;)
<kklimonda> sure, but have you tried using Evolution over flaky edge connection? ;)
<JanC> probably not
<JanC> maybe Mozilla got that implemented better?
<kklimonda> definitely
<kklimonda> evolution has problems with terminating stalled connections
<JanC> but that doesn't excuse their lack of support for other features...  :-/
<hyperair> like?
<JanC> i think I listed several of them before?
<hyperair> i only read something about html..
<hyperair> er html-to-text?
<hyperair> which is also present in thunderbird
<JanC> hyperair: actually, their editor doesn't support plain text mails properly
<kklimonda> "edit plain text before sending"
<hyperair> JanC: how so?
<hyperair> i've been sending plain text mails for a couple of years now using thunderbird
<JanC> hyperair: unless they fixed that recently  :P
<hyperair> i wouldn't call a couple of years recent...
<kklimonda> hyperair: you have to jump through the hoops to send git patches without TB breaking them
<hyperair> kklimonda: ah, is this about line-wrapping?
<JanC> among other things
<kklimonda> hyperair: last time I've tried setting it up I've had to change two or three options in about:config and then TB was still displaying content wrongly (it was sending it properly though afair)
<JanC> it does other things it shouldn't do
<kklimonda> hyperair: well, that's one complain for TB I can think of right now :)
<JanC> it should leave plain text mails alone, period
<hyperair> hmm i like the line-wrapping though..
<JanC> hyperair: Evolution has line-wrapping when you want it
<hyperair> besides that, i think it mostly leaves my plain-text mail alone.
<hyperair> JanC: right, but i haven't seen any differences between evolution's and thunderbird's patch handling
<JanC> hyperair: you must be lucky  ;)
<JanC> hyperair: now try to reply to a HTML mail with a plain text mail...   ;)
<hyperair> JanC: works for me.
<hyperair> am i supposed to see something wrong?
<JanC> but does it work for you recipients?
<hyperair> yeah it does
<hyperair> they just get it in plain text.
<JanC> that would be a serious improvement over previous behaviour of Thunderbird then
<hyperair> i guess
<hyperair> open source projects tend to move fairly quickly
<hyperair> evolution aside
<JanC> hyperair: if you think pre-2000 bugs being fixed in the last 1-2 years is "quickly", maybe  :P
<JanC> even Evoltiuon bugs get fixed fatser
<hyperair> heh :P
<hyperair> i think it's an issue of *which* bugs
<kklimonda> JanC: come on, it's not like evolution has no old bugs opened ;)
<JanC> kklimonda: it might well have, but most of them don't impact me as much as the long-time Thunderbird/Mozilla-bugs do/did
<JanC> actually, many Thunderbird bugs are older than Evolution
<hyperair> that may just mean that the new bugs are fixed faster
<JanC> which is not useful  ;)
<hyperair> well think about it. i'm sure you've seen horribly complicated X bugs that never get fixed lying around in Ubuntu.
<JanC> anyway, I think the point is that no mail client is really good
<hyperair> yeah
<hyperair> i think claws would be great if it didn't get screwed over by a bad network
<JanC> one good point of claws seemed to be that it didn't need insane amounts of RAM
<hyperair> hmm yeah
<hyperair> actually it did for me
<hyperair> it actually hit 200-300M
<hyperair> which was better than thunderbird, which is happily sitting around 500M here
<hyperair> oh it's 362M now hmm
<JanC> Evolution needs are expressed in GiB on my (64-bit) system
<dupondje> To join the conversation, I really miss descent LDAP support in TB
<JanC> dupondje: how well is LDAP support in Evolution currently?  (AFAIK it wasn't bad in the past, but...)
<dupondje> no idea on the current status
<dupondje> but there was read-write support a year ago
<dupondje> which still isnt in TB
<dupondje> And evolution got a nice LDAP schema, Mozilla made one, but still Alpha
<JanC> if unless somebody broke it, it probably still works  ;)
<kklimonda> damn, how was the gnu tool for browsing through C projects called? it started with C afair
<JanC> so*
<kklimonda> cscope!
<JanC> âº
<verwilst> hi
<verwilst> any knows why dlm-pcmk has been removed from precise?
<dupondje> Hi mr verwilst  :)
<dupondje> verwilst: https://launchpad.net/ubuntu/+source/redhat-cluster source is still there .. but the bin is not build
<verwilst> hi dupondje
<verwilst> http://packages.ubuntu.com/search?keywords=dlm-pcmk&searchon=names&suite=all&section=all
<verwilst> it's been there up until precise
<verwilst> clustering under linux is sucky enough without missing modules :D
<dupondje>   * Drop dlm-pcmk and gfs-pcmk.
<dupondje>     - debian/control: Drop control rules for such packages.
<dupondje>     - debian/{gfs,dlm}-pcmk.install: Dropped
<verwilst> yes, but why :P
<kklimonda> verwilst: ask roaksoax, he's the one who's uploaded the package which dropped it
<verwilst> roaksoax, ^^ :P
<JanC> heh, all these belgians here suddenly...  :P
<dupondje> invasion
<JanC> would be useful if you guys worked for ubuntu-be locoteam too, from time to time  ;)
<dupondje> verwilst: if I look good the dlm-pcmk is now in another git, and not more included in the cluster source
<dupondje> JanC: where you need help in the locoteam ? :)
<verwilst> myeah ok, but that doesnt bring back my ability to use clvm with corosync ;)
<dupondje> you asked for the reason ;)
<dupondje> could try to create a package from the new source
<dupondje> and get it into Precise
<verwilst> but there must be a reason why
<dupondje> because the source split up? :)
<JanC> dupondje: you should join #ubuntu-be and/or our mailing list for that, but maybe you can help with an Ubuntu Global Jam event or such?
 * JanC goes to sleep now but will check back on that tomorrow...
<dupondje> verwilst: https://wiki.ubuntu.com/ArchiveAdministration#NBS
<verwilst> hm
<verwilst> dupondje, heb je de link van de nieuwe repo?
<dupondje> source split up, new package was uploaded without pcmk, but no new package created for pcmk ...
<dupondje> new repo ?
<verwilst> location of the pcmk code :)
<verwilst> " if I look good the dlm-pcmk is now in another git,"
<dupondje> https://fedorahosted.org/cluster/wiki/HomePage
<dupondje> http://www.redhat.com/archives/cluster-devel/2009-January/msg00013.html
<verwilst> bleh
<verwilst> so cluster is at 3.1.7 ( 3.1.8 is latest ), and i guess the dlm.git is version.. 3.99.2?
<dupondje> http://git.fedorahosted.org/git/?p=cluster.git;a=tree;f=group/dlm_controld;h=23322874fb5a3686f56b68f28eab1206dff9370c;hb=e2fe317d5e1c313f5bece465e0e703b0548d50cf
<dupondje> seems there is still dlm, but without pacemaker support...
<verwilst> i've mailed the redhat guy
<verwilst> http://git.fedorahosted.org/git/?p=dlm.git
<verwilst> this ranks as a solid 8 on my suckiness scale!
<wolfslord> I'm using Ubuntu 12.04 with Gnome-shell. Installed gnome-tweak-tool and changed mouse theme to adwaita but cursor only changes when selecting, loading, resizing, etc
<wolfslord> but the normal mouse is still the same
<wolfslord> Does anyone knows how to chenge that?
#ubuntu-devel 2013-04-08
<lifeless> why isn't there a linux-image-generic package on armhf ?
<mwhudson> lifeless: what would that be?
<mwhudson> lifeless: currently kernels are soc-specific
<lifeless> mwhudson: maybe a placeholder.
<lifeless> mwhudson: I thought the Linaro project was to make the soc-specificness go away?
<mwhudson> it's working on it
<mwhudson> far from done yet aiui
<mwhudson> and will probably never make a kernel that boots on all boards currently supported by ubuntu afaik
<mwhudson> more future focused
<cpatrick08>  I was wondering if there has any new info on the rolling development, how to activate it.
<pitti> Good morning
<ion> that
<dholbach> good morning
<ion> that
<mlankhorst> could someone approve xorg-server?
<mlankhorst> in raring
<pitti> tjaalton: FYI, PPA mesa has run here since the morning
<mlankhorst> \o/
<pitti> tjaalton: I didn't notice any regression yet, except that bringing up the dash is very slow
<pitti> but TBH I don't remember how slow it was with the current raring mesa
<mlankhorst> it's slow on llvmpipe too
<pitti> slow == I see about 5 "slides" which last ~ 0.2 s each
<pitti> so it's far from a proper fading effect
<smb> You won't know how slow until you try llvmpipe on an atom... :-P
<pitti> smb: oh, I do
<pitti> I'm talking about my X201 here (intel arrandale)
<smb> pitti, but that is i915 isn't it? That would not be llvmpipe?
<mlankhorst> smb: which I did? :P
<pitti> smb: yes; I meant that I know how unity feels on llvmpipe on an arm or netbook as well
<smb> mlankhorst, Yeah, me too ... unfortunately did not realize the new poulsbro trap
<mlankhorst> some old asus eee with pineview graphics, i tried software fallback for giggles
<smb> pitti, Ah yeah
<smb> mlankhorst, That box is an Intel Atom with gma500 (2D only integrated). By the time anything happens one already things the keypress/mouseclick did not get accepted. There is not really a way around the slowness but having fad-in and -outs for everything does not help either. ;-P
<mlankhorst> yeah unity needs to disable whatever is causing the slowness (blur, I guess?) for llvmpipe and slower laptops
<seb128> mlankhorst, it does disable it
<seb128> on llvmpipe at least
<smb> Not sure it would be visible there, in ccsm it "dash blur" was set. But disabling it did not change anything either.
<tjaalton> pitti: thanks for testing!
<tjaalton> pitti: about the slowness; is it any worse than before?
<pitti> tjaalton: would it be helpful to downgrade to raring again, and compare?
<pitti> ah, snap :)
<tjaalton> yeah
<pitti> tjaalton: ok, will do
<tjaalton> libgl1-mesa-dri, -glx should do
<tjaalton> hmm or not
<pitti> I'll just use ppa-purge
<tjaalton> ah, right
<mpt> A crash in apport-retrace? That must mean I win a prize of some sort.
<mpt> Now, will that crash itself be retraced...
<pitti> mpt: no need to retrace Python crashes :)
<pitti> tjaalton: dash reveal/hide is a lot faster with raring's mesa
<tjaalton> pitti: bah
<tjaalton> so it's gen5 too..
<tjaalton> gen6%7 got fixed
<tjaalton> the regression that is
<mitya57> pitti: any news about https://code.launchpad.net/~mitya57/debian/sid/calibre/remove-embedded-libraries/+merge/157195 ?
<pitti> mitya57: still on my list; last week was too short (holidays) and too busy (psql security update), sorry
<mitya57> thanks pitti!
<mitya57> Maybe I'll look at some of the "Known issues" this week
<tjaalton> pitti: do you think the performance is so bad that it would block the update? anholt isn't online so can't ask how long it would take to get fixed
<Riddell> jtaylor: you added a patch to pyqt?
<pitti> tjaalton: it's certainly bearable, but it looks quite ugly
<Riddell> jtaylor: I think it's making pykde fail
<dpm> Hi all, I don't seem to be able to properly boot my laptop anymore on raring: I get this error - "mountall: could not mount filesystem: /boot"
<dpm> Any ideas on what I could do or look at to fix it?
<dpm> I've ran fsck and it complains about "ext2" filesystem not recognized
<cjwatson> ext2 might be modular and for some reason missing or unloaded
<dpm> cjwatson, I'm not sure. For some reason, if I skip the prompt to load /boot, the system boots to lightdm, I can then log in, but there is no network
<dpm> I've now removed the hard disk, plugged it into my desktop, and after entering the encryption passphrase nautilus tells me it cannot mount it due to an unrecognized file system
<dpm> does anyone know how I can mount the encrypted volume from the command line? That might give me more of a clue what the error is
<pitti> dpm: udisksctl unlock -b /dev/sdXXX; udisksctl mount -b /dev/mapper/XXX ?
<dpm> let me try
<pitti> dpm: oh, this won't work in an initramfs shell, if you meant that
<pitti> (just read some backscroll)
<dpm> pitti, I've got the disk attached to my desktop PC now, I thought I'd run fsck over it. I've tried to mount it with nautilus and it fails after entering the encryption passphrase. I'm trying to mount it manually now. I tried these instructions: http://askubuntu.com/a/63598/9781 but the "sudo mount /dev/mapper/my_encrypted_volume /media/my_device" step fails with "mount: unknown filesystem type 'LVM2_member'"
<dpm> so shall I try your commands now, as in "udisksctl unlock -b /dev/sdb5; udisksctl mount -b /dev/mapper/5" (where sdb5 is the encrypted partition)
<dpm> pitti, I'm poking a bit in the dark here, so I'm not sure I did it right, but here's what I did: http://paste.ubuntu.com/5689323/
<pitti> dpm: what does sudo blkid -p /dev/mapper/luks-9cf37a83-e84a-4b85-9bba-7bcbaba8058e say?
<dpm> pitti, $ sudo blkid -p /dev/mapper/luks-9cf37a83-e84a-4b85-9bba-7bcbaba8058e
<dpm> /dev/mapper/luks-9cf37a83-e84a-4b85-9bba-7bcbaba8058e: UUID="d7SXgb-eMNG-0jiA-E3EA-L0M2-VsSJ-3r5Xmo" VERSION="LVM2 001" TYPE="LVM2_member" USAGE="raid"
<mlankhorst> can some sru admin approve xserver-xorg-video-nouveau in quantal-proposed?
<dpm> I believe it trips on the LVM2_member bit, which is where the other instructions I tried where failing
<pitti> dpm: oh, so it's partition-on-lvm-on-luks
<pitti> I had expected our dmsetup/udev rules to automatically create the LVs for those
<dpm> pitti, I've no idea what it is, that's what the installer created when I installed (I think) quantal on that hard disk
<dpm> is there a way to mount it, so that I can try to recover my data?
<pitti> dpm: is that your only PV?
<dpm> what's a PV?
<pitti> dpm: recent dmesg output might help to see what went on
<pitti> "physical volume", i. e. the bits a VG (volume group) is built from
<pitti> dpm: wait, /dev/mapper/ubuntu-root, was that created by the udisksctl unlock command, or is that your desktop's LVM?
<xnox> dholbach: can you RT my twitter status to ubuntudev and collect answers? =) https://twitter.com/tdlk/status/321248213959069696
<xnox> dholbach: webteam is pondering how to convey the answers to those questions in less than 140 characters ;-)
<xnox> (as that's the space we have on the website for such text)
<dholbach> xnox, I collect answers?
<xnox> dholbach: just retweet it on the @ubuntudev to get exposure.  I will monitor the replies =)
<dholbach> ah ok - sure :)
<dpm> pitti, to the first question: here's what the laptop disk I'm trying to recover looks like partitionwise: http://pastebin.ubuntu.com/5689356/
<xnox> dholbach: I'm not "popular" on twitter =)
<dholbach> xnox, we could do the same on G+? there might be even more replies there
<pitti> dpm: I meant, are you using full disk encryption on your desktop (i. e. the machine you just plugged this in)?
<pitti> dpm: i. e. is /dev/mapper/ubuntu-root from your current host, or actually from the plugged in device?
<pitti> dpm: it might be that /dev/mapper/ubuntu-root is just the one you want to mount
<pitti> dpm: sorry, back in 45 mins; I hope someone else can jump in in the meantime
<dpm> pitti, I don't use full encryption on my desktop, just home directory encryption IIRC
<xnox> dholbach: sure =) but please add "In less than 3 sentences." Cause G+ allows one to write essays......
<pitti> dpm: otherwise, I'll need the contents of /dev/mapper/ before "unlock" and dmesg after
<dpm> pitti, no worries, thanks for all your help
<dpm> ok
<pitti> dpm: ok, so udisksctl mount -b /dev/mapper/ubuntu-root it is
<dpm> pitti, it worked! \o/
<dpm> pitti, ok, now I'll save all data first, and then will try to find out what's going on. Is there any extra step I need to do to unmount the encrypted volume?
<Pjotr> Hello, I have a question about the Ubuntu download page
<Pjotr> Perhaps it's a good idea to present the LTS version as the primary eye-catching download option. Not as a "mere"second option. So that beginners with Ubuntu, will usually pick the LTS.
<Pjotr> Reason: as we know, starting with Raring, support for intermediate ("standard") releases will be halved to nine months.
<Pjotr> As Mark Shuttleworth said: "Our working assumption is that the latest interim release is used by folks who will be involved, even if tangentially, in the making of Ubuntu, and LTS releases will be used by those who purely consume it." http://www.markshuttleworth.com/archives/1246
<Pjotr> The main issue here is support period, I think. It's not nice for a beginner to be forced to upgrade very quickly...
<Pjotr> What do you think?
<jcastro> I believe there's a bug open to change the page to default to LTS
<jcastro> I know I've seen it, I just don't have it handy
<stokachu> is there a "mentor" irc channel for someone like bug 1165927
<ubottu> bug 1165927 in Ubuntu "List with CRITICAL tons of bugs, dont have the time to add them seperately" [Undecided,Invalid] https://launchpad.net/bugs/1165927
<dobey> stokachu: #ubuntu-bugs maybe? (is that even a channel?)
<stokachu> ah looks to be the closest thing
<stokachu> thanks dobey
<pitti> dpm: \o/
<dobey> i'd mark it invalid with a note that they need to be filed separately. if one doesn't have the time to file bugs separately, i haven't got time to sort through the crap and fix them either :)
<pitti> dpm: eject it in nautilus, or udisksctl unmount -b /dev/mapper/
<stokachu> dobey: agreed
<dpm> pitti, thanks!
<dpm> dobey, sorry it took a while, approved the e-mail now
<dobey> dpm: thanks
<dholbach> barry, thanks
<barry> dholbach: sure thing
<doko> DktrKranz, could you have a look at https://launchpadlibrarian.net/136234437/buildlog_ubuntu-raring-armhf.pyexiv2_0.3.2-5ubuntu1_FAILEDTOBUILD.txt.gz ? looks like scons does add the arch specific include path only
<doko> jodh, cking: $ apt-cache -n search smatch
<doko> $
<DktrKranz> doko: probably not before the weekend, unfortunately
<jodh> doko: it's not in the archive, apparently as it specifies no license.
<stokachu> dobey: hopefully these new patches dont suck
<zaytsev> cjwatson: hi colin, could you please be so kind to tell me if scripts/casper-bottom/25adduser runs with set -e or set +e? there is nothing at the top of the script. the reason why i'm asking is that i'd like to know whether everything will break if i just delete /usr/share/applications/ubiquity-gtkui.desktop or it will work still
<zaytsev> cjwatson: the reason why i'm looking for a solution as simple as deleting the file is that i want to avoid rebuilding the ram disk if at all possible
<stokachu> dobey: didn't see your attachment until now :\
<stokachu> dobey: fortunately it is the same as yours
<dobey> stokachu: it is not the same :)
<dobey> stokachu: you applied my changes to the packages from the wrong pocket
<stokachu> i pulled from whats out in the archive
<dobey> you pulled from the release pocket, not from proposed
<stokachu> damnit
<cjwatson> zaytsev: +e, although you do need to make sure that the last command in the script exits 0
<cjwatson> zaytsev: (but that should be fine here)
<zaytsev> cjwatson: thank you very much! it seems to work
<infinity> BenC: *nudge*
<infinity> BenC: I can haz linux-ppc rebase?
<stokachu> dobey: do you mind looking over my precise debdiff now?
<zyga> xnox: ping
<zyga> xnox: I've got most of the data now ready, I will probably have the first version of the new data file for raring x86 amd64 this evening
<xnox> awesome.
<zyga> xnox: if my mirror is not finished on time I will have evetything by tomorrow
<zyga> xnox: I had a look at the new data
<zyga> xnox: I will need to go through some manual cases (currently about 200 of them) to manually extract alternative updates
<zyga> xnox: but it looks better than old data already
<xnox> hmmm...
<xnox> zyga: if it has upstart-monitor in it, I will be happy =)
<zyga> xnox: with the exception of certain packages that are in the manual section (like vim or emacs)
<zyga> xnox: let me check :)
<zyga> xnox: althouh u- is far in the mirror, I'm earlier than that :)
<zyga> xnox: unlike the old solution this one is very correct
<zyga> xnox: and should have no false positives
<xnox> cool.
<zyga> xnox: and absolutely no missing items
<zyga> xnox: I wrote a post about c-n-f just now, it's on planet ubuntu
<zyga> xnox: so maybe there will be more interest in fixing the actual user experience for remote uers
<zyga> users
<xnox> =)
<t1mp> mhall119: ping
<jbicha> hi, could someone from the SRU team take a look at bug 1128804? it's been sitting in the quantal queue for 6 weeks now
<ubottu> bug 1128804 in mutter (Ubuntu Quantal) "Update mutter/gnome-shell to 3.6.3" [Medium,In progress] https://launchpad.net/bugs/1128804
<infinity> jbicha: Can you do me a favour and nudge me about that again in ~3h?  I have a series of poking and prodding appointments to get to today, but will be SRUy when I get back.
<jbicha> infinity: sure, thanks
<mhall119> t1mp: pong
<t1mp> mhall119: I was just reading http://mhall119.com/2013/04/building-an-ubuntu-sdk-app-rev-1/
<t1mp> mhall119: nice post. But I noticed something with the header that I though I might help with
<t1mp> mhall119: the spacing between the header and first list item is a bit too big. If you do not set anchors for Page/PageStack/Tabs, it should all be automatic for you.
<t1mp> mhall119: but since I pinged you I noticed 2 things: 1. You use a custom header in newer revisions, and 2. In raring archives is 0.1.38 of the ui-toolkit and I fixed some header behavior/spacing in 0.1.39.
<cking> doko, you're most welcome to package up smatch ;-)
<t1mp> t1mp: so my comments may not be that valid anymore.  But if you want to use the SDK header you can always ping me if there are issues with it. :)
<t1mp> mhall119: ^
<BenC> infinity: Yep, will do within some hours
<mhall119> t1mp: reading and eating at the same time, I'll be a bit slow
<t1mp> mhall119: ok :)
<mhall119> t1mp: yeah, the header's behavior changed between when I wrote that code and when I went back for a screenshot
<t1mp> mhall119: if you want to try stuff with the SDK header, make sure you have qtdeclarative5-ubuntu-ui-toolkit-plugin version 0.1.40 because since 0.1.38 some issues were fixed.
<mhall119> t1mp: ok, do we have updated docs I can push to developer.u.c/api/?
<mhall119> some things there look out of date too
<t1mp> yes! we have updated docs.
<t1mp> it is out of date, but I don't know the process to get it from our bazaar repository to the website
<mhall119> where?
<t1mp> the documentation is automatically generated from the source with qdoc.
<t1mp> mhall119: if you check out lp:ubuntu-ui-toolkit there is a documentation/generate_html.sh that creates the html.
<mhall119> dpm: ^^ can we automate that on developer.u.c?
<t1mp> mhall119: there are big changes with a bunch of new examples for pagestack, page, mainview, tabs
<t1mp> ^+ToolbarActions
<mhall119> t1mp: and there are all in the PPA for quantal, as well as the archives for raring?
<t1mp> mhall119: no, I just discovered that they are not.
<t1mp> mhall119: they are in our ppa https://launchpad.net/~ubuntu-sdk-team/+archive/ppa/+packages but not in the raring archives
<t1mp> mhall119: but I'll check with Mirv tomorrow to figure out how to get it in the raring archives automatically
<dpm> t1mp, mhall119, yeah, we can automate it when the Ubuntu theme is integrated into the documentation for the SDK. I've got a merge proposal I sent quite a while ago for that. If someone could help with getting that in, it'd be a lot less painful to update the documentation on d.u.c -> https://code.launchpad.net/~dpm/ubuntu-ui-toolkit/developer-style-api-docs/+merge/152564
<t1mp> greyback: you were reviewing that. Is there still something that needs to be fixed?
<greyback> t1mp: see the last comment I made. Those were my thoughts at the time
<t1mp> dpm: I get the same warnings as greyback mentioned.
<t1mp> dpm: some css files are missing
<t1mp> greyback: ok thanks
<dpm> t1mp, greyback I haven't looked at that branch in a while, let me do it now
<t1mp> dpm: thanks
<greyback> dpm: I'm still not liking that you integrate the whole theme into the SDK's repo. I'm surprised there isn't some server-side magic to add standard headers & footers to a bunch of HTML
<t1mp> dpm: can you bzr merge lp:ubuntu-ui-toolkit to avoid problems with merging?
<greyback> dpm: it'll do, of course. It just means lots of duplicate code spread around
<dpm> t1mp, greyback, how are you getting those warnings? I'm running the generate_html.sh script and it does not give me any warnings
<t1mp> dpm: maybe you need to add the css files to bzr because we don't have them.
<dpm> timp, I've just checked out the branch to /tmp, they are in bzr
<greyback> dpm: run the 'qmake' command. It's the build system we're using. Some file paths specified in the qdoconf files are not correct
 * t1mp otp
<t1mp> brb
<dpm> greyback, from the top of the source tree, or on the documentation/ folder?
<greyback> dpm: top
<dpm> ok, trying that now
<mhall119> greyback: in the future I would like to import qdoc output into a Django site that will add the theming
<dpm> greyback, in terms of server magic, I don't know of any way, so I'm open to any suggestions. In the future, as Mike is saying, we want to generate documentation differently
<greyback> mhall119: sounds great!
<greyback> dpm: ok
<mhall119> greyback: but I'm going to need some qdoc expert help
<greyback> mhall119: we'll be happy to help
<mhall119> cool, thanks
<jtaylor> Riddell: re pyqt, yes how does pyqt fail?
<jtaylor> Riddell: I doubt its the patch but the change that forced as to add the patch
<dobey> stokachu: better :)
<Riddell> jtaylor: it was the patch, I've fixed it now
<jtaylor> Riddell: have you forwarded it then?
<jtaylor> Riddell:  its a patch from upstream
<Riddell> jtaylor: yes, fix from upstream
<jtaylor> good
<jtaylor> somewhat bad that we have 4.10 in raring as it so buggy :/
<jtaylor> + the usual 10 version issues in other softare
<tedg> If I've got a binary package that another package has a build dep on it.  Will that package stick around until that build dep is changed?  Or does the non-purge only happen for binary deps?
<bdmurray> Where does software-properties get the list of mirrors from?
<cjwatson> tedg: it'll stick around in general, although if the package *version* changes such that the build-dep isn't satisfied any more then we probably won't notice that until the next test rebuild
<cjwatson> removals are all manual though and we check both runtime and build dependencies for those
<dobey> doh, dpm is gone already?
 * dobey wonders if anyone else has moderator access to ubuntu-translators@
<stokachu> dobey: cool thanks man
<tedg> cjwatson, Ah, cool.  We were curious about API transitions, how quickly we have to update.  For instance if the next branch landed has to have the update.  It sounds like no, which makes our lives easier.  Thank you.
<stokachu> jodh: ping
<stokachu> jodh: unping, roaksoax: ping
<jtaylor> doko: we should update numpy in raring, it has some bad bugs, I can probably do so this weekend
<jtaylor> to 1.7.1 bugfix release
<doko> jtaylor, will this include a scipy update?
<jtaylor> why?
<jtaylor> there is no bugfix release for scipy in raring so far I know
<jtaylor> we don't want 0.12 yet
<jtaylor> it has major changes = high regression change
<doko> please check that the scipy inraring builds with the updated numpy
<jtaylor> it does
<jtaylor> its only a bugfix release, no api changes
<jtaylor> also we got autopkgtests for scipy
<doko> ok
<tjaalton> pitti: can you open a new bug about the arrandale mesa regression upstream on bugs.fd.o?
<tjaalton> or maybe just lp, I can forward it
<cjwatson> tedg: it has to be soon after; by default, a transition that involves changing library names won't land in raring (as opposed to -proposed) until all reverse-(build-)dependencies have transitioned
<cjwatson> tedg: so the "no automatic removal" thing doesn't mean that this is something that can be put off - incomplete transitions become blockers for other people's work
<tedg> cjwatson, So what gets blocked?  New versions of the lib or new versions of the apps using the lib?
<cjwatson> tedg: yes
<cjwatson> sets of packages entering raring must form a coherent whole that doesn't regress installability; by default (though it can be forced with a very good excuse), this includes assuming that all no-longer-built-from-source binary packages are removed from the archive
<tedg> cjwatson, Okay, so if someone was developing the package they'd still have the old versions until the trunk of their package updated.  So that works for my use-case.
<bdmurray> slangasek: any ideas about bug 1163920?
<ubottu> bug 1163920 in update-notifier (Ubuntu) "update-notifier doesn't go away when you press the close button" [Medium,Confirmed] https://launchpad.net/bugs/1163920
<slangasek> bdmurray: hmm, nope.
<slangasek> bdmurray: if update-notifier didn't also generate a traceback, then I think the only way to debug it is to get a reproducer case first
<Plouj> hi
<Plouj> How can I check if a package in my personal repository is signed correctly?
<Plouj> Also, what kind of a check can I perform on my repository if I get a BADSIG error all the time, like this: http://askubuntu.com/questions/1877/what-is-the-easiest-way-to-resolve-apt-get-badsig-gpg-errors ?
<sarnold> Plouj: from that question, the answers that show how to delete the lists and remove those lists from any cachers you may be using, looked the most useufl
<Plouj> sarnold: that doesn't work for me because I've tried those steps, and it actually happens on a clean Lucid install
<Plouj> _and_ I'm the owner of the repo in question so I'm sure it's my fault, not some caching funkyness
<Plouj> I don't use any cachers that I know of
<sarnold> Plouj: aha.. hrm. I think you ought to be able to compare the md5/sha1 sums of packages against that in the package lists using standard md5sum and sha1sum programs...
<sarnold> Plouj: I _think_ only sources actually get signed; the binary packages are protected by having their hashes in the lists, and then the lists are signed
<sarnold> Plouj: perhaps your list signing operation is broken? is that key expired?
<cjwatson> while source packages are signed for the purposes of upload, as far as apt etc. is concerned they're verified in exactly the same way as binary packages, not by checking the signature on the .dsc
<Plouj> humm, the files listed in Release have the right md5sum sums
<Plouj> and I don't see an expiration on the key
<cjwatson> Probably best to check all the sums, not just md5 - I'd hope apt would prefer the stronger ones
<cjwatson> Also check the downloaded versions in /var/lib/apt/lists/
<cjwatson> (Sorry, don't have time to debug this fully, just a few suggestions in passing)
<sarnold> cjwatson: re: apt and md5 and other hashes, It's Complicated: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1098738
<ubottu> Launchpad bug 1098738 in apt (Ubuntu) "apt-get source only checks md5 hashes in Sources files" [High,In progress]
<cjwatson> Sources isn't likely to be relevant here
<sarnold> cjwatson: thanks for filling in some of my weaker understanding with the source packages handled the same as the binaries
<cjwatson> I mean, unless we're specifically talking about source packages rather than that being something that came up in passing
<sarnold> hrm, I thought that bug had grown to include more than just Sources
<cjwatson> Ah, didn't read it I'm afraid :)
<sarnold> it's been a while for me, too :) hehe
<Plouj> I don't get why, after running 'do-release-upgrade', which fails with: Error authenticating some packages and apt-get update starts showing "W: GPG error: ... The following signatures were invalid: BADSIG..."
<Plouj> no such problems before apt-get update
<Plouj> that's the main problem I'm trying to solve here
<sarnold> Plouj: can you validate the listst manually, using something like this? for f in *.gpg ; do gpg --verify $f ${f%.gpg}; done
<Plouj> sarnold: do you mean in /var/lib/apt/lists/ ?
<Plouj> I don't seem to have a Release.gpg for my particular repo in that directory
<sarnold> Plouj: hrm. does your archive have the .gpg files?
<Plouj> I do have Release.gpg in /var/lib/apt/lists/partial/ ...
<Plouj> sarnold: yes, the repo serves Release.gpg among others
<sarnold> Plouj: can you verify the files from the repo?
<Plouj> yup, it verifies
<sarnold> Plouj: how about the one in partial/ ?
<Plouj> it currently doesn't verify on the client because of: gpg: Can't check signature: public key not found
<Plouj> but sudo apt-key list shows the key....
<sarnold> Plouj: wget the file and diff them?
<Plouj> where is apt's truststore?
<Plouj> I mean keyring
<Plouj> found it
<sarnold> I think /var/lib/apt/keyrings
<Plouj> yeah, it say bad signature
<Plouj> humm, so Release.gpg matches what's on the server, but Release doesn't
<Plouj> umm
<Plouj> diff shows:
<Plouj> +-----BEGIN PGP SIGNED MESSAGE-----
<Plouj> +Hash: SHA1
<Plouj> +
<Plouj> I wonder if gpg was upgraded on the server causing it to put the signature into the file itself...
<Plouj> I might have something to go on. Thanks sarnold
<sarnold> Plouj: good luck :)
<slangasek> arges: ping
#ubuntu-devel 2013-04-09
<Plouj> Iiinteresting.
<Plouj> Release.gpg exists in /var/lib/apt/lists/ _until_ I run do-release-upgrade.
<Plouj> And the extra ---- GPG stuff creeps into Release on the client. The server doesn't have it (as expected).
<Plouj> perhaps do-release-upgrade is broken in Lucid
<sarnold> Plouj: does just 'apt-get update' do that?
<Plouj> sarnold: no
<Plouj> not from a fresh install, at least
<BenC> infinity: linux-ppc coming in 5 minutes
<infinity> BenC: Cool, sagari's all yours.
<infinity> BenC: Did you manage to get anyone from IBM or Freescale (or elsewhere) to bite on the importance of a V8 port, by the way?
<BenC> infinity: it's been brought up at some high level discussions...
<infinity> BenC: chrome and nodejs were bad enough, but losing fundamental bits of QT5 as well is getting a bit ridiculous.
<BenC> waiting to see how that pans out
<BenC> infinity: Ick, I hadn't heard about QT5+v8
<BenC> That's sub par for sure
<infinity> Maybe this will finally spur someone to do a generic C port or something.
<BenC> infinity: upload away...
<cjwatson> a/wg 66
<cjwatson> oops
 * infinity eyes component-mismatches suspiciously.
<cjwatson> That is a bit odd.  Regression from the latest commit?  I can't see why, though.
<infinity> cjwatson: Talking about c-m's kernel hatred, or something else?
<infinity> cjwatson: Oh, I see.  It learned about pockets.  Not immediately obvious why that would break udebs, though.
<infinity> +        if options.suite != pocket:
<infinity> +            suite = "%s-%s" % (options.suite, pocket)
<infinity> +        else:
<infinity> +            suite = options.suite
<infinity> Isn't that always going to rewrite raring to raring-release?
<infinity> Or to "raring-", perhaps?  I dunno.
<infinity> Oh, no.  Hrm.
<Mirv> mhall119: the ubuntu-ui-toolkit uploads have been prepared for automation, but the automated uploads will probably be only enabled after S begins. we need to figure out whether we upload 0.1.40 to raring or even newer.
<didrocks> xnox: slangasek: not sure how you deal with your WI on the fundation team, but please, do not set them to "DONE" when there are still some work to do on https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVVX1BOYm1qdUtyX2xUNmdwWlhTS0E#gid=0 in term of tests
<didrocks> xnox: should I revert your WI on https://blueprints.launchpad.net/ubuntu/+spec/client-1303-delivering-touch-apps-to-raring so that we have a real view of what's need to be done?
<infinity> ...
<infinity> I just upgraded and rebooted and my global menus are gone.
<lifeless> infinity: \o/ ?
<infinity> lifeless: Well, given that 99% of my windows are terminals, and I just turned the menu off instead, I don't care much, but I imagine it points to a bug somewhere. :P
<infinity> didrocks: ^-- Thoughts?
<didrocks> infinity: I didn't restart since my upgrade, but seeing that only Unity was reviewed in the last 24 hours (we still have a lot of things stuck in unapprovedâ¦), I doubt there is a change
<didrocks> let me try a guest session
<infinity> didrocks: I haven't rebooted in about a month, so I'm not really the best bisection candidate.
<sarnold> infinity,didrocks: https://bugs.launchpad.net/bugs/1165436
<ubottu> Error: launchpad bug 1165436 not found
<infinity> didrocks: But all my menus have gone application-local.
<didrocks> sarnold: no access to it
<sarnold> *sigh* moment..
<infinity> Scratch that.  All my gtk3 menus, maybe?  Firefox's is still global.
<didrocks> infinity: you did try gedit or something like that?
<sarnold> infinity,didrocks fixed..
<infinity> didrocks: gedit, pidgin, gnome-terminal: all local menus.  firefox: global.
<didrocks> sarnold: not really helpful but report :/
<sarnold> the auto-translation is supremely rough, but it sounds like the same problem to me.
<infinity> sarnold: Oh, I was hoping that bug would be informative. :P
<sarnold> didrocks: hehe, yeah, it -does- lack a bit in details.
<sarnold> infinity: it does add one bit of data though -- it's not just you :)
 * infinity wonders if he has anything QTish installed to confirm this "only gtk3" suspicion.
<pitti> Good morning
<didrocks> hey pitti
<RAOF> Hey pitti!
<didrocks> dkms runningâ¦
<infinity> Hrm, no, mumble is QT and it's also got local menus.
<infinity> So firefox is just special?
<infinity> Oh, wait, it does global menus differently, doesn't it?
<StevenK> Firefox has a plugin for it
<didrocks> infinity: justr tried a guest, working and restarted my own session, still working
<pitti> tjaalton: can do; do you know of some demo program that also exercises that particular effect (blur?) which upstream may have for reproducing?
<infinity> *grump*
<infinity> didrocks: Is there a sane way to trace what might be going on here?
<didrocks> infinity: it's weird you are getting firefox though, because this would mean /usr/lib/x86_64-linux-gnu/indicator-application-service is running
<infinity>  2690 ?        Sl     0:00 /usr/lib/x86_64-linux-gnu/indicator-application-service
<didrocks> as well as /usr/lib/unity/unity-panel-service
<infinity> Indeed it is.
<infinity> Not that I know what that means.
<didrocks> infinity: do you have the same in a guest?
<tjaalton> pitti: I've filed it already: https://bugs.freedesktop.org/show_bug.cgi?id=63283
<ubottu> Freedesktop bug 63283 in Drivers/DRI/i965 "blur performance regressed on ILK" [Normal,New]
<pitti> tjaalton: ah, thanks
<tjaalton> pitti: not sure about the demo, I'll check
<infinity> didrocks: I don't have the guest account enabled.  Would take some violence to test that.
<didrocks> infinity: as you are never rebooting, you maybe have some dbus protocol mismatch, but in the last day, only unity change and nothing close to that code
<didrocks> infinity: I would be interested in a new session test
<infinity> didrocks: But I'll hazard a guess that if it doesn't happen for you, it also wouldn't for me.
<infinity> didrocks: I never reboot, until today.  Which is when I saw it.
<pitti> tjaalton: subscribed, thanks; I can test patches
<tjaalton> pitti: nice. no news on that front yet I'm afraid :)
<didrocks> infinity: I'm still puzzled that firefox is working for youâ¦
<infinity> didrocks: It's the only thing that is...
<infinity> Oh, and LibreOffice too.  Just tested.
<infinity> But same story there, right?  Firefox and LibreOffice both do global menus via different paths than "normal" applications, right?
<didrocks> well, they have different hooks
<didrocks> but the unity part is the same
<didrocks> so I would guess you have something in your gtk3 and qt patches
<infinity> Okay, more confusion.
<infinity> About Computer gives me global menus.
<infinity> That didn't really match the pattern.
<didrocks> yeah, it's gnome-control-center which is a gtk3 application
 * infinity scratches his head.
<infinity> Yeah, hence the confusion.  Should behave the same as gnome-terminal and pidgin, one would assume.
<infinity> And gedit.
<infinity> And it doesn't.
<infinity> Argh.
<infinity> didrocks: I can try a clean session in a sec, but if that works (and it probably does), there's something very strange going on here in some profile/settings upgrade...
<didrocks> infinity: there is nothing to do with any settings or profile written anywhere, that's why I'm puzzled
<didrocks> it's just a gtk appmenu plugin which is loaded if on the diskâ¦
 * infinity adds a new user and logs out.
<infinity> didrocks: Huh.  Fresh user, same problem.
<didrocks> interesting, and gnome-control-center is still showing the exported menu?
<infinity> didrocks: So, apart from disabling guest, the only other GUI-related tweak I've done on a system level is disabling overlay scrollbars.  I can't imagine that would have such a strange effect, though?
<didrocks> infinity: I doubt it would impact it, but that's interesting, because both applications don't use the same GTK API
<infinity> didrocks: Yeah, g-c-c and firefox still DTRT, gnome-terminal and gedit not.
<didrocks> infinity: you do have the global menu for nautilus?
<infinity> didrocks: nautilus is global.
<didrocks> ok, so you "only" don't have them for the apps using appmenu-gtk3 library
<didrocks> infinity: I bet appmenu-gtk3 is installed, right?
<infinity> It sure isn't.
<didrocks> oh?
<didrocks> well, that's your answer though
<didrocks> then*
<infinity> (base)adconrad@cthulhu:~$ reverse-depends appmenu-gtk3
<infinity> Reverse-Recommends
<infinity> ==================
<infinity> * indicator-appmenu
<infinity> * kubuntu-desktop
<infinity> * kubuntu-full
<infinity> That doesn't seem like it would pull it in...
<infinity> And certainly not guarantee it.
<didrocks> infinity: indicator-appmenu is installed by default, isn't it?
<didrocks> it recommends all the qt and gtk bindings
<infinity> Yes, and installed.  And I generally upgrade with recommends, but there may have been resolver pain that caused it to not get installed.
<infinity> The only one I have installed is appmenu-qt5
<didrocks> infinity: possible, well, rather something which removed it I guess :)
<didrocks> ok, you need the 3 others for gtk2, 3, qt4
<didrocks> (gtk3 without)
<didrocks> (gtk3 without the new GNOME api)
<didrocks> which is the case for gnome-terminal and gedit for instance
<infinity> I'm not the only person this happened to, so there must be a bit of a hiccup here.
<didrocks> yeah, once some people are making upgrade testing, I'll look at that closely
<infinity> Doesn't jibel run upgrade testing constantly now?
<didrocks> infinity: you need to logout/login back or export UBUNTU_MENUPROXY="libappmenu.so" to your apps for having the library loaded
<infinity> Anyhow, installed the lot here.
<didrocks> (it's in /etc/X11/Xsession.d/80appmenu-gtk3)
<infinity> I'll log out. :P
<didrocks> ok ;)
<infinity> didrocks: So, yeah.  All fixed.  But clearly not a happy upgrade.
<didrocks> infinity: yeah, would be interesting so see what upgrade path concluded to removing those modules, especially as there is no particular conflicts/breaks against them AFAIK
 * infinity goes crosseyed reading apt history logs.
<infinity> didrocks: So, it's pooooossible I did this to myself.
<didrocks> infinity: oh? you hated them? and forgot about it? :p
<infinity> didrocks: No, I think I was going on an "autoremove doesn't remove enough crap" rampage, judging from my apt history.
<didrocks> ah, here we go ;-)
<infinity> And they got caught in the crossfire. :P
<didrocks> heh
<infinity> Doesn't explain the entertainingly-worded bug, but it explains mine.
<didrocks> infinity: oh, I know why it's working for g-c-c and nautilus
<didrocks> infinity: it's because, GNOME has a new "global menu API"
<didrocks> and we hook into it
<didrocks> not all apps transitionned to it though
<infinity> Ahh.
<didrocks> but for those, it's built-in gtk3
<didrocks> no need for a 3rd party module
<dholbach> good morning
<zyga> good morning
<tjaalton> bad usb-creator
<tjaalton> fails to empty a usb-stick with raring installer on it
<zyga> tjaalton: is it using udisks1?
<tjaalton> zyga: looks like it, and the error seemed udisks-y
<zyga> tjaalton: I mean udisks1 vs udisks2
<tjaalton> it depends on udisks, not udisks2
<zyga> tjaalton: I wonder if that is caused by the fact that gvfs is using udisks2 and certain events are no longer emitted through udisks1 dbus
<zyga> tjaalton: right
<tjaalton> so it didn't get ported, and is installed by default
<zyga> yes
<zyga> it could still work fine
<zyga> since udisks1 still works fine
<zyga> but there are some subtle differences in behavior
<zyga> just because other pieces of the desktop use udisk2 instead of udisks1
<tjaalton> it's bug 1160035
<ubottu> bug 1160035 in usb-creator (Ubuntu) "Startup Disk Creator unable to format USB drive - Error modifying partition: helper exited with exit code 1: In part_change_partition" [Undecided,New] https://launchpad.net/bugs/1160035
<tjaalton> actually no, my error is different
<jibel> doko_, hey, could you have a look at bug 1165172
<ubottu> bug 1165172 in python2.7 (Ubuntu) "upgrade 12.10 -> 13.04 fails : new libpython2.7-minimal used during upgrade while libpython2.7-stdlib is not yet unpacked and configured." [Critical,Confirmed] https://launchpad.net/bugs/1165172
<xnox> didrocks: platform-api is in the daily landing PPA. Sensors are not yet. I've set them to DONE/INPROGRESS. Or do you want them both INPROGRESS?
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox
<didrocks> xnox: I would like INPROGRESS if possible, I added some coments to the spreasheet ;)
<didrocks> xnox: so that DONE really means "nothing else to be left to do"
<didrocks> xnox: do you mind answering to my questions on the spreadsheet between 2 sponsosrings?
<xnox> didrocks: spreadsheets have comments =) ok will asnwer them.
<didrocks> thanks!
<m_3> does pbuilder safely survive a laptop suspend in raring?
<mlankhorst> why wouldn't it?
<m_3> it seems fine, just kept chugging along... wondering if I should suspect the build
<lifeless> m_3: do you mean a pbuilder build in progress? Should be fine
<m_3> mlankhorst: dunno, just never suspended with it before and was windering
<m_3> cool
<m_3> thanks!
<mlankhorst> if your system survives a suspend, userspace should not notice a thing from suspend
<m_3> ack
<lifeless> time skew + network going away and returning
<lifeless> quite noticable if anything is looking for it - but nothing should be
<mlankhorst> time skew is forward time skew, though
<lifeless> yes
<mlankhorst> and network outage can happen without suspend too
<lifeless> yup
<lifeless> just saying, it is noticable if anything cares
<mlankhorst> meh personally I do echo mem > /sys/power/state; /etc/init.d/fancontrol restart
<mlankhorst> I keep hoping that nouveau survives, I haven't nailed down why it doesn't yet :(
<rbasak> When debian/source/options contains single-debian-patch, is it acceptable to remove that file to introduce an Ubuntu delta?
<zyga> pitti: ping
<pitti> hello zyga
<zyga> pitti: is this section of the upstart cookbook no longer accurate after we moved to logind: http://upstart.ubuntu.com/cookbook/#run-a-job-when-a-user-logs-in
<zyga> pitti: it mentions start on dbus-activation org.freedesktop.ConsoleKit
<mlankhorst> rbasak: why would you want to?
<pitti> zyga: indeed; but that seems wrong even now
<rbasak> mlankhorst: to keep the Ubuntu delta in a separate patch, so it's easier to merge in future?
<zyga> pitti: ah, I thought so
<pitti> consolekit is being called/used way before the first user logs in
<mlankhorst> oh sure
<pitti> zyga: one needs to actually listen for CK's/logind's signals for new sessions, or query for current sessions, not just check when the service gets activated
<mlankhorst> though can't you just explicitly create ubuntu patches for the delta?
<zyga> pitti: I think the actual answer is 'it depends and it is complicated'
<zyga> pitti: the cookbook should be corrected though, it can lead people to do wrong stuff
<rbasak> mlankhorst: I did but dpkg-source squashed them into the single patch and then the build got confused by trying to double apply it. Removing single-debian-patch from source/options fixes that problem
 * zyga tries to recall james hunt's IRC nickname
<rbasak> zyga: jodh
<mlankhorst> ah
<zyga> thanks
<zyga> jodh: hey
<jodh> zyga: hi
<zyga> jodh: pitti and I think that one section of the upstart cookbook is incorrect
<jodh> zyga: feel free to raise a bug with details.
<zyga> jodh: thanks
<zyga> jodh: do you know of a way to start a job after a server is initialized, is that also runlevel=2 in practice?
<zyga> brendand: ^^
<jodh> zyga: http://upstart.ubuntu.com/cookbook/#normal-start
<zyga> thanks
<zyga> pitti, jodh: reported as https://bugs.launchpad.net/upstart-cookbook/+bug/1166708
<ubottu> Launchpad bug 1166708 in Upstart Cookbook "Incorrect hint on how to start a job when user logs in" [Undecided,New]
<jodh> zyga: thanks
<pitti> zyga: FYI, we didn't move to logind yet (denied FFE)
<brendand> jodh, will that guarentee that a network connection is in place when the job starts?
<brendand> jodh, i.e. what are 'basic' services
<zyga> pitti: oh, too bad
<zyga> pitti: well, -s is just a few moments away
<zyga> pitti: -s will be pretty cool I think
<pitti> yeah, I plan to do the migration on the sprint, when I can get a hold of Robert for logind, etc.
<jodh> brendand: runlevel gets emitted after the last static i/f is up. I admit it's a bit terse, but this is all documented in upstart-events(7).
<brendand> jodh, so using 'start on (local-filesystems and net-device-up IFACE!=lo)' is okay?
<jodh> brendand: maybe this should be discussed on #upstart? What are you actually truing to do?
<xnox> brendand: the fact that network is up, configured and one has ipaddress does not mean one can access the internet though...
<brendand> xnox, we don't need to access the internet :)
 * brendand moving this to #upstart
<pitti> xnox: I uploaded a fixed apturl for bug 1103024 now
<ubottu> bug 1103024 in apturl (Ubuntu Raring) "apturl-gtk crashed with TypeError in _on_finished(): 5 parameters needed for signal action-done; 3 given" [High,Fix committed] https://launchpad.net/bugs/1103024
<pitti> seb128: do you see any reason to keep ubuntu-system-service in raring?
<xnox> pitti: interesting, thanks. i will have a look.
<seb128> pitti, not if we don't "fix" gnome-control-center to add back the "set proxy" feature
<pitti> oh, right
<pitti> "apt-cache rdepends ubuntu-system-service" doesn't have any remaining depends any mroe
<seb128> pitti, right, and the archive grep didn't return anything else using the dbus api
<mdeslaur> I thought we discouraged the use of aptitude on ubuntu...but I can't seem to find a relevant link...am I remembering wrong?
<tumbleweed> it was broken in the early multi-arch days, but should be fine again now
<mdeslaur> I seem to recall something about it not using the same dependency resolver, so it would do funny stuff on Ubuntu
<tumbleweed> it has its own dependency resolver, yes
<tumbleweed> but if it does "funny stuff" those are bugs
<xnox> mdeslaur: I am an avid ex-user of aptitude, I stopped using it when multiarch landed.
<xnox> mdeslaur: I remember during squeeze release somebody was doing upgrade tests with apt-get and aptitude and the two upgrades were not the same =/
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<mdeslaur> xnox: I guess I'm misremembering an official stance on it
<tkamppeter> pitti, do you have any idea what is happening with this bug: bug 1157972?
<ubottu> bug 1157972 in cups (Ubuntu) "Cups overwrites config with no backup" [Undecided,Confirmed] https://launchpad.net/bugs/1157972
<pitti> the apport-collect was rather unhelpful
<pitti> tkamppeter: but /etc/cups/printers.conf isn't even a conffile, so unless you added something to the postinst that would replace it, I have no idea
<pitti> the description of the bug is rather vague
<tkamppeter> pitti, the user tells that his conffiles are overwritten without any backup and AFAIK dpkg always takes backups. The only place in the maintainer scripts where conffiles are actually removed is the purge section of postrm.
<pitti> tkamppeter: printers.conf isn't handled by dpkg, it's not a conffile
<tumbleweed> xnox: same, also used to be an avid aptitude user. use it a lot less now. but of course the upgrades aren't going to be the same - the dependency problem is non-trivial...
<tkamppeter> pitti, and how can the update remove it then?
<pitti> tkamppeter: as I said, no idea
<tkamppeter> pitti, (assuming that the purge section of postrm is not called on update).
<tkamppeter> pitti, as I have already checked the maintainer scripts that they do not touch printers.conf (except purge) it seems that I can safely ignore this bug as being noise.
<pitti> tkamppeter: yes, I think so
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<tkamppeter> pitti, another mysterium for me is that an update to a newer Ubuntu release removes cups-pdf (bug 987026). cups-pdf is not necessarily needed due to PDF output facilities already integrated in most desktop apps, but if a user installs it, it should stay on his system.
<ubottu> bug 987026 in update-manager (Ubuntu) "cups-pdf package removed at each ubuntu version upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/987026
<tkamppeter> pitti, and there are no conflicts with cups-pdf defined in other packages, as the user can simply re-install cups-pdf.
<OdyX> tkamppeter, pitti : printers.conf disappears on cups downgrades.
<OdyX> tkamppeter, pitti: saw that but as we don't support downgrades, I've never investigated.
<pitti> so perhaps its the daemon itself which removes printers.conf if it deems it incompatible?
<tkamppeter> OdyX, pitti, can it be that purge is called during a downgrade?
<pitti> tkamppeter: that needs /var/log/dist-upgrade/ logs for debugging
<OdyX> tkamppeter: no: http://wiki.debian.org/MaintainerScripts#Downgrading
<tkamppeter> OdyX, pitti, if the daemon removes printers.conf (or any other conffile) this would be a severe upstream bug. This should get reported upstream.
<tkamppeter> OdyX, you should check error_log (in debug mode) to see whether CUPS tells there why it is removing print queues or why it is removing printers.conf altogether.
<tkamppeter> OdyX, perhaps bug 1157972 is the same problem.
<ubottu> bug 1157972 in cups (Ubuntu) "Cups overwrites config with no backup" [Undecided,Confirmed] https://launchpad.net/bugs/1157972
<jamespage> pitti,is it possible to configure apport to report bugs for packages from alternative sources to a specific launchpad project?
<pitti> jamespage: yes, quite a lot of packages do that
<pitti> jamespage: see /usr/share/doc/apport/package-hooks.txt.gz (CrashDB field), and e. g. /usr/share/apport/package-hooks/source_linux-nexus7.py as an example
<pitti> jamespage: you can also make a package hook which sends ubuntu reports for packages from ubuntu, and to an LP project if it comes from e. g. a PPA
<jamespage> pitti, I think its that second example I need; specifically I want to report bugs to the cloud-archive project for packages that come from http://ubuntu-cloud.archive.canonical.com/
<pitti> ogasawara: don't make it too easy to contribute to the kernel, lest I may lose my fear completely :)
<ogasawara> pitti: :)
<mpt> tvoss, hi, I see you're the drafter of <https://blueprints.launchpad.net/ubuntu/+spec/client-1303-location-service>
<tvoss> mpt, yup
<mpt> tvoss, in the description of the code I see mention of GPS. Would/will it use locations of wi-fi hotspots and cell tower locations as well?
<tvoss> mpt, it uses arbitrary location providers, but the client does not know about the actual provider
<mpt> tvoss, I don't know what that means, sorry
<mpt> What's a location provider?
<tvoss> mpt, gps, is a location provider, a wifi hotspot, glonass etc.
<tvoss> mpt, does that impact design?
<mpt> tvoss, yes, it affects the text. For example, whether we need to tell people that location will be less accurate when wi-fi is off.
<xnox> tvoss: will it tell the client precission? e.g. you are in london +/- 1km radius vs London Big Ben +/- 15m
<tvoss> mpt, hmmm, the text inside applications?
<mpt> tvoss, no, in the System Settings panel.
<mpt> Which I'm working on right now. :-)
<tvoss> xnox, that depends on the application, we will provide location updates, heading, velocity, and accuracies, plus geocoding capabilities
<mpt> tvoss, I think you're using "accuracies" for what xnox meant by "precision"
<mpt> ?
<jamespage> pitti, figured it out - thanks for the pointers
<xnox> mpt: yes. and accuracy is more correct term anyway =)
<tvoss> mpt, ack, and for the system settings: As the list of location sources is not fixed, we would need to account for that, too, I guess
<tvoss> mpt, do you have a draft for the ui?
<mpt> tvoss, what do you mean by "fixed"? Do you mean "decided yet", or "the same all the time"?
<tvoss> mpt, the same all the time/might differ per device
<mpt> tvoss, as I say, I'm working on it right now.
<tvoss> mpt, okay
<jamespage> pitti, do you think my changes would be an acceptable SRU for apport in precise? I'm just defining a new crashdb and general-hook
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin
<dobey> dpm_: hey, i have a second mail that was in moderation that i sent last night after you went away. could you let it through?
<dobey> dpm_: also, is there anyone else that can moderate that list, so i can poke them instead when you aren't around? :)
<dpm> dobey, done
<dobey> dpm: gracias
<dpm> dobey, I'm thinking of sharing the moderation with other members of the translations community, but those who'd be good candidates are in similar time zones as I am
<dpm> dobey, for now I'll whitelist you
<dobey> dpm: ah ok, thanks
<dpm> if someone has got a suggestion on how I can add a couple of filters to mailman for @ubuntu.com or @canonical.com e-mail addresses, I'd add those, which would make things easier
<dobey> maybe barry knows something :)
 * barry is sure he knows... something ;)
<barry> dpm: yes, you can whitelist all @ubuntu.com or @canonical.com, but you have to do it on a per-list basis
<barry> dpm: go to Privacy options->Sender filters
<dpm> barry, that's exactly what I want, I just want to whitelist those addresses on the ubuntu-translators list
<barry> dpm: then scroll down to accept_these_nonmembers
<barry> dpm: enter this on one line:
<barry> dpm: er, let's make that two lines:
<barry> .*@ubuntu.com
<barry> .*@canonical.com
<barry> shoot, wait
<barry> it's:
<barry> ^.*@ubuntu.com
<barry> ^.*@canonical.com
<barry> (the leading ^ tells mm that what follows is a python regexp)
<roaksoax> slangasek: howdy! I was wondering if MAAS was gonna be accepted into -proposed for verification
<dpm> barry, ah, before there was:
<dpm> ^.@ubuntu.com
<dpm> ^.@canonical.com
<dpm> that might be why it didn't work
<dobey> ah someone forgot the *
<barry> dpm: unless x@canonical.com posted :)
<dobey> yeah
<dpm> :-)
<barry> ^.+@canonical.com might also work better
<dpm> ok, I've used that, then
<barry> cool
<dpm> thanks barry and dobey!
<doko> rbasak, heh, nice, first use of the powerpc cross compiler =)
<tjaalton> pitti: if you're still around, there's a mesa build I did with one revert http://koti.kapsi.fi/~tjaalton/mesa
<stokachu> xnox: i've got a few bugs needing a little attention could i paste them for you?
<tjaalton> pitti: looks like it's working just as fine on snb as with the 19 upstream patches the previous one had..
<xnox> stokachu: ok, paste away here. And we can discuss them =)
<stokachu> xnox: cool thanks
<stokachu> bug 1013798, bug 857983, bug 1068399, bug 1158465, bug 859600, bug 1069570
<ubottu> bug 1013798 in libgcrypt11 (Ubuntu Raring) "Blink SIP client segfaults with libgcrypt11 1.5.0-3ubuntu0.1" [Critical,In progress] https://launchpad.net/bugs/1013798
<ubottu> bug 857983 in gpointing-device-settings (Ubuntu Quantal) "The Pointing Devices menu item is missing after upgrading to Oneiric" [Medium,Triaged] https://launchpad.net/bugs/857983
<ubottu> bug 1068399 in Precise Backports "Please backport parallel 20120422-1 (universe) from raring" [Undecided,New] https://launchpad.net/bugs/1068399
<ubottu> bug 1158465 in walinuxagent (Ubuntu Quantal) "[SRU] update Windows Azure WALinuxAgent to 1.3.2 (12.04.2, 12.10 and 13.04)" [Critical,In progress] https://launchpad.net/bugs/1158465
<ubottu> bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,In progress] https://launchpad.net/bugs/859600
<stokachu> and bug 1027086
<ubottu> bug 1027086 in vino (Ubuntu Precise) "incorrect schema setting used for authentication-methods in vino server" [Medium,In progress] https://launchpad.net/bugs/1027086
<stokachu> bug 1069570
<ubottu> bug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Triaged] https://launchpad.net/bugs/1069570
<xnox> stokachu: about azure - upload utlemming's branches?
<stokachu> xnox: yea
<stokachu> xnox: i didnt think there was anything formal really for azure stuff
<stokachu> im going to have those guys apply for per package rights on azure in the near future
<xnox> stokachu: as in, there are no debdiff nor merge proposals => thus nothing to sponsor =)
 * xnox skipped though it during piloting.
<xnox> stokachu: for libgcrypt "bug" only python-gnutls is needed and libgcrypt says the same across the board?
<stokachu> xnox: yea we should remove the libgcrypt being affected
<xnox> stokachu: that's fine, I'll mark it invalid then.
<stokachu> cool, that one needs to be uploaded as well
<stokachu> micahg: are you still actively handling backports?
<pitti> tjaalton: ah, that somehow removes gstreamer1.0-plugins-bad, but not a biggie
<pitti> tjaalton: testing now
<pitti> tjaalton: it seems a tad faster than the PPA version, and a tad slower than the raring version
<pitti> good night everyone
<stokachu> xnox:  bug 778627 has verification-done how longs does it usually take for it to make it into -updates?
<ubottu> bug 778627 in bash (Fedora) "In natty, bash completion now quotes shell variable references rather than expanding them" [Undecided,New] https://launchpad.net/bugs/778627
<seb128> pitti, 'night
<xnox> stokachu: http://people.canonical.com/~ubuntu-archive/pending-sru.html so stuff that is green and still in proposed should be promoted to -updates, but it's manual step done by SRU team.
<stokachu> ok
<Riddell> chrisccoulson: ping
<Riddell> chrisccoulson: bug 1165408 is annoying but an easy fix
<ubottu> bug 1165408 in firefox (Ubuntu) "Kubuntu Raring - Kubuntu-firefox-installer blocks the install of Firefox" [Undecided,Confirmed] https://launchpad.net/bugs/1165408
<stokachu> bdmurray: do you have some time to push bug 778627
<ubottu> bug 778627 in bash (Fedora) "bash completion now quotes shell variable references rather than expanding them" [Undecided,New] https://launchpad.net/bugs/778627
<stokachu> bdmurray: and bug 1162876 :)
<ubottu> bug 1162876 in apt-cacher-ng (Ubuntu Precise) "apt-cacher-ng data corruption with HTTP headers" [Medium,Fix committed] https://launchpad.net/bugs/1162876
<cjwatson> I'll release that now
<cjwatson> Well, no, not apt-cacher-ng, it's far too young
<bdmurray> stokachu: yes, however apt-cacher-ng has not been available for more than 7 days
<cjwatson> Generally bugs must age for ... what he said
<stokachu> ah ok
<cjwatson> Doing bash now
<stokachu> cjwatson: excellent thank you!
<cjwatson> Looks like we'd got a bit behind on releasing to -updates
<stokachu> yea ive been pinged more times than normal on some of them
<stokachu> bdmurray: re: bug 1013798 do you have an eta of when you'd be able to look that over?
<ubottu> bug 1013798 in libgcrypt11 (Ubuntu Oneiric) "Blink SIP client segfaults with libgcrypt11 1.5.0-3ubuntu0.1" [Critical,In progress] https://launchpad.net/bugs/1013798
<stokachu> stgraber: re: bug 1057358 do you have an eta when this will be addressed?
<ubottu> bug 1057358 in isc-dhcp (Ubuntu Precise) "dhcpd in isc-dhcp-server-ldap cannot read /etc/ldap/ldap.conf due to missing entry in apparmor profile" [Medium,In progress] https://launchpad.net/bugs/1057358
<bdmurray> stokachu: I was on vacation most of last week, I'll get to it today or tomorrow
<stokachu> bdmurray: ok cool
<tjaalton> pitti: hmm ok.. but sounds like an improvement and not that bad than stock 9.1.1
<tjaalton> pitti: actually it's probably way better than stock 9.1.1, the ppa one had one additional branch that fixed it for SNB
<stokachu> seb128: i appreciate all your hard work :) would you mind adding bug 859600 to be sponsored? :P
<ubottu> bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,In progress] https://launchpad.net/bugs/859600
<stokachu> seb128: add to your todo list i mean
<ogra_> lol
<ogra_> http://lists.debian.org/debian-devel/2013/04/msg00337.html
<ogra_> thats hilarious ...
<ogra_> package roulette
<ogra_> xnox, we should actually ship it now that i read that mail ... but definitely in "section: games"
<geser> ogra_: catching up with Debian mails? :)
<ogra_> geser, well, someone proposed inclusion of (and eventually a switch to) aptitude by default on ubuntu-devel-discuss ... that thread came up in the discussion
<slangasek> ogra_: heh, I assumed you were referring to the /earlier/ package roulette thread
<slangasek> https://lists.debian.org/debian-devel/2013/04/msg00000.html
<ogra_> lol
<seb128> stokachu, hey, I can try having a look but it 's a non trivial change so it would be better if you could get somebody more familiar with multiarch issues (e.g slangasek) to review it
<stokachu> seb128: ah ok
<slangasek> man
<slangasek> you desktop people, always making me the patsy for multiarch
<seb128> slangasek, there will be free beers in return it that makes it better? ;-)
<infinity> slangasek: If the pasties fit...
<infinity> Oh, wait.  "patsy".  *cough*
<med_> heh
<stokachu> infinity: could you pretty please help us out on a azure bug
<slangasek> seb128: beer makes me fat, and we're focused on reducing footprint this cycle
<seb128> slangasek, fair enough, free glass tap water for you ;-)
<slangasek> hah
<seb128> +of
<jcastro> slangasek: try wine!
<slangasek> jcastro: I do!
<slangasek> ;)
<infinity> slangasek: Try more!
<infinity> stokachu: Which one?  The walinuxagent update?
<stokachu> infinity: we've got a heater and no debdiffs or MP's, i will work with those for future bugs on the processes
<stokachu> infinity: yea :(
<infinity> stokachu: Shouldn't need diffs or MPs, it's in the queue already, no?
<stokachu> there are related branches attached to the series but that is all
<stokachu> for raring i think lemme check precise
<infinity> Unless we're talking about two different things.
<slangasek> roaksoax: maas> sorry about that, I'm not sure how it fell off the radar... I thought I had done this already, maybe I was waiting for a queue diff or something
<stokachu> infinity:  this one is bug 1158465
<ubottu> bug 1158465 in walinuxagent (Ubuntu Quantal) "[SRU] update Windows Azure WALinuxAgent to 1.3.2 (12.04.2, 12.10 and 13.04)" [Critical,In progress] https://launchpad.net/bugs/1158465
<infinity> stokachu: https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=walinux
<slangasek> so I saw that walinuxagent has been packaged in Debian now
<infinity> stokachu: I'll review them today.
<slangasek> only the maintainer has called it 'waagent'
<slangasek> someone want to sync up with them? :)
<stokachu> med_: ^ (sync with debian?)
<stokachu> infinity: awesome man i really appreciate it
<infinity> slangasek: Can we call it waaaahagent instead?
<slangasek> wagilent
<med_> stokachu, I think there are some deltas. I'll take a look   slangasek infinity
<slangasek> med_: by 'sync with Debian' I don't mean "take Debian's package unmodified", just "correct the fact that we're doing double work with them" :)
<med_> slangasek, I think that we'll have some work to do to get them synced up.
<med_> since upstream has taken our patches, that should put debian in a better position
<infinity> Given upstream's constant insistence that THE WHOLE WORLD WILL EXPLODE if you don't run the latest version, I'm not sure we can sync with Debian terribly effectively.
<med_> I'll review (and try and engage utlemming ) in the debian packages and see if we can't all "get together"
<infinity> But maybe they'll settle the eff down and stabilise soon.
<infinity> (A man can dream)
<slangasek> med_: Debian is also a few upstream versions behind, from what I see - 1.2 vs. 1.3.2?
<med_> yep, uck
<infinity> Anyhow, if we can consolidate on packaging, slapping a new orig on occasionally isn't world-ending.
<infinity> (But, for now, 1.2 and 1.3.x packaging would be pretty different by necessity, due to 1.2's silly attempts to reinstall itself from itself without patching all that out)
<roaksoax> slangasek: no worries :), I thought it was ready for verification too but it wasn;t :(
<slangasek> roaksoax: accepted now
<roaksoax> slangasek: awesome! thanks a lot :)
<slangasek> infinity: well, I don't see any good reason that Debian should be using 1.2 instead of 1.3.2 either, do you?
<infinity> slangasek: Oh, absolutely not.  They should be on the latest and shiniest.
<slangasek> hallyn: hey, wrt ovmf/edk2, I'm surprised that you say there's no support upstream for maintaining state - I certainly did find code in ovmf that's meant to load/save UEFI variables from disk, I just haven't figured out yet why it's not working
<infinity> slangasek: But given that we've been agressively SRUing new upstreams (at least, for now, I really hope that settles down), we won't stay in sync for long unless Debian's maintainers are on the ball (or we join them).
<slangasek> infinity: well, step one is to get the Debian maintainer to fix the package name ;p
<hallyn> slangasek: it was two weeks ago i was looking, but the docs certainly said there wa sno support.  maybe it's in the works?
<infinity> slangasek: Or for us to suck it up and do a transitional one, yeah.
<slangasek> infinity: 'waagent' is a much woorse name
<infinity> slangasek: waaaah.
<slangasek> hallyn: what docs are those?
<infinity> slangasek: But I agree, and given that it's only in unstable, there's time to fix.
<slangasek> hallyn: I assure that the code is there and quite mature - it just isn't working for me, and I've thus far failed at creating a debug build of ovmf
<infinity> And, for whatever reason, the Debian maintainer decided it was amd64-only.
<slangasek> hallyn: do you know the right way to get a debug build? :)
<infinity> I guess he couldn't fathom the concept of people running i386 cloud instances.
<utlemming> infinity: that is because Windows Azure only supports amd64
<utlemming> infinity: they won't allow 32-bit builds
<infinity> utlemming: Then why does our package build for i386? :P
<utlemming> s/they/MS/g
<infinity> (And really?  Silly Azure)
<infinity> utlemming: Still, nothing stopping you from running an amd64 kernel and i386 userspace.
<utlemming> infinity: I don't remember the reason...but I for some reason it wasn't allowed to be uploaded
<utlemming> infinity: that sounds like vaugely like the justification
<utlemming> infinity: I can't remember the reason for it being that way
<infinity> I doubt there's a "valid" reason, so not much point trying to remember what it was.
<infinity> (The valid reason may, in fact, have more to do with Windows images than Linux ones, and they just applied the same rules blindly across the board)
<hallyn> slangasek: apparently the tip at the bottom of OvmPkg/REAMDE is NOT one of the things i tried
<hallyn> so, maybe that works
<hallyn> slangasek: I do know jeremy-kerr's bios has debugging enabled (if i tested right)
<slangasek> yeah, his has debugging
<slangasek> but I can't reproduce it with the package :-)
<slangasek> hallyn: the README talks about 'UNIXGCC' which is not the build profile we're using... we're using 'GCC47'
<utlemming> infinity, slangasek: fixing Debian's version is going to be painful. They are going to have the same problem that we ran into, whereby upgrading the system can lock out the admin user
<hallyn> slangasek: sigh, i'm trying to find the file i'd been editint go try enabling debugging, but these directory names just confound me
* infinity changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin
<infinity> utlemming: It's only in unstable so far.  Maybe you can just convince the maintainer (very politely) to just take your packaging?
<infinity> utlemming: Upgrades from his current package to yours are probably not even worth worrying about, if the switcheroo is quick. :P
<utlemming> infinity: yeah, I think I'll ask him. The other problem with it is the name is supposed to be walinuxagent.
<infinity> utlemming: Well, yes.  Taking your packaging would imply the name change too.
<infinity> utlemming: And then you could just ask ftpmaster to remove waaahagent, and done.
<hallyn> slangasek: anyway i mainly need that postponed until after this coming week.  after that i'll look bac into it (noted in my tickler file)
<slangasek> hallyn: ok :)
<slangasek> hallyn: fwiw, from what I've read of the code I think the problem is going to come down to understanding *where* ovmf is pulling the persistence from, and maybe a bug in when it applies its fallback of creating a new file
<slangasek> since it uses UEFI's own filesystem calls to manage it, there are possibly-arcane rules about the order in which it iterates the FAT filesystems
<hallyn> slangasek: yeah, it was while trying to find where it gets its persistance that i thought i saw notes sayint it doesn't.  maybe it was old mailing list notes.
<slangasek> hallyn: right - well, there's an awful lot of code here for it to not do anything ;)
<ogra_> slangasek, beer has influence on your shoe size ?
<ogra_> (you should see a doctor ... )
<slangasek> ogra_: yes, it pools in my feet
<ogra_> oouch ...
<infinity> ogra_: Do you nick highlight on "beer"?
<ogra_> lol
<ogra_> you dont ?
<infinity> ogra_: I don't drink.
<slangasek> infinity: you "imbibe"?
<mlankhorst> chug ;)
<infinity> I won't listen to this slander.
<dobey> slander? libations!
<dobey> man, i didn't realize aptitude was such a controverisal piece of software
<slangasek> heh
<slangasek> it's only controversial because it's buggy
<infinity> It's only controversial because people insist that it's useful.
<infinity> Bugginess wouldn't matter if those people stopped. :P
<slangasek> dobey: the first time I typed 'aptitude install $foo' and was offered a solution to remove 10 packages, upgrade 4, and not install the package I requested, I ragequit
<cyphermox> +1
<mlankhorst> :>
<cyphermox> however perhaps the response was overwhelming
<dobey> slangasek: it's almost like getting recommendations to install things i already have installed :)
 * ogra_ has never used it ... 
<dobey> i've never used aptitude either. no need to
<ogra_> but the thread is really entertaining ...  why couldnt  he bring it up on friday though
<dobey> apt-get works fine
<cyphermox> ogra_: on friday?
<ogra_> fridays are for trolling :)
<cyphermox> so you could do more reading? :D
<slangasek> cyphermox: hey, wrt your latest commit on libappindicator, I'm reasonably certain that your 'clean' target is entirely superfluous and should be dropped
<cyphermox> slangasek: I think so too
<cyphermox> but I opted to just fix it for now, clean up properly later
<cyphermox> (wasn't mine in the first place)
<slangasek> cyphermox: I welcome such proper cleanup at all points :)
<cyphermox> slangasek: good point though, I better do it *now* so I don't forget
<cyphermox> the rule as it is will just do what it would do if it was absent nayway
<slangasek> yep... except it actually does it twice ;)
<cyphermox> which makes it more clean! :)
<cyphermox> slangasek: you didn't file a bug about this did you?
<slangasek> cyphermox: nope
<cyphermox> ok, just making sure
<dobey> mhall119: hey. recently (i think last week sometime), i saw a post on planet ubuntu iirc, that mentioned someone having poked about with making a softwre-center UI for ubuntu touch using the sdk. do you know anything about that? like where the code is and who did it?
<tjaalton> slangasek: hey, about the lightdm/plymouth race.. guess it's time to upload the upstart job change to raring? It has fixed the race for me
<slangasek> tjaalton: yes... mlankhorst tried to pin that on me, without much success ;-)
<slangasek> (I think I agreed to upload it and then it fell off my radar)
<slangasek> tjaalton: feel free to upload the change described in my last comment on the bug?
<tjaalton> heh, ok
<tjaalton> yep, I'll prepare it tomorrow
<tjaalton> another thing..
<tjaalton> we'd (still) like to update mesa 9.0.3 -> 9.1.1 (9.1.2 later this week)
<tjaalton> bug 1164093 is the ffe report
<ubottu> bug 1164093 in mesa (Ubuntu) "FFe: new upstream release 9.1.1" [Wishlist,Triaged] https://launchpad.net/bugs/1164093
<tjaalton> so the latest word is that with a fairly simple revert the intel performance issue with blur/fade is mostly solved
<slangasek> tjaalton: I saw the earlier comments about the mesa upgrade; on its face it makes me very nervous to take this post-final beta
<slangasek> as it's not clear to me how much burn-in it's had beyond identifying the one intel performance regression
<tjaalton> i've ran it for two months on sandybridge
<tjaalton> but yeah it could've gone in earlier
<slangasek> tjaalton: one person running it for two months is not the kind of reassuring breadth of coverage I'd be looking for
<slangasek> tjaalton: maybe you should coordinate with balloons to get some community testing, and we can revisit based on what people find?
<tjaalton> I'm not the only one, it's been on the staging ppa for that long, although it had all of xserver 1.14 too
 * doko did hear that argument earlier this month as well ;p
<tjaalton> slangasek: I sent a CFT last Friday, a handful of people reported success but all on intel I think
<tjaalton> slangasek: ok I could post to the forums too, and update the ppa package to match what I have now
<slangasek> doko: yes, because silence is not assent and we need to get in the habit of being more rigorous about testing things before we land them without a rollback plan :-)
<slangasek> tjaalton: well, best would be if you could coordinate with balloons
<slangasek> ... who is hiding from us on #ubuntu-release
<tjaalton> oh, a person? :P
<slangasek> that way we can be systematic about gathering feedback, and you don't have to worry :)
<slangasek> yes! :)
<tjaalton> sure thing
<tjaalton> thanks
<lifeless> win 52
<med_> infinity, slangasek : stop working on walinuxagent please (for the moment)
<slangasek> med_: oh, I've done no work on it, never fear :)
<jerry66> http://www.reddit.com/r/fuckedhardxxx/comments/1c0mor/hot_amateur_movie_collection/
<med_> slangasek, nod.
<med_> slangasek, infinity it was a pebcak, not a package issue with walinuxagent.
<mhall119> dobey: yeah, Ashley Johnson or something like that, let me find his posts
<dobey> mhall119: thanks
<mhall119> dobey: http://elbuntuprojects.com/new-ui-in-progress-ubuntu-mobile-appstore/
<mhall119> I don't see a link for code though
<mhall119> dobey: ah, here it is: https://github.com/elbuntu/umobile-software-center-universal
<dobey> ah, thanks
<dobey> hmm
#ubuntu-devel 2013-04-10
<micahg> stokachu: not as much as I used to be, but if somethings needed, I can try to squeeze it in
<stokachu> micahg: is there someone who took up that task?
<micahg> stokachu: I think the 3 of us who are "active" do it as we have time
<stevengottlieb> i have a question regarding my software update for 12.10
<stevengottlieb> hello?
<stokachu> can i get https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=gpoint approved?
<mlankhorst> gday
<RAOF> maaaaaaaate
<mlankhorst> no!
<pitti_> Good morning
<zyga> good morning
<mardy> kaleo: hi! I was asked to check if the SDK team had any opinion about this: https://lists.ubuntu.com/archives/ubuntu-devel/2013-March/036935.html
<apachelogger> cjwatson: hey, if you get a chance today it would be cool if you could have a look at https://code.launchpad.net/~kubuntu-members/debian-cd/kubuntu-raring-artwork/+merge/157998
<tjaalton> @pilot on
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<tjaalton> pilot in
<tjaalton> bah
<tjaalton> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: tjaalton, sconklin
<dholbach> good morning
<cjwatson> apachelogger: you definitely want to switch to HIDDEN_TIMEOUT=2 (i.e. the same desktop image boot workflow that Ubuntu uses)?  I don't object, just wanted to double-check that
<cjwatson> apachelogger: that's also a UI-freeze-worthy change - are there any relevant docs?
<apachelogger> cjwatson: yes on the hidden timeout, see bug 1164854 for freeze exception
<ubottu> bug 1164854 in kubuntu-settings (Ubuntu) "[UIFE] Kubuntu Boot Artwork Update" [Undecided,Fix released] https://launchpad.net/bugs/1164854
<cjwatson> gotcha, thanks
<cjwatson> apachelogger: it'll probably take LP a while to notice, but it's merged and deployed now, thanks
<apachelogger> cjwatson: thank you :)
<ev> bdmurray, pitti: have you heard many reports of reporting to Launchpad still being enabled post-release in 12.10?
<ev> trying to find the right google terms for that :)
<pitti> ev: no, I didn't; that might happen for people who manually re-enable it?
<ev> very doubtful in this case - a designer in the office has it enabled on 12.10
<ev> I'll see what else I can find
<seb128> ev, maybe they played with the control center privacy settings (does that change apport's status?)?
<ev> seb128: that only toggles whoopsie running
<seb128> ok
<seb128> apport is enabled in the /etc config ?
<ev> maybe they've pulled in some 13.04 bits
<ev> yeah
<ev> in /etc/default/apport
<seb128> ok, weird
<seb128> dunno either then
<seb128> ev, is it possible that they reported a bug, got asked for details and copied/pasted the command from the stock reply that tell them the command to enable apport?
<ev> seb128, pitti: she doesn't appear to have enabled it herself or taken instruction from anyone else to do so. She's also not running anything from raring as far as she's aware. It sounds like a fairly stock system.
<ev> I've asked to have a look at her computer again later today
<ev> I'll see what I can dig up then
<seb128> ok
<pitti> ev: the precise contents of /e/d/apport would be interesting; perhaps it was modified years ago already
<seb128> look at when the /etc file got edited and the packages installed around this time in dpkg.log maybe
<ev> will do to both :)
<mpt> ev, remarkable how that most common error in R is much more common in weekdays than weekends ... pre-release, I would have expected the opposite.
<ev> :D
<ev> I'm always encouraged when it challenges our preconceptions
<lifeless> mpt:, ev: o/
<ev> hi!
<mpt> o/`
<maxb> I've been using R for my office workstation for weeks, I just have a dual boot to Q on standby in case it all goes horribly wrong
<mpt> ev, if we were tracking hangs by now, I get the feeling we'd be seeing a lot in update-manager
<seb128> right
<seb128> the computation to sort depends from an app under the app icon seems to be quite slow
<doko> seb128, what about allowing the deprecated glib functions for the final release of 13.04 again? would save a lot of effort to fix the ftbfs now
<seb128> Laney, pitti: ^ opinions?
<seb128> doko, do you have specific deprecations you would like to comment/drop?
<seb128> we can't just turn any deprecations off
<doko> meh :-/
<pitti> FTBFS because of packages which disable deprecated symbols, but use them?
<seb128> pitti, yes
<seb128> in universe
<seb128> doko, how many of those are left?
<seb128> should be easy enough to drop the G_DISABLE_DEPRECATED flags, but I'm not sure how many sources we are talking about there
<pitti> I don't like changing glib itself to not mark them as deprecated, because that would be a lie
<seb128> same here
<doko> I didn't count, but it's every third or fourth package I'm touching
<doko> at least the g*'s
<seb128> how many are left on the ftbfs list?
<doko> 520
<seb128> hum
<seb128> crazy
<pitti> for "dead" software we'll keep having this problem, so at some point we need to fix (or remove) those anyway
<seb128> right
<seb128> I would rather trying a bit harder to "clean" those and not change glib
<pitti> so maybe we can find some five people and a day to go through them and drop G_DISABLE_DEPRECATED
<seb128> I can help having a look through the list and fix some
<pitti> or remove the software if it's not even working any more, etc.
<Laney> right, I agree
<seb128> doko, pitti: let me try to build a list of affected sources from the build logs
<seb128> then we can try to call for help dealing with those
<Laney> maybe someone from +1 would help out
<Laney> also mail the motu list
<seb128> the 5 a days would work for me
<pitti> ack
<seb128> ok, let's do that
<pitti> I can help out there, too; it should be possible to get through some 20 FTBFSes on one day
<seb128> doko, do you know why > q on that list only failed on armhf? most of those build issues don't seem armhf specific
<doko> seb128, see https://launchpad.net/builders
<seb128> doko, ok, other arches didn't get to those yet
<doko> yes :-/
<pitti> doko: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html is still the current one, right?
<seb128> doko, Laney, pitti: ftbfs i386 due to glib deprecations: http://paste.ubuntu.com/5694973/
<seb128> well those are the ones that match "grep "is deprecated " *.txt | grep glib"
<seb128> in the 229 i386 ftbfses
<seb128> doing the same for other arches
<pitti> seb128: ah, I was looking at some 20 packages, and so far I didn't find a single one; many are due to missing -lm, or breakage which is specific to that pacakge
<seb128> right
<seb128> same here
<seb128> pitti, I did some hackish, grep on the .html, wget of the logs and "grep "is deprecated " *.txt | grep glib" on the stack of lgos
<seb128> logs
<pitti> seb128: I'll just take the first 20?
<seb128> pitti, if you want, please
<pitti> seb128: for NM tests I'm kind of blocked on reaching Dan Williams anyway, and I'm not feeling too awake today anyway
<pitti> so this seems like the perfect job for a day with just half a brain :)
 * seb128 hugs pitti
 * seb128 runs the loop of wget on the ~400 armhf build issues
<ogra_`> 400 ?
<ogra_`> where do you see these ?
<ogra_`> the fstbfs list doesnt have as many
<seb128> ogra_`, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html
<seb128> ogra_`, universe is over 500
<ogra_`> geez
<ogra_`> there werent as many last week !
<seb128> ogra_`, build was not done, there is still 3 days of build backlog on i386/amd64
<ogra_`> yeah, who cares for these obsolete arches
<seb128> lol
<seb128> Laney, pitti, doko: that's the end of the list (using armhf): http://paste.ubuntu.com/5695016/
<seb128> total is 59 glib related ftbfses
<pitti> seb128: would you mind putting them into an etherpad?
<pitti> easier for coordination
<ogra_`> would be really nice if the ftbfs UI could filter builds that only fail on one arch
<seb128> Laney, pitti: http://pad.ubuntu.com/glib-deprecated-ftbfs
<seb128> that's the full list
<Laney> thanks
<Laney> i'll take some this afternoon
<pitti> seb128: ^5s
<seb128> thanks
<seb128> pitti, ^5s ;-)
<seb128> $ grep "try adding it to the linker command line" *.txt | sed 's#buildlog_ubuntu-raring-armhf.##' | sed 's#_FAILEDTOBUILD.*##' | sort | uniq  | wc -l
<seb128> 113
<seb128>  
<pitti> that's mostly -lm?
<seb128> so twice as many due to missing -l
<seb128> pitti, 40 due to libm
<seb128> pitti, I've added the "missing -lm" to the bottom of the pad
<seb128> http://paste.ubuntu.com/5695026/
<seb128> rather
<seb128> let's not mix stuff
<pitti> seb128: you seem to have some false positives there; easyspice is due to -lm, not due to glib
<pitti> as we have them in your last paste, I'll just drop it from the pad
<seb128> pitti, ups
<mpt> seb128, thanks for the hint, I reported bug 1167277 about it
<ubottu> bug 1167277 in update-manager (Ubuntu) "Unresponsive for a long time after checking for updates" [Undecided,New] https://launchpad.net/bugs/1167277
<pitti> seb128: and e. g. ecore also only has those as warnings, not failures
<pitti> seb128: (it fails due to 'PRIO_PROCESS' undeclared, which I can't find anywhere)
<seb128> pitti, Laney: ok, list down to 11 ...
<pitti> ah, nice
<seb128> pitti, sorry, I matched warnings only before
<seb128> those have "error: ... is deprecated ... glib..."
<pitti> ok, so for 11 FTBFSes we shouldn't change glib, but just fix them
<pitti> I'm fine to do those this afternoon
<seb128> pitti, thanks
<seb128> doko, ^ doesn't help you much though :-(
<Laney> how come doko thought there were loads due to that then?
<pitti> seb128: is that the first block on the pad now?
<seb128> Laney, he crossed a few while doing fixes
<Laney> just seeing warnings due to glib which failed for some other reason
<mpt> ev, end of an era -- the list of bugs in Errors no longer fits one on page of a default Launchpad listing
<seb128> pitti, yes
 * mpt wonders if we can persuade wgrant to increase the default batch size from 75 to 100
<pitti> seb128: did you see buzztard and cutter-testing-framework in your updated grep?
<pitti> seb128: these were due to glib (I just uploaded fixes for those two)
<geser> seb128: instead of greping the .html file, you can also grep the .csv file (but it only lists one log if a package fails on several archs) (http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.csv)
<seb128> pitti, hum, no, the error is no "deprecated" but "unknow type" ... will add that to my grep, one min
<pitti> seb128: I'll just take your first block then
<seb128> buzztard_0.6.0-1
<seb128> cutter-testing-framework_1.1.7-1.2ubuntu1
<seb128> gnome-pie_0.5.4-1build1
<seb128> thoggen_0.7.1-1ubuntu1
<seb128>  
<seb128> pitti, those are the only 4 in that case
<pitti> ok, added those
<seb128> pitti, danke
<seb128> geser, thanks, I just used the file to have the list of logs to wget, that worked ... maybe next time ;-)
<doko> pitti, language packs did arrive :-/
<pitti> yeah, at some point we'll need an update; but they should build on i386 in about an hour, it's just updates
<seb128> doko, those 5 had dpkg errors, you might want to retry them
<seb128> arpack++_2.3-2
<seb128> cairo-clock_0.3.4-2ubuntu2
<seb128> haskell-regex-tdfa_1.1.8-2build2
<seb128> krename_4.0.9-1build1
<seb128> ncap_1.9.2-1build1
<Laney> hmm, that's a release version of regex-tdfa
<Laney> there's a newer version in proposed - did the rebuild not take that into account?
<Laney> (not that I'm saying this version is fixed)
<doko> Laney, no, rebuild is for the release pocket only. not interested in test rebuilds in things which we don't release. and not everything stays that long in -proposed like haskell ;p
<seb128> Laney, could you look at the tomboy one? it seems something with the libappindicator sharp bindings, likely a libappindicator issue but you probably know better how the "find the dll" stuff works
<zyga> barry: ping
<Laney> seb128: yes - can you update the pad?
<Laney> doko: well, we certainly intend to release everything in proposed ...
<seb128> Laney, done
 * zyga found a python3 bug?
<ev> mpt: we can fix that :)
<zyga> or python3/python2 bugs
<zyga> wft
<doko> zyga, ?
<zyga> doko: eh, sorry, nothing
<zyga> doko: I thought I found a python3 metaclass inhertiance regression
<zyga> doko: but it was my fault for using type(...) vs type.__new__(mcls, ...)
<zyga> doko: just quickly tested that on precise/raring and it works
<ev> apw: I found the problem with getting kernel oops reports on https://errors.ubuntu.com. Fixing now.
<Laney> seb128: I think that the problem is that libappindicator0.1-cil-dev is an arch:all package but has pkgconfig files in a multiarch directory
<seb128> Laney, oh
<apw> ev, nice thanks
<Laney> ie packaging bug
<seb128> Laney, thanks for investigating ;-)
<Laney> should be easy to fix
<seb128> Laney, let's make the binary arch any then?
<cjwatson> is it architecture-dependent in any other way?  if not, better to move the .pc file to /usr/share/pkgconfig/
<Laney> That would be weird because the library is arch:all
<Laney> I'll move the pkgconfig file
<seb128> that makes sense
<barry> zyga: hi.  problem all sorted out?
<zyga> barry: yes, my bad: type(...) != type.__new__()
<zyga> barry: subclass did not seem to inherit metaclass
<barry> zyga: ah.  fun stuff. :)
<zyga> barry: not pythonic :)
<zyga> barry: well, I learn every day
<barry> zyga: if you ain't learnin' you ain't livin'! :)
<zyga> barry: is that because type.__new__() somehow super-calls __new__ again while type() does not?
<barry> zyga: well, hard to know exactly what's going on without looking at your code, but suffice to say, these are tricky corners of the language
<zyga> barry: I have a few line example
<barry> zyga: pastebin!
<zyga> barry: https://gist.github.com/zyga/5354531
<zyga> barry: basically, look at that, if you replace type.__new__() with type() - it fails
<barry> zyga: py3 docs on __new__: http://docs.python.org/3/reference/datamodel.html?highlight=__new__#object.__new__
<barry> but this makes sense, because three-arg type() is a constructor
 * barry ->reboots
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: tjaalton, sconklin, seb128
<pitti> seb128: bah, I fixed two causes of FTBFS in thoggen, and now I see that it doesn't build against our current (i. e. already years old) hal, and against our current dbus
<pitti> last build was in jaunty
<pitti> at some point we must drop hal stuff anyway, so I'm really inclined to just remove that package; objections?
<seb128> pitti, hal is on the ftbfs list btw ;-)
<seb128> pitti, no objection from me
<pitti> ah, it got removed from testing, too
<xnox> pitti: do not remove hal !!!!
<pitti> we should have removed it about 3 years ago, but some ancient and dead software still depends on it
<mdeslaur> pitti: flash needs it
 * xnox still wants Amazon Pay-to-view to work in US and Google Play Movies work in US/UK/other? and Adobe Flash DRM to work as well.
<pitti> xnox: but for now I only want to remove thoggen
 * mdeslaur misunderstood
 * pitti congratulates xnox as our new hal maintainer :)
<mdeslaur> xnox: congrats! :)
<pitti> seriously, this stuff uses hal!?
<pitti> does that even work still these days?
<xnox> pitti: i'm on vacation today, so don't take me too seriously =)))))
<mdeslaur> pitti: i think it uses hal to get the hard disk serial number for drm
<xnox> pitti: yes, all of that $drm-crap works on top of flash which depends on hal.
<pitti> flash certainly doesn't pull in hal
<xnox> hmmm....
<mdeslaur> pitti: it doesn't fail if hal isn't installed, but it disabled drm
<tjaalton> slangasek: so, fixing lightdm isn't that easy after all, since plymouth-splash could be stopped already before lightdm is about to start (able to hit that here)
<tjaalton> slangasek: and adding 'and (stopped plymouth or started plymouth-splash)' means the transition isn't as smooth anymore
<pitti> doko: could you please retry gnome-pie on ARM? This error ("unknown type name 'GCancellab'
<pitti> doko: ...) doesn't make any sense
<pitti> sun rays/RAM corruption/etc ?
<pitti> it builds fine on amd64, and "GCancellab" doesn't appear any where in the code
<doko> pitti, done
<pitti> thanks
<pitti> doko: that's it then, all the rest of glib-induced failures uploaded
<pitti> (and got accepted)
<pitti> seb128: ^ FYI
<seb128> pitti, danke
<seb128> doko, pitti, I've fixed some of the -lm issues, will try to do some every day
<doko> seb128, thanks!
<seb128> yw ;-)
<doko> tried to revert that one in binutils, but that seems to be tangled with other uploads, maybe glibc
<seb128> doko, specifically libm or linking being pickier?
<doko> seb128, there are other libs too, but libm and libpthread are the ones which are seen many times. there were some libgmodule-2.0 (or such) too
<bdmurray> ev: no, but I haven't looked
 * dholbach hugs seb128
 * seb128 hugs dholbach back
<slangasek> tjaalton: hmm, ok
<Quintasan> ...
<Quintasan> why on earth I can't login into cups admin panel with my username and password when I am in the lpadmin group?
<ogra_> doko, looking at the ants buioldlog it seems to think it hits an ICE, do you think it makes sense to give it back at least once ?
<doko> Please submit a full bug report,
<doko> with preprocessed source if appropriate.
<doko> See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
<doko> The bug is not reproducible, so it is likely a hardware or OS problem.
<doko> it even tells you =)
<ogra_> i know that it tells me :P
 * ogra_ was there during that reading class back then :P
<ogra_> doko, i'll do a local build later then to collect that
<doko> ogra_, wait until the build finishes ...
<ogra_> oh there is a build running ?
<ogra_> i wish the ftbfs UI would reflect that
<ogra_> bah, 2min old :P
<ogra_> doko, bino looks like a rebuild candidate too (bus error while unpacking deps)
<ogra_> doko, err, sorry that was brise
<ogra_> (wrong row)
<doko> given back
<dholbach> can somebody moderate my mail on u-d-a?
<cjwatson> dholbach: done
<dholbach> thanks cjwatson
<menace> are there dbg-packages for nautilus in ubuntu precise?
<menace> if yes: in which package? there is no nautilus-dbg
<Sarvatt> menace: https://wiki.ubuntu.com/DebuggingProgramCrash debug symbol section on there, its nautilus-dbgsym
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: tjaalton, sconklin
<seb128> menace, nautilus-dbgsym like for any other binary, you just need to enable the ddeb source
<seb128> or Sarvatt already replied
<menace> 1
<Laney> 2
<menace> sry, kvm-switch...
<menace> :D
<jim00234> hi
<Laney> apachelogger: are your kdiff3 and im-config patches forwarded?
<tjaalton> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin
<zyga> hi
<zyga> I just got locked out of my laptop
<zyga> raring desktop, I updated / rebooted
<zyga> secure boot blocked my system
<zyga> cjwatson: ^^ ?
<zyga> I disabled secure boot, I'm now in 3.8.0-17
<zyga> I've updated to 3.8.0.17.33
<zyga> let's see
<zyga> same
<zyga> hmm
<zyga> pitti: do you know who would be the best person to debug this?
<infinity> slangasek: Can you remind me where the Debian bug for that WUR issue was?  I lost context somewhere in the last few days.
<slangasek> infinity: what's 'WUR'?
<infinity> slangasek: warn-unused-result
<infinity> slangasek: I thought it was a samba bug, but can't find it, and now I can't find context for our conversation either, leading me to wonder if I've gone (more) insane.
<infinity> Oh, hah.  But the last "git show" in my bash history is for 7e66ee5142deda977163d0a858c3d2883cae3f07 which happens to be the commit with the liberal application of __wur.
<slangasek> infinity: ah right - I think it was on cifs-utils?
<infinity> So, I don't have the bug tracker context, but I have the code.
<infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701422
<ubottu> Debian bug 701422 in src:cifs-utils "cifs-utils: ftbfs with eglibc-2.17" [Important,Open]
<infinity> slangasek: That's it, thanks.
<mlankhorst> slangasek: runlevel is set to 2 from telinit, can plymouth-stop run because of stopped rc RUNLEVEL=2, before rc RUNLEVEL=2 is started?
<slangasek> mlankhorst: I'm confused by the question. Are you asking whether a 'stopped rc RUNLEVEL=2' event would be seen before a 'started rc RUNLEVEL=2' event would be emitted?
<mlankhorst> yeah
<slangasek> it cannot
<mlankhorst> meh something weird is happening though
<tjaalton> I can't get --verbose work with upstart on raring
<tjaalton> initctl log-priority still shows info
<tjaalton> after adding the option to cmdline
<stokachu> could i get someone to approve nominations for bug 1069570
<ubottu> bug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Triaged] https://launchpad.net/bugs/1069570
<slangasek> tjaalton: the kernel commandline?
<slangasek> tjaalton: it definitely WFM
<tjaalton> slangasek: yeah, not here :)
<slangasek> tjaalton: ah, in fact 'initctl log-priority' shows the same for me, but I'm definitely /getting/ logging
<tjaalton> where does it log?
<tjaalton> upstart cookbook says 'grep init: /var/log/syslog' but nothing there
<slangasek> tjaalton: it logs to dmesg, effectively
<slangasek> tjaalton: and there's a bug in recent releases that I haven't pinned down which prevents this from finding its way into syslog
<slangasek> (presumably a kernel or rsyslog bug)
<tjaalton> slangasek: ahh, yeah dmesg has them
<zyga_> hi
<zyga_> I need help figuring out why my raring system stopped booting in secure mode
<zyga_> anyone interested?
<slangasek> zyga_: "secure mode" meaning UEFI Secure Boot, or something else?
<zyga_> slangasek: yes
<zyga_> sorry
<zyga_> a bit hectic over here (real life problems piling up, almost contained now)
<slangasek> zyga_: where does it break down?  Can you still boot older kernels?
<zyga_> slangasek: I was on 3.8.0-5, rebooted to -17 failed to boot in secure boot mode
<zyga_> slangasek: I tried they all seem to have failed
<slangasek> hmm
<zyga_> I could not access grub easily though
<zyga_> I can now reinstall -5 and other kernels (I have a local mirror with --no-cleanup)
<zyga_> and retest anyway you like
<zyga_> this is a lenovo g580 system
<zyga_> it never had secure boot issues before
<zyga_> it works since december last year
<slangasek> how do you mean, "could not access grub easily"?  there's the problem that holding shift doesn't work to display the grub menu, but you should still get the grub menu after any failed boot
<zyga_> slangasek: I didn't get either
<zyga_> slangasek: I managed to get into normal boot and edit /etc/default/grub enough to access the menu
<slangasek> well, there was an upload of grub2 just yesterday
<slangasek> it's possible something regressed as a result of the rebuild :/
<zyga_> slangasek: would it affect secure boot or are those unrelated?
<slangasek> zyga_: well grub is the bootloader, so it's relevant to secure boot
<zyga_> slangasek: ok, I can install -17 (current) and -16 only
<zyga_> right
<zyga_> silly me
<zyga_> sorry
<zyga_> I thought we used a shim
<slangasek> that's the first stage bootloader only
<slangasek> (and hasn't been changed)
<zyga_> isn't that what is actually signed?
<zyga_> ok
<zyga_> I'm not sure if my messages were from bios, shim or grub though
<zyga_> what would you advise checking?
<slangasek> can you try downgrading to grub-efi-amd64-signed 1.11+2.00-12ubuntu1 and grub-efi-amd64 2.00-13ubuntu2 ?
<zyga_> let's see if I have it already
<slangasek> what messages?
<zyga_> yes, I have that
<zyga_> slangasek: failed secure boot messages
<slangasek> well, if you can quote me the message I can probably tell you where it's from ;)
<zyga_> I'd have to reboot, I'll write it down the next time
<zyga_> slangasek: ok, let me install those packages
<zyga_> slangasek: can I just dpkg -i the relevant debs?
<slangasek> zyga_: yes; if you do it that way, you'll need to include the matching grub-efi-amd64-bin and grub2-common packages
<zyga_> ok
<zyga_> can I do it via apt somehow?
<slangasek> zyga_: IFF those versions are still in your cache
<slangasek> (your apt cache, not the physical cache on disk)
<zyga_> slangasek: I have that in my mirror
<zyga_> but it's probably not in Packages
<zyga_> anyway
<zyga_> let's do it manually
<slangasek> anyway, it's probably not worth figuring out how to do it with apt, you might as well just dpkg -i the 4 packages
<zyga_> right
<zyga_> there are also -bin packages
<zyga_> should I get them/
<slangasek> zyga_: grub-efi-amd64-bin, grub-efi-amd64, grub-efi-amd64-signed, grub2-common, grub-common - AFAICS that's what you need
<zyga_> ok, let me try
<slangasek> (I overlooked grub-common the first time, sorry)
 * zyga_ tries to munge that into shell
<zyga_> $ sudo dpkg -i grub2/grub-common_2.00-13ubuntu2_amd64.deb grub2/grub2-common_2.00-13ubuntu2_amd64.deb grub2-signed/grub-ef
<zyga_> i-amd64-signed_1.11+2.00-12ubuntu1_amd64.deb grub2/grub-efi-amd64_2.00-13ubuntu2_amd64.deb grub2/grub-efi-amd64-bin_2.00-13ubuntu2_amd64.deb
<zyga_> trying
<zyga_> ok, installed
 * zyga_ *had* to install mirror just to get this recovery option ;)
<zyga_> slangasek: shall I reboot and re-enable secure boot now?
<slangasek> zyga_: that's the thing to try
<zyga_> ok
<zyga_> brb
<zyga> slangasek: it failed the same way, I took a photo
<zyga> slangasek: let me share it
<zyga> slangasek: https://plus.google.com/116315264177593873442/posts/9UUGFQ2cphM
<slangasek> zyga: mmm.  Do you have the shim and shim-signed packages installed?
<slangasek> zyga: (the answer is that these messages are from firmware)
<zyga> yes
<doko> stgraber, python-cffi is the new way to write python bindings
<zyga> oh
<zyga> no
<zyga> I don't?
<zyga> I have shim-signed
<zyga> slangasek: I don't have shim
<slangasek> zyga: ok, that should be sufficient
<zyga> slangasek: http://paste.ubuntu.com/5696609/
<slangasek> zyga: what's the output of 'sudo efibootmgr -v'?
<zyga> slangasek: dpkg --get-selections
<zyga> http://paste.ubuntu.com/5696611/
<slangasek> zyga: md5sum /boot/efi/EFI/ubuntu/grubx64.efi ?
<zyga> bb8cea9bb89a83aa714bd175d61cf5bc  /boot/efi/EFI/ubuntu/grubx64.efi
<slangasek> zyga: doesn't match the shim-signed binary
<slangasek> zyga: so, we should figure out where it does come from
<zyga> slangasek: how did you figure that out, from this line: ?
<zyga> Boot0001* Ubuntu	HD(1,800,2f000,947c5c3f-fa10-495c-b18d-97a7c757148f)File(\EFI\ubuntu\grubx64.efi)RC
<slangasek> zyga: well, I mostly figured it out because I helped implement it so know what's supposed to be where ;), but yes, that line shows the path that's being booted
<slangasek> (I wanted the efibootmgr output to confirm that the boot options themselves were configured correctly)
<zyga> right, I meant the actual checksum
<slangasek> zyga: I checked the shim-signed package
<zyga> ah
<zyga> ok
<slangasek> zyga: you could try reinstalling shim-signed
<zyga> ok
<slangasek> zyga: but before you do, please make a copy of grubx64.efi
<zyga> ouch
<zyga> too late :/
<slangasek> ohwell ;)
<slangasek> zyga: order of operations fail on my part
<slangasek> zyga: so what's the md5sum of that file on disk /now/?
<zyga> cde67f528af411dd8d8f1b4bc643b484
<zyga> different
 * slangasek scratches his head
<slangasek> that's not the md5sum I expect either ;)
<tjaalton> slangasek: turns out the upstart logs don't have any mention of plymouth-splash, so no wonder 'started plymouth-splash' didn't work
<zyga> cde67f528af411dd8d8f1b4bc643b484  /boot/efi/EFI/ubuntu/grubx64.efi
<zyga> slangasek: is that the right file?
<tjaalton> problem is I don't know what would work, so that the smooth transition is preserved
<tjaalton> something to play with tomorrow then
<slangasek> tjaalton: do you have plymouth in the initramfs?
<tjaalton> slangasek: probably, using cryptsetup
<zyga> slangasek: I can probably find the older grubx64.efi from the mirror I use
<slangasek> tjaalton: right, that explains - no 'started' event because the service is started before upstart is
<zyga> slangasek: and if it has the right md5sum I've pasted here, give it to you
<slangasek> zyga: actually, sorry, I was directing you to the wrong place
<tjaalton> slangasek: ha, ok
<tonyyarusso> Hey everybody, I've been doing some mucking about with a script shipped with update-notifier-common (/usr/lib/update-notifier/apt_check.py).  I discovered that while it appeared to be intended to be usable as a module, it was never tweaked to actually be so.  So, I made some changes and was wondering if anyone could take a glance to see if they seem sane.  Here's the original: http://pastebin.com/102RGrjK , the new version: ...
<tonyyarusso> ... http://pastebin.com/j7ZNVdMg , the diff of the two: http://pastebin.com/4Rmy1Hjc , and an example script using it as a module: http://pastebin.com/p808Hp9T .
<slangasek> zyga: because apparently the system I was referencing here is also not configured for SB currently :P  How about 'sudo grub-install --uefi-secure-boot', then check if the efibootmgr output shows a different boot path?
<zyga> k
<zyga> huuh
<zyga> slangasek: it _removed_ ubuntu?
<slangasek> errr
<zyga> slangasek: http://paste.ubuntu.com/5696643/
<slangasek> really?
<zyga> slangasek: as you can see
<slangasek> that's... special
<zyga> tonyyarusso: hi, I think this is best addressed on the ubuntu-devel@ mailing list
<zyga> tonyyarusso: alternatively as a merge request (to trigger discussion) to the relevant project on launchpad.net
<zyga> slangasek: am I being hacked or is this 20*13* showing its teeth
<zyga> slangasek: and we got a borked upload with some interesting bug
<slangasek> zyga: man, I don't know - none of these pieces have been uploaded recently, except for grub and the change there is irrelevant!
<tonyyarusso> zyga: All righty - care to point me to a primer on how to do a merge request?  I've opened bugs before, but haven't had a solution to offer.  :)
<slangasek> zyga: so, ah... if you run grub-install again, does the missing boot entry come /back/?
<zyga> tonyyarusso: sure, there's a full help page on launchpad about that
<zyga> slangasek: checking
<stgraber> doko: is that the actual upstream recommended way of doing bindings nowadays? my understanding was that ffi was indeed quite cool to generate minimal on the fly bindings as something a bit cleaner than ctypes, but it didn't look like something that should be used for a full upstream binding
<zyga> no
<lifeless> stgraber: upstream for what value of upstream
<zyga> slangasek: do I get it right that I should _not_ reboot now ;)
<slangasek> tonyyarusso: http://developer.ubuntu.com/packaging/html/udd-intro.html + http://developer.ubuntu.com/packaging/html/fixing-a-bug.html
<slangasek> zyga: yes, probably don't do that ;)
<lifeless> stgraber: upstream has never recommended ctypes for bindings
<zyga> right ;)
 * zyga has been in such a situation once before ;)
<slangasek> zyga: in theory you could still browse manually in the firmware and ask it to boot the Ubuntu botloader by name, but that doesn't sound fun
<zyga> slangasek: ah
<zyga> slangasek: so uefi shell is always around?
<zyga> slangasek: I thought that's only in the reference impl
<stgraber> lifeless: doko was essentially saying I should be using cffi for the LXC binding instead of my current native C extension
<zyga> slangasek: been there, done that, should be okay if I have to
<slangasek> zyga: not shell; it's incompatible with Win8 cert reqs to ship the shell
<zyga> heh
<slangasek> zyga: but your firmware menu *probably* has an option to boot a specific EFI executable by path
<zyga> ok
<slangasek> (this only works under Secure Boot if the binary is signed)
<zyga> hmm, I don't recall such a menu
<stgraber> lifeless: I know ctypes haven't been recommended by upstream and for very good reason, that's why to me cffi looked like something a bit cleaner than ctypes but not something that upstream python would recommend for a real-world binding
<lifeless> stgraber: cffi should be equivalent, because it still invokes the compiler
<zyga> ok
<zyga> what shall we try next?
<slangasek> zyga: I'm reading grub-install code right now to figure that out
<zyga> slangasek: if the next UDS wasn't virtual I'd get you a beer for helping me :)
<slangasek> zyga: what the heck... how about sending me the output of 'sh -x /usr/sbin/grub-install --uefi-secure-boot'?
<zyga> slangasek: I'll set LANG= so that you can read it
<slangasek> if you wish ;)
<tjaalton> slangasek: a horrible hack I guess but works: 'and (started cryptdisks-enable or started plymouth-splash)' :)
<slangasek> tjaalton: truly horrible; I think we should fix upstart instead to synthesize 'started' events for jobs started from initramfs
<zyga> slangasek: http://pastebin.ubuntu.com/5696669/
<slangasek> tjaalton: (there's no guarantee that plymouth in the initramfs is caused by use of cryptsetup, for one thing)
<tjaalton> slangasek: heh, yeah. I was wondering if there was some more generic event to abuse here
<slangasek> tjaalton: not really, we need to create one - either by fixing it in upstart, or by adding a secondary job that's 'start on startup or started plymouth-splash', checks for plymouth-splash running already, and emits an appropriate common event
<tjaalton> slangasek: right, that could work
<tjaalton> as an interim solution
<slangasek> tjaalton: and by 'checks for plymouth splash running', I mean checking the output of 'status plymouth-splash'
<doko> bah, after every reboot after a unity update my system comes up in low graphics mode
<tjaalton> doko: most likely not related to unity, but the lovely plymouth-splash/lightdm race we have
<doko> ahh
<tjaalton> which is finally understood, just needs some head-scratching to fix it properly :)
<doko> but unity sees updates more often =)
<slangasek> zyga: 'fs_module=ext2' (line 1453) - /boot/efi is a VFAT partition, right?
<zyga> yes
<tjaalton> doko: pastebin Xorg.0.log from the failing boot
<slangasek> zyga: hmm, ok
<slangasek> zyga: so what if you run this command by hand?: efibootmgr -c -d /dev/sda -p 1 -w -L ubuntu -l \EFI\ubuntu\shimx64.efi
<slangasek> (with appropriate quoting)
<zyga> appropriate quoting?
<zyga> ah
<zyga> \ ?
<slangasek> yah
<zyga> EFI uses windows style path separators?
<zyga> omg
<zyga> slangasek: nothing
<doko> tjaalton, hmm, $ ls -l /var/log/Xorg.*
<doko> -rw-r--r-- 1 root root 31919 Apr 10 23:37 /var/log/Xorg.0.log
<doko> -rw-r--r-- 1 root root 31151 Apr 10 23:36 /var/log/Xorg.0.log.old
<doko> -rw-r--r-- 1 root root 34547 Apr 10 23:35 /var/log/Xorg.failsafe.log
<doko> -rw-r--r-- 1 root root 34547 Apr  7 22:36 /var/log/Xorg.failsafe.log.old
<slangasek> zyga: successful exit?
<zyga> slangasek: as in, efibootmgr -v does not list anything new
<zyga> no
<zyga> slangasek: 1
<slangasek> zyga:  -v it
<zyga> slangasek: it dind't print anything either way
<slangasek> man
<slangasek> what's up with that
<tjaalton> doko: hmm, .old is probably not useful, guess you logged out soon?
<slangasek> zyga: are you sure /bin/efibootmgr isn't corrupt/trojaned/
<doko> tjaalton, yes
<zyga> slangasek: if it was, that'd be interesting
<barry> slangasek: just to verify, the patch to bug 1078697 needs to be backported to lucid-updates, right?  i ask because the patch in raring/precise does not apply cleanly, and i want to make sure i need to adapt it before i spend too much time on backporting (a lot has changed in the code since lucid ;)
<ubottu> bug 1078697 in apt (Ubuntu) "Ubuntu archive is missing SHA-1/SHA-256 hashes for some packages" [High,In progress] https://launchpad.net/bugs/1078697
<doko> tjaalton, will keep it the next time
<zyga> slangasek: since I'm not in secure mode I'd have to boot from a CD to check for sure
<zyga> slangasek: I can give you the md5sum I currently see
<tjaalton> doko: check /var/log/Xorg.0.log next time it happens, it's probably kinda short and shows something like 'no screens'
<zyga> ea865d9082f8aa250fc9f749e6391dbb  /bin/efibootmgr
<doko> ok, will do
<tjaalton> doko: in which case it's bug 982889
<zyga> slangasek: maybe we can strace it?
<ubottu> bug 982889 in OEM Priority Project precise "X trying to start before plymouth has finished using the drm driver" [Critical,In progress] https://launchpad.net/bugs/982889
<slangasek> zyga: checksum is correct.  strace it is!
<zyga> http://paste.ubuntu.com/5696697/
<zyga> write(3, "B\0o\0o\0t\0000\0000\0000\0001\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2084) = -1 ENOSPC (No space left on device)
<slangasek> barry: I'm confused, why would we need this for lucid-updates?
<zyga> hmmm
<zyga> that's _not_ good
<slangasek> zyga: have you had any recent kernel panics?
<zyga> slangasek: did I bork my EFI flash stuff
<barry> slangasek: that's my question.  when this came up last, cjwatson said it did.  i didn't have a chance to ask him why last time ;)
<zyga> slangasek: not that I recall but I had a few problems earlier with my wifi (bcm) module
<slangasek> zyga: are you using the raring kernel?
<zyga> slangasek: yes
<zyga> Linux g580 3.8.0-17-generic #27-Ubuntu SMP Sun Apr 7 19:39:35 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
<slangasek> zyga: hmmmm, not sure how to address this then; for some context, see http://mjg59.dreamwidth.org/23554.html
<zyga> slangasek: can I purge that space somehow?
<slangasek> zyga: you may be able to clean it manually from the efivars filesystem, *but*, the firmware may not recognize you've done this until after you've rebooted
<slangasek> (maybe rebooted /twice/ according to that page)
<zyga> slangasek: is that safe?
<zyga> slangasek: and how do I erase it, just files?
<slangasek> and of course the thing you're trying to write to firmware right now is your bootloader entry, so :P
<zyga> ohh
<zyga> right
<zyga> I have a ton of things in /sys/firmware/efi/vars
<zyga> http://paste.ubuntu.com/5696710/
<slangasek> zyga: none of this is safe, here there be dragons, but if you can find the right variable it should be safe to remove it since that's basically the same thing efibootmgr itself does
<zyga> can I remove dump- variables?
<zyga> man, I want the old bios back
<zyga> or uboot ;)
<slangasek> zyga: I would /guess/ those are the kernel pstore variables, yes
<zyga> slangasek: rm -rvf dump-*
<zyga> ?
<slangasek> zyga: not sure
<slangasek> zyga: note that there's a 'del_var' interface there
<slangasek> you might need to use that
<zyga> OMG
<zyga> I need to get a charger
<slangasek> or you can use /sys/firmware/efi/efivars instead
<zyga> this day is _interesting_
<slangasek> which is more filesystem-like
<slangasek> rm /sys/firmware/efi/efivars/dump* ?
<zyga> one has files, other directories
<zyga> well, efivars has files
<slangasek> /sys/firmware/efi/efivars is the new hotness
<zyga> yeah
<zyga> each dump- is full of backtraces
<zyga> I wonder if that's safe
<zyga> I mean
<zyga> it's flash
<zyga> it's going to die
<zyga> and people get tons of that (wifi, nfs, etc)
<slangasek> zyga: that's a question for the kernel team after we get you booting again :)
<slangasek> zyga: in the meantime, rm the dump*, and reboot to either recovery media or (preferably) to /efi/ubuntu/shimx64.efi directly, then recover your bootloader entry with efibootmgr
<slangasek> well, you can try efibootmgr one last time /before/ rebooting, but no guarantee that'll work
<zyga> slangasek: ok, I need to prep some stuff
<zyga> slangasek: yeah
<slangasek> zyga: the good news is, the variable names encode a unix timestamp and you've been accumulating these since at least December... so unlike some other implementations, yours seems to include a proper amount of variable space... :P
<zyga> slangasek: ok, power up
<zyga> hehe
<zyga> thanks lenovo
<zyga> slangasek: let me burn raring image on a CD before we continue
<slangasek> zyga: but be aware that filling the efi nvram is known to brick laptops in some cases (Samsung's implementation most notably), so even if we get those vars removed there's still some risk that this is going to go south on reboot
<zyga> slangasek: well, I was about to get my refresh anyway ;)
<zyga> (thought this laptop is brand new)
<zyga> I wonder if that's under warranty
 * zyga wgets current raring image
<zyga> I guess it sucks to have the full mirror and yet wget all the iso's
<slangasek> zyga: did the 'rm' work?
<zyga> I didn't try
<slangasek> ah
<zyga> I want to burn raring DVD before I continue
<slangasek> that part's safe enough to try, but ok
<zyga> actually
<zyga> I can burn the older DVD I still have in my archive
<zyga> and then rm
<xnox> slangasek: barry: yes, we need it for lucid _or_ for lucid in cat-ppa to deploy it where the checksums are generated.
<chiluk> slangasek, I was just trying to verify pad.lv/1057358 , and the fix is still not showing up in the final deb.  It looks like you still have the patch too far down 00list
<chiluk> I haven't figured out what processes 00list, and why it's so touchy... but I know it to be true.
<slangasek> chiluk: I didn't upload it; looks like that was stgraber's upload?
<chiluk> I don't know.
<chiluk> slangasek, I assume you have a script that goes through and auto marks packages for needing verification.
<chiluk> that's why I got excited.
<slangasek> chiluk: the script is run manually by the SRU team when the package is accepted into -proposed; in this case that got missed somehow and stokachu prodded me :)
<slangasek> but anyway, if the fix isn't working, you'll want to take that up with stgraber
<chiluk> yeah we'd really like to get this "simple" bug off our queue.
<slangasek> chiluk: or simply following up to the bug with that info and marking it 'verification-failed' to nudge things along
<chiluk> already marked verification-failed
<stokachu> chiluk: what did you break
<stokachu> ;P
<chiluk> wasn't me this time.
<chiluk> although I feared it was me.
<zyga> slangasek: burning
<stokachu> chiluk: are you using edit-patch to make sure the previous patches are applied before doing your work?
<zyga> slangasek: I'll remove the dump-* variables after that
<slangasek> zyga: ok
<zyga> slangasek: I think it's really bad that we keep no bounds on the number of those
<zyga> slangasek: I mean, keepin one or 5 is okay
<zyga> slangasek: keeping them till we can is crazy
<chiluk> stokachu... it's a gotcha with isc-dhcp... where it requires certain patches to be in a certain order or it will revert them halfway through the build.
<chiluk> basically I fixed my deb-diff..
<stokachu> chiluk: i did a build recently and didnt see that problem
<chiluk> but my fix didn't get pulled in.
<chiluk> stokachu, then you were doing it wrong!
<chiluk> my debdiff works.
<stokachu> apparently not if the verification-faild
<chiluk> what's in the repo has the dhcpd-ldap-apparmor.dpatch  at the end of the file where it gets reverted
<chiluk> my debdiff is not what has been applied.
<slangasek> zyga: that's one of the problems here, yes.  another is using precious nvram for non-fatal kernel oopses
<slangasek> zyga: once this is all over, do you mind filing a bug on the kernel package about this?
<zyga> slangasek: absolutely
<chiluk> man I was really excited to get this bug out of my queues ..
<zyga> slangasek: better yet, on ubuntu-devel@ we have a million bugs anyway
<stokachu> chiluk: https://launchpadlibrarian.net/136643012/isc-dhcp_4.1.ESV-R4-0ubuntu5.8.precise.debdiff
<stokachu> it add the patch at the end of 00list
<zyga> slangasek: bot not many of them may brick machines
<stokachu> chiluk: if you used edit-patch within the source directory it would handle all this for you
<chiluk> I did use edit-patch... that's what screwed up in the first place.
<zyga> slangasek: I'll copy all the dumps from that nvram to my good old hdd
<chiluk> stokachu, from 00list  #these get reverted during the build, so put non-ldap
<chiluk>  #patches earlier
<stokachu> chiluk: then i dont know b/c like i said i did the process for each distro using both dpatch and quilt
<chiluk> stokachu, you should really verify your debdiff to make sure that your patch does not get reverted.
<zyga_> slangasek: ehh
<stokachu> chiluk: edit-patch applys all patches and the work i did on top of that would've already had whatever ldap gets reverted
<zyga_> slangasek: I cannot understand anything
<zyga_> slangasek: my kernel just crashed
<zyga_> slangasek: I tried to rsync my efi vars just in case there's something I need to restore later
<slangasek> stokachu: the build log shows what's up, with the patch being applied at build time for the 'patched-ldap' build, followed by it being unapplied for a different build. https://launchpadlibrarian.net/132443806/buildlog_ubuntu-precise-amd64.isc-dhcp_4.1.ESV-R4-0ubuntu5.7_UPLOADING.txt.gz
<zyga_> slangasek: then it didn't fully crash, it was just one big overlay on the framebuffer
<zyga_> slangasek: then I rebooted it thinking that's it, the CD didn't finish burning
<zyga_> slangasek: then it _booted_ from disk
<slangasek> zyga_: omgwhat
<zyga_> slangasek: but now efibootmgr -v shows Ubuntu
<zyga_> slangasek: I have the backtrace as a photo, coming up
<zyga_> slangasek: if this makes any sense
<zyga_> slangasek: maybe the firmware adds the stuff from disk somehow if there are no entries at all?
<slangasek> stokachu, chiluk: however, this behavior seems consistent with chiluk's own debdiff on the bug, so...
<zyga_> http://paste.ubuntu.com/5696799/
<zyga_> that's my current efi
<slangasek> zyga_: that would be an insane thing for the firmware to do
<chiluk> yeah as I said the current version of code didn't use my debdiff
<zyga_> slangasek: insane + firmware == daily? right
<chiluk> the patch I wanted is still in the wron place for 00list
<slangasek> zyga_: do you have nvram space *now* to update with efibootmgr?
<zyga_> let's see
<zyga_> slangasek: nope
<zyga_> same strace result there
<zyga_> I didn't remove anything though
<zyga_> this is insane
<slangasek> right
<slangasek> *can* you remove anything?
<slangasek> or does it all just crash?
<zyga_> let's try
<lifeless> is there UEFI support for 32-bit builds ?
<zyga_> I just did
<slangasek> lifeless: no
<lifeless> slangasek: what would be involved, in principle ?
<zyga_> http://pastebin.ubuntu.com/5696808/ that's what I removed (usuniÄty == removed)
<zyga_> slangasek: reboot twice now?
<slangasek> zyga_: yep
<zyga_> cross your fingers
<slangasek> lifeless: grub-efi-ia32 exists, so in theory you just need boot media
<slangasek> lifeless: as this cannot sanely done on our existing i386 boot image without compromising bootability on *other* systems, this is not something I expect to see in Ubuntu; but you can try to persuade cjwatson otherwise
<stokachu> slangasek: is it me or is isc-dhcp using bad patching practices
<slangasek> lifeless: (oh, there's probably installer bits that need doing as well)
<lifeless> slangasek: I have a tablet here for experimentation, its an atom w/64 bit extensions, but a 32-bit UEFI environment
<slangasek> stokachu: ... possibly?
<lifeless> slangasek: and no non-UEFI boot facility [it ships w/windows 8]
<stokachu> its just weird having to put patches above other because other patches revert code
<slangasek> lifeless: make someone give you a 64-bit UEFI upgrade for it? :)
<lifeless> slangasek: so I'm pondering getting enough of Ubuntu onto it to poke at touchscreen and video support.
<slangasek> stokachu: they don't revert code; the structure of the patch file is magic and used to represent different sets of patches that are applied for different builds
<lifeless> slangasek: if only it was that easy. I will dig up the right contacts and email them
<tuxskar> hello, I'm using ubuntu 12.10 and I have this problem using libpcre3-dev
<tuxskar> ~/apertium/apertium-en-es â® apt-cache policy libpcre3-dev
<tuxskar> libpcre3-dev:
<tuxskar>   Installed: 1:8.30-5ubuntu1
<tuxskar>   Candidate: 1:8.30-5ubuntu1
<tuxskar>   Version table:
<tuxskar>  *** 1:8.30-5ubuntu1 0
<tuxskar>         500 http://es.archive.ubuntu.com/ubuntu/ quantal/main amd64 Packages
<tuxskar>         100 /var/lib/dpkg/status
<zyga> slangasek: hmm
<tuxskar> Error: pcre_compile missing )
<zyga> slangasek: not good
<zyga> slangasek: keyboard / mouse does not work
<zyga> slangasek: I've plugged external usb
<zyga> slangasek: I had this just before the issues began
<slangasek> lifeless: so if it's for a tablet and what you really need is a preinstalled image on removable media... that's fairly doable by just creating a disk image with a properly configured vfat partition and the magic binary bits in the right directory (/efi/boot/bootia32.efi, IIRC)
<tuxskar> any idea?
<zyga> slangasek: also bladernr_ is experiencing that
<zyga> bladernr_: canyou type?
<slangasek> zyga: !
<slangasek> zyga: at what point is it failing?
<zyga> slangasek: it does not respond in any way
<bladernr_> zyga: i'm fine, mine is an old issue and probably not even closely related to yours
<zyga> bladernr_: no, it started the _same_ way
<bladernr_> and it's very transient and re-occuring
<bladernr_> interesting...
<zyga> bladernr_: then I rebooted and it all went nuts
<zyga> bladernr_: are you using efi
<xnox> lifeless: you can use rEFIt builds of 32bit EFI, it works well enough on UEFI devices despite targetting Apple's EFI from that you can at least boot/chain boot into grub-32bit. The "install" process will be very manual though.
<slangasek> zyga: so you get what, a firmware screen and no input?
<lifeless> xnox: thanks
<lifeless> slangasek: thanks
<zyga> slangasek: no, I booted to ubuntu :)
<slangasek> hah
<xnox> lifeless: this is the most "current" way to bootstrap/boot into 32bit only UEFI.
<zyga> slangasek: but keyboard / mouse is not operational
<lifeless> I shall put some time aside in a couple weeks to give it a spin
<bladernr_> zyga: nope... my system is too old for that
<zyga> ok
<slangasek> zyga: ok, I claim no responsibility for this ;)
<zyga> slangasek: heh
<zyga> slangasek: ok, so I don't see any efi vars
<zyga> slangasek: shall I reboot again?
<slangasek> if deleting efi variables broke your keyboard... then that's a whole new world of crazy
<slangasek> zyga: you don't see *any* vars, at all?
<slangasek> did the efivarfs fail to mount?
<zyga> slangasek: no, I do see a few, just none of the dump-*
<slangasek> ok
<slangasek> zyga: I'd try running efibootmgr again
<zyga> slangasek: they are mounted ok
<zyga> as in -v or to add the record?
<zyga> http://paste.ubuntu.com/5696825/
<zyga> that -s
<slangasek> zyga: add the record
<zyga> I booted with partially burned raring disk
<zyga> ok
<zyga> slangasek: I think that worked
<slangasek> hurray!
<zyga> http://pastebin.ubuntu.com/5696827/
<slangasek> two Ubuntus?
<slangasek> -v?
<zyga> http://paste.ubuntu.com/5696831/
<zyga> odd
<zyga> shim + grubx
<zyga> is that expected?
<slangasek> yeah, efibootmgr writes a new boot entry instead of overwriting the existing
<slangasek> grub-install has code to handle this
<slangasek> just wanted to see which one is which to make sure the ordering was correct - and it looks fine
<slangasek> so I think you can reboot to SB mode now
<zyga> ok
<zyga> and hopefully keyboard will work ;)
<zyga> rebooting
<zyga> slangasek: yay, everything works
<slangasek> zyga: so the real question is how you ended up with a wrong, non-SB boot entry in the first place
<zyga> slangasek: so let's file a few bugs
<slangasek> zyga: upgrade logs may or may not provide illumination on this
<zyga> slangasek: that's interesting but unless there's a log that knows this I don't know how to find out
 * zyga will write a $10 app that "checks if your laptop is about to brick" ;)
<slangasek> zyga: /var/log/apt/term.log would be a start
<zyga> it should not be translated, meh
<zyga> http://paste.ubuntu.com/5696840/ http://paste.ubuntu.com/5696841/ and http://paste.ubuntu.com/5696842/
<zyga> slangasek: from the second log:
<zyga> slangasek: Rozpakowywanie pakietu systemd-shim (z .../systemd-shim_1-0ubuntu1_amd64.deb) ...
<zyga> slangasek: should that be installed?
<slangasek> yes, it's unrelated to the shim bootloader
<zyga> is that a "shim systemd"?
<zyga> ok
<stokachu> slangasek: since isc-dhcp is already in proposed with the reverted patch issue, maybe we can use https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570/comments/41
<slangasek> apparently grub-install isn't verbose enough about its EFI handling
<ubottu> Launchpad bug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Triaged]
<stokachu> slangasek: to push on top of it
<zyga> Przygotowywanie do zastÄpienia pakietu shim-signed 1.1+0~20120906.bcd0a4e8-0ubuntu4 (wykorzystujÄc .../shim-signed_1.2+0~20120906.bcd0a4e8-0ubuntu4_amd64.deb) ...
<slangasek> ohwell
<zyga> that's all I can see shim-related
<stokachu> slangasek: it contains changes from previous changelog along with mine and the proper ordering of the patches
<slangasek> zyga: oh, was shim-signed uninstalled at some point?  (since that's a new install, not an upgrade?)
<zyga> slangasek: checking
<zyga> slangasek: I dind't remove it myself if that's what you're asking
<slangasek> stokachu: er, don't patch debian/ from within debian/patches
<zyga> slangasek: what makes you think that shim-signed was uninstalled?
<zyga> as in ever uninstalled
<stokachu> slangasek: sorry not following what you mean
<zyga> slangasek: I have history.log files they have timestamps and other info
<slangasek> stokachu: the debian/patches/add-option-ignore-client-uids.dpatch there is definitely wrong, it shouldn't be patching other patches
<slangasek> stokachu: debian/patches/add-option-ignore-client-uids.dpatch *contains* debian/patches/dhcpd-ldap-apparmor.dpatch... and patches to 00list and debian/changelog as well
<slangasek> zyga: oh, sorry, this was a simple reinstall of the package, I was reading wrong
<slangasek> zyga: so yeah, looks like we have nothing to explain the wrong boot entry
<zyga> slangasek: yes, that appears to be the case
<zyga> slangasek: so what about the entry was wrong?
<zyga> slangasek: the checksum?
<slangasek> zyga: it pointed to grubx64.efi instead of shimx64.efi
<zyga> I see
<zyga> hmm
<slangasek> and only shimx64.efi is signed with Microsoft's key
<chiluk> so slangasek word round town is that stgraber is awwl (with leave) who would be the next best person to talk to about getting this issue and  https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570 committed?
<ubottu> Launchpad bug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Triaged]
<stokachu> slangasek: hah, how the..
<slangasek> chiluk: it seems that stokachu is preparing the SRU patch
<zyga> slangasek: so I see a few bugs: mysterious grubx64.efi installed, kernel oopses logged to precious efi nvram, no cap / rotation on debug data in nvram
<slangasek> zyga: the grubx64.efi isn't mysterious; it's expected and required, it's the second-stage bootloader
<zyga> slangasek: + maybe the keyboard bug but I have no way to explain that (maybe apart from efi fastboot not starting USB for some reason but without any evidence)
<zyga> slangasek: mysterious as in in that efi config space
<zyga> (I probably phrase that incorrectly)
<slangasek> ah - yes, the efi boot entry was mysterious
<zyga> slangasek: I'll write a short email to ubuntu-devel@, I'll follow up with bugs tomorrow
<zyga> slangasek: I wonder if anyone else got affected by that
<zyga> slangasek: and if the nvram depletion a factor
<stokachu> chiluk: that apparmor patch why not just edit debian/apparmor-dhcpd directly?
<chiluk> because I was still new when I wrote it at first, and I was curious about the patching system.
<chiluk> curiousity killed the cat.'
<YokoZar> cjwatson: I subscribed you to https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1166124  because I remember our conversation ~ the printed text on the CD sleeves being grossly unrealistic a year or two ago
<ubottu> Launchpad bug 1166124 in unity (Ubuntu) "Ubuntu minimum system requirements needs to be updated" [Undecided,Confirmed]
<YokoZar> cjwatson: I'm not sure if Canonical is printing CDs for 13.04 but if so please make sure they don't say 256 megs required :D
<zyga> slangasek: I wonder if it's safe to upgrade grub2 now
<stokachu> slangasek: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570/comments/42
<ubottu> Launchpad bug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Triaged]
<stokachu> slangasek: mind taking a peek now, i think ive addressed everything
<stokachu> slangasek: that should cover the broken -proposed and squash another bug
<zyga> slangasek: did we get two ubuntu entries after my crash/reboot?
<zyga> slangasek: email sent
#ubuntu-devel 2013-04-11
<ausxxh> in ubuntu is tgt or iscsitarget default for openstack/cinder?
<pitti> Good morning
<dholbach> good morning
<stgraber> chiluk: so, for bug 1057358, I didn't upload the fix, but it sounds like someone re-uploaded the exact same broken fix as last time... I said I'd take care of this when I had time but it looks like that wasn't good enough for somebody who went ahead anyway
<ubottu> bug 1057358 in isc-dhcp (Ubuntu Precise) "dhcpd in isc-dhcp-server-ldap cannot read /etc/ldap/ldap.conf due to missing entry in apparmor profile" [Medium,Fix committed] https://launchpad.net/bugs/1057358
<stgraber> chiluk: for bug 1069570, the "fix" is a feature addition in isc-dhcp, so I have no plan to SRU it as it's against SRU policy
<ubottu> bug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Triaged] https://launchpad.net/bugs/1069570
<tkamppeter_> OdyX, I have released cups-filters 1.0.34, uploaded it to Ubuntu and committed it to the Debian BZR.
<OdyX> tkamppeter_: aye. Won't have time today unfortunately.
<pitti> tkamppeter_: need some Debian sponsoring?
<OdyX> pitti: ah yeah, if you could upload it to experimental, it would be great.
<pitti> OdyX: I'll update the changelog for Debian then
<OdyX> pitti: of course. :-) .oO(And in these cases, uploading there first, and syncing looks like a good plan to me, but I'm not enough into Ubuntu to knowâ¦)
<pitti> sbuilding..
<apachelogger> Laney: yes (about kdiff3 and im-config)
<Laney> ah, because I checked the Debian BTS list for im-config and didn't see it
<apachelogger> I wasn't particularly in the mood to file tickets in all the broken software I saw yesterday, so I sent mails to the authors
<Laney> if you add patch headers then people can find this information out without having to check with you
<apachelogger> good point
<tkamppeter> OdyX, pitti, I know that getting usually synced packages to Debian first is the better way, I only quickly upload into Ubuntu as we ara in a stage close to release and so the packages should get in quickly to get more testing.
<OdyX> tkamppeter: yeah, np, as long as the general rule stays first-to-experimental-when-reasonable, I'm happy.
<pitti> cjwatson, Daviey: from the desktop side, seb128 proposed to turn off apport now as for raring we won't change a lot any more and we have errors.u.c.; any opinion from you from the foundations/server side?
<pitti> (for crash reports)
<xnox> ev: see pitti above ^
<Daviey> pitti: It makes little difference to server TBH. So i don't object.
<cjwatson> pitti: I'm OK with that if ev is
<ev> pitti: to be clear, leave it running for reporting to errors.ubuntu.com? Just turning it off for reporting to Launchpad, right?
<pitti> ev has lobbied for turning off apport LP reports all the time :)
<pitti> ev: correct
<ev> pitti: fine by me then
<ev> and yeah, the sooner we can make errors.u.c a suitable replacement for using LP bugs as a crash database for seb128 and others, the better :)
<Daviey> ev: Do you have some recent documentation how server users can add more value to errors.ubuntu.com?
<ev> Daviey: I still need to implement an automatic non-interactive reporting toggle :-/
<pitti> ev, seb128: oh, and we've traditionally kept "Type: Package" reports on LP
<Daviey> (In Raring+1, I'd really like us to considering running the dev cycle with it submit-by-default, easy opt-out - and turn off at B1.
<pitti> i. e. upgrade errors
<seb128> pitti, is e.u.c listing those?
<pitti> seb128: yes
<dpm> pitti, cjwatson, if we get the language pack exports from Launchpad to be part of the new release opening process, do you think it might make sense to add the step to set up the language packs PPA for the new release on https://wiki.ubuntu.com/NewReleaseCycleProcess ?
<cjwatson> feel free
<ev> pitti: those things are the bane of my existence. Can we sit down at not-UDS with some dpkg/apt/aptd/software-center/ohmygodtoomanypieces people and come up with a better signature algorithm?
<pitti> seb128, ev: I have no strong opinion about package problems on LP
<ev> I'm not convinced the current wall of text is particularly useful for grouping them together.
<pitti> +1
<pitti> they are incredibly hard to process even manually
<ev> yay
 * ev nods
<pitti> it often takes nontrivial smarts to figure out what the actual problem is
<xnox> ev: pitti: so we often tell people to run `ubuntu-bug ubiquity` to collect and submit all the installation logs. Would they simply arrive to errors.u.c or whould that command just do nothing?
<pitti> xnox: bug reports have never been disabled
<pitti> specifically, errors.u.c. isn't well suited for manual bug reports
<pitti> so they always go to LP, even for stables
<xnox> pitti: ah, ok. than it's all good. So it's just apport popups for "something crashed" will stop taking people to +filebug ?!
<pitti> right
<Daviey> ev: Are you likely going to have capacity to add server lovin' to whoopie in raring+1?
<xnox> pitti: awesome. +1 from me ;-)
<ev> Daviey: I really hope so.
<ev> But extra hands are always welcome
<Daviey> ev: If we can help.. just let me know.
<doko> pitti, jibel: python3.3 now ready for autopkgtest's
<ev> Daviey: find me someone to write a bit of code to automatically process and upload an apport report.
<pitti> doko: \o/
<ev> It's really not that much work - I'm just buried under the day-to-day operations.
<pitti> doko: can we disable the one test that relies on stdin existing? or was that fixed/dropped in 3.3?
<ev> s/upload/mark for upload/g
<pitti> seb128, ev: apport uploaded
<ev> Daviey: basically apport-cli without the interaction and an upstart job
<doko> pitti, please first run the test
<ev> yay
<pitti> doko: is it in some branch?
<doko> pitti, it might be different, because subprocess handles file desriptors different in 3.x
<pitti> ah, I just got a closed bug mail, apparently you uploaded already
<cjwatson> pitti: I thought I contributed debian/script.py some time back to fix that test
<pitti> ok, will still take a bit until jenkins hits it
<cjwatson> does the autopkgtest not use it?
<pitti> I'm already running a VM on my workstation right now, I have too little RAM to run a second one with py3.3; but can do in teh afternoon
<doko> cjwatson, it doesn't help (I think), if apt-run enables the redirection
<pitti> cjwatson: apparently not; but the failure is easy to reproduce with "python2.7 -E -Wd -3 -E -tt /usr/lib/python2.7/test/regrtest.py -w test_file2k </dev/null"
<cjwatson> not sure I agree; debian/script.py should work regardless of the prior state of stdin
<pitti> is debian/script.py a wrapper which the tests should be run under?
<cjwatson> yes
<doko> they do in the build
<cjwatson> right, grep debian/rules for it
<seb128> pitti, danke
<pitti> python debian/script.py foo 'python2.7 -E -Wd -3 -E -tt /usr/lib/python2.7/test/regrtest.py -w test_file2k' < /dev/null
<pitti> ^ works
<pitti> foo â /dev/null works as well (we aren't actually interested in the output)
<pitti> so that should be added to debian/tests/testsuite ?
<pitti> jibel: ^ FYI (as you were looking at that, too)
<cjwatson> pitti: just to check, you're testing this within adt-run and not just from a terminal?
<pitti> I tested that particular bit in a terminal
<pitti> I ran the full thing under run-adt-test (i. e. adt-run in a VM) and adt-run (i. e. on my workstation), and reduced the failure to above command
<dpm> cjwatson, ok, thanks, will do (re: new release openings and translations). pitti, do you have the steps documented somewhere to set up the langpacks PPA for dev releases, or can you give me a couple of bullet points and I'll add them to the wiki page?
<cjwatson> tests in a terminal are misleading here because in a terminal you have a useful stdin
<pitti> adt-run redirects stdin, causing the failure of that particular test
<cjwatson> anyway, yeah, debian/script.py is very likely the right answer
<pitti> cjwatson: the "</dev/null" should disable that, though?
<cjwatson> right
<cjwatson> I wasn't sure exactly what you meant by "foo â /dev/null", that's all
<cjwatson> â not being a redirection operator in my shell :-)
<pitti> dpm: langpack PPA to NewReleaseCycleProcess> yes from my side; you can add me as a contact point
<pitti> dpm: we don't actualy use the PPA for dev releases, we upload straight to raring; we just need to do a first manual build (once we have an export), and then set up the crontabs
<pitti> dpm: but we should set up the cronjobs for the stable releases when opening a new dev release
<dpm> pitti, yeah, I'm documenting that too
<cjwatson> damnit, haskell-hakyll hangs on the buildds - I could've sworn I'd fixed that
<dpm> thanks
<pitti> cjwatson: right, sorry; I meant: python debian/script.py /dev/null 'python2.7 -E -Wd -3 -E -tt /usr/lib/python2.7/test/regrtest.py -w test_file2k' < /dev/null
<pitti> i.e. just replacing the "foo" in my orignal call with /dev/null
<cjwatson> ah, gotcha
<cjwatson> I'd recommend just running the entire suite under debian/script.py and catting the logfile at the end, or similar?
<pitti> yes, sounds good
<pitti> cjwatson: actually, we don't need to cat the log file; output still goes to stdout AFAICS?
<doko> pitti, and enable xvfb too, and fix the disabled tests for running in the installed location ;)
<pitti> (hence my "/dev/null" log file proposal)
<cjwatson> pitti: oh, yes, true
<cjwatson> forgot my own code
<pitti> doko: one step at a time :) but it's great to have coverage for the pythons now!
<cjwatson> Laney: so, slightly perplexingly, this ghc change changes the libghc-ghc-dev ABI hash on i386 (although none of the others), and the debdiff shows the addition of /usr/share/man/man1/runghc.1.gz, /usr/share/man/man1/ghci-7.6.2.1.gz, and /usr/share/man/man1/ghci.1.gz
 * Laney blinks
<cjwatson> Laney: ghci still works fine; I wonder if some of this depends on which ghc was used to build (IOW the effective change here might simply be that I'm building ghc with ghc 7.6 rather than ghc 7.4)
<Laney> That wouldn't surprise me
<cjwatson> and libghc-ghc-dev changing hash isn't a problem if it's going to change on armhf anyway; it just surprised me
<Laney> cjwatson: I just turned up http://thread.gmane.org/gmane.comp.lang.haskell.debian/3287
<cjwatson> Ah, yes, the tail-end of that thread matches
<cjwatson> If the armhf build also only changes the ghc hash then I think we're good enough
<Laney> "In fact, I'm pretty impressed that we manage to get the same hashes even
<Laney> sometimes."
<cjwatson> heh, yeah, I liked that
<Laney> at least he's honest!
<cjwatson> I believe the reverse chain is (1) doctest, ghc-mtl, ghc-syb-utils, gitit, haddock (2) hint
<cjwatson> Which seems tolerable
<jibel> doko, pitti sorry lunch break. I'll run the testsuite in our environment with script.py
<jibel> doko, python2.7 testsuite pass when run under script.py
<doko> jibel, the other tests too?
<tim`> is there a reason raring is sticking with boost 1.49 instead of moving up to 1.53?
<tim`> errr 1.50 maybe - looks like both are packaged
<cjwatson> tim`: regardless of reasons it's far too late now - boost transitions take time
<cjwatson> we do them at or near the start of release cycles
<jibel> doko, yes, the 3 tests that failed yesterday: stdin, fsync and fdatasync. For fsync I removed eatmydata. IO performance is good enough with unsafe-io enabled in dpkg.
<tim`> just curious if there was something specific holding it up
<tim`> or if there was just not much interest
<doko> jibel, ok, thanks! for bonus points you may want to re-enable the tests in the test scripts, and then send patches to fix these =)
<doko> tim`, time ... and there is no 1.50 anymore
<pitti> doko: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python3.3/, FYI
<tim`> when do versions for 13.10 get laid out ?
<pitti> Invalid -u/--use option: all,-network,-urlfetch,-gui,-xpickle
<pitti> Use --help for usage
<pitti> it didn't get very far
<doko> pitti, my browser tries to download these files. is there a way to show these in the browser?
<pitti> doko: not that I know of; but you can use the "console output", that will be displayed inline
<pitti> I just look at them in gedit
<pitti> doko: "Konsolenausgabe" is at the left menu, leading to https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python3.3/1/ARCH=i386,label=adt/console
<doko> apw, ogasawara: I'm preparing an upload of the final GCC 4.7.3. the current version in r already has 4.7.3 as the "upstream" version. There are no changes on x86, compared to the current version. still looking at armhf and arm64
<cjwatson> tim`: only a handful of toolchain packages need to be decided early
<cjwatson> tim`: so nowish or before, and AFAIK it'll be boost 1.53
<doko> we switch to 1.53 together with GCC 4.8
<doko> at least, that's my plan
<doko> xnox had already set up the transition tracker
<apachelogger> cjwatson: I forgot to remove the colors yesterday, https://code.launchpad.net/~kubuntu-members/debian-cd/kubuntu-raring-artwork/+merge/158350 should fix this
<cjwatson> apachelogger: merged/deployed, thanks
<tim`> oh man - gcc 4.7 breaks enough things already :)
<apachelogger> cjwatson: thank you
<xnox> tim`: well and gcc 4.8 fixes a lot of C++11 things that were missing in 4.7 ;-)
<tim`> will there likely be an alt gcc-4.6 package still ?
<xnox> tim`: raring has 1.49 as default and 1.53 available in universe. The plan for next cycle (S-something) is to have 1.53 the one and only atm. We might be switching to 1.54 or have it available in universe, all depends on upstream release timing.
<tim`> cool
<xnox> tim`: why do you want gcc-4.6?
<xnox> boost-1.53 is looking very good so far: http://people.canonical.com/~xnox/boost1.53/
<tim`> i guess the issues i've run into are with cuda and zeroc-ice - ice has sorted out thier issues by now - not sure about cuda
<xnox> still a few things to fix, but nothing out of the ordinary.
<cjwatson> we only remove older gcc packages once nothing in our archive requires them any more
<cjwatson> we do generally have to keep moving forward though, otherwise the hill to climb is just that much higher later on
<tim`> yeah - understandable
<mitya57> we still have gcc-4.6 in raring (and even 4.4), but I wouldn't recommend anyone to use that
<doko> 4.4 will die in the s-series, killing all the games packages implemented in Dv1
<doko> working on getting D to 4.8, so 4.6 can die too
<tim`> D?
<doko> not C
<mitya57> https://en.wikipedia.org/wiki/D_(programming_language)
<tim`> ah yes
<NCommander> Beside D, is there any other unusual GCC frontends hanging around? (I know GNAT is kinda special though thats fortunately mainstream ...)
<siretart> go?
<xnox> siretart: we have go even in precise ;-)
<xnox> siretart: 4.8 has some support for 1.1.
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<doko> NCommander, do you want to package the PL/1 and Cobol frontends?
<NCommander> doko, don't we already have opencobol in archive? (and no, I don't :-P)
 * xnox really thinks old-style cmake find modules are brain dead..... goes to file a patch to FindZlib.cmake to include /usr/include/$(MULTIARCH) in the $ZLIB_INCLUDE_DIRS
<xnox> that looks wrong... and still doesn't solve my ftbfs... looking more.
<jamespage> pitti, could you take a look at https://code.launchpad.net/~james-page/ubuntu/raring/apport/cloud-archive/+merge/158378 - it adds a crashdb config and handler to pickup packages from the ubuntu cloud archive
<jamespage> I'd like to backport the same into 12.04 as well
<pitti> jamespage: do you figure that users will have a need to change that configuration?
<jamespage> pitti, not quite sure I understand your question
<pitti> jamespage: I'd start with putting the actual configuration into the hook, instead of adding it to the config file
<jamespage> pitti, ah - so add the crashdb configuration to the ubuntu_cloud.py hook itself - right - lemme give that a go
<pitti> jamespage: right, like report['CrashDB'] = '{"impl": "launchpad", ....}'
<jamespage> pitti, working on that now
<pitti> jamespage: and as a style nitpick, let's drop the line break and the parens in the if
<jamespage> pitti, ack
<jamespage> pitti, hmm - so on 12.04 I got a origin text in the package field - how do I detect the source of the package in raring?
<pitti> jamespage: oh, inline config doesn't work in 12.04 yet, there we'll need a file in /etc/apport/crashdb.conf.d/
<jamespage> pitti, yeah - I just noticed that :-)
<jamespage> OK - so for 12.04 I need a crashdb config in crashdb.conf.d
<pitti> jamespage: you should get the origin text in raring as well, but only if it's actually from a PPA
<pitti> jamespage: if not, then it's the ubuntu package
<jamespage> pitti: these packages come from ubuntu-cloud.archive.canonical.com
<pitti> jamespage: you can check explicitly with if apport.packaging.is_distro_package(report['Package'].split()[0]):
<pitti> jamespage: you don't get an [origin: ...] field in raring?
<jamespage> pitti, lemme check again
<doko> Sweetshark, bug subscriptions for liblangtag missing ...
<xnox> doko: http://paste.ubuntu.com/5698613/        isn't         /usr/include/x86_64-linux-gnu/ missing from that list?
<doko> damn, he did smell that
<doko> $ gcc -v -E -dM - < /dev/null 2>&1| grep '^ '
<doko>  /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -E -quiet -v -imultilib . -imultiarch x86_64-linux-gnu - -mtune=generic -march=x86-64 -fstack-protector -dM
<doko>  /usr/lib/gcc/x86_64-linux-gnu/4.7/include
<doko>  /usr/local/include
<doko>  /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed
<doko>  /usr/include/x86_64-linux-gnu
<doko>  /usr/include
<doko> xnox, works for me. why do you call cc1 directly?
<jamespage> pitti, it would appear not
<doko> Sweetshark, bug subscriptions for liblangtag missing ...
<xnox> doko: hmm.... thanks that your command also works for me.
<xnox> doko: trying to understand https://launchpadlibrarian.net/136352236/buildlog_ubuntu-raring-armhf.sword_1.6.2%2Bdfsg-5ubuntu1_FAILEDTOBUILD.txt.gz
<xnox> zlib.h is in non-arch qualified, zconf.h is in arch-qualified location. Yet somehow zconf.h doesn't get included from zlib.h..... probably cmake/that package silliness.
<xnox> then.
<jamespage> pitti, packaging.get_package_origin give me 'Canonical' - I think thats good enought for my filter
<doko> xnox, the -I/usr/lib/arm-linux-gnueabihf looks suspcicious, but shouldn't hurt
<doko> -- CONFIGURING SOURCE LIST
<doko> -- ZLib: system /usr/lib/arm-linux-gnueabihf/libz.so
<doko> -- cURL: system /usr/lib/arm-linux-gnueabihf/libcurl.so and /usr/include
<apw> doko, thanks
<Sweetshark> doko: thx for adding
<doko> xnox, ^^^ so for curl it does detect the include, but not for zlib ?
<doko> cmake madness?
<stokachu> xnox: am i reading nmu wrong? i thought since im not the maintainer it should be filed as such (re sosreport)
<xnox> stokachu: from the point of view of the Debian Project - the package maintainer is the person who uploads and maintains the package in debian. the upstream contact is who wrote the software and is the main committer, the upstream contact can be mentioned in ./debian/copyright
<xnox> stokachu: NMU is when another person makes an upload of the debian package on-behalf of the regular package maintainer.
<xnox> stokachu: for example if you upload xiphos into debian, instead of me, that would be NMU. As I'm debian maintainer for xiphos.
<stokachu> ahh
<xnox> stokachu: if I upload sosreport into debian instead of you, that would be NMU. As i will not be the regular maintainer of that package.
<cjwatson> filing a bug report with "NMU" in the title is kind of a declaration of intent
<cjwatson> assuming that's what you mean
<xnox> cjwatson: stokachu meant to do an ITP ;-)
<jamespage> pitti, how does that look - https://code.launchpad.net/~james-page/ubuntu/raring/apport/cloud-archive/+merge/158378
<stokachu> ok so do i close this sponsor request
<jamespage> seems to work OK for me (although the test on raring is a little artificial as the cloud archive is really just for 12.04
<jamespage> )
<xnox> stokachu: one files an ITP if you intend to upload and hence become package maintainer in debian for that new piece of software.
<pitti> jamespage: splendid!
<stokachu> xnox: yea thats what i need to do
<cjwatson> stokachu: don't close the bug and open a new one - that's pointless
<cjwatson> stokachu: mutate it into what it's supposed to be instead with control commands
<pitti> jamespage: yeah, but it doesn't hurt to have it there, so that it will be there for the next LTS, or if we actually get a cloud archive for raring for some reason
<stokachu> ok
<cjwatson> http://www.debian.org/Bugs/server-control
<jamespage> pitti, yes indeed - that's kinda what I thought
<xnox> stokachu: well open an ITP with cc to debian-devel, and mutate the sponsorship request =)
<jamespage> pitti, are you OK for me to upload that and push the branch?
<stokachu> so i should have an ITP ane a sponsorship request bug
<pitti> jamespage: I just hope that ~cloud is a sufficiently tight test
<stokachu> and*
<xnox> stokachu: as one should file ITP to "announce" that you are about to take-up a package.
<jamespage> pitti: I think ~cloud with origin 'Canonical' is
<stokachu> xnox: 698329
<pitti> jamespage: sure, please do (and use  "dch -r" and "debcommit -r" after that)
<jamespage> pitti, ack
<xnox> stokachu: yeah. As ITPs are usually forwarded to debian-devel and some people can point out typpos in the descriptions, or reason for a package to be not included in debian and such like. Just google for "ITP" on debian-devel to get the sense of those bugs/descriptions.
<xnox> stokachu: new maintainer guide should tell you all about these things.
<stokachu> yea ive been reading through the guides but i guess i got confused on nmu versus itp
<BenC> infinity: any reason that linux-ppc-3.8.0-8 isn't in raring proper yet?
<xnox> stokachu: in ubuntu we do not have "strong maintainership" instead anyone can upload anything, thus the concept of NMU is non-existent in ubuntu.
<cjwatson> BenC: it's waiting for me to upload debian-installer
<BenC> cjwatson: Ah, ok, thanks
<cjwatson> which in turn is waiting for somebody to approve libdebian-installer in the upload queue
<BenC> Just making sure it doesn't fall through the cracks :)
<stokachu> xnox: ahh
<stokachu> xnox: its all making sense now :)
<cyphermox> slangasek: I'd remove the duplication for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1073433 if you don't mind, I can definitely reproduce the / is busy even after manually stopping and killing just about everything before doing a reboot; I got lsof after the stops and all, and there's very little left around
<ubottu> Launchpad bug 1124803 in network-manager (Gentoo Linux) "duplicate for #1073433 NetworkManager doesn't respond to SIGTERM in daemon mode" [Undecided,New]
<slangasek> cyphermox: ok, so what is keeping the root fs busy?
<cyphermox> slangasek: I don't know ;)
<cyphermox> slangasek: http://paste.ubuntu.com/5698847/  <-- I think "sh", is related to sendsigs too, there are no sessions open at the time in VTs or in lightdm or anywhere
<cyphermox> certainly running lsof like so adds one more thing to write to /, but the same issue appears even if I comment out that part
<cyphermox> (I had lsof run as part of sendsigs)
<pitti> stgraber, Laney: could you please accept ~ubuntu-core-dev invitation into ~network-manager?
<pitti> with that, core devs can finally push to the NM packaging branch
<stgraber> pitti: yep, will do
<stgraber> done
<pitti> stgraber: merci!
<pitti> jamespage: http://launchpadlibrarian.net/136986347/apport_2.0.1-0ubuntu17.1_2.0.1-0ubuntu17.2.diff.gz LGTM
<jamespage> pitti, great!
<tkamppeter> OdyX, I have added a new USB quirk rule patch (5 printers) to CUPS and also submitted it upstream, it also contains your correction for the Stylus Photo 750. See Debian GIT, new Ubuntu CUPS package, and https://www.cups.org/str.php?L4311.
<bryce> slangasek, does udev automatically reload all rules at boot, or do you have to deliberately run udevadm trigger?
<bryce> (or udevadm control --reload-rules; google gives me some conflicting recommendations)
<smoser> cjwatson, do you know how i can make debian installer not go into vga mode from the netboot iso?
<smoser> trying to boot with 'kvm -curses'
<smoser> kirkland, for some reason i think maybe you have known that?
<slangasek> bryce: so, if by "reload" you mean "load from disk when started from the root filesystem"... sure?
<slangasek> bryce: what's the root problem here?
<bryce> slangasek, for the gpu hang apport hook, which is started by a udev rule, I wanted to disable that for the release, so commented out the line in the udev rule.  However I'm noticing we're still getting a few reports, so am wondering if something more needs done to get the rule disabled for folks.
<slangasek> bryce: udev has an in-memory cache of the rules (naturally), but otherwise reads them from disk on every boot.
<bryce> slangasek, ok, that's what I thought.  But I can't explain how bug #1168066 got autofiled.  I mean it's good that it got filed, it's a legit bug.  But AFAIK the rule should not be filing these bugs anymore so I'm a bit perplexed.
<ubottu> bug 1168066 in xserver-xorg-video-intel (Ubuntu) "[arrandale] GPU lockup IPEHR: 0x54300004" [High,New] https://launchpad.net/bugs/1168066
<slangasek> bryce: we're talking about /lib/udev/rules.d/40-xserver-xorg-video-intel.rules, right?
<bryce> slangasek, yes
<slangasek> bryce: I have the version of the package from that bug installed, and I see a present and active udev rule
<slangasek> so it doesn't seem to actually be disabled in the package?
<bryce> slangasek, not commented out?
<slangasek> bryce: nope
<slangasek> # Disable freeze hook.
<slangasek> SUBSYSTEM=="drm", ACTION=="change", ENV{ERROR}=="1", RUN+="/usr/share/apport/apport-gpu-error-intel.py"
<slangasek> there's a nice comment /above/ it ;)
<bryce> hum, that could be the problem.  It *is* commented out in the package
<slangasek> define "in the package"
<slangasek> that's the unmodified version of the file, from the binary package in the archive
<bryce> apt-get source xdiagnose; cat xdiagnose-3.4.4/debian/xdiagnose.udev
<slangasek> bryce: oh, but it's not shipped by xdiagnose
<slangasek> it's shipped by xserver-xorg-video-intel!
<bryce> o_O
<ogra_> heh
<bryce> ahem.  yay leftovers.
<barry> slangasek: so, apt-ftparchive.  between mvo and i, we've uploaded for raring and sru for precise.  i *think* i've got a chroot to build for lucid-cat.  now the fun bit: lucid dpkg-source can't parse multiarch deps like gettext:any.  it's probably okay to just remove :any from the build-dep (it's the only bd with that that i can see).  agreed?
<slangasek> barry: definitely yes
<barry> slangasek: cool.  we'll see if that makes the package buildable :)
<barry> slangasek: hmm, likely will have to bump down some dep version numbers as well
<slangasek> bryce: so I guess that also explains why I was getting two apport popups for every gpu hang ;D
<bryce> slangasek, and also why we were still getting false gpu reports after we thought we fixed it...
<roadmr> hello! when doing a pxe installation with raring, entries in /etc/network/interfaces appear borked ;/ there's no space between the lo and eth0 stanzas. Is this known or should I file a bug?
<sarnold> roadmr: can't go wrong with a bug report :)
<roadmr> sarnold: ok, makes sense, let me research this a bit more and then I'll file
<bryce> slangasek, sru's are in for that.  thanks for noticing the redundant rule.
<dobey> barry: is bug #1071897 still relevant at all or should i just close it as invalid?
<ubottu> bug 1071897 in ubuntuone-client (Ubuntu) "4.0.0-0ubuntu1 fails to build (test failures) on Raring" [Undecided,New] https://launchpad.net/bugs/1071897
<barry> dobey: i haven't tried recently.  let me grab it and try.
<dobey> barry: does it even matter now? 4.2.0 is in rarning now, and this bug is from ~5 months ago when lots of deps were changing
<barry> dobey: yeah, probably doesn't
<barry> dobey: well, the test suite is still giving me errors on a local sbuild.  if it's not breaking on the buildd's, i'll close my eyes and pretend they aren't happening.
<dobey> barry: it works building in 3 PPAs and the official archive, so not sure what the difference would be exactly to cause it to fail locally for you
<barry> dobey: me neither, but if you don't care i don't either :)
<dobey> barry: i do know i had problems with ubuntu-sso-client when trying to switch from pbuilder to sbuild for testing locally, and i think there is a config difference with the lp builders vs. local sbuild, where the issue doesn't occur on the lp builders, so maybe it's related to that. but i haven't had time to deal with fixing it, and it's a fairly complicated thing to fix
<cjwatson> smoser: https://help.ubuntu.com/12.04/installation-guide/i386/boot-parms.html - DEBIAN_FRONTEND=text
<cjwatson> barry: the fact that you're asking that question (gettext:any) makes me a bit concerned that you're trying to drop the whole of raring's apt into lucid-cat, rather than cherry-picking the relevant patches - is that the case or am I missing something?
<cjwatson> (or precise-updates' apt into lucid-cat, either way)
<slangasek> cjwatson: yep, sorry, I may have suggested to barry that a full apt backport from precise-updates /might/ possibly be easier
<barry> cjwatson: well, i was being optimistic, but i think it's not the right way to go.  unfortunately, the apt code in question has changed significantly since lucid, so the precise/raring patch has little hope of applying to the lucid version.  i've been talking with mvo over email about it, and he'll probably take a crack at producing a lucid version of the patch instead
<slangasek> but apparently this was me forgetting just when lucid was :-)
<barry> slangasek: ;)
<slangasek> (i.e.: before multiarch... and apparently also before dpkg-symbols supported c++ names!)
<barry> slangasek, cjwatson maybe we should convince is to just upgrade to precise already :)
<slangasek> barry: depends on how soon we want this bug fixed
<barry> slangasek: yeah.  the bug report made it sound like a big deal for some folks
<barry> anyway, let's see if mvo can help us out here before we worry too much
<celso_> People,  i need something that install the updates available until last week. but i dont want to install the ones after that. how do i do that? i need this to detect a regression.
<sarnold> celso_: there's a log of package operations in /var/log/dpkg.log -- perhaps that can help you
<geofft> celso_: ask xnox if he's deployed our LP-Librarian-using snapshot code yet :)
<geofft> I can probably cobble something together if you give me a timestamp
<celso_> i will explain what is happening. until near last week, my laptop was doing fine, using vgaswitcheroo to turn off my atihd5000 series to use my intell hd3000. after the last week updates (near that time) my laptop almost 90% of the time, when booting, it stays with the black screen.
<celso_> but it won't happen if i don't install the updates, so, something has gone wrong in some file updated.
<celso_> and i would like to find what is.
<celso_> but unfortunatly, i am no developer or programer.
<celso_> so, i am kind of "stuck"
<sarnold> celso_: If I understand what I've seen others report, plymouth fights lightdm for console during boot.. you may wish to search for bugreports with both those names
<celso_> but it don't even show a console. it stays with completely black screen with brightness and with some disk activity each half second.
<celso_> i think a feature to install/block updates by time would be a good feature to debug some bugs
<celso_> the problem for dpkg.log is it will not show the time each update become available if i install all now
<celso_> i think
<sarnold> celso_: true enough, it only shows what happened on that one machine..
<celso_> i will install 100 updates each time and will see what happens, and then cut another half, and again....
<celso_> it will cost alot of bandwitch but its the only way i can see.
<celso_> brb and by the way, thanks for the help!
<stokachu> if there is a LICENSE file and a debian/copyright but the package is for both Debian and Fedora do I renamed the LICENSE file to like LICENSE.Fedora?
<sarnold> celso_: apt-cacher-ng or apt-cacher can easily cache packages that you download, it can drastically save time here
<celso_> ok. i will try.
<celso_> thanks!
<ion> Also see squid-deb-proxy
<celso_> have to restart. brb
<stokachu> so if an upstream source has a LICENSE file is it acceptable to remove it during a debian build? lintian keeps reporting an extra-license-file error
<stokachu> i have updated debian/copyright accordingly
<slangasek> stokachu: it doesn't make sense to remove it from the source tree during the build, but you can use any of a number of techniques to make sure it doesn't ship in the binary package, yes
<stokachu> slangasek: any urls you can point me to? googling is failing for me :(
<slangasek> stokachu: might be better to use a worked example
<slangasek> stokachu: can you point me at your package?
<stokachu> so right now im working off https://github.com/sosreport/sosreport/tree/master/debian
<stokachu> using debhelper and the Makefile is what is forcing a install of LICENSE into /usr/share/sos/.
<stokachu> so one thing i thought of was to let debian and rpm spec handle the actual copying of the license file and removing it out of the makefile
<slangasek> stokachu: (the reason I suggest this is that "how do I exclude this file" is dependent on the style of packaging in use... it might be a matter of fixing debian/sos.install, or calling 'rm debian/sos/usr/share/sos/LICENSE' in debian/rules)
<slangasek> stokachu: python-support is deprecated, please use dh_python instead (wiki link in one second)
<stokachu> yea ive got a few changes i haven't committed yet
<stokachu> lemme show you my branch one sec
<slangasek> ok
<stokachu> slangasek: https://github.com/battlemidget/sosreport/tree/debian-packaging/debian
<stokachu> thats my latest work from after fixing all lintian errors
<slangasek> stokachu: so I'd say the simplest approach here is:
<slangasek> override_dh_auto_install:
<slangasek> \tdh_auto_install
<slangasek> \trm -f debian/tmp/usr/share/sos/LICENSE
<stokachu> ah ok
<stokachu> i tried override before but didnt call dh_auto_install first
 * slangasek nods
<stokachu> gonna try that now and test
<stokachu> slangasek: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705192 trying to get this thing sponsored
<ubottu> Debian bug 705192 in sponsorship-requests "RFS: sosreport/2.3-2 ITP" [Wishlist,Open]
<stokachu> so far i think ive fixed all the warnings from message 29
<slangasek> stokachu: you seem to still have a dep on python-support in your branch
<stokachu> ah in my control file
<stokachu> lemme remove that
<stokachu> i also see this warning
<stokachu> W: dh_python2:90: Python 2.7 should install files in /usr/lib/python2.7/dist-packages/. Did you forget "--install-layout=deb"?
<stokachu> but when i look at the layout after it builds it is in dist-packages already
#ubuntu-devel 2013-04-12
<slangasek> well, --install-layout=deb is an argument to distutils/setuptools, which isn't being used here... so I think that's an ignorable warning
<stokachu> ok
<doko> this warning is ... interesting. but you should ignore it if the results look ok
<stokachu> yea as far as i can tell the file layout is what it warns about
<stokachu> slangasek: https://github.com/battlemidget/sosreport/blob/debian-packaging/debian/rules
<stokachu> lintian sosreport_2.3-3_amd64.deb
<stokachu> W: sosreport: extra-license-file usr/share/sos/LICENSE
<stokachu> does the rules file look right?
<stokachu> that is the last lintian error and its taking me forever to figure out lol
<slangasek> stokachu: that looks right to me
<stokachu> slangasek: should it be something like $(CURDIR)/debian/$(PACKAGE)/usr/share/sos/LICENSE
<slangasek> hmm
<slangasek> stokachu: yes, I suppose it should after all
<slangasek> stokachu: sorry, I'm used to dh_auto_install acting on debian/tmp, not debian/$pkg, because that's what it does in the multiple-binary case
<stokachu> ahhh
<stokachu> i was reading back through the log and saw the directory structure so lemme try that
<stokachu> slangasek: yay success
<celso_> sarnold: are you here?
<celso_> well, for those who are here and heard my history of a bug, after i installed the updates a few each time, i found the problem it was random. i thought it ws because of a file corrupted of some bug in some file but it wasn't, it seems.  Probably, after my ubuntu's updates installations, it doesn't update correctly the initramfs, so, after the long work, updating the initramfs will fix it. strangely its only afects me when i am us
<celso_> by the way, sorry for my bad english.
<celso_> and thanks for the help.
<pitti> Good morning
<pitti> slangasek: ah, your pkexec PAM env patch landed upstream, good
<pitti> so we can put that change into Debian
<pitti> [done]
<pitti> tkamppeter_: wrt. your cups upload, don't you want to merge with the Debian changes in git? (-4) there are more fixes, like the one you gave to me yesterday about the web UI triggering an AppArmor violation
<pitti> tkamppeter_: oh, I guess you don't want the cups-server-common split?
<dunkel2> hello
<tkamppeter> pitti, yes, it is the cups-server-common split why I stopped syncing cups.
<dholbach> good morning
<tkamppeter> pitti, your apparmor fix is now ported to Ubuntu and uploaded as cups 1.6.2-1ubuntu5.
<dholbach> RAOF, happy birthday!
<RAOF> dholbach: Thank you!
<shadeslayer> RAOF: happy birthday :)
<didrocks> happy birthday RAOF ;)
<RAOF> Thanks!
<Laney> tkamppeter: can you reupload cups with -v please? so that all the bugs get closed
<Laney> that or merge the versions into ubuntu4 since this didn't get accepted yet
<tkamppeter> Laney, uploaded all in one shot as -1ubuntu4 now.
<Laney> merci!
<seb128> hum, I never remember
<seb128> does it work to have .install.<arch> files?
<seb128> like binary.install.i386 and binary.install.amd64?
<cjwatson> yes, see debhelper(7)
<OdyX> tkamppeter: aye, nice.
<cjwatson> but remember that they entirely override .install - if you need to combine them then you'll need to generate those files
<cjwatson> you could also use dh-exec(1) as an alternative
<seb128> cjwatson, thanks, I was looking at man dh_install
<seb128> cjwatson, that's for streamer-fluendo-plugins-partner, it's basically one .so to install, and a different one for i386 and amd64
<seb128> we had 2 sources but that doesn't seem required, I'm merging them
<seb128> the .install.<arch> will do ;-)
<seb128> in fact that already uses dh-exec
<seb128> so I can build on that
<pitti> Committed revision 666.
<pitti> beware of 3v1l!
<jussi> pitti: you are of the devil...? :D :P
 * jussi hugs pitti
 * pitti hugs you back
<pitti> that was a commit to NM to add integration tests with simulated wifi devices
<pitti> so, not that far from "evil" indeed :)
<celso_> sarnold, i found the problem.
<celso_> it seems the update manager wasn't updating the initramfs, so, leaving my boot broken. i updated the initramfs manualy and it fixed the problem.
<stgraber> for those interested, we'll have a Google hangout on air in 40min (http://ubuntuonair.com) about image based updates and our plan for Ubuntu Touch. I'll send a summary with links to the video and wiki page to the ubuntu-devel ML after the meeting.
<smoser> cjwatson, thanks for following up wrt the text mode.  I did find what i wanted, but it wasn't so straight forward.  the issue is that i was hoping to use 'kvm -curses' which does not do vesa, and the default media has a vesa menu.
<smoser> i was able to rebuild with menu.c32 rather than vesamenu.c32 to get what i wanted.  also have to modify kernel cmdline params to have 'nomodeset' and (possibly) 'fb=false'
<voldyman> hi, i want to make an indicator using appindicator in vala. something like the current sound indicator. can someone point me to docs? or an example code? the doc i found at ubuntu.com is very sparse
<cjwatson> Laney: does https://launchpadlibrarian.net/137180694/buildlog_ubuntu-raring-armhf.gitit_0.10.2-1ubuntu2_FAILEDTOBUILD.txt.gz make any sense to you?
<cjwatson> built fine on other arches
<cjwatson> stgraber: the other defence you could add is an expiry date on the index
<cjwatson> on the signed object, that is
<cjwatson> not perfect in the face of wrong clocks on the client though
<stgraber> cjwatson: good point, I currently include a generate date, so we could at least have the client refuse anything older than the last one
<cjwatson> (as in, there are two problems: an attacker also intercepting ntp.u.c or whatever; and an accidental wrong date causing people to be innocently unable to upgrade)
<cjwatson> so it may not be the right answer, just worth considering
<Laney> cjwatson: I don't understand on the face of it why that would be arch specific
<Laney> does the code have some ifdefs or similar?
<Laney> hm, parseImportDecl comes from ghc
<cjwatson> Laney: ah, parseImportDecl is #ifdef GHCI
<cjwatson> (in ghc itself)
<Laney> that'd do it
<cjwatson> Laney: so this is really a missing build-dep on ghc-ghci, I guess
 * Laney nods
 * cjwatson removes the binaries then
<Laney> I wonder if the 'else' branch of that #if would work
<Laney> I can't see that findModule and mkModuleName are conditional
<Laney> my testing appears to show that those two functions are there on armhf still
<Laney> so this might be rescuable
<cjwatson> that'd be nice.  no interesting rdeps so it's not a disaster if not
<Laney> still, would be nice to have gitit the application
<cjwatson> yeah, I care more about applications than the libraries along the way :)
<tseliot> pitti: do you still have the python test file to reproduce bug #804662 ?
<ubottu> bug 804662 in nvidia-common (Ubuntu Precise) "jockey-gtk crashed with TypeError in _execute_child(): execv() arg 2 must contain only strings" [High,Triaged] https://launchpad.net/bugs/804662
<OdyX>  /win 26
<Hammerhead2011-S> Hi All
<Hammerhead2011-S> I see that this Bug #1102484  was "fix released" Can someone help me out with how to get the fix? an update from apt-get does not seem to do it....
<ubottu> bug 1102484 in gnome-screenshot (Ubuntu) "Selecting 0â0 screenshot area produces "All possible methods failed" error message" [Low,Triaged] https://launchpad.net/bugs/1102484
<zyga> jodh: ping
<jodh> zyga: hi
<zyga> jodh: upstart-file-bridge running in the user session fails to write a PID file
<zyga> jodh: cat ~/.cache/upstart/upstart-file-bridge.log
<jodh> zyga: ignore it - it's harmless (and already fixed upstream).
<jodh> zyga: doesn't stop the bridge working fully.
<zyga> jodh: cool, thanks
<zyga> jodh: this could be used to start an arduino sketch after plugging in arduno :)
<zyga> jodh: or asking the user if they want to install the right software
 * zyga likes that a lot
<jodh> zyga: the bug # is 1163103 btw.
<zyga> and it would play nice with uctrl "control center" for hw geeks
<zyga> jodh: is :sys: a "namespace" for events from the system upstart?
<jodh> zyga: yes, see upstart-events-bridge(8).
<med_> slangasek, how do we get walinuxagent out of -proposed and into distro today?
<med_> stokachu, ^
<xnox> med_: which distro?
<med_> precise and quantal
<med_> xnox
<med_> trying to get them into updates
<Laney> Packages usually age there for seven days before moving over
<xnox> med_: and we do not release -updates on Fridays, becuase if regression happens there is very little people over the weekend to fix things up.
<cjwatson> we can waive the seven-day waiting period for critical reasons (sounds like this may be), but indeed I'd much prefer to release end of Sunday / start of Monday if possible
<med_> utlemming, ^ does that do us any good?
<med_> cjwatson, pretty time crit.
<med_> (many thanks for the eyeballs/feedback guys)
<cjwatson> to be fair the only users this would break are basically azure images, and it's been tested there
<med_> yep
<utlemming> med_, cjwatson: if we can have it by SOD Monday, then it should be okay
<med_> and that's where/why it is needed.
<cjwatson> med_,utlemming: what's your availability over the weekend in the event of a problem?
<med_> so Sunday would work
<med_> cjwatson, I'm flying to OpenStack but generally avaiable after 1pm Pacific
<cjwatson> if you're available, I'm happy enough to waive the waiting period and release now, to unblock
<med_> +1
<cjwatson> just don't want the possibility of a regression with nobody around
<utlemming> +1, we'll make this a crit sit for the cloud images, and make absolutely sure things go smoothly
<med_> I'm avaiable today and tomorrow and Sunday
<cjwatson> ok, releasing
<utlemming> same here
<utlemming> cjwatson: thank you kindly
<cjwatson> xnox is right in general though, this isn't a precedent :)
<med_> cjwatson, xnox, Laney : many thanks. Sorry for the exception (and we're both working on getting further upstream in the process to avoid this.)
<Laney> np, hope it goes smoothly
<utlemming> cjwatson: agreed....we were content to let this go through the regular process, but the process ran out of time
<cjwatson> right, if we're going to have to waive anyway, I'd rather do so earlier than later to allow more time to iterate if necessary
<cjwatson> just to explain rationale for now rather than Sunday evening
<xnox> utlemming: it's just something to factor in - that a fix accepted into -proposed on Friday-Sunday can only be release on Monday the week after.
<cjwatson> Laney: gitit> no, afraid not.  setContext and compileExpr are only defined #if GHCI.
<cjwatson> Laney: Though I suppose disabling plugins might work
<Laney> ah, I only checked findModule and mkWhateverItIs
<stokachu> cjwatson: ill be around this weekend as well
<stokachu> if any regressions pop up from azure
<Laney> seems there is a flag for plugins, so try passing -f-plugins
<cjwatson> Yeah, was just trying that
<cjwatson> You think that'd be OK in Debian as a better-than-nothing option?
<Laney> yeah I think so, do you?
<Laney> maybe document it somewhere or other
<cjwatson> Yeah
<cjwatson> README.Debian I suppose
<GridCube> jbicha, ping
<seb128> barry, doko: do you have any idea about the issue in https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/1162124 ?
<ubottu> Launchpad bug 1162124 in python-defaults (Ubuntu) "package gconf2 3.2.5-0ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed]
<seb128> it seems quite frequent according to error.ubuntu.com
<seb128> it fails to import "io"
<jbicha> GridCube: what's up?
<GridCube> :) hi jbicha i noticed that you edited last the wiki entry for the irc redirection, can i pm you with some questions?
<jbicha> GridCube: #ubuntu is probably a better place for general questions about IRC on Ubuntu
<GridCube> no, its not about that its about adding a new subdir to the /IRC/ wiki
<barry> seb128: i think that's a dupe of a bug that doko has been working on
<seb128> barry, ok, "known issue" then?
<seb128> barry, do you know the master bug number by any chance?
<barry> seb128: yes, i think so.  let me see if i can find it.
<seb128> barry, thanks
<barry> seb128: bug 1165172
<ubottu> bug 1165172 in python2.7 (Ubuntu Raring) "upgrade 12.10 -> 13.04 fails : new libpython2.7-minimal used during upgrade while libpython2.7-stdlib is not yet unpacked and configured." [Critical,Fix released] https://launchpad.net/bugs/1165172
<seb128> barry, thanks!
<barry> np :)
<seb128> nice to see it's already fixed as well ;-)
<barry> time machine ftw!
<Hammerhead2011-S> I see that this Bug #1102484  was "fix released" Can someone help me out with how to get the fix? an update from apt-get does not seem to do it....
<ubottu> bug 1102484 in gnome-screenshot (Ubuntu) "Selecting 0â0 screenshot area produces "All possible methods failed" error message" [Low,Triaged] https://launchpad.net/bugs/1102484
<Hammerhead2011-S> any help would be greatly appreciated
<Hammerhead2011-S> I use this program a lot.
<Hammerhead2011-S> Do I need to be in a different group asking this question?
<GridCube> jbicha, sorry to bother you :( its that #ubuntu-wiki its empty
<jbicha> GridCube: oh, as long as you're trying to make things better you can edit the wiki how you like, you can log in with your Launchpad account
<GridCube> jbicha, :) thanks, i did a proper question on #ubuntu-doc just now
<GridCube> sorry to have bothered you
<GunnarHj> slangasek: ping?
<slangasek> GunnarHj: hi
<GunnarHj> slangasek: Didn't Jamie say he's fine with the patch at bug 1155327? I mean, you don't really need anyone else to review it to upload it, right? ;-)
<ubottu> bug 1155327 in skype (Ubuntu Raring) "skype crashed with SIGSEGV in malloc@plt()" [High,In progress] https://launchpad.net/bugs/1155327
<slangasek> jdstrand: ^^ bug #1155327 - I'm not sure if you've acked this patch, or just withdrawn your objection to the principle
<ubottu> bug 1155327 in skype (Ubuntu Raring) "skype crashed with SIGSEGV in malloc@plt()" [High,In progress] https://launchpad.net/bugs/1155327
<slangasek> I'm still not sure how good of a workaround it is
<slangasek> because I don't know *why* libGL is used by skype/qtwebkit
<jdstrand> slangasek: I've withdrawn my objection to the idea of supplying a skype workaround
<slangasek> if it actually needs it, using mesa in place of the binary driver will give wrong results
<GunnarHj> Me neither. I have no clue. But it works. :)
<jdstrand> slangasek: I don't really have any other insight. I think if we were going to do this, the script should be updated to use 'exec ...' rather than backgrounding the process and to reference the upstream bug in the script and the debian/changelog
<slangasek> the dependency tree is skype -> libQtWebkit -> libQtOpenGL -> libGL
<slangasek> jdstrand: agreed
<slangasek> GunnarHj: could you make the changes jdstrand suggests?
<jdstrand> slangasek: the only other concern I had is how much leeway we have with the package since it is in partner (I forgot about that)
<slangasek> well, we do diverge from upstream's own package
<jdstrand> k, then it seems reasonable. you'd know better than I
<slangasek> so I can do whatever's needed here, though I'll want to give folks a heads-up that I'm doing it
 * jdstrand nods
<GunnarHj> slangasek: Sure, I can adjust the patch like that.
<jdstrand> I'll comment in the bug
<slangasek> Mirv: so regarding skype/qtwebkit/nvidia... I'm not sure lack of crash reports points to this being skype-specific, given how useless the backtrace is
<lifeless> it might be measurement bias
<GunnarHj> slangasek, jdstrand: Ready to go. :)
<Acibi> Hi, I got a question about 13.04..
<Acibi> Is gksu will be install by default in the final release?
<slangasek> Acibi: there are no changes planned between now and release for the set of default packages
<slangasek> I believe, from a quick archive check, that gksu is included as part of the liveCD environment but is *not* included by default when installing
<Acibi> Yeah, I've seen this..
<Acibi> Thanks.
<slangasek> gksu should certainly be regarded as deprecated in favor of policykit
<sarnold> is 'ubuntu-core' the line to look at in the 'seeded-in-ubuntu' output?
<slangasek> sarnold: how do you mean?
<sarnold> slangasek: seeded-in-ubuntu -b pksu shows 'ubuntu: ' and 'xubuntu: ' and similar lines.. but seeded-in-ubuntu -b dash or -b bash both show 'ubuntu-core: ' lines...
<sarnold> slangasek: I'm curious if these lines are an indicator of what will be installed by default or not
<sarnold> or, do you just have to know the installer and what it does? :)
<slangasek> sarnold: nope; 'ubuntu-core' refers there to the ubuntu-core /image/
<slangasek> sarnold: in this case, I looked at 'apt-cache show gksu | grep Task' - the purpose of seeded-in-ubuntu is to tell you whether the package impacts an image, it doesn't give information about live env vs. install
<sarnold> slangasek: ah! thanks :)
<slangasek> in this case, I'm uncertain why gksu shows up on daily-preinstalled
<slangasek> that smells funny to me
<Acibi> So still unclear if it will be there? :P
<slangasek> Acibi: not unclear unless you're using a "preinstall" image, which only applies to nexus7
<Acibi> mmhh kk.
<slangasek> right, it's only present on the preinstalled image because ubiquity uses it; so after first-boot when ubiquity runs, gksu is probably removed from that case too
<slangasek> Acibi: why the interest in gksu?  It is, as I said, deprecated in favor of policykit
<Acibi> Use in our application, used to write global preferences as root in a file, kind of parental control.
<Acibi> We used it to launch the script that write the data, so it prompt the user for the password.
<slangasek> right; well, if your app is provided as a package, that package should depend on gksu whether or not it's available by default
<Acibi> The problem is there, not provided as a package ;)
<Acibi> I'll try to figure something, maybe using pkexec to install gksu for now, but in long term I'll have to use only pkexec I presume ;)
<slangasek> why use pkexec to install gksu instead of just using pkexec to run your script?
<Acibi> gksu is also used to launch the graphical installer of the application, as I understand how policykit work, we would have to add that installer to the list of binarie who can run as root...
<slangasek> pkexec will let an admin user run any arbitrary command, it just prompts for a password in the default policy
<slangasek> ... which seems to be equivalent to what gksu gives you anyway
<GunnarHj> slangasek: How would you do "gksu gedit /usr/bin/skype"? (I usually use sudo instead, but I have been told I shouldn't.)
<slangasek> GunnarHj: 'pkexec gedit /usr/bin/skype'?
<jbicha> slangasek: WARNING **: Could not open X display
<Acibi> ;)
<slangasek> hmm, really?
<Acibi> gEdit must ben in the config file
<GunnarHj> $ pkexec gedit /usr/bin/skype
<GunnarHj> No protocol specified
<mbiebl> running X apps needs explicit configuration
<GunnarHj> ** (gedit:5937): WARNING **: Could not open X display
<GunnarHj> Cannot open display:
<jbicha> slangasek: yeah that's a security feature or something
<slangasek> ah
<GunnarHj> Run '/usr/bin/gedit --help' to see a full list of available command line options.
<mbiebl> see /usr/share/polkit-1/actions/org.debian.pkexec.gnome-system-log.policy as an example
<Acibi> So what? I should use pkexec to launch a non-X app who will add configuration??
<mbiebl> sorry, I don't understand your question
<Acibi> I currently have an installer, that client run to install the app. We currently launch the installer with gksu (and beesu on Fedora). What should I do now? Use pkexec to create the config file and then launch the installer with pkexec??
<jbicha> Acibi: the easiest way for now is just to make your package depend on gksu, see debian/control
<sarnold> Acibi: speaking as J Random User, _easiest_ would be for you guys to prepare a .deb package and provide an apt repository, so it could be installed via 'sudo apt-get install neat-acibi-thing' or the software center or whatever... :)
<jbicha> or you could have your installer package install the .policy file and then use pkexec like gnome-system-log does on Debian
<jbicha> or synaptic or gparted do on Ubuntu
<Acibi> jbicha : Not distributing the apps in the form of a package :P
<jbicha> uh, you should
<Acibi> I'll take a look! Thanks!
<Acibi> Yeah, I know... Not my decision.
<Acibi> Kind of a miracle that we have a linux version of the product :P
<jbicha> tell them that some guy on the Internet told them to make a .deb ;)
<Acibi> Ahahaha ;)
<Acibi> They don't really like big changes :P Make me scream in my head all the time :P
#ubuntu-devel 2013-04-13
<jbicha> LP doesn't install recommends when it installs build-depends?
<jbicha> oh I see https://lists.ubuntu.com/archives/ubuntu-devel/2010-August/031130.html
<smartboyhw> Any Python masters here?
<smartboyhw> We have a Bug 1167553
<ubottu> bug 1167553 in Ubuntu Studio raring-13.04 "Arandr won't start on Ubuntu Studio 13.04 Beta 2" [Undecided,New] https://launchpad.net/bugs/1167553
<smartboyhw> According to the traceback the problem exists in Python 2.7 with Ubuntu Studio 13.04 Beta 2.
<smartboyhw> Or actually, speaking about this: Images are NOT supposed to ship with old Python right!/
<smartboyhw> Hmm more weird: Arandr does only depend on python (2)
<smartboyhw> This is very weird
<Drakeson`> How can I turn a chroot (on a usb stick) to a bootable media?  The chroot is populated with debootstrap, also a kernel is installed there.
<gotwig> hello
<gotwig> I want to use GeoClue, GeoIP with the Ubuntu Provider in the vala programming language. How would I do that?
<gotwig> geoclue-test-gui doesnt show me any info about the user. I heard there is yahoo integration? How would I use that, to get the geoID for the user?
#ubuntu-devel 2013-04-14
<andrewsh> hello everyone
<andrewsh> what can be done so I could maintain some of my packages in Ubuntu directly
<andrewsh> without waiting for someone who re-uploads them from Debian?
<siretart> andrewsh: file bugs with patches, find someone to apply and upload them in the appropriate places
<siretart> which often is Debian
<Dark_light> I'm having issues with the installer of 13.04
<Dark_light> http://paste.ubuntu.com/5707491/ here's the debug file
<Dark_light> *log
<Dark_light> I'm using yesterday's build
<andrewsh> siretart: the question about doing things directly
<siretart> andrewsh: that comes with a lot of commitments, see https://nm.debian.org/public/newnm for pointers
<siretart> andrewsh: sorry, I meant to refer to http://www.debian.org/devel/join/newmaint
<andrewsh> siretart: I'm a DD
<siretart> andrewsh: oh, I'm sorry, I wasn't aware.
<siretart> andrewsh: in that case, have you seen https://wiki.ubuntu.com/Ubuntu/ForDebianDevelopers yet
<siretart> ?
<andrewsh> siretart: the problem is that the usual import process is too slow
<andrewsh> not yet
<andrewsh> I haven't
<siretart> that page contains a lot of pointers, espc. with links how the syncing process works. I suggest that you first try working with those processes
<siretart> if things are still too slow, then you should consider applying for MOTU and/or per-package-upload-rights (that works a bit similar to the debian maintainers ACLs in Debian)
<siretart> HTH
<andrewsh> well, let's try this requestsync thing
<andrewsh> thanks
<andrewsh> hmm
<andrewsh> strange
<andrewsh> probably it's not quite what I want
<andrewsh> well, I think I just keep the thing as it is now
<andrewsh> thanks anyway
<andrewsh> bye
<nigelb> lucas: Congrats!
#ubuntu-devel 2014-04-07
<jrwren> dist-upgrade?
<kirkland> doko_: probably;  I don't know of any particular interest in it anymore
<hyperair> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1293081 <-- is it just my machine, or is there really nobody else facing this issue in trusty?
<ubottu> Launchpad bug 1293081 in compiz (Ubuntu) "black screen or frozen screen after a change in multihead configuration" [Undecided,New]
 * hyperair finds it ridiculous that we're going to release with unity having issues switching between single-head and multihead on an IVB-equipped thinkpad
<RAOF> hyperair: Is there some reason you're overriding the i915's RC6 defaults? Deep RC6 states have been a fairly rich source of bugs.
<RAOF> hyperair: Likewise, semaphores, etc? Do you still get the same hang without all your i915 tweaks? (I ask this because *my* HSW machine is quite happy to enable or disable monitors)
<RAOF> That might also suggest an answer to âis it just my machineâ âº
<hyperair> RAOF: hmm, it's been like that since the previousd ubuntu release.
<hyperair> RAOF: as in i had no issues until upgrading to ubuntu 14.04
<hyperair> considering i use the same custom kernel that i used in 13.10, i'm more inclined to believe this is a unity issue.
<hyperair> but yeah i'll try disabling my tweaks and seeing if that helps
<RAOF> Mesa's also changed, which could be hitting new codepaths.
<hyperair> hmm
<hyperair> somehow rc6 doesn't sound like the kind of thing that would affect multihead transitions.
<hyperair> i mean rc6 is basically super deep sleep for the GPU isn't it?
<hyperair> i'm sure the transition stage is when it's not sleeping.
<hyperair> is there a way to disable rc6 temporarily without rebooting?
<RAOF> hyperair: You can *probably* tweak those things at runtime by writing things to /sys/module/i915/parameters/*
<hyperair> hmm
<hyperair> come to think of it, i'm not sure what the defaults for this gpu is
<hyperair> *are
<RAOF> hyperair: You can write -1 into most of them to get default behaviour; I don't know if that'll work post-startup, though.
<hyperair> don't think so
<hyperair> at least rc6 didn't work some time ago
<pitti> Good morning
<pitti> infinity: at least they seem happy for now (almost 2 days uptime)
<infinity> pitti: I'm not sure that "surviving for two days" is a good indication of stability, but it's better than nothing. :P
<dholbach> good morning
<RAOF> dholbach: Sorry about the delay; I've tested libxkbcommon 0.4.1, and everything seems hunky-dory. Go about your FFe-ing business!
<dholbach> tjaalton, mlankhorst: ^ does that look all right to you?
<dholbach> thanks RAOF
<tjaalton> dholbach: yep
<dholbach> fantastico!
<dholbach> pitti, jibel, didrocks: salut mes amis.... do you know who could reply to https://bugs.kde.org/show_bug.cgi?id=333041 ?  comment 1 in particular
<ubottu> KDE bug 333041 in Ubuntu "Tests fail in armhf build" [Normal,Unconfirmed]
<RAOF> Dear lord the Debian BTS is a fractal of annoyance.
<didrocks> dholbach: hey my friend! I'm not part at all of the QA team nor I'm particularly skilled in those tests. Not sure how I can help :)
<dholbach> didrocks, I just wasn't sure who might know the answer to these questions
<dholbach> didrocks, I thought you might have a pointer for me :)
<didrocks> dholbach: not really knowledgeable on that, sorry!
<RAOF> Oh, I don't think xvfb is going to do EGL.
<didrocks> RAOF: even with lvmpipe?
<didrocks> llvmpipe*
<RAOF> Even with llvmpipe; I'm not sure our EGL handles swrast at all.
<RAOF> Hm, no. That's not true; the dri2 provider should support swrast.
<pitti> mvo: nice changes in apt 1.0! (not a joke, I hope)
<pitti> mvo_: what's the difference between "apt upgrade" and "apt full-upgrade" now? Or is upgrade what it always used to be, and that's a typo in your blog?
<mvo_> pitti: apt upgrade will never remove a package, full-upgrade will also remove packages
<mvo_> pitti: 1.0 is for real :)
<pitti> aah
<pitti> mvo_: so it's more than upgrade (also installs new packages), but less than dist-upgrade
<mvo_> (it used to be that apt upgrade would not install/rmeove anything, but the restriction on install is bad for e.g. the kernel etc)
<mvo_> yeah
<pitti> mvo_: so this still would stop on package transitions, right?
<pitti> or does it take explicit conflicts:/replaces: into account?
<pitti> (but that would be the full dist-upgrade
<mvo_> pitti: if the transition implies removes it will stop there, but that is actually a good idea to make it smarter
<mlankhorst> dholbach: sounds about right
<dholbach> mlankhorst, cool
<pitti> mvo_: anyway, nice work! I like the easier CLI
<pitti> haha, 10000b years in the making :)
<seb128> what changed?
<mvo_> pitti: thanks :)
 * seb128 uses update-manager nowadays ;-)
<mvo_> seb128: a simpler CLI with the new "apt" command
<pitti> I use apt-cache all the time, and have aliases for that
<pitti> alias acs='apt-cache search'
<pitti> alias acsh='apt-cache show'
<pitti> alias asrc='apt-cache showsrc'
<pitti> I type these all the time, so I got lazy :)
<mvo_> hehe
<seb128> yeah, I used those often as well, just not upgrade/dist-upgrade
<dholbach> seb128, one day you'll use image-based updates ;-)
<seb128> dholbach, stop making mvo sad
<dholbach> seb128, I don't think he'll be sad :)
<seb128> hum, no "apt" here
<seb128> ignore that, wrong prompt :p
<mvo_> seb128: upgrade to trusty ;)
<seb128> mvo_, but, precise is the LTS!
<seb128> ;-)
<mvo_> seb128: ;) and window maker is the WM ;)
<seb128> indeed!
<mvo_> seb128: :-D
<seb128> glad you arrived to this conclusion as well ;-)
<dholbach> hippies!
<pitti> mvo: oh wow, I completely ignored the presence of "apt" in trusty; I thought it was new in 1.0
<mvo> pitti: the 1.0 has a slight improved text progress bar, but the functionality is all there
<pitti> now, how long will it take to adjust my finger muscle memory to that, after umpteen years of typing apt-get every morning..
<mvo> lol
<seb128> pitti, alias apt-get='apt' :p
<mvo> I know the feeling, I type apt-g^W^W
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<pitti> mvo: not much manpage yet, and apt remove --help doesn't really work: is there a couterpart for "clean up my system", i. e. apt-get --purge autoremove?
<seb128> Laney, happy piloting!
<pitti> Laney: don't get lost!
<mvo> pitti: yeah, the manpage is sadly not in ubuntu yet, the 1.0 one is better
<mvo> pitti: and no autoclean, I guess adding that is a really good idea, maybe combined with some way to make it easy to idenitfy "local" packages that are no longer downloadable
<pitti> and of course the most important command of all works! apt moo
 * pitti hugs mvo
<mvo> :P
 * mvo hugs pitti
<cking> cjwatson_, is xnox around this week?
<xnox> cking: yeap =)
<Laney> haha
<cking> ah, i didn't see you xnox doh
<cking> xnox, i still have some installer issues with my special SSD device
<xnox> cking: =( right.
<cking> sorry to make you life so bad :-/
<xnox> no worries. we need it working for 14.04....
<dholbach> pitti, hast Du 'ne Ahnung, wer mir Informationen fÃ¼r https://bugs.kde.org/show_bug.cgi?id=333041 geben kÃ¶nnte?
<ubottu> KDE bug 333041 in Ubuntu "Tests fail in armhf build" [Normal,Unconfirmed]
 * dholbach hugs Laney
 * Laney hugs dholbach 
<xnox> warum alles sprechen Deutsch? wir sind kein Suse =)))))
<mvo> lol
<xnox> mvo: Guten Morgen! =)
<mvo> guten morgen xnox!
<seb128> mvo, we need tab completion for apt commands ;-)
<seb128> mvo, like "sudo apt dis<tab>" ;-)
<infinity> seb128: Inclding rewriting dis to ful?
<mvo> seb128: oh, indeed
<StevenK> seb128: zsh can already do that
<StevenK> % sudo apt-get install
<StevenK> zsh: do you wish to see all 43092 possibilities (43092 lines)?
<seb128> StevenK, what, tab completion? apt-get as well
<infinity> StevenK: apt, not apt-get.
<seb128> just not the name "apt"
<seb128> new name*
<infinity> bash does apt-get fine.
<StevenK> steven@undermined:~% sudo apt-get install language-pack-e
<StevenK> language-pack-el       language-pack-eo       language-pack-et
<StevenK> Including stuff like that?
<seb128> right, sorry, I misread what StevenK wrote
<infinity> And with a less ugly interface. :P
<infinity> (base)adconrad@cthulhu:~$ apt-get install
<infinity> Display all 45235 possibilities? (y or n)
<seb128> StevenK, read :p
<StevenK> seb128: Pft, reading is totally overrated
<seb128> StevenK, that's "apt-get" you are using, not "apt"
<seb128> yeah, I see that
<seb128> infinity, since you are up, any chance you could review some of trusty queued items? ;-) some are waiting since thursday, would be nice to get things moving before the trusty freeze
<infinity> seb128: I'm not actually here.  Just a bit of insomnia and then back to bed to try harder.
<seb128> k
<seb128> infinity, I guess you people are going to be angry if I just accept stuff, right? ;-)
<infinity> possibly.
<infinity> I'll poke mozjs quickly.
<infinity> Under the assumption that that sync better be a no-change upload.
<StevenK> No compdef for apt :-(
<StevenK> Guess I'll have to write one when I'm bored
<juliank> mvo: I had the same idea for bug 1302736 tonight, but I had versioned the breaks using (>> 0). This should take care of detecting custom-build packages as well (IIRC, people continued maintaining the official packaging scripts for some time on github, and build personal packages).
<ubottu> bug 1302736 in apt (Ubuntu) "apt 0.9.15.4ubuntu4 uninstalls ppa:webupd8team/java oracle-java[78]-installer" [Undecided,Invalid] https://launchpad.net/bugs/1302736
<juliank> It's a bit uncommon to have >> Breaks and Provides, but hey, it works with stuff like https://github.com/rraptorr/sun-java6 as well
<mvo> juliank: aha, nice idea. I was wondering about what to do with all the custom builds and that looks like a neat hack to get rid of them as well. but the downside would be that we would also include "sun-java6-jdk" from precise which is free of the apt binary. or am I missing something in your idea?
<juliank> mvo: Was there a version of sun-java6-jdk that had no apt binary? I think only openjdk-6-jdk was changed, but sun-java6-jdk always shipped apt.
<mvo> juliank: oh, indeed, I mixed them up - you are right
<mvo> juliank: so +1 for your idea, if you haven't commited it to git already I can do that now and cherry pick for ubuntu
<juliank> It would still break things if someone created an oracle-java6-jdk package that provides sun-java6-jdk; but I don't think anyone did.
<juliank> Let me do a test build, I'm sure lintian complains about it.
<infinity> mvo: What is the "apt" binary in the sun jdk, and has anyone whined to them about the namespace collision, so we can have a proper versioned breaks/replaces?
<mvo> infinity: its deprecated since java5(? or 6?) (or even before)
<mvo> infinity: so its not a issue with all recent jdks
<mvo> juliank: ok
<infinity> mvo: Ahh, kay.
<mvo> infinity: its mostly for correctness, we had no report in trusty and its enabled (the apt binary) since ~jan
<trijntje_>    ping pitti: i'm using ubuntu-defaults-builder to create localised Iso images for trusty but they can't boot in UEFI mode. Is this a known limitation or did I do something wrong?
<xnox> is Kylin also built with ubuntu-defaults-builder? cause we'd need UEFI for those images...
<infinity> mvo: Oh, and on the point of "apt" and "autoremove", since apt is a new binary with a new interface, there shouldn't currently be any behavioural assumptions.  If it's meant to be more user-friendly with fewer commands, could "full-upgrade" just offer to autoremove at the end of the run?
<infinity> mvo: Bonus points if --purge is also made the default for remove/autoremove (haven't played with it yet to see if that's the case anyway).
<infinity> xnox: Sort of.
<mvo> infinity: auto-remove on full upgrade sounds useful, --purge by default is a bit dangerous as it may blow away carefully crafted configs
<infinity> xnox: The livefs is, but then it's still jammed through the cdimage machinery for the ISO, so it depends on where your fix needs to be.
<xnox> infinity: i see, let me sync a kylin and check if it has uefi or not.
<infinity> mvo: I've often thought that the "non-technical end user's" expecation of "remove" is that it should --purge too.  This would obviously be a bad change for 'dpkg -r' or 'apt-get remove' where established behaviour is not to purge, but for new friendly tools, it feels like the right thing to do.
<infinity> mvo: Opinions on that may vary, but for non-technical users, I don't think the concept of "removed but conffiles remaining" is useful, just confusing.
<infinity> mvo: I guess that also depends on the target audience of 'apt', but given the tiny --help output, I'm guessing it's meant to be simplified and friendly, not to completely replace apt-*?
<juliank> infinity: Many users accidentally remove packages because they do not listen to APT. I'm sure they do not want to lose their configuration.
<infinity> juliank: I'd argue that people who don't read apt's output and accidentally remove packages probably don't have a lot of venn overlap with people who heavily customize conffiles.
<infinity> juliank: And people who heavily customize conffiles will probably also continue using apt-get, with its known behaviour.
<infinity> Unless the intent is to completely phase out apt-* in favour of the simpler-looking tool, which might annoy me. :P
<mvo> infinity: apt-get is there forever, I don't want to even think how many scripts are using it
<trijntje_> xnox: I don't know about that. I know that a Chinese version of ubuntu was in the original scope of ubuntu-defaults, but I don't think it's used now since the tool hasn't been updated a couple of releases AFAIK
<infinity> mvo: Seven.  Seven scripts.
<infinity> (give or take a few thousand)
<mvo> infinity: I see your point, however removing configuration sounds dangerous given the small amount of diskspace etc. maybe the answer is to make it super easy to see/get rid of those packages
<infinity> mvo: Well, if full-upgrade also offers an autoremove, it could follow up with a list of packages in ^rc state and ask what to do about them?  But that might be getting a bit verbose.
<juliank> mvo: I pushed the change to git.
<mvo> juliank: ta
<infinity> mvo: So maybe a "clean" action that does what apt-get clean does (clear the ephemeral data), but also offers to autoremove and purge ^rc stuff?
<mvo> infinity: I think that sounds very reasonable
 * mvo wonder if it should be called "apt computer-janitor"
 * infinity laughs.
<infinity> mvo: To properly emulate past computer-janitor behaviour, it would also have to offer to rm ~
<mvo> lol
<darkxst> hey, pilot Laney! Bug 1294891
<ubottu> bug 1294891 in Ubuntu "Ubuntu GNOME community wallpapers" [High,Confirmed] https://launchpad.net/bugs/1294891
<Laney> darkxst: f5
<darkxst> Laney, sorry, its still queue though
<darkxst> I suppose that takes some time to update?
 * juliank will have breakfast now
<darkxst> anyway, thanks!
<Laney> darkxst: yeah, needs archive admin
<infinity> mvo: While I'm filing wishlist bugs via IRC that you'll forget about, can we have an "apt-get autopurge" that's shorthand for "apt-get --purge autoremove" the same as "purge" == "--purge remove"?
<xnox> trijntje_: infinity: kylin looks all good - has efi partition and all that.
<infinity> xnox: Kay, the partition layout was expected, since that's done by debian-cd.
<infinity> xnox: So, the bug for people using pure defaults-builder is that livecd-rootfs's ISO creation probably doesn't DTRT.
<infinity> Err, live-build, I mean.
<infinity> Some day, we need some round tuits to make live-build spit out nearly byte-identical ISOs to what debian-cd does.
<mvo> infinity: that is a nice idea
<pitti> trijntje_: not known, but u-d-b's live-image config hasn't been updated for quite a long time; I guess it needs some updates for UEFI
<pitti> trijntje_: I don't think you did something wrong
<trijntje_> xnox: that's good to know, I'll check out kylin to see if anything is applicable to udb
<pitti> dholbach: the qemu armhf emulation isn't very reliable I'm afraid; I wouldn't blame it on upstream gcc or the KDE project unless it's been verified that it also segfaults (!) and fails the test on real hw
<pitti> dholbach: quite a lot of syscalls aren't implemented in the user qemu emulation, like posix timers
<pitti> dholbach: so as a first step I'd suggest to try and build it on real hw?
<trijntje_> pitti: I've tried to take a look at the code myself but I'm completely out of my depth. Should I file a bug for the uefi problem?
<pitti> trijntje_: sure
<pitti> tseliot: happy birthday!
<tseliot> pitti: thanks :)
<dholbach> pitti, thanks
<morphis> pitti: ping
<pitti> morphis: hello
<trijntje_> pitti: I'll file a bug against dub, thanks for your time
<morphis> pitti: hey!
<morphis> pitti: regarding https://bugs.launchpad.net/python-dbusmock/+bug/1225151
<ubottu> Launchpad bug 1225151 in python-dbusmock "Allow packages to include templates themselves" [Medium,Triaged]
<tjaalton> dholbach: there's no ffe bug for libxkbcommon?
<morphis> do you have plans to implement that soon?
<pitti> morphis: I can put it on my TODO list; so far, no plans (but should be fairly easy to do, so patches accepted, too)
<morphis> pitti: ok, I can have a look myself
<morphis> just didn't wanted to do double work :)
<pitti> morphis: I guess the actual implementation is just a two-liner, most work is a new test case for that
<dholbach> tjaalton, ah yes, that might be - it was just something that was reported to me and I wanted to bring everyone in touch about it
<caribou> Laney: just saw your message regardin the sosreport SRU
<dholbach> brb
<caribou> Laney: I found out this morning that arges has been working on another SRU on the same package
<morphis> pitti: yeah, that is what I guess too
<Laney> caribou: yeah?
<caribou> Laney: so I need to synchronize with him later today on how we go about this one
<Laney> ok, please update the bug then and I'll leave it
<Laney> same comments about backports apply of course
<caribou> Laney: sure, I'll do that.
<tjaalton> dholbach: ok, filed bug 1303706
<ubottu> bug 1303706 in libxkbcommon (Ubuntu) "FFe: new upstream version 0.4.1" [Undecided,New] https://launchpad.net/bugs/1303706
 * dholbach hugs tjaalton
<jamespage> xnox, re bug 1297012 - not so close to release right? I'll comment
<ubottu> bug 1297012 in partman-auto (Ubuntu) "hyper-v: Manual partitioning formats /boot with ext2 file-system" [High,Won't fix] https://launchpad.net/bugs/1297012
<xnox> jamespage: we could try =)))) but it is dead close to release. I'd be happy with: mke2fs -t ext4 -O ^has_journal ^extent ^huge_file, which is pretty much what ext2 is yet called "ext4" not sure if freeze-api/ext4 kernel driver will like that or not.
<xnox> jamespage: also i'd want to bump the default size of /boot, since current one is very small (also given that we do not autoremove kernels, only mark them for autoremoval)
<jamespage> xnox, I'd prefer to push back on this so close to the release
<xnox> jamespage: indeed.
<jamespage> xnox, this might be a small change but I feel the potential impact could be big
<jamespage> xnox, OK with you if I raised a task for U series and mark won't fix for trusty
<jamespage> ?
<xnox> jamespage: already did that + commenting.
<jamespage> xnox, lol
<didrocks> chrisccoulson: yeah, so your oxide-qt upload is fixing bug #1301341, right?
<ubottu> bug 1301341 in webbrowser-app "grooveshark playback has stopped functioning" [Undecided,Confirmed] https://launchpad.net/bugs/1301341
<didrocks> chrisccoulson: I heard there is a need for a webbrowser-app change as well, are you driving that?
<mwhudson> is do-release-upgrade -d the recommended way to get to trusty?
<mwhudson> because it seems a bit flaky...
<chrisccoulson> didrocks, oSoMoN is doing that change (for webbrowser-app)
<chrisccoulson> and the upload doesn't fix that grooveshark bug. that requires a bit more work
<didrocks> chrisccoulson: it will only be webbrowser-app change as well?
<didrocks> s/as well/then/ ?
<oSoMoN> chrisccoulson, no it will be only an oxide change :)
<didrocks> hum, seems you guys are deadlocking on the other?
<chrisccoulson> yeah, it requires a build system change in oxide and then a packaging change to build oxide twice, and split libffmpegsumo in to 2 conflicting packages (one with proprietary codecs and one without)
<chrisccoulson> basically
<juliank> Someone should move all webapps from universe to multiverse.
<oSoMoN> didrocks, thereâs no deadlock, only a build change in oxide needed
<juliank> They all contain non-free images
<didrocks> oSoMoN: seems that you are doing that change (what chris was telling)
 * didrocks is puzzled now
<oSoMoN> chrisccoulson, am I doing bug #1301341 ?
<ubottu> bug 1301341 in webbrowser-app "grooveshark playback has stopped functioning" [Undecided,Confirmed] https://launchpad.net/bugs/1301341
<chrisccoulson> oSoMoN, it's ok, i can look at this one today
<chrisccoulson> are you still looking at the geolocation bits?
<oSoMoN> chrisccoulson, yes
<chrisccoulson> oSoMoN, cool, thanks. i'll let you carry on with that :)
<jamespage> xnox, ta
<xnox> pitti: fixed ubiquity adt test, whilst not building ubuntuone plugin it was still installing it from the archive (listed as depends in debian/tests/control) despite it being well NBS. And hence the tests were failing.
<xnox> pitti: it does indicate that possibly we are not quite running everything as installed - since installed != src-dir and we were failing on not finding u1 plugin in the src-dir.
<pitti> xnox: I saw the success mail, thanks!
<pitti> cyphermox: since today's update I often get DHCP reconnects, and dmesg says http://paste.ubuntu.com/7216850/ (apparmor violations)
<pitti> cyphermox: are you aware of any recent changes in the network/dhcp stack?
<dawnk_> When I change my scaling in Settings > Display from 1 to anything less than that, some parts of unity gets messed up.
<dawnk_> For instance, when I right click on any application on the dash, the options I get are not aligned.
<dawnk_> Can anyone check if it is replicable?
<dawnk_> I'm using Ubuntu 14.04
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<xnox> dawnk_: yeah reproducible. file a bug against "unity" package in ubuntu with: $ ubuntu-bug unity
<xnox> dawnk_: and attach photographs if possible, or just verbally describe
<dawnk_> well, if I set my scale to any value less than 1, when I try to right click any programs in the unity-dash, the options do not look aligned properly
<dawnk_> For instance, when I right click firefox, instead of "Open a New Window", it shows "Open a New Window     Open"
<dawnk_> xnox: unfortunately, I won't be able to post a pic. My uni blocks most file sharing sites.
<dawnk_> xnox: I'll try my best to describe it if you do not understand.
<Laney> You can attach pictures to launchpad bugs
<dawnk_> Laney: alright, I'll do that.
<cjwatson> mdeslaur: Hi.  Do you folks need me to prepare updates for CVE-2014-2653, or is it already in progress?  I did the backports for squeeze and wheezy.
<ubottu> The verify_host_key function in sshconnect.c in the client in OpenSSH 6.6 and earlier allows remote servers to trigger the skipping of SSHFP DNS RR checking by presenting an unacceptable HostCertificate. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2653)
<mdeslaur> cjwatson: no, that's fine, I was about to start doing it
<cjwatson> OK, cool
<mdeslaur> cjwatson: I'll take care of it
<cjwatson> Thanks!
<mdeslaur> thanks!
<jtaylor> bug 970260 does not seem fixed or has reappeared in trusty :(
<ubottu> bug 970260 in os-prober (Ubuntu Precise) "Setting up memtest86+ hangs because of "grub-probe: error: unknown filesystem"" [Undecided,Confirmed] https://launchpad.net/bugs/970260
<jtaylor> someone want to help me figuring gathering the required logs?
<arges> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges
<jdstrand> pitti: that would be us
<jdstrand> pitti: let me prepare and upload
<jdstrand> weird that we didn't see it in testing
<pitti> jdstrand: oh, thanks!
<jdstrand> pitti: well, before I do the upload...
<jdstrand> pitti: can you add this to /usr/lib/NetworkManager/nm-dhcp-client.action {} in /etc/apparmor.d/sbin.dhclient?
<jdstrand> /var/lib/NetworkManager/*lease r,
<pitti> jdstrand: done, and AA restarted
<cyphermox> jdstrand: that was removed by mistake?
 * pitti flushes dmesg -c, and will report back to jdstrand if it still happens
<jdstrand> no, it is due to the new kernel
<pitti> but this addition looks straightforward, thanks
<dawnk_> xnox, https://launchpadlibrarian.net/172063791/Screenshot%20from%202014-04-07%2019%3A04%3A35.png
<arges> dholbach: hi. doing some patch piloting and noticed that I can't unsubscribe sponsors... what permissions do I need to set up for that? Thanks
<dholbach> arges, being part of the team should be it - let me check if you are
<dholbach> fixed :)
<arges> dholbach: thanks
<xnox> dawnk_: what's the bug number?
<xnox> dawnk_: i can't get to the bug from the attachment URL.
<dawnk_> xnox: https://bugs.launchpad.net/unity/+bug/1303812
<ubottu> Launchpad bug 1303812 in Unity "Options in sidebar not aligned properly with reduced display scaling" [Undecided,New]
<xnox> dawnk_: thanks!
<dawnk_> xnox: Thanks for confirming.
<jtaylor> cjwatson: grub-probe in trusty fails on lvm snapshots
<jtaylor> I notice there was once a patch to handle that
<jtaylor> which disappeared
<cjwatson> Yeah, lamont asked me about that, that patch disappeared because it was supposed to have been fixed upstream
<jtaylor> in some upstream commit with an unrelated commit message
<cjwatson> I haven't had a chance to set up a reproduction environment yet
<jtaylor> I wonder if it was a mistake
<cjwatson> I'll see if I can set it up in Xen later today
<jtaylor> the patch was upstream for a while
<xnox> mvo: apt 1.0 is probably the best trusty feature!
<xnox> and loving the new progress bar
<jtaylor> it was removed in fc18f6
<cjwatson> There may have been a mistake, but I remember dropping the patch intentionally
<jtaylor> the issue just bit me when upgrading from saucy :/
<cjwatson> I'll have a look, going into town now though
<jtaylor> no usb disk available only broken usb stciks = much timewaste :/
<jtaylor> I'll do some debugging to see if the patch still fixes it
<xnox> jibel: $ ubiquity --greeter should start the page you want.
<cjwatson> I'll want to set up that Xen guest regardless, if nothing else so that I have an easier way to test this kind of thing in future
<xnox> jibel: apart from weird sizing issues, it should be ok. So far i can't manager to crash it.
<xnox> jibel: which language did you pick?
<xnox> bah wrong chan!
 * ogra_ bets it was french though 
<arges> dholbach: hey if something has already been sponsored should I unsubscribe sponsors, or just leave it?
<Laney> arges: Set "Fix Committed" or something maybe
<dholbach> arges, can the bug be closed maybe?
<arges> Laney: hey! looking at bug 1298220. Just trying to go through the sponsoring queue
<ubottu> bug 1298220 in bash-completion (Ubuntu) "Sync bash-completion 1:2.1-4 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1298220
<Laney> arges: Oh yeah, I was keeping sponsor-patch open "Wait for the bug to be closedâ¦" for that one
<Laney> but I lost that when I restarted my session :P
<Laney> so I guess Fix Released and if it gets rejected reopen it
<arges> Laney: ok will do thanks
 * Laney did it
<Laney> thanks for pointing it out
<arges> : ) beat me to it
<arges> np
<Laney> Oh look, someone accepted it
<ochosi> hey arges
<arges> ochosi: hi
<jdstrand> pitti: uploaded isc-dhcp for your fix
<ochosi> Laney mentioned i could talk to you in case there is something urgent we'd need upload wise
<ochosi> and indeed there are two items in the sponsors queue
<pitti> jdstrand: cheers!
<arges> ochosi: yes, i'm patch piloting today. What do you need reviewed?
<ochosi> arges: to be exact, it's the light-locker-settings 1.2.1 update and the related sync_lock_xfpm_session
<ochosi> arges: without those patches, the settings for lock-on-suspend aren't kept in sync, so that might cause a security problem because users currently have to check 3 dialogs individually to be sure
<arges> ok so i see https://launchpad.net/bugs/1302484
<ubottu> Launchpad bug 1302484 in light-locker-settings (Ubuntu) "[needs-packaging] Please upload light-locker-settings 1.2.1" [Undecided,Confirmed]
<ochosi> yup
<ochosi> the other one is:
<ochosi> https://code.launchpad.net/~smd-seandavis/ubuntu/trusty/xfce4-power-manager/sync_lock_xfpm_session/+merge/214392
<smoser> pitti, you're back up on wolfe-0X, right?
<smoser> they went down on friday as the host fell
<arges> ochosi: why is bug 1302484 marked [needs-packaging] ?
<ubottu> bug 1302484 in light-locker-settings (Ubuntu) "[needs-packaging] Please upload light-locker-settings 1.2.1" [Undecided,Confirmed] https://launchpad.net/bugs/1302484
<infinity> smoser: Fell?  Was intentionally rebooted, you mean.
<pitti> smoser: yes, so far they are holding up fine
<pitti> last week they became unbearably segfaulty
<infinity> smoser: I restarted all the VMs after the host.
<ochosi> arges: i think that was a mistake, bluesabre meant "needs uploading"
<arges> ochosi: is this update a bugfix only release?
<ochosi> arges: yes, there are no new features apart from keeping the settings of those three dialogs in sync: xfce4-session-settings, xfce4-power-manager-settings, light-locker-settings
<smoser> infinity, right.
<smoser> "intentionally" deserves some quotes there.
<smoser> it wasn't really planned downtime.
<infinity> smoser: I planned it several minutes in advance. ;)
<smoser> touche
<arges> Laney: i'm looking at bug 1302484. I believe this is an FFe and it looks like the update is bugfix only. Do I need a release-team member to verify? Thanks
<ubottu> bug 1302484 in light-locker-settings (Ubuntu) "[FFe] Please upload light-locker-settings 1.2.1" [Undecided,Confirmed] https://launchpad.net/bugs/1302484
<Laney> arges: Nah, not if it's bug fix only
<arges> Laney: cool thanks
<Laney> It'll go to the queue anyway so you can be spanked if that turns out to be false. :P
<arges>  : )
<Laney> Sweetshark: "we dont care for stderr in the autopkgtest configure" in libreoffice-l10n, yet there's no autopkgtest there
<Laney> copy-paste error?
<seb128> Laney, same packaging for libreoffice and l10n
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges, mterry
<seb128> Laney, so they share changelog entries
<Laney> same packaging?
<seb128> Laney, there is 1 packaging tree, the source has just been split to reduce build time
<seb128> Laney, but you can consider libreoffice and -l10n as one package if you prefer
<Laney> I don't prefer that
<Twooey> Is there any good documentation on how to start contributing to ubuntu as a new programmer?
<seb128> Laney, ok, I'm going to let Sweetshark answer then
<Laney> I understand what you're saying, but ...
<arges> Twooey: hey depends on how you want to contribute. There is lots of documentation at https://wiki.ubuntu.com/
<Laney> Think about if you did that for an upstream project, it'd be weird
<Laney> Same here
<seb128> right, the other solution is to fork/double the packaging
<seb128> with having the changelog different between the 2 trees
<Laney> It manages to have a separate control file
<seb128> and having to maintain them in sync
<seb128> I guess they could have 2 changelogs and pick the one corresponding to the source built
<Twooey> arges: I'm hoping to find some simple bugs and such I can work use to improve my programming, and help benefit the project. I could have sword I saw something a while ago, but I can't find it.
<seb128> anyway, I'm not defending the solution
<Laney> ok, thanks for explaining
<seb128> just saying why you have changelog content non match l10n
<seb128> yw!
<arges> Twooey: I would find a bug that personally affects you that may seem simple, file an ubuntu bug (or find an existing one). Then look through this wiki a bit http://community.ubuntu.com/contribute/developers/package-maintenance/
<Twooey> thanks!
<Twooey> I had just found my way there.
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges
<seb128> does anyone know what's the right component for bug #1302192?
<ubottu> bug 1302192 in iputils (Ubuntu Trusty) "ping is not setuid root" [Undecided,Confirmed] https://launchpad.net/bugs/1302192
<seb128> it works for me but that received a duplicate and some users confirming, so it's likely an issue
<mvo> jibel: is it easy for you to do a upgade test with this PPA: https://launchpad.net/~mvo/+archive/eglibc-trusty ? (once eglic is build)? should fix #1298281
<Elv1313> Hello, I am one of sflphone developper, we need to patch this bug ASAP https://bugs.launchpad.net/ubuntu/+source/sflphone/+bug/1299967 , there is two one liner patches to fix these issues. How can we get them in? (the packages come from Universe)
<ubottu> Launchpad bug 1299967 in sflphone (Ubuntu) "sflphone do not start" [High,Confirmed]
<slangasek> xnox: please have a look at the latest comments on bug #893021
<ubottu> bug 893021 in upstart "ability to specify signal for reload command" [Undecided,Fix released] https://launchpad.net/bugs/893021
<xnox> slangasek: right, indeed i just ripped out the previous way. I'll look into patching in the fallback path.
<slangasek> xnox: thanks
<Elv1313> I need to get this https://projects.kde.org/projects/playground/network/sflphone-kde/repository/revisions/937fc35baea892dcb4cc19334cab9dba98eaff8f/diff/src/lib/phonenumber.cpp and this https://projects.savoirfairelinux.com/projects/sflphone/repository/revisions/390d5826f2f0db8bf7634f773ca36fb622009a06/diff/gnome/src/sflphone_client.c into 14.04 or the app wont start for most users
<xnox> Elv1313: file a bug on launchpad against ubuntu distribution and package in question + attach the required patches. For extra points, check that they apply cleanly, build and result in working packages, and prepare a full debdiff
<xnox> Elv1313: on the bug report, steps to reproduce the issue would be useful (written for people who are unfamiliar with that package)
<Elv1313> there already is a bug report and the patch is already linked (it also apply clean) https://bugs.launchpad.net/ubuntu/+source/sflphone/+bug/1299967
<ubottu> Launchpad bug 1299967 in sflphone (Ubuntu) "sflphone do not start" [High,Confirmed]
<Elv1313> it doesn't open at all due to a glib change
<xnox> dholbach: stokachu joined core-dev so he is now available to do patch piloting duties to review and sponsor packages =))))) he is well versed in SRU process, so should be easy for him to review those ;-)
<dholbach> awesome, thanks xnox
<dholbach> stokachu, congratulations!
<tarpman> fresh blood!
<Elv1313> xnox: Ok, I attached a patch to both bugs (with the "patch" checkbox), what's next?
<xnox> Elv1313: what's the bug numbers?
<Elv1313> xnox: #1299967 #1303897
<xnox> Elv1313: look easy enough fixes. Bumped priority and targeted for trusty. Any developer now needs to apply those two simple fixes to the package and upload.
<xnox> Elv1313: i might do it, unless somebody will beat me to it.
<Elv1313> xnox: thanks! Is it possible to move the bugs to "sflphone-gnome" and "sflphone-kde" respectively instead of "sflphone"?
<cjwatson> Elv1313: no, they're in the same source package and Ubuntu bugs are categorised only up to the granularity of source packages
<Elv1313> ok, thanks. If you need any more info, just ping me, I will be AFK for lunch for the next half hour.
<Sweetshark> Laney: libreoffice-l10n is autogenerated
<Laney> Sweetshark: Yeah, I see; the results are a bit confusing IMO
<stokachu> ScottK: sorry had ameeting, but yes the asking questions part :D
<stokachu> Laney: i have that site bookmarked and will contribute
<Laney> great
<arges> @pilot out
<trijntje> ping ypwong: can I ask you some questions about generating iso's for ubuntu kylin? I'm trying to do something similar for dutch using ubuntu-defaults-image, but the resulting image cant boot on UEFI hardware.
<xnox> trijntje: ubuntu kylin do not just use ubuntu-defaults, there are assembled into final iso on the official cdimage builders and thus are capable of uefi just like normal ubuntu image.
<xnox> trijntje: i'm don't know which changes/where are needed to enable ubuntu-defaults builder to also produce uefi capable images.
<trijntje> xnox: I've been looking at their code on launchpad and it looks like they do use ubuntu-defaults as part of the build process, but I don't know the details
<trijntje> thats why I figured I would ping someone of the kylin team to ask them, but it would probably have been more polite to use mailingist first :(
<xnox> trijntje: sure, though that's only to build the livecd. (see scrollback between myself and infinity earlier today0
<xnox> trijntje: ubuntu installer team / release team is producing the isos, not kylin team. Kylin team does development of the localised packages, and uploads those into the archive mostly.
<xnox> trijntje: cdimage.ubuntu.com produces the iso's.
<xnox> trijntje: see http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntukylin/trusty/ and http://people.canonical.com/~ubuntu-archive/livefs-build-logs/trusty/ubuntukylin/
<xnox> for build logs.
<trijntje> xnox: I see. So I should try to get the release team to produce the iso's for me ;)
<xnox> trijntje: it's automated canonical servers, and they produce for official flavours only.
<xnox> trijntje: =) but indeed we need to sort out defaults-builder / uefi story as it's very useful tool to remaster isos
<trijntje> the problem is that I've only ever used the defaults-builder scripts to create iso's, so I cant really read the build logs you linked
<ScottK> doko: The ruby packages you pointed us to are fixed/removed.  Because we're still using ruby1.9 as default and Debian is using ruby2.0, it was a little more complicated than just using what Debian had.  I'd suggest we switch default Ruby to 2.0 as part of the initial toolchain updates for "U", so it's default when the release opens.
<trijntje> I'm guessing it wouldn't work to just copy the EFI folder from an official image to mine and rebuild the iso? I only have to create a single iso so I could do that manually
<doko> ScottK, make this 2.1
<ScottK> doko: OK.  Something > 2 and I'm happy.
<doko> ScottK, can you prepare this? I'm travelling
<ScottK> Maybe.
<ScottK> doko: Would it make sense to sync 2.1 into Universe for Trusty so it's at least present in the previous release?
<trijntje> xnox: is there any chance that would work or does UEFI boot require some sort of signature that only canonical can put on an image?
<[reed]> anybody know the LP bug tracking the fix for CVE-2014-0160 (http://heartbleed.com)?
<ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160)
<mdeslaur> [reed]: we don't track security updates in LP. It's compiling now, will be out tomorrow morning after QA.
<[reed]> mdeslaur: did you all not have heads-up on this? :/
<mdeslaur> nope
<[reed]> that's ridiculous
 * mdeslaur shrugs
<[reed]> mdeslaur: it's a super bad bug... seems like somebody should have better coordinated so distros could have had patches ready :/
<doko> zul, jamespage: python-taskflow is blocked by failing autopkg tests
<zul> doko:  ill have a look tonight
<hallyn_> mdeslaur: hey, looking at bug 1304008.
<ubottu> bug 1304008 in libvirt (Ubuntu) "user not added to libvirtd group with iso trusty 'virtual machine host' installation method" [Undecided,New] https://launchpad.net/bugs/1304008
<hallyn_> mdeslaur: (and zul) would it make sense to have libvirt-bin Pre-Depends on sudo?
<hallyn_> i.e. would that ensure that group sudo would container the created user at libvirt setup time when using tasksel at machine install to setup libvirt-bin?
<hallyn_> cjwatson: can you confirm how/when group sudo is populated when installing from iso?
<hallyn_> does the initial user jsut get added?  does every 'group adm' user get added?
<RAOF> jcastro: Hey, is the juju local provider expected to work in 14.04?
<jcastro> yep
<jcastro> ensure juju-local is installed
<RAOF> jcastro: OOooh!
<RAOF> jcastro: https://juju.ubuntu.com/docs/config-LXC.html should probably not say âyou need to run âsudo juju bootstrapââ, given that doing so will cause juju to say âERROR bootstrapping a local environment must not be done as rootâ
<RAOF> Which I misread, missing the ânotâ.
<RAOF> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: RAOF, arges
#ubuntu-devel 2014-04-08
<xnox> trijntje: no.  and signed binaries are uploaded and available from the archive. see *-signed packages.
<xnox> trijntje: so anyone can use them, furthermore they need to be distributed on the cd and to the users machines.
<Netsnipe> utlemming: hey Ben
<Netsnipe> are you in?
<Netsnipe> is there anybody else in who's responsible for the EC2 AMI images for Ubuntu?
<Netsnipe> I'm looking for an ETA as to when the OpenSSL patched AMIs are going to be built.
<sarnold> Netsnipe: what's up?
<sarnold> ah, drat, no idea there. sorry. :)
<Netsnipe> sarnold: any idea on who else I can speak to?
<sarnold> zul, roaksoax_, rbasak_ ^^ are you guys the one to ask about ec2 ami images?
<Netsnipe> is there anybody awake in here who's responsible for the EC2 AMI images for Ubuntu?
<infinity> utlemming: ^
<Netsnipe> infinity: I already pinged him.
 * hyperair wonders if the unity webapps extension has died again in chrome. =\
<RAOF> cyphermox: Have you seen https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1296226 ? I've folded that into the network-manager branch as a part of piloting; it looks like that should get uploaded pre-Trusty, right?
<ubottu> Launchpad bug 1296226 in network-manager (Ubuntu) "Patches rely on TARGET_DEBIAN to be defined" [Undecided,New]
<RAOF> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges
<FourDollars> arges: Hi, could you help me to review the patch of https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1303819 ?
<ubottu> Launchpad bug 1303819 in bluez (Ubuntu) "Bluetooth menu's content disappeared after resume." [Undecided,New]
<cyphermox> RAOF: yes, thanks. I'll take care of it in the morning (or if you want, feel free to upload)
<FourDollars> cyphermox: Hi, could you help me to review the patch of https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1303819 ?
<ubottu> Launchpad bug 1303819 in bluez (Ubuntu) "Bluetooth menu's content disappeared after resume." [Undecided,New]
<cyphermox> FourDollars: I'll be happy to, but in my morning
<FourDollars> cyphermox: OK. Thanks a lot.
<cyphermox> I'm just accidentally on; trying to follow the elections here and get some small tasks done unrelated to work :)
<FourDollars> haha
<cyphermox> FourDollars: ok, looked quickly
<FourDollars> IRC should prompt some information about timezone. XD
<cyphermox> seems to make sense if that -1 is a valid adapter ID to say that the adapter is not there :)
<cyphermox> FourDollars: I'm in east coast north america
<FourDollars> cyphermox: Take your time.
<cyphermox> FourDollars: like I said, I'll check to upload only tomorrow; but it looks fine with a quick glance
<cyphermox> thanks for looking into this
<FourDollars> cyphermox: -1 is the initial value of this global variable.
<cyphermox> awesome
<FourDollars> cyphermox: So it is reasonable to set it back to -1 when there is no adapter available. (That is what I think.)
<cyphermox> yes
<FourDollars> And it does fix the problem. :)
<FourDollars> cyphermox: Thanks again for your help. :)
<RAOF> cyphermox: I've already got the stuff ready, so I'll upload. Thanks!
<cyphermox> RAOF: hold on if it's not too late
<cyphermox> there was a fix in the packaging branch, from pitti re: autopilot tests
<RAOF> Yup; I folded that in.
<RAOF> (Or, rather, I started with the packaging branch)
<cyphermox> https://code.launchpad.net/~network-manager/network-manager/ubuntu
<cyphermox> oh, cool
<Mirv> I wonder if any core-dev would be available to call 'requestsync -d unstable pitivi' to sync pitivi for bug #1253009 ? the only thing I'm pondering about is whether it matters if the demoting to universe happens before or after the sync
<ubottu> bug 1253009 in pitivi (Baltix) "[FFe] Please sync latest upstream release (0.9x) from Debian unstable - Pitivi developers recommends to use 0.92 or later" [Medium,Triaged] https://launchpad.net/bugs/1253009
<Mirv> there's a branch too but intltool-update -p wouldn't be needed after pitivis is universe, so there are no changes left to keep in ubuntu
<RAOF> Mirv: I don't _think_ it would be a problem if it were syncd before demotion; it'll just FTBFS until it is. That said, I'd prefer to be sure :)
<infinity> RAOF: No, it should be demoted before it's attempted.
<infinity> I'll sort this out.
<infinity> (It'll only FTBFS if it's missing a build-dep, which the bug log doesn't make clear... And if it's built successfully and then demoted, it will have all the translations stripped)
<infinity> So, first, we need to see why it's in main.
<infinity> ubuntu.trusty/usb: * pitivi
<infinity> I assume that.
<infinity> It's been in main since lucid, I'm not sure just suddenly dropping support is the kindest thing to do.
<RAOF> Huh. mterry found it only on the ubuntustudio dvd.
<Mirv> thanks infinity for looking. mterry indeed also replied via e-mail that it should be safe to demote.
<Mirv> I think the history was that it was either included or considered to be included by default at some point, but then dropped later.
<infinity> Safe isn't the same as right.
<infinity> Like I said, it's been in main since (at least) lucid.  If we wanted to be supporting it, we should be looking at its deps, not just dropping it on the floor.
<infinity> But if we don't care about supporting it (or if, historically, we've not really supported it anyway), meh.
 * infinity looks for evience of the latter.
<infinity> So, there was one micro-release SRU in precise, and 0 SRUs or security updates in any other series'...
<infinity> That points to "it wasn't really supported anyway, despite being in main".
<ScottK> It's mostly used by Studio and IIRC they focus on LTS.
<infinity> So, let's drop it from that seed and see what germinate has to say.
<ScottK> So micro-release in precise doesn't surprise me.
<infinity> ScottK: That was the Canonical desktop team (seb) that did that update.
<ScottK> Oh.
<infinity> ScottK: Though, maybe that was because it was in main and studio couldn't upload. :P
<infinity> So, it might be best for them if it demotes anyway.
<ScottK> Maybe.
 * infinity follows the trail on that a bit more.
<infinity> So, that was in response to bug #1001516
<ubottu> bug 1001516 in pitivi (Ubuntu Precise) "Please SRU to PiTiVi 0.15.2" [High,Fix released] https://launchpad.net/bugs/1001516
<infinity> Which claimed it was "completely broken" in precise.
<infinity> There've been no other SRUs except for this one "it doesn't work at all for anyone" bug, so that leans to my "it wasn't really well supported to start with" argument.
<Mirv> well, it was, and it again is. before the rewrite to gstreamer-editing-services it has struggled to be functional with GStreamer updates (even just 0.10 series updates)
<infinity> So, I'm okay with demoting it.
<infinity> I've committed the seed change, and will demote when c-m says it's okay, and then do the sync.
<infinity> If anyone decides it really should be in main, there's still time to argue that case, and either neuter the package or MIR the deps.
<Mirv> excellent, thanks infinity, users should rejoy this since they've a chance of doing some video editing
<infinity> (An MIR for pitivi itself wouldn't seem necessary)
<Mirv> neutering would not be possible fully, at least gstreamer-editing-services1.0 and gnonlin1.0 would be strict new dependencies from universe
<infinity> Mirv: demoted and synced.
<Mirv> \o/
<pitti> Good morning
<pitti> infinity, smoser: argh, wolfes are dpkg crashy again, rebooting
<pitti> nevermind, seems someone already did last night
<dholbach> good morning
<zyga> dholbach: good morning :)
<dholbach> hi zyga
<cjwatson> hallyn_: when installing, there's only one user; what groups later-added users get put into is up to desktop components and such.  user-setup adds the first user to the sudo group if configured that way (there are expert installation paths where you can set a root password during installation instead)
<zyga> hey, I need a DD to review a few RFS for debian (python modules and apps) that we need to urgently sync to 14.04, they were reviewed by our sponsor but he doesn't have time before evening today and we're in a rush. Is there anyone here that could help me?
<zyga> mvo: hey, perhaps you could help?
<mvo> zyga: can do in some minutes, do you have a link for me?
<zyga> mvo: not really (we just used email before), those are in DPMT (plainbox, checkbox-ng) and PAPT (plainbox-provider-{resuorce-generic,checkbox})
<zyga> mvo: all are in debian svn
<zyga> mvo: and all got a round of review yesterday
<zyga> *resource
<mvo> zyga: aha, do you have links to the svn repo (e.g. on svn.debian.org)?
<zyga> sure, let me dig those up for you
<zyga> mvo: http://anonscm.debian.org/viewvc/python-modules/packages/plainbox/ http://anonscm.debian.org/viewvc/python-modules/packages/checkbox-ng/ http://anonscm.debian.org/viewvc/python-apps/packages/plainbox-provider-resource-generic/ and http://anonscm.debian.org/viewvc/python-apps/packages/plainbox-provider-checkbox/
<mvo> zyga: ok, I have a checkout of plainbox now, do you guys use svn-buildpackage? or just dpkg-buildpacakge? or something else?
<zyga> mvo: we use svn-buildpackage
<zyga> mvo: those are our first debian packages so we currently just follow the trend in DPMT and PAPT
<zyga> mvo: all the tarballs are on pypi/launchpad
<mvo> zyga: ok, so what are they using :) ?
<zyga> mvo: svn-buildpackage
<mvo> zyga: ok
<zyga> mvo_: do you have any updates on that? anything I can help with?
<zyga> mvo_: I just saw, thanks!
<mvo_> zyga: its building, do you mind if I commit a "debian/rules get-orig-source" target? this makes the tarball fetching/renaming automatic
<zyga> mvo_: I don't mind, piotr typically doesn't want that but I'm sure he'll understand
<mvo_> zyga: it also complaining that the post commit hook is not working
<mvo_> zyga: what is he using/doing in order to get the orig tarball?
<smb> I know I am quite late for asking this: where would I need the smarts (and how would those have to look like) to make people who would have installed xen-hypervisor-(i386|amd64) installed in Precise, pick up xen-system-amd64? That is also both i386 and amd64 move to system-amd64 as there is no 32bit hypervisor anymore.
<xnox> smb: you want xen-hypervisor-4.1-amd64 & xen-hypervisor-4.1-i386 to migrate to xen-system-amd64, right?
<xnox> smb: in that case you need to provide dummy/empty package named xen-hypervisor-4.1-amd64 and xen-hypervisor-4.1-i386, which have "Depends: xen-system-amd64"
<smb> xnox, right. that would be a meta-package to ensure the whole system gets upgraded/installed.
<xnox> smb: correct, and it's the only way to guarantee upgrade path, no-matter how the user choose to upgrade (dpkg, dselect, apt, aptitude, upgrade-manager, etc.)
<smb> xnox, ok. thanks. then I add those to the current xen-4.4 source
<xnox> smb: you probably want similar packages fro xen-system-i386, xen-hypervisor-4.4-amd64, xen-hypervisor-4.3-amd64, xen-hypervisor-4.2-i386, Package xen-hypervisor-4.2-amd64.... depending on which upgrade paths you are willing to support (or forgot to support =))) )
<smb> xnox, Yeah, true. Especially since there likely is enough documentation out there telling people to use the hypervisor package as the base install selector. Which was true in the past.
<jibel> pitti, bug 1304403 is for you?
<ubottu> bug 1304403 in ubuntu-release-upgrader (Ubuntu) "Precise to Trusty - all of main - fails: The package 'postgresql-server-dev-9.1' is marked for removal but it's in the removal blacklist" [Undecided,New] https://launchpad.net/bugs/1304403
<pitti> hm, does that mean that some package conflicts with postgresql-9.1?
<pitti> ah, found it in the apt log
<brainwash> xnox: hey, did you already take a closer look at bug 1284910? sadly I'm not familiar with ubiquity and how it can be easily debugged/tested
<ubottu> bug 1284910 in ubiquity (Ubuntu) "Xubuntu Beta 1 and Beta 2 installer has debian background wallpaper" [Critical,Confirmed] https://launchpad.net/bugs/1284910
<brainwash> the last comment points to a commit which might be the cause for the wrong wallpaper
<gioele> hello, I just run FWTS and it has found a series of failures. How should these be handled? Is there a place where they can be reported? Just in launchpad?
<zyga> how long does it take from something to show up in debian sid to be syncable via requestsync?
<jibel> pitti, actually the root cause seems to be the transition from libkadm5srv-mit8 to libkadm5srv-mit9
<pitti> The following packages will be REMOVED:
<pitti>   krb5-multidev libkrb5-dev libpq-dev postgresql-server-dev-9.1
<pitti> jibel: that's what I get on dist-upgrade, so I indeed see that
<jibel> pitti, the upgrade path is libkadm5srv-mit9 -> rb5-multidev -> libpq-dev -> postgresql-server-dev-9.1
<jibel> but it refuses to upgrade -mit8 to -mit9
<Laney> how do I do git reset --hard origin in bzr?
<mvo> Laney: I assume bzr revert is not good enough as you want to go to the orgin base version?
<Laney> mvo: indeed
<Laney> I tried bzr revert -r :parent but that didn't do it
<sergiusens> Laney: how about bzr uncommit -r revno && bzr revert ?
<seb128> Laney, what is that git command doing?
<seb128> Laney, can't you just uncommit&revert?
<sergiusens> seb128: that's basically what it does
<Laney> I want it to calculate it all for me
<Laney> uncommit -r :parent makes bzr crash :D
<mvo> Laney: yeah, I just tried the same trick with the same result :)
<seb128> Laney, what are you trying to do?
<seb128> why the -r?
<seb128> just uncommit & revert?
<Laney> I could have any number of commits
<seb128> Laney, then uncommit -r <rev>?
<mvo> Laney: have you tried asking in #bzr yet?
<seb128> Laney, you can also pull --overwrite :p
<cjwatson> "git reset --hard origin" is "I am completely giving up on everything I haven't pushed, please just reset my branch to origin and forget about the rest"
<cjwatson> you could always rebranch
<Laney> seb128: yeah I know I can do it manually
<Laney> rebranch is "I'm giving up on this VCS now" :P
<Laney> I'll ask in #bzr and give up
<cjwatson> you should probably not start from the axiom that bzr is as flexible as git is with regard to moving branches around ...
<seb128> I think pull --overwrite is smart enough to not do a full checkout
<Laney> Actually that does look like it worked
<Laney> seb128: seems like that is actually the right way
<seb128> Laney, pull --overwrite?
<Laney> yep
<Laney>   If you want to replace your local changes and just want your branch to
<Laney>   match the remote one, use pull --overwrite. This will work even if the two
<seb128> cool ;-)
<Laney>   branches have diverged.
<Laney> tyhicks: thanks for the lightdm fixes, logout works for me now
<seb128> Laney, tyhicks: \o/
<mlankhorst> great :)
<mvo> is there a equivalent for git-dch for bzr?
<hallyn> cjwatson: yeah, talked to stgraber about it last night;  the problem is that if tasksel installs libvirt-bin during iso install, the postinst which adds all sudo group members to the libvirtd group doesn't find the initial user in sudo group  yet
<seb128> mvo, not sure if there is a standard tool, but didrocks has one, the autolander generate changelogs from vcs commits at least
<mvo> seb128: cool, maybe didrocks can give me a hint
<seb128> mvo, he's off for exercice but I'm sure he's going to pong once he's back/done with backlog
<mvo> thanks seb128
<seb128> yw
<tyhicks> Laney: good to hear! :)
<cjwatson> hallyn: user-setup-apply does that after tasksel runs
<cjwatson> hallyn: so things will need to tolerate that
<hallyn> cjwatson: yes, i proposed a one-liner to user-setup in bug 1304008 ...
<ubottu> bug 1304008 in libvirt (Ubuntu) "user not added to libvirtd group with iso trusty 'virtual machine host' installation method" [High,Triaged] https://launchpad.net/bugs/1304008
<cjwatson> hallyn: why wouldn't we just add that to passwd/user-default-groups directly?
<cjwatson> rather than getting the value from another place in the same package and then adding to it :)
<hallyn> i thought that was only done with preseed.  is there a global default?
<hallyn> (i didn't see it in user-setup)
<cjwatson> debian/user-setup-udeb.templates
<hallyn> sounds perfect :)
<stgraber> oh, didn't think of that. I did think of passwd/user-default-groups but not about always setting libvirtd in there even in the non-libvirt case
<hallyn> well the adduser line does || true so it's ok in non-libvirtd case,
<cjwatson> hallyn: so yeah, I can do that now
<hallyn> cjwatson: thanks!
<seb128> can something stop/retry https://launchpad.net/~ci-train-ppa-service/+archive/landing-013/+build/5889261 ?
<seb128> that seems to be hanging, I would like to get it retried without having to wait on the buildd job to timeout
<Laney> has that happened before?
<seb128> Laney, I don't know
<seb128> Laney, other archs built fine
<seb128> we had transient tests issues for sure
<seb128> but I don't know if that includes hangs or only fails
<Laney> I'll try it
<cjwatson> seb128: cancelled and I'll retry
<Laney> ooh, who won?
<cjwatson> I hit cancel before posting here ...
<Laney> me too
<cjwatson> anyway, it's running now
<seb128> cjwatson, Laney: thanks
<seb128> cjwatson, Laney: retry worked, thanks
<Laney> cool
<Riddell> pitti: could we add gpgsm back to gpgme to fix bug 1293704 ?
<ubottu> bug 1293704 in gpgme1.0 (Ubuntu) "Kleopatra don't support s/mime" [High,Confirmed] https://launchpad.net/bugs/1293704
<pitti> Riddell: sure, if you have a way to make that build and work with gpg 1 and 2, please go ahead
<pitti> Riddell: I remember that I spent an hour or two on it and I didn't see how
<pitti> stgraber: thanks for pointing out lxc-start -s!
<stgraber> pitti: np, it's not the most advertised feature :)
<pitti> stgraber: I greatly simplified adt-virt-lxc with that now
<pitti> jibel: so apparently bug 1304403 doesn't pop up in the automatic upgrade tests, right?
<ubottu> bug 1304403 in ubuntu-release-upgrader (Ubuntu) "Precise to Trusty - all of main - fails: Broken transition from libkadm5srv-mit8 to libkadm5srv-mit9" [Undecided,New] https://launchpad.net/bugs/1304403
<pitti> jibel: looking at this now (got distracted with some other stuff); at least if it's due to krb-dev it only affects server-dev, and this isn't important to keep after an upgrade
<pitti> jibel: so perhaps we can just refine the regexp to not catch -dev, but I'll check if there's an easy way to nudge the upgrade
<jibel> pitti, no, I found it while testing main_all manually. It is not automated due to the disk space it uses
<pitti> jibel: at least upgrade-ubuntu-precise-trusty-server-tasks-amd64 covers the critical case of keeping -9.1 on upgrades
<didrocks> mvo: hey! so I have something which isn't a separate binary unfortunately. It's quite linked to CI Train/cu2d as I ignore the commit message to generate the changelog if there is a manual change for that commit in the mainline in debian/control
<didrocks> mvo: and on bzr upstream advice, the only way to achieve it with that constrain was to parse the output, so not very elegantâ¦
<mvo> didrocks: I have a solution for now https://code.launchpad.net/~mvo/bzr-builddeb/dch - need to find a bzr-buidlddeb upstream to figure out if this might go upstream
<didrocks> mvo: oh nice, james_w can maybe review it ;)
<mvo> didrocks: getting his feedback would be great, I'm sure there is tons to do
<Laney> slangasek: I guess https://wiki.ubuntu.com/Ubuntu%20Kylin/Ubuntu%20Kylin%20Archive needn't call out the GPL/LGPL explicitly
<jibel> mvo, I tried an upgrade with eglibc from your ppa (2.19-0ubuntu4) on amd64 and still have the prompt during upgrade from precise. and in text mode because libgtk-perl cannot be loaded.
<slangasek> Laney: indeed not
<cyphermox> pitti: could you please look into why your NM tests are still randomly failing? https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-network-manager/
<pitti> jibel: I have a simple and obvious fix, uploaded now; I tested it successfully in a chroot
<cyphermox> pitti: in theory RAOF included your isolation-machine fix
<pitti> cyphermox: they don't fail randomly, but very reliably; apparently 0.9.8.8-0ubuntu5 introduced some regression
<pitti> cyphermox: yes, but that's only for the ppc64el and armhf tests (they are just skipped now)
<pitti> I can have a look tomorrow, yes
<jibel> pitti, nice, I'll wait before restarting the test then.
<pitti> jibel: the release team still needs to review/ack it
<cyphermox> pitti: the reason I say "fail randomly" is because those are issues in the tests, not in NM. With the exception of the PE stuff; these tests are things I verify and use routinely -- such as the killswitch connection restore, or suspend and resume
<RFleming> Greets and salutations
<RFleming> quick question re the heartbleed patch on OpenSSL
<RFleming> over in #ubuntu lots of people are asking about the version number remaining the same
<RFleming> 1.0.1 14 Mar 2012
<RFleming> is the version number changing with the patch?
<RFleming> ahh, openssl version -a to compare built on date.
<tarpman> RFleming: also, ubuntu revision on the package version. e.g. in precise: ubuntu5.11->ubuntu5.12
<cjwatson> Right, you should always look at the full package version.  It's often inappropriate to take entire new upstream releases.
<RFleming> tarpman, the questions have been "I installed the patch, but it still shows 1.0.1 14 Mar 2012.  What gives?"
<RFleming> but using the -a switch can show the patch has applied with the build date.
<cjwatson> RFleming: Use "dpkg-query -W libssl1.0.0" instead.
<RFleming> that doesn't really help
<RFleming> :)
<cjwatson> It sure does.
<cjwatson> You can compare with https://launchpad.net/ubuntu/+source/openssl/+changelog
<RFleming> I can yes... Joe user?
<cjwatson> Or you can look at /usr/share/doc/libssl1.0.0/changelog.Debian.gz locally and see the fixed version there
<cjwatson> I don't think expecting Joe User to remember a slew of independent version-discovery commands for lots of different packages (openssl is just today's problem) and correlate those against build dates is at all sensible
<cjwatson> Oh, also, the package version numbers in which any given security vulnerability was fixed are listed in the USNs on security.ubuntu.com
<cjwatson> http://www.ubuntu.com/usn/usn-2165-1/ in this case
<cjwatson> So the instruction is "run 'dpkg-query -W libssl1.0.0' and make sure the version listed is at least that shown on http://www.ubuntu.com/usn/usn-2165-1/ for your release of Ubuntu"
<RFleming> vs run openssl version -a and see if it was built yesterday?
<cjwatson> That might help as a special case for today's problem, but you aren't giving people tools that will help them not need to ask the same question for the next vulnerability
<RFleming> ahh, I see where you're going
<cjwatson> And, for future things, build dates are often misleading for one reason or another
<cjwatson> So if people rely on them it often leads to them wasting time on blind-alley questions
<cjwatson> It's only not misleading in this case because we didn't get any advance notice of this CVE
<RFleming> perhaps "run 'dpkg-query -W libssl1.0.0' and make sure the version listed is at least that shown on http://www.ubuntu.com/usn/usn-2165-1/ for your release of Ubuntu" should be made #ubuntu's MOTD
<jpds> !sslbug | RFleming
<ubottu> RFleming: A fix for the recent OpenSSL vulnerabilities (2014-0076 & 0160) has been pushed to the Ubuntu repositories, see http://www.ubuntu.com/usn/usn-2165-1/ and http://heartbleed.com/ for more information.
<RFleming> that works :)
<roaksoax> slangasek: do you have a few minutes to spare to approve maas from the unapproved queue? (It has important bugfixes that we would like to release)
<slangasek> roaksoax: accepted
<roaksoax> slangasek: thanks a lot!
<mvo> jibel: thanks, same text as the previous one? then I will have a look tomorrow morning
<arges> xnox: hi. looking at an trusty installer issue with a mellanox card. does the module need to be in /etc/network/devnames-static.gz in order for that card to be properly detected?
<arges> xnox: when we get to the 'configure the network' dialog, other NICs show up, but not this mlx4 one.
<arges> xnox: just realized its pretty late where you are, i'll send an email
<xnox> arges: hey =) maybe try stgraber  =)
<xnox> arges: i have no clue what you are on about =)))))
<arges> xnox: hey! ok will do.. yea its installer questions
<stgraber> arges: no idea
<xnox> arges: well, networking configuration parts of it, which i don't deal with at all. Never heard of /etc/network/devnames-static.gz either. sounds weird to have gzip compressed files under /etc/network.
<xnox> arges: if you need kernel modules, they should be packaged / included in the udebs
<cjwatson> I'd expect it to just need to be set up so that the kernel/udev can automatically load the module for it
<arges> yea, we're trying to figure out if this is a hw-detect issue or exists somewhere else
<cjwatson> anything that requires manual hw-detect action is very much deprecated
<cjwatson> please don't introduce more of it unless you have fully investigated the better alternatives and know why they won't work for you :)
<xnox> arges: if you can't modprobe it / no kernel module to load, then well that's the first thing to do.
<arges> xnox: the module is in nic-modules
<arges> xnox: i can modprobe it just fine
<arges> cjwatson: so the installer is using udev at that point?
<cjwatson> yes
<cjwatson> devnames-static is an escape hatch for ancient crufty stuff
<arges> cjwatson: ok good to know.
<cjwatson> it hasn't been touched at all in over five years
<arges> cjwatson: xnox stgraber : thanks guys so looks like we need to setup udev properly to fix this
<stgraber> arges: is that a Mellanox ethernet card or are you trying to get d-i to install using IP over IB?
<arges> stgraber: this is a mlx4 IB card. just trying to detect it at this point
<stgraber> arges: ok, because once you get past loading the ip over ib module and get netcfg to detect it, I can tell you things will fail pretty horribly
<stgraber> dhclient fails over infiniband unless you generate a valid hardware identifier, put it in a conffile and pass that to dhclient
<arges> stgraber: sounds like the next level of issues to deal with : )
<rtg> stgraber, does it work with a static IP address ?
<stgraber> rtg: it should, yes
<stgraber> it's really just dhcp that's a bit weird and anything lower than IP (obviously)
<jdstrand> slangasek: fyi, bug #1304657
<ubottu> bug 1304657 in apt (Ubuntu) "world writable files in /var/lib/apt/lists" [Undecided,New] https://launchpad.net/bugs/1304657
<slangasek> jdstrand: oh my
<slangasek> jdstrand: follow-up q on bug
<jdstrand> slangasek: hmmm, I did this in a vm. my desktop system doesn't have those rw files
<jdstrand> I'm not sure how to do what you asked
<saiarcot895> This probably isn't the right channel, but do GPG private keys need to be regenerated due to Heartbleed?
<slangasek> jdstrand: 'apt-cdrom -d /mount/point add'?
<jdstrand> saiarcot895: no
<slangasek> saiarcot895: no
<saiarcot895> Thanks jdstrand and slangasek
<jdstrand> slangasek: give me a minute. I need to update a different vm and see what happens
<jdstrand> slangasek: ok, responded. seems apt-cdrom is likely to blame
<slangasek> jdstrand: huh - surprising, but thanks for checking
<jdstrand> slangasek: curious if there is any word on bug #1298539?
<ubottu> bug 1298539 in upstart (Ubuntu) "apparmor rcS.d sysv initscript is running too late" [Undecided,New] https://launchpad.net/bugs/1298539
<jdstrand> in related yet I think actually unrelated news, dhclient is starting unconfined even though the network-interface-security job ran (ie /run/network-interface-security exists)
<jdstrand> in a new vm install, but not my laptop
<jdstrand> which looking at the job, boggles me
<slangasek> jdstrand: no word yet, sorry
<slangasek> xnox: ^^ do you have another half a day somewhere between now and release to look at 1298539 on top of all your other bugs?  Or should I try to dig up some more time myself?
<xnox> jdstrand: why apparmor is not an upstart job? (that question was on the back of my mind since forever)
<jdstrand> ok, the dhclient issue is separate. seems there is a bug in qemu that prevents encrypted lvm from working in a vm unless you use 'nomodeset' (I was booting into singleuser then doing 'resume', which apparently unloaded the profiles)
<sarnold> xnox: here's the historical reasoning https://lists.ubuntu.com/archives/upstart-devel/2011-December/001771.html
<sarnold> xnox: improving apparmor's load is on our todo list for next cycle
<jdstrand> xnox: let's just say its complicated
<jdstrand> xnox: but there is the historical reference sarnold mentioned. we plan to do profile compiles in kernel postinst which then means we can do a simple apparmor upstart job super early in the boot process that won't affect boot times
<jdstrand> (we can then employ the same technique during touch image generation and improve first boot startup times there too)
<slangasek> jdstrand: hmmm, but now I'm wondering why lightdm starts before runlevel 2
<jdstrand> but that isn't for 14.04. we wanted it, but alas, it didn't happen
<slangasek> oh, it doesn't
<slangasek> 'start on filesystem and runlevel [!06] [...]'
<jdstrand> (to be fair, we only dreamt up how to do it in less than two months ago :)
<jdstrand> and it is partially implemented. anyhoo, I digress
<slangasek> jdstrand: ok, so on second glance, I don't understand how the start conditions we have here actually cause the behavior you're describing (of user processes being started up before the apparmor policy is applied)
<jdstrand> slangasek: well, I don't either-- if you recall, it was you and infinity who discussed it and came up with that
<slangasek> jdstrand: because the sysvinit script is run from /etc/init/rc-sysinit.conf, before we emit the 'runlevel' event later in the same job script; lightdm doesn't start until after we switch runlevels
<jdstrand> slangasek: why are you talking about lightdm?
<slangasek> jdstrand: because the user processes are all children of the login session?
<jdstrand> cause of evince, firefox, etc?
<slangasek> jdstrand: yeah
<slangasek> you said you saw this problem in the wild on desktop installs?
<jdstrand> well, I added that before the irc discussion
<jdstrand> jj sees it on his desktop. infinity sees it on server
<jdstrand> (many servers)
<xnox> slangasek: jdstrand: on todays cloud images, servers and desktops i totally have tty2 & logged in and start executing things ahead of reaching runlevel 2. We have enough things upstartified, such that we should be fully up without sysv init scripts invoked yet, thus imho we should have apparmor job as upstart possibly just before runlevel 2 event.
<slangasek> what infinity is seeing is "network starts after the getty"
<slangasek> which is different
<xnox> heck ubiquity installer is start on starting lightdm and that has full-blown desktop with network manager =)
<slangasek> xnox: apparmor does run just before the runlevel 2 event, the problem is that the runlevel event is late due to slow network configuring
<slangasek> jdstrand: so the problem that infinity had is not related to apparmor confinement, and won't be fixed by moving rcS earlier in the sequence
<slangasek> that is, it'll prevent 'apparmor' from being one of the things spit out at the console, but he was getting console spew from both rcS and rc2
<xnox> slangasek: hm? is this startpar bridge magic that init.d scripts are ahead of upstart jobs =))))) i see start on remote_fs
<xnox> right.
<slangasek> xnox: the apparmor script is in rcS, all of rcS is processed before runlevel is emitted (see above)
<slangasek> net result, while we could do with not holding up rcS waiting for the network, making such a change doesn't fix whatever bug jdstrand is seeing
<jdstrand> hrm
<jdstrand> slangasek: I thought that initscripts ended up being executing in parallel to jobs?
<xnox> and i also see my tty1 login prompt rutinely hidden by "spew", where as tty2 comes up quick. let me cranck up verbosity and see when tty1 comes up vs runlevel 2 has finished.
<jjohansen> slangasek: I haven't dug into it, but I have repeatedly seen policy loaded after I have logged in, and say started firefox. So that the firefox is unconfined. It is not just an issue of the logging showing up late
<jjohansen> now I haven't checked to see if this is happening for a while now, and it may be fixed
<jdstrand> well, console spew is one thing, but it isn't security relevant
<jjohansen> jdstrand: right, just saying it isn't just console spew
<jdstrand> jjohansen: I can't reproduce myself. I thought I had something when I filed the bug, but don't see to have it now. I guess file a bug when you see it?
<jdstrand> jjohansen: yeah, I hear you
<xnox> jdstrand: the premise is that tty1.conf job is "start on stopped rc RUNLEVEL=2" and that we assert that by that time, all rc2.d is complete and thus all security profiles loaded and all "spew" is complete.
<jdstrand> xnox: so, apparmor isn't in rc2
<jdstrand> id is in rcS.d
<jdstrand> it will be nice when we just have the upstart job...
<xnox> jdstrand: given it's already in rcS it should make much differences to put it into an upstart job. But let me experiment here locally to see the ordering we are currently getting.
<jdstrand> xnox: thomi
<jdstrand> meh
<jdstrand> thomi: nm
<jdstrand> xnox: thanks
<jdstrand> I have to step away for bit
<jjohansen> jdstrand: I still think its weird that we don't do the upstart job and just block boot for a few seconds if policy needs to be compiled
<xnox> jjohansen: jdstrand: yeah, ureadahed also delays initial boots - for the sake of speeds upon second boot.
<jjohansen> yep
<Netsnipe> hi everyone
<Netsnipe> utlemming: are you there?
<slangasek> jdstrand: init scripts in *rc2* execute in parallel to jobs that are 'start on runlevel'.  But apparmor is rcS, so not in parallel
<slangasek> jjohansen: so I accept there may be a bug with firefox winding up unconfined, I just don't see any way that it could follow from what we're talking about in bug #1298539
<ubottu> bug 1298539 in upstart (Ubuntu) "apparmor rcS.d sysv initscript is running too late" [Undecided,New] https://launchpad.net/bugs/1298539
<xnox> jdstrand: jjohansen: http://paste.ubuntu.com/7224096/ takes negligible amount of time if the caches are valid, and when stale seems faster that execing piles of shell. Ideally i'd not source /lib/apparmor/functions at all - and just rely on filebridge to generate an instance per profile to load.
<sarnold> xnox: the end goal is to omre or less just call apparmor_parser /etc/apparmor.d/  and have it Do The Right Thing without goofing around in shell. the parser itself is almost entirely there now..
#ubuntu-devel 2014-04-09
<xnox> sarnold: excellent
<sarnold> xnox: of course your little script provides a nice abstraction around when we eventually do that. :) heh
<xnox> sarnold: it's a bit shame there is no definitive extension name for the profiles, thus stending time filtering out ".dpkg-new" et. al.
<xnox> sarnold: and each location is processed in parallel, however one still does the loop twice =(
<sarnold> xnox: heh, perhaps a decade or so back, we did have a .sd ('subdomain') extension on profiles, but we ditched that somewhere along the way as annoyingly redundant. heh.
<jjohansen> sarnold, xnox: the parser isn't almost there, it is completely there. What it can't do yet is directly handle caching for multiple policy versions, so the old version is replaced when stale, and it doesn't handle profile removal on restart
<jjohansen> it does the filtering for different extensions etc, you can point it at a directory and it loads the profiles from it
<jjohansen> it handles the cache management, 90% of what the initscripts do could be dropped
<jjohansen> oh I guess it doesn't do parallel compiles
<jjohansen> but that is actually minor
<jjohansen> when arekm ripped out the initscript stuff for pld it made things go something like 95% faster. /me would have to dig to get the actual figures
<sarnold> jjohansen: cripes, that's impressive :)
<jjohansen> sarnold: found it, scrapping the bash scripting and doing direct cache load for his 4500 profiles reduced the time from 1m22s to 1.5s
<sarnold> jjohansen: omg I want that
<jjohansen> yeah, for a small profile count the bash scripting overhead is not so bad, but well its time to fix it
<rajat_kapoor> Can anyone please help me , I have started getting "Segmentation fault (core dumped)" on 12.04 desktop terminal?
<Unit193> It would appear the auto importer isn't picking up network-manager, it would appear the last run was 2012.  (Also would be nice to have the systemd services installed, but guessing that won't happen any time soon.)
<darkxst> Unit193, you mean lp:debian branches? there are loads of branches in there that are pretty much broken
<Unit193> darkxst: No, I don't use those.  https://code.launchpad.net/~ubuntu-branches/ubuntu/trusty/network-manager/trusty
<TheMuso> B/c
<pitti> Good morning
<pitti> infinity, smoser: meh, doing daily reboot of wolfe-*; seems your magic from Friday didn't last long?
<infinity> pitti: Yeah, I didn't expect it to fix it, I'd just hoped. :/
<infinity> pitti: If you get a VM in that wedged state and can live with it staying broken for a bit, apw said he'd like to have access to play/debug a bit.
<pitti> infinity: sure; I'll take wolfe-05 offline in jenkins, and just reboot/fix the other three?
<infinity> pitti: Sure, and give him ssh access to that one then, I guess.
<infinity> pitti: I'm heading to bed, but I assume Andy will be up in an hour or two.
<pitti> infinity: yep, will talk to him
<infinity> pitti: Ta.
<pitti> infinity: hmm, seems the other three don't come back from reboot
<pitti> infinity: the host might need a reboot again, too?
 * pitti sends his daily "screw you" jenkinswards
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges, pitti
<dholbach> good morning
<pitti> hey dholbach
<mvo> hey dholbach & pitt, good morning
<pitti> hallo mvo, wie gehts?
<mvo> pitti: good, thanks! still not fully awake, but I'm hopeful the tea will help with that :) and you?
<pitti> mvo: pretty much the same :)
<dholbach> hey pitti, hey mvo
<zyga> good morning
<zyga> could someone enlighten me about the purpose of incoming.debian.org? I was under the impression that it's a place packages go to be built by all the arch builders
<zyga> is my understanding correct?
<pitti> zyga: not quite
<pitti> zyga: it's the staging area where uploads and built packages are queued after accepting it from the upload queue, and publishing it into the archive
<pitti> zyga: i. e. the publisher flushes incoming every 6 hours
<pitti> zyga: but buildds look at incoming so that they don't need to wait for the publisher; but they also build sources which are already published
<pitti> and then again upload the build (going through incoming again)
<pitti> mvo: ah, are you already handling https://code.launchpad.net/~brian-murray/ubuntu-release-upgrader/bug-1302380/+merge/214349 ?
<mvo> pitti: yeah, I have a slightly extended version of his branch, I hope he gets a chance to review that soon(ish)
<zyga> pitti: so after a package gets accepted it goes to incoming, gets built by buildds, then gets back to incomin ? and then flushes to the archive?
<zyga> pitti: and that happens four times a day
<pitti> zyga: not "back" to incoming
<pitti> zyga: upload -> accept (every 10 mins or so) -> incoming -> publisher -> archive
<pitti> zyga: and buildds watch for new sources in incoming and archive -> build -> upload -> same as above
<zyga> pitti: ah
<zyga> pitti: I'm trying to understand when a few small packages that got uploaded there yesterday will make it into the archive
<zyga> pitti: it's almost 24 hours now
<pitti> that sounds like a bug
<zyga> pitti: there are also packages from 7th of April
<zyga> http://incoming.debian.org/
<zyga> or do I read that wrong?
<pitti> hm; they might be NEW or something?
<zyga> pitti: plainbox|checkbox packages aren't new
<zyga> NEW I mean
<zyga> and I cannot see them in https://ftp-master.debian.org/new.html
<pitti>  plainbox | 0.5.3-2 | sid    | source, all
<pitti> seems fine
<zyga> oh!
<pitti> zyga: so it seems incoming has some problems with cleaning up?
 * zyga looks if requestsync sees that now
<pitti> zyga: it's also already on https://launchpad.net/debian/+source/plainbox
<pitti> zyga: so yes, requestsync ought to see it
<zyga> right, I see
<zyga> great :)
 * zyga just saw that versiontools got packaged for python :-)
<pitti> zyga: FYI: https://ftp-master.debian.org/dinstall.html
<zyga> ohhh
<pitti> zyga: dinstall is equivalent to what LP calls "publisher"
<zyga> nice!
<zyga> thanks
<zyga> right
<zyga> I know about it
<pitti> zyga: after dinstall it usually takes about two hours to get imported into LP
<darkxst> pitti, oh no! bug 1302077 will break high contrast theme
<ubottu> bug 1302077 in nautilus (Ubuntu) "Hardcoded css style checks on GTK Theme instead of XGD_CURRENT_DESKTOP" [Undecided,Fix committed] https://launchpad.net/bugs/1302077
<darkxst> well mess it up
<pitti> darkxst: hm, that previous list actually seemed incomplete
<darkxst> (and Adwaita, but I doubt anyone uses that in unity)
<pitti> darkxst: I thought we don't want the title bar under unity, period; not just under these two themes?
<pitti> darkxst: but anyway, if this causes regressions I'm happy to reject from the queue and revert from the branch
<pitti> darkxst: how does it cause regressions/
<pitti> ?
<Noskcaj> pitti, blueman branch is fixed. I'd just committed without .pc/ last time
<pitti> hate hate hate tracking .pc/ in UDD; this is just utterly wrong
<pitti> Noskcaj: thanks
<darkxst> pitti, that patch is overriding some theming issues with the ubuntu themes
<maxb> I'd agree on the .pc/ thing - UDD on v3 source packages needs a serious rethink
<darkxst> pitti, there is a seperate patch to bring back titlebar
<pitti> darkxst: can you please explain that in bug 1302077 so that Leon can adjust?
<ubottu> bug 1302077 in nautilus (Ubuntu) "Hardcoded css style checks on GTK Theme instead of XGD_CURRENT_DESKTOP" [Undecided,Fix committed] https://launchpad.net/bugs/1302077
<pitti> darkxst: I reject the upload
<darkxst> pitti, ok
<Noskcaj> maxb, My suggestion to fix it would be the ubuntu branches don't have stuff applied by default, and .pc/applied-patches is force added
<maxb> force added?
<Noskcaj> maxb, always there
<Noskcaj> pitti, thanks for the sponsorings
<pitti> meh, I sponsor as fast as I can, and yet the queue *increases* :)
<Noskcaj> that's my goal.
<pitti> 1 out of 1 hunk FAILED -- rejects in file blueman/plugins/applet/DhcpClient.py
<pitti> Patch dhcpclient_priority can be reverse-applied
<pitti> Noskcaj: ^ still no good :/
<Noskcaj> really? wow.
<pitti> Noskcaj: nevermind; I got the orig.tar.gz from the failed bzr bd and now use plain debuild
<Noskcaj> thanks
<pitti> Noskcaj: I don't physically merge this anyway, I just upload and let the auto-importer sort it out
<pitti> still, it's a pain
 * pitti really prefers plain debdiffs on bugs
<Noskcaj> that seems to be the majority opinion. Maybe bzr could be hacked to give normal debdiffs
<pitti> not sure if it's the majority; some folks seem to like it the way it is
<pitti> zyga: can you handle https://code.launchpad.net/~brendan-donegan/ubuntu/trusty/checkbox/ffe_ui_custom_transport_ubuntu/+merge/214603 ? you seem to do this via debian and upstream
<pitti> zyga: or, if you fine with an ubuntu upload, I can have a look at sponsoring, but maybe you'd like to cross-check
<ricotz> pitti, good morning :), could you take a look at libcdr 0.0.15 which is/will be the version supported by libreoffice 4.2.4 -- http://people.ubuntu.com/~ricotz/packages/libcdr/
<pitti> ricotz: does that new version work with cdr2odg (source: writerperfect)?
<zyga> pitti: hey, this is a coordinated ubuntu+debian package set
<zyga> pitti: everything except for checkbox-gui is in debian
<zyga> pitti: and is a sync of the new package
<pitti> ricotz: the dh_autoreconf change is already in Ubuntu, could you mark this as "Merge with Debian unstable, remaining Ubuntu changes:"?
<zyga> pitti: checkbox-gui is using ubuntu-sdk so it's not in debian
<zyga> pitti: I'll have a sanity-check look but we've been working on that for the past two weeks :)
<brainwash> anyone familiar with ubiquity? how can I easily test the installer mode?
<brainwash> I want to debug bug 1284910
<ubottu> bug 1284910 in ubiquity (Ubuntu) "Xubuntu Beta 1 and Beta 2 installer has debian background wallpaper" [Critical,Confirmed] https://launchpad.net/bugs/1284910
<ricotz> pitti, yes cdr2odg runs and works, will update the changelog in a bit
<mwhudson> hello
<mwhudson> ah, +1 would be better for this
<ricotz> pitti, updated
<zyga> mwhudson: hey :)
<zyga> pitti: thanks for syncing most of the checkbox stuff over
<pitti> zyga: yw; doing your most recent sync now
<zyga> pitti: are you also going to sync checkbox-support (ppc64el bugfix) and plainbox-provider-resource-generic (a few fixes)
<pitti> zyga: I don't see the latter in the queue yet, but yes, I'll get to it
<zyga> pitti: ok, thanks
<pitti> zyga: please note that they are in unapproved, so the release team needs to ack those, too
<zyga> ok
<zyga> https://bugs.launchpad.net/ubuntu/+source/plainbox-provider-resource-generic/+bug/1304850 is the critical one
<ubottu> Launchpad bug 1304850 in plainbox-provider-resource-generic (Ubuntu) "Sync plainbox-provider-resource-generic 0.3-1 (main) from Debian unstable (main)" [Undecided,New]
<zyga> https://bugs.launchpad.net/ubuntu/+source/checkbox-support/+bug/1304191 less so
<ubottu> Launchpad bug 1304191 in checkbox-support (Ubuntu) "Sync checkbox-support 0.2-1 (main) from Debian unstable (main)" [Undecided,New]
<zyga> pitti: I'll be in #ubuntu-release, do I need anything else to assist in reviewing/landing those?
<pitti> zyga: ah, sponsors aren't subscribed to teh former
<zyga> oh, weird? thanks
<pitti> zyga: I looked at the linked bugs lists, so it seems bug fix only; so it ought to be fine
<pitti> zyga: but syncs don't have a debdiff attached to them, so the release team might have questions about where to see the changes/NEWS/changelog/etc.
<zyga> pitti: I see, I'll try to produce those
<pitti> zyga: which combinations did you test? the full stack of all new versions together?
<zyga> pitti: yes, along with the chcekbox-gui merge request (directly to ubuntu)
 * zyga works on debdiffs
<zyga> pitti: 'debdiff old.dsc new.dsc > pkg.debdiff' is sufficient?
<pitti> zyga: yes
<zyga> thanks
<pitti> zyga: perhaps put them into a pastebin and point to that in #u-r?
<zyga> right
<pitti> probably helps to ask around who has time to review the whole stack
<pitti> ricotz: uploaded libcdr
<pitti> Noskcaj: so in bug 1300521 you said that both (i. e. also gnome-photos) just needs a new grilo-plugins dep, but your branch adds a gnome-online-miners dep?
<ubottu> bug 1300521 in gnome-photos (Ubuntu) "gom-flickr-miner crashed with signal 5 in _start()" [Undecided,New] https://launchpad.net/bugs/1300521
<pitti> Noskcaj: is gnome-online-miners a too big dependency, or does it actually use the miners index?
<Noskcaj> pitti, It was requested by darkxst
<FourDollars> arges: pitti: Can you help me to do SRU for precise? https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1303819
<ubottu> Launchpad bug 1303819 in bluez (Ubuntu Precise) "Bluetooth menu's content disappeared after resume." [Undecided,In progress]
<pitti> FourDollars: too late, I already uploaded :)
<pitti> (and updated the MP and bug)
<FourDollars> pitti: haha. I see it. Thanks a lot. :D
<jibel> pitti, upgrade to Trusty is still blocked on postgresql-server-dev removal even with the fix of krb5, bug 1304702 is the same on i386
<ubottu> bug 1304702 in ubuntu-release-upgrader (Ubuntu) "update-manager fails because of postgresql-server-dev-9.1" [Undecided,New] https://launchpad.net/bugs/1304702
<pitti> jibel: hm, that ^ bug is still with the previous krb5
<darkxst> pitti, right, gnome-photos does use gnome-online-miners now
<pitti> jibel: oh wait, actually not
<pitti> jibel: meh, that helped for me
<jibel> pitti, 1.12+dfsg-2ubuntu3 is latest version right?
<pitti> jibel: yes
<pitti> so I'm afraid I ran out of ideas how to fix this; I might need to invoke the mvo joker card..
<ricotz> pitti, thanks!
<pitti> darkxst: thanks for confirming
<mvo> pitti: ok, I have a look (bug 1304702, correct?)
<ubottu> bug 1304702 in ubuntu-release-upgrader (Ubuntu) "update-manager fails because of postgresql-server-dev-9.1" [Undecided,New] https://launchpad.net/bugs/1304702
<pitti> mvo: right; I tried to fix that yesterday in https://launchpad.net/ubuntu/+source/krb5/1.12+dfsg-2ubuntu3 by adding an additional Replaces: to the Breaks:, to nudge apt
<pitti> mvo: that helped in a schroot, but apparenlty not for everyone still
<jibel> mvo, 1304702 is from saucy to Trusty and 1304403 is from precise to trusty
<jibel> I'll attach new logs for P->T
<mvo> ok
<pitti> jibel: oh, I missed that; so it does work for p->t now?
<pitti> I didn't test s->t in a schroot
<jibel> pitti, no it doesn't
<jibel> pitti, but the format of apt.log changed, maybe it will be more clear
<mvo> jibel: yeah, it should contain more debug info now
<Noskcaj> pitti, Would you mind checking the sra-sdk merge i put up?
<Noskcaj> Your review is wrong
<pitti> Noskcaj: you mean a newer one than https://code.launchpad.net/~noskcaj/ubuntu/trusty/sra-sdk/ftbfs/+merge/214647 ?
<pitti> that one is 2.3.3-4~dfsg-1ubuntu1 from Logan_, which is already in teh archive
<Noskcaj> pitti, never mind. It didn't commit my changes. I'd tried to merge from debian
<Noskcaj> which should fix ftbfs
<mvo> jibel: if you get the chance could you run the upgrade with https://launchpad.net/~mvo/+archive/eglibc-trusty/+packages again? I uploaded a new version
<pitti> apw: hey Andy
<pitti> apw: infinity said you'd like to take a look at the dpkg segfaults on ppc64el?
<pitti> apw: it keeps happening a few hours/a day after rebooting; I kept one box in that state (you can ssh) if you want to take a look
<pitti> smoser: wolfe-{03,04,06} didn't come back after a reboot (needed to because of the dpkg segfaults); would you mind having a look? thanks!
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges
<jibel> mvo, in progress
<mvo> jibel: \o/
<mvo> pitti: quick question - its ok to remove postgresql-server-dev-9.1 I assume? its no longer in the archive  so it can be removed on a trusty upgrade?
<pitti> mvo: for -server-dev, yes
<pitti> mvo: but not for postgresql-9.1, postgresql-client-9.1, postgresql-pl*-9.1, and postgresql-9.1-<extensions>
<pitti> mvo: our regexp catches -server-dev as well, we could also limit that to not catch that (but still catch extensions)
<mvo> pitti: ok, I look at the krb-dev transition currently if we could get that under control that should fix the issue, but might still be worthwhile to relax the regexp a little bit
<pitti> mvo: *nod*
<apw> pitti, i would indeed
<Laney> pitti: was your change to network-manager supposed to fix the tests?
<pitti> Laney: for ppc64 and armhf at least, yes (and that worked)
<pitti> Laney: as for the x86 test, it seems the ubuntu5 install broke them; I'm looking at them tnow
<Laney> pitti: okay, thanks - interesting that the failures are x86 specific
<pitti> Laney: it's not really about the arch, it's about runing in LXC (which doesn't work as the test needs to fiddle with the kenrel) vs. Qemu
<pitti> Laney: the "isolation-machine" thing just skips the test on LXC instead of failing
<jibel> mvo, no prompt with -0ubuntu4.1
<Laney> pitti: aha, so it passes on arm64/ppc64el because the tests aren't actually run there
<mvo> jibel: \o/
<mvo> jibel: thanks a lot for the test
<pitti> mvo: oh, you have an idea about the krb upgrade?
<mvo> pitti: yeah, a transitional pkg fixes it, but I'm looking into the resolver right now, its a bit embarassing that it needs so much hand holding :/
<pitti> mvo: a transitional package for the old -8 library? eww; but thanks!
<mvo> pitti: yes, exactly ewww :/
<mvo> pitti: it seems like it needs to penalize packages that disappear much stronger
<cjwatson> pitti: UDD> let's not fix it and use git-dpm instead. :-)
 * cjwatson trolls gently
<pitti> cjwatson: it can't possibly be any more complicated than gitpkg :) (I think I managed to check out the old debian systemd git once, but forgot all about it again)
<cjwatson> Not a fan of what I've read of gitpkg's approach
<pitti> cjwatson: yeah, I'm quite happy that they replaced it with a standard git-buildpackage tree now
<pitti> (or, at least there is one now which is supposed to become "the" tree soon)
<ev> pitti: what do we lose if we lose ProcMaps in error reports, post-submission? Isn't this what the Dependencies field ultimately provides?
<ev> context: ProcMaps is 71% of all the data in the error tracker :)
<pitti> ev: we must have it for retracing
<pitti> ev: after we computed the stack trace and the duplicate signature (although that alreayd happens client-side), we can drop it
<ev> cool, that seems easy enough to code
<pitti> ev: for LP it's occasionally interesting to have it as an attachment, but we can surely kick it out of daisy's db
<ev> after retrace, go back to the bucket and drop the ProcMaps in each OOPS
<pitti> *nod*
<ev> bdmurray: ^
<pitti> ev: effectively, you can treat ProcMaps.txt like the core dump; their lifetimes should be quite the same
<mvo> pitti: I think I have some idea whats going wrong in the resolver, I will continue further after lunch
<ev> pitti: interesting. I wonder if we should store them in much the same way then.
<ev> ah, the client doesn't really allow that without some rearchitecting
<ev> this aforementioned approach should do for now
<pitti> ev: yes, that's what I thought; treat (CoreDump, ProcMaps) as one thing for conditional submitting, and clean them both up after retracing
<ev> bdmurray: if you want to investigate both ^
 * ev creates an Asana task for this
<ev> https://app.asana.com/0/11345516654327/11523893065995
<rbasak> cjwatson: around? I'm concerned about bug 1302192. Seems like a critical issue to me, perhaps installer related?
<ubottu> bug 1302192 in iputils (Ubuntu Trusty) "ping is not setuid root" [Undecided,Confirmed] https://launchpad.net/bugs/1302192
<rbasak> Or xnox maybe? ^^
<cjwatson> how would that be installer-related?
<rbasak> It seems to be that the package is good, but an ISO based install mysteriously ends up with the file capability missing
<cjwatson> well, maybe capabilities aren't preserved in squashfs
<cjwatson> or maybe ubiquity doesn't copy them, I guess that's possible
<cjwatson> let me check
<rbasak> Ah. I didn't realise that ping switched from setuid to a file capability in Saucy -> Trusty
<cjwatson> /usr/bin/gnome-keyring-daemon /usr/bin/arping /bin/ping /bin/ping6 <- potentially affected programs on my system
<cjwatson> squashfs does seem to have xattr support though
<cjwatson> and in particular supports the security namespace
<cjwatson> so might just be that ubiquity's copying code needs to preserve xattrs
<rbasak> I should probably know this, but does the server iso even use ubiquity?
<Unit193> Should be debian-installer.
<rbasak> That's what I thought, but I am unsure. I use cloud images.
<cjwatson> what he said, yes
<cjwatson> still copying off squashfs in that case for the base system, but using live-installer instead
<cjwatson> anyway, I'll check both
<rbasak> OK, thanks.
 * rbasak needs to brush up in this area
<cjwatson> ah, live-installer uses tar, we'd need to pass --xattrs I think
 * mvo wonders what happend to his eglibc upload, no confirmation from the upload since ~1h
<cjwatson> mvo: 10:37 -queuebot:#ubuntu-release- Unapproved: eglibc (trusty-proposed/main) [2.19-0ubuntu3 => 2.19-0ubuntu4] (core)
<Laney> you should have had a Waiting for approval email
<cjwatson> good, "getcap /bin/ping" in a live session returns "/bin/ping = cap_net_raw+p"
<mvo> thanks cjwatson and Laney
<pitti> cyphermox, Laney: NM> ah,  it seems our apparmor workaround for bug 1244157 stopped working
<ubottu> bug 1244157 in linux (Ubuntu) "[3.11.0-12.18 regression] "Failed name lookup - disconnected path" in dhclient D-BUS access" [Low,In progress] https://launchpad.net/bugs/1244157
<cjwatson> mvo: accepted anyhow
<mvo> thanks cjwatson
<rbasak> beisner: ^^ if you're interested. Thanks for your help.
<xnox> jodh: slangasek: looks like mounted events block mountall - instead of "--no-wait" =(
<jodh> xnox: yes, this is documented in mounted(7) since 'mounted' is a hook-type event (upstart-events(7)).
<xnox> jodh: ack. Fair enough, used a different check/event so i'm all good.
<GunnarHj> xnox: Anything I can do to help processing bug #1294858? Or will it have to wait?
<ubottu> bug 1294858 in ubiquity (Ubuntu) "Installer does not install all language support packages" [Undecided,Confirmed] https://launchpad.net/bugs/1294858
<xnox> GunnarHj: i didn't have time to look into it yet. if not this week, then it would be for U-cycle / SRU into trusty 14.04.1 release =/
<GunnarHj> xnox: Ok thanks, then I know.
<jdstrand> xnox: thanks for the apparmor job! question: because this is a task, it isn't possible for a console login, lightdm login, *dm login, etc to happen without this first running?
<jdstrand> well a task and its start on line
<xnox> jdstrand: it's a task, thus "started appararmor-loaded" event will only be emitted after it completes fully.
<xnox> jdstrand: thus e.g. another jobs can do "and started apparmor-loaded" or in their pre-start do $ start apparmor-loaded, which will block until it's completed.
<xnox> jdstrand: let me check the graphs to see where it's placed... 1sec.
<jdstrand> xnox: ok, right. so in order to deploy this properly, we need an apparmor job and then adjust all other login jobs to use "and started apparmor-loaded"
<jdstrand> xnox: what happens when apparmor is not installed on the system?
<jdstrand> xnox: eg, someone wants to use selinux
<smoser> pitti, deal
<pitti> smoser: in case you need to reboot the host: apw is currently debugging the segfault on wolfe-05, so can you please wait with that a bit?
<pitti> smoser: rebooting the other three VMs is fine at any time as they are essentially dead (at least with ssh)
<xnox> jdstrand: there is a better way
<jdstrand> xnox: I guess we could solve that by having upstart itself ship the job file
<jdstrand> xnox: oh?
<jdstrand> xnox: I also think we need something along the lines of: http://paste.ubuntu.com/7226194/
<jdstrand> so I can collapse the click-apparmor and apparmor jobs into one
<xnox> jdstrand: so if we change it to "start on mounted MOUNTPOINT="/" " then that job will block reaching further significant events (e.g. local-filesystems, filesystems, runlevel, etc.) until apparmor profiles are compiled and fully loaded.
<smoser> pitti, i bounced the guests.
<smoser> and they should all be up now.
<jdstrand> (along with short-circuiting some known situations)
<pitti> smoser: cheers; I'll dist-upgrade them while they are still off jenknis, and then plug them back in
<xnox> jdstrand: yeah, but will need to add a not-container check in the script itself, since we can't block on an "and" condition.
<jdstrand> xnox: I'm not sure I understand the statement. are you saying that we should remove 'and not-container' and then uncomment the '#[ -x /bin/running-in-container ] && /bin/running-in-container && exit 0' ?
<xnox> jdstrand: well running-in-container is shipped by upstart =) so yeah, we'd need to add a line which is "! running-in-container"
<xnox> to the job.
<jdstrand> xnox: ok, here is the updated job: http://paste.ubuntu.com/7226232/
<jdstrand> xnox: the 'better way' was referring to making sure console and display managers logins don't have to be modified?
<xnox> jdstrand: that's way too much.
<jdstrand> xnox: what is too much?
<xnox> jdstrand: clicks are already handled by the click-apparmor.conf job
<jdstrand> xnox: I know-- I want to remove that job
<xnox> jdstrand: ok, "convergence" eh? =)
<jdstrand> honestly, I'd like to find a better way than that hack I came up with to know when to run aa-clickhook, but that is for another day
<beisner> rbasak - cool, thx. looks like it's just about tackled (ping getcap)
<xnox> jdstrand: i don't like the gazzilion checks we do in shell. If the task fails, that's fine and the upstart job will stop, cause it's all running under set -e.
<xnox> jdstrand: thus none of the upstart jobs typically do  [ -x /usr/bin/foo ]; exec /usr/bin/foo
<jdstrand> ehh
<jdstrand> that makes me very unconfortable
<xnox> jdstrand: if load_configured_profiles gracefully fails, when apparmor is not available that's all what we need.
<xnox> jdstrand: i'd rather be aggressively loading the profiles.
<jdstrand> xnox: load_configured_profiles is shell. I can move the checks there, but not sure what difference that would make
<xnox> jdstrand: http://paste.ubuntu.com/7226258/ without any checks.
<xnox> they are no-op code / asserts.
<jdstrand> so, we actually do have these checks
<xnox> ... because of $reasons ?! =)
<jdstrand> look at /lib/init/apparmor-profile-load
<xnox> right.
<jdstrand> that is what something like mysql uses
<jdstrand> we have these checks because over the years we've found they are needed
<pitti> cyphermox, Laney: NM with adjusted tests uploaded; something in the DHCP client stack got slower, so I had to bump the DHCP timeout from 15 to 20 seconds to make them pass again; the other failure was due to the PE change in ubuntu5
 * xnox can't wait for "u-cycle" to switch all of these to apparmor stanza =)))
<pitti> cyphermox: I disabled the negative test for the temporary IP with PE disabled, as I'm not sure whether that's intended
<jdstrand> well, I figured we wouldn't do that too aggressively because of systemd
<xnox> jdstrand: having all check in the upstart job is fine. as long as the conditions are correct.
<cyphermox> pitti: I think the PE stuff was broken and is now fixed
<xnox> jdstrand: e.g. check for /sys/kernel/security manually, as one cannot do "and mounted MOUNTPOINT=" reliable (mounted event blocks mountall and thus other portions of the and condition will not get emitted and deadlock mountall)
<pitti> cyphermox: yeah, perhaps; before, you got a temp IP with PE enabled, and no temp IP with PE disabled, which sounded quite plausible
<cyphermox> well, no that's the way it should be
<xnox> jdstrand: hence "start on mounted MOUNTPOINT="/"" and this point it's past mounting "/sys/kernel/security" or try to mount it again. and all profile loading will block boot.
<pitti> that's the way that it was until ubuntu5, now it always gets a temp IP
<xnox> jdstrand: and it practice it's lightning quick, here on a typical laptop with an SSD.
<cyphermox> pitti: must be that the fixes to some patches got done wrong
<cyphermox> pitti: I'll take a look at it
<pitti> cyphermox: ok, thanks; I disabled that test in r812 as you told me it's correct now; but please revert that if it passes again
<jdstrand> xnox: sorry, you lost me. the apparmor job in my paste (http://paste.ubuntu.com/7226232/) doesn't currently check for /sys/kernel/security/apparmor (I missed that). are you saying it should or should not?
<xnox> jdstrand: let me reply with a paste =)
<cyphermox> sure
<pitti> cyphermox: not sure where the slowdown comes from, but with the increased timeouts they at least pass again
<cyphermox> right
<cyphermox> pitti: you meant ubuntu6 for the patches no?
<cyphermox> ubuntu5 contains a patch, but it should be irrelevant to PE
<pitti> cyphermox: could be, yes; I meant reversion of the disabled "no temp IP" test (r812)
<cyphermox> ok
<pitti> if the previously checked behaviour was in fact right, and the test pointed out an actual regression
<xnox> jdstrand: something like this: http://paste.ubuntu.com/7226316/
<xnox> jdstrand: changed "start on" and added "/sys/kernel/security" block.
<jdstrand> xnox: ack
<jdstrand> I wonder if mounting securityfs is enough to get /sys/kernel/security/apparmor
<jdstrand> I guess it would be (would have to check)
<pitti> mvo: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html > your eglibc upload keeps my little minions busy :)
<jdstrand> xnox: so, because this is 'start on mounted MOUNTPOINT="/"' and it's a task, does that mean other jobs/tasks will block until this is done?
<mvo> pitti: hehe
<jdstrand> xnox: ie, we don't have to adjust the lightdm job (et al)
<xnox> jdstrand: correct it will block, and no changes are required in other jobs.
<apaKhelogger> does anyone know under which circumstances /proc/sys/crypto/fips_enabled would be present and get EACCESS on fopen()?
<apaKhelogger> I don't seem to have crypto/ at all
<jdstrand> xnox: ok, cool. I've got this locally. I guess my team can figure out if we want to push this in 14.04 (it requires a lot of testing)
<jdstrand> xnox: thanks for you help! it will definitely be in 14.10
<xnox> jdstrand: "in 14.10" as in, in just 9 days ;-) =)))))
<jdstrand> :)
<apw> stgraber, when we setup lxc environments, what do we use to setup the network brigding for them ?
<stgraber> apw: most people just use the bridge that's setup by the lxc-net upstart job, or you can define extra bridges in /etc/network/interfaces or you can use libvirt's own bridges
<cjwatson> rbasak: ok, hopefully wheels now mostly in motion - thanks for the heads-up
<rbasak> cjwatson: no problem. Thank you for looking at it at such short notice. I certainly wouldn't have been able to figure out all the pieces quickly enough.
<cjwatson> I probably can't easily do much about systems that are already broken
<cjwatson> dpkg-reconfigure of the relevant packages should sort them out, or possibly even ongoing upgrades
<jdstrand> xnox: so, in theory, this upstart job would remove the need for the apparmor stanza?
<cjwatson> or sudo apt-get --reinstall iputils-ping etc. (perhaps also iputils-arping, gnome-keyring)
<Laney> pitti: thanks!
<cjwatson> s/--reinstall/--reinstall install/
<rbasak> --reinstall is what I was thinking. dpkg-reconfigure wouldn't fix the delivered binaries, would it?
<cjwatson> dpkg-reconfigure has the side-effect of running the postinst and it's the postinst that sets the capabilities
<cjwatson> but --reinstall is probably better, rather than perpetuating the meme of using dpkg-reconfigure for things other than debconf :)
<brainwash> xnox: please help! =S
<rbasak> Ah - I was under the impression that the binary package's archive magically contained the capabilities.
<cjwatson> no, in a sane world it'd be that way, but I think it has to be in maintainer scripts because packages need to define fallbacks in the event of filesystems that don't support xattrs
<rbasak> I see - thanks.
<brainwash> xnox: the xubuntu installer background issue needs to be fixed and I would like to help debugging it
<rbasak> A no change rebuild of the affected packages would fix everything then, right? Not worth it?
<apw> stgraber, i am more asking by default what interface do you use to add things to the bridge
<cjwatson> rbasak: it would, though no way to synchronise it with people who do installs from beta-2 media between now and release
<apw> stgraber, do you run external things, or talk netlink, or ...
<stgraber> apw: netlink
<apw> stgraber, where do i find your netlink bits for that
<cjwatson> rbasak: maybe just -devel-announce with a recipe once the installer is fixed
<rbasak> Anyone who installed from beta-2 media would have an older version though, and so would end up upgrading and thus fixing?
 * rbasak doesn't follow
<cjwatson> well, uh, maybe you're right
<stgraber> apw: https://github.com/lxc/lxc/blob/master/src/lxc/network.c
<cjwatson> yeah, I think you are
<cjwatson> still, hold off until the installer's done, I need to get attr in and then I need to write the live-installer code; and we need to upload ubiquity
<stgraber> apw: oh, actually, looks like the bridge add is done through an ioctl
<rbasak> OK, sure. Thanks!
<jamespage> pitti, have you seen anything like bug 1303649
<ubottu> bug 1303649 in systemd (Ubuntu) "systemd-logind high cpu consumption" [Undecided,New] https://launchpad.net/bugs/1303649
<jamespage> pitti, I've hit it on my main laptop, a spare and now on one of our servers in the CI lab
<pitti> jamespage: not so far; when did that start, just recently? i. e. with the cgmanager integratino?
<jamespage> pitti, might have - its definately in the last week or so I noticed it
<pitti> jamespage: yeah; it otherwise hasn't changed for the entire cycle
<jamespage> mainly because my fan was being noisy
<pitti> jamespage: when that happens, could you attach strace to it, to see what it's spinning on?
<jamespage> pitti, sure
<jdstrand> xnox: also, this job should also obviate the need to the network-interface-security job, no?
<xnox> jdstrand: definately not needed any more for the network-manager and networking, not sure about network-interface
<xnox> jdstrand: yeah, it shouldn't be needed. but do test without network-interface-security job.
<hallyn> what time does freeze start?
<jdstrand> xnox: I haven't tested it, but for network-interface-security it needs to have '/' mounted to load the policy at all
<jdstrand> xnox: so if the apparmor task blocks, then network-interface-security should come after it
<jdstrand> xnox: but yes, need to test
<jdstrand> xnox: if it doesn't work, I guess we could add another condition in the network* jobs to make sure
<mvo> does "Apr  9 14:08:19 base-installer: apt-install or in-target is already running, so you cannot run either of" ring a bell? bugreport from a friend of mine installing the server cd on a dell poweredge. if not I will try to reproduce and look into it
<mvo> (image from yesterday apparently)
<hallyn> d'oh, it's tomorrow.  silly me
<rbasak> xnox: may I have your comment on bug 1303717 please? Is a missing init.d script a policy violation? It reads to me that there must be a functional init.d service script, but I thought the plan was to detect and make them non-functional? Thus I'm a little confused.
<ubottu> bug 1303717 in nis (Ubuntu) " (trusty) missing /etc/init.d/ files" [Undecided,New] https://launchpad.net/bugs/1303717
<Daviey> mterry: Hey, your disabled test in duplicity upload... Is there a bug tracking the issue?
<mterry> Daviey, not yet, just a TODO on my sticky note  :)  I'll file one
<Daviey> mterry: I quite favour putting the bug number in the .skip comment personally.. but I am sure you'll keep an eye on this, right? :)
<Laney> Patch headers!
<mterry> Daviey, yes.  I have an idea of how to fix already.  Just didn't want to wait given 14.04's imminent release  :)
<Daviey> Laney: well yeah, that aswell... but seeing the skip reason when running a build does stand out.
<xnox> rbasak: it's a policy violation in Debian.
<xnox> rbasak: in ubuntu we have about 220 upstart jobs without init.d scripts shipped.
<rbasak> xnox: thanks. We're considering it fine in Ubuntu to continue with upstart jobs with no init.d counterpart then?
<ogra_> until systemd comes :)
<xnox> rbasak: yes. as long as they are precise and trusty compatible.
<mterry> Daviey, bug 1305124 filed btw
<ubottu> bug 1305124 in Duplicity "test_last_file_missing_at_end test is flaky" [Undecided,New] https://launchpad.net/bugs/1305124
<LocutusOfBorg1> hi, any ubuntu-sponsor there?
<LocutusOfBorg1> I got an ack from release team
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+bug/1290253
<ubottu> Launchpad bug 1290253 in Ubuntu "[Ffe] Sync can-utils 0.0+git20140227-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed]
<rbasak> LocutusOfBorg1: try arges. He's listed in the topic as on patch pilot duty today.
<arges> rbasak: i am? i can take a look
<LocutusOfBorg1> thanks
<LocutusOfBorg1> usually I don't bother people, but they asked for "asap"
<arges> LocutusOfBorg1: is there a debdiff / bzr associated with this bug?
<arges> oh its a sync
<LocutusOfBorg1> sync
<LocutusOfBorg1> plain sync
 * arges looks at it
<LocutusOfBorg1> arges, can you please also look at this bug?
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/gambas3/+bug/1296763
<ubottu> Launchpad bug 1296763 in gambas3 (Ubuntu) "Please merge gambas3 3.5.2-1 (universe) from Debian testing (main)" [Undecided,New]
<LocutusOfBorg1> seems to be the only way to fix https://bugs.launchpad.net/ubuntu/+source/gambas3/+bug/1295963
<ubottu> Launchpad bug 1295963 in gambas3 (Ubuntu) "the official packages for gambas3 is wrong" [Undecided,New]
<arges> man, i forgot to pilot out from the other day
<arges> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<arges> LocutusOfBorg1: ok let me get to that next.
<LocutusOfBorg1> but unfortunately the package is stuck in debian/new queue
<LocutusOfBorg1> no problem arges
<LocutusOfBorg1> :)
<LocutusOfBorg1> I really appreciate
 * pitti hugs mvo
<pitti> mvo: apt: 10000b years and still not perfect :)
<mvo> pitti: very true!
 * mvo hugs pitti
<arges> LocutusOfBorg1: bug 1296763 needs an FFe... its a really really big jump in versions and I doubt its a 'bug-fix only release'. I'll mark this in the bug
<ubottu> bug 1296763 in gambas3 (Ubuntu) "Please merge gambas3 3.5.2-1 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/1296763
<LocutusOfBorg1> yes arges , but the current version seems to be unusable
<LocutusOfBorg1> don't know, this isn't a package I care too much
<LocutusOfBorg1> but I'm working on libsdl-gfx transition right now
<LocutusOfBorg1> and gambas is FTBFS
<LocutusOfBorg1> the same for ubuntu https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741789
<ubottu> Debian bug 741789 in src:gambas3 "gambas3: FTBFS: dh_install: gambas3-gb-db-postgresql missing files (usr/lib/gambas3/gb.db.postgresql*), aborting" [Serious,Open]
<arges> LocutusOfBorg1: understood. see comment in the bug regarding FFe. Try going through that process.
<arges> cjwatson: i'm looking at bug 1290253. i'd like to sponsor this FFe, but its a new package. Which tool(s) do I use to get this package in the upload queue? I have some ideas, but i'd liek to make sure i'm doing this correctly. Thanks
<ubottu> bug 1290253 in Ubuntu "[Ffe] Sync can-utils 0.0+git20140227-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1290253
<cjwatson> just syncpackage as normal
<arges> cjwatson: then I should see it in the trusty new queue?
<cjwatson> yep
<arges> cjwatson: so acutally i did run this, but didn't get any feedback. I did 'syncpackage can-utils'...
<cjwatson> it's in the new queue
<cjwatson> $ queue info can-utils
<cjwatson> or https://launchpad.net/ubuntu/trusty/+queue
<arges> cjwatson: ah there it is : ) ok thought i was going crazy
<arges> cjwatson: thanks
<cjwatson> np
<LocutusOfBorg1> thanks
<Riddell> Sweetshark: what's the plan for bug 1300283 ? you will upload with the revert?
<ubottu> bug 1300283 in libreoffice (Ubuntu) "LibreOffice does not start in a KDE 4 session" [Critical,In progress] https://launchpad.net/bugs/1300283
<cjwatson> Riddell: he already did, I accepted it recently
<mvo> slangasek: I was looking at bug #1243090 as it appears on the qa tracker and wonder if http://bazaar.launchpad.net/~mvo/update-notifier/use-pycurl/revision/845 might be something worth considering (needs a real testcase first, but not worth persuing if its too late anyway which I kind of suspect :)
<ubottu> bug 1243090 in update-notifier (Ubuntu) "Dist Upgrade from 13.04 to 13.10 stuck during flashplugin-installer" [Undecided,Confirmed] https://launchpad.net/bugs/1243090
<Riddell> cjwatson: nice
<jdstrand> slangasek, xnox and infinity: fyi, I just subscribed you to bug #1305108 (I split it from bug 1298539). if you want to peruse the attach job for obvious errors or the description for obvious problems, that's fine, but mostly I wanted to make sure you guys saw in conversations surrounding it.
<ubottu> bug 1305108 in apparmor (Ubuntu) "please provide upstart job for apparmor" [Undecided,Confirmed] https://launchpad.net/bugs/1305108
<ubottu> bug 1298539 in upstart (Ubuntu) "apparmor rcS.d sysv initscript is running too late" [Undecided,New] https://launchpad.net/bugs/1298539
<jdstrand> slangasek, xnox, infinity: the security team hasn't discussed the timing of landing this, so fyi only atm
<infinity> jdstrand: I like it.  What are the odds we could band together and test this enough to actually make the change for release?  I know that fails the "conservative changes only" test by a mile, but I can't help thinking the security (and simplicity) win here is worth it.
<jdstrand> infinity: it is tempting, isn't it? I need to talk with mdeslaur and the team to see what resources we can put behind it. I plan to do that in a bit when people are online
 * jdstrand is coordinating another landing atm
<mdeslaur> I personally think it's insane
<infinity> mdeslaur: What's insane?  Trying to land the upstart change?
<infinity> mdeslaur: Or the current state of affairs?
<infinity> mdeslaur: Or both? :P
<mdeslaur> trying to land that at this time, in an LTS, blocking boot for policy compilation, not adding it to upstart as a library before other jobs get processed, etc.
<zyga> mvo: hey, could you look at checkbox-ng in debian again? we missed a build-dep after one of the dpeendencies droping one of their own dependency. I just commited a one-line fix for that, could you please sponsort that and sync it over to Ubuntu?
<zyga> http://paste.ubuntu.com/7227007/
<zyga> that's the debidiff
<zyga> roadmr: ^^
<zyga> pitti: ^^ (perhaps?)
<roadmr> zyga: looks ok to me, but we need someone who can sponsor that for us :(
<zyga> I know, just letting you know
<slangasek> mvo: 1243090> how does switching to curl fix the actual bug?
<roadmr> zyga: thanks :)
<slangasek> mvo: I'm inclined to say we shouldn't push this before 14.04; but if we know for sure that curl fixes a bug vs. urllib, maybe this should be an SRU?
<pitti> zyga, roadmr: yes, can sponsor
<zyga> thanks
 * zyga needs to figure out how to do clean feeder archive builds locally :-(
<pitti> zyga: uploaded
<zyga> pitti: thanks, what do we need to do about syncing it to ubuntu now?
<zyga> pitti: requestsync again after it clears debian?
<pitti> zyga: wait for about 8 hours, i. e tomorrow morning
<zyga> pitti: can that still be synced tomorrow? the deadline is 10th of April, is it not?
<pitti> zyga: I can also do a fakesync
<zyga> what it a fakesync?
<pitti> take the Debian .dsc and build an ubuntu source.changes for it (syncpackage --no-lp)
<pitti> zyga: uploaded; if the release team doesn't like that, we can sync it properly tomorrow morning
<zyga> pitti: thanks, I really owe you one
 * zyga will learn and setup proper clean, feeding package build infrastructure at home
<slangasek> jdstrand, mdeslaur, infinity: yes, I don't think we should make this change last minute, especially when the driver for this seems to be an issue we have no root causing for and moving apparmor loading up earlier in boot risks making our race condition harder to track down (but no less harmful)
<pitti> zyga: sbuild is great; if you combine it with apt-cacher-ng, and symlink /var/lib/schroot/unpack to a tmpfs (I use /tmp), it outright rocks :)
<pitti> and mk-sbuild is fairly easy to do
<zyga> I'll give sbuild another go, I had issues with getting some of standard tools to build clean debian correctly and I ended up doing custom, broken stuff
<pitti> hm, I build all my stuff in a sid sbuild, works quite nicely
<cjwatson> ditto, have absolutely no problem with sbuild for Debian.  I think a few Ubuntu releases back it was less good
<Laney> my problem is my inability to remember -s
<pitti> Laney: heh, me too; I have alias sbuild-sid='sbuild -s -d unstable'
<pitti> Laney: and $build_source = 0; in ~/.sbuildrc, as I don't generally want it to (re)build my source, I usually do that with bzr bd or git-buildpackage
<Laney> pitti: good idea
<Laney> ooh, build_source, that'll help
<Laney> hrm, it's supposed to default to 0
<pitti> Laney: perhaps; could also be because I copied that from a template
 * pitti waves good night
<Laney> I'm in the habit of not passing -s for ubuntu because it was doing that ...
<Laney> possibly an obsolete habit though
<bdmurray> pitti: what about ProcMaps and python crashes - is it useful?
<cjwatson> chrisccoulson: is there any chance you could fix the firefox-testsuite -> ttf-arphic-ukai NBS entry (http://people.canonical.com/~ubuntu-archive/nbs.html) in time for release?
<bdmurray> jibel: why is bug 1269397 set to high?
<ubottu> bug 1269397 in update-manager (Ubuntu) "update-manager crashed with AttributeError in resize_to_standard_width(): 'NoneType' object has no attribute 'get_resolution' if $DISPLAY is not set" [High,Triaged] https://launchpad.net/bugs/1269397
<chrisccoulson> cjwatson, will get to it later
<bdmurray> infinity: Do you have time to look at bug 1296386?
<ubottu> bug 1296386 in casper (Ubuntu) "[PATCH] Remove 23etc_modules script" [Undecided,New] https://launchpad.net/bugs/1296386
<infinity> bdmurray: It seems to rely on a kernel patch that hasn't been accepted yet.
<infinity> bdmurray: Err, well, the other bug does.  This one might be harmless to fix regardless.
<bdmurray> infinity: ah, well I think the casper one is causing some install failures
<infinity> Yeah, we can fix the casper one.  It might break sound on a select few machines in the live environment, but that seems like a fair tradeoff.
<infinity> bdmurray: FWIW, it was added in 2006, due to https://bugs.launchpad.net/ubuntu/+source/casper/+bug/27862
<ubottu> Launchpad bug 27862 in casper (Ubuntu) "sound does not work any more on ppc live CD" [Medium,Fix released]
<bdmurray> woo, a time capsule
<infinity> bdmurray: So, the way I see it, fixing casper will make the live session happy, but the world will still explode on reboot into the installed system without fixing bug #1296373
<ubottu> bug 1296373 in hw-detect (Ubuntu) "[PATCH] Fix sound on PowerPC" [Undecided,New] https://launchpad.net/bugs/1296373
<infinity> And fixing that one will leave people without sound entirely until the kernel patch is in.
<infinity> Fun.
<infinity> Maybe still worth it.
<infinity> No sound is better than crashy kernels.
<infinity> bdmurray: casper change uploaded, hw-detect change commented on, kernel change still in BenH's hands, but maybe we can get it pulled into 3.13 stable as an SRU.
<cjwatson> chrisccoulson: thanks
<Sweetshark> Riddell: as noted on the bug: was uploaded today, has finished building on amd64/i386. Note that the libreoffice-kde thing in 4.2.3 is still somewhat shaky, there is a set of additional fixes upstream in for 4.2.4 that were too risky to backport this late.
<Sweetshark> Riddell: so while this fixes the immediate issue -- back to the state we had before, 4.2.4 should be better in general, and be quickly SRUed after testing.
<Riddell> Sweetshark: great, thanks
<rsalveti> slangasek: bug 1305315 (the issue with the i386 android toolchain)
<ubottu> bug 1305315 in gcc-i686-linux-android (Ubuntu) "Android container fails to start when built with the gcc-i686-linux-android toolchain" [Undecided,New] https://launchpad.net/bugs/1305315
<rsalveti> and another one related with the toolchain: bug 1302799
<ubottu> bug 1302799 in gcc-i686-linux-android (Ubuntu) "Android build fails if -fstack-protector is used in TARGET_GLOBAL_CFLAGS" [Undecided,New] https://launchpad.net/bugs/1302799
<rsalveti> slangasek: for qtbase: http://paste.ubuntu.com/7228323/
<rsalveti> slangasek: also had to remove the custom override_dh_makeshlibs rule, as that was causing all the packages to have a runtime dep of (= ${binary:Version})
<rsalveti> that was something we got from the 4.8 src package, not sure exactly why that was decided
<rsalveti> let me know if you're fine with it and I'll do a src upload
<slangasek> rsalveti: fwiw in my own testing, variants 3 and 5 of the symbol dependency were unused and can be safely dropped
<rsalveti> slangasek: yup, just had there for reference, but yeah, let me remove it
<slangasek> rsalveti: seems ok to me otherwise
<slangasek> and pretty closely matches what I had here
<rsalveti> great
<bdmurray> stgraber: does ubiquity update itself before starting the install?
<stgraber> bdmurray: no. The option is however provided to the user if they wish to do so.
<bdmurray> stgraber: ah, and do you recall what that updates? just ubiquity?
<stgraber> bdmurray: not sure, sorry
<xnox> bdmurray: from code, it upgrades ubiquity. but it needs to be service-side triggered (e.g. similarish to how upgrade-manager / manifests are triggered to move people to next lts)
<xnox> bdmurray: i've never triggered that, though.
<xnox> bdmurray: 'http://changelogs.ubuntu.com/ubiquity/%s-update-available' % _ver is the trigger
<bdmurray> xnox: I think the fix for bug 1051935 created bug 127706
<ubottu> bug 1051935 in oneconf (Ubuntu Precise) "Fails with SystemError when too many files are open" [Undecided,Confirmed] https://launchpad.net/bugs/1051935
<ubottu> Error: Launchpad bug 127706 could not be found
<bdmurray> er bug 1277706
<ubottu> bug 1277706 in ubiquity (Ubuntu) "ubiquity install failure due to new ubiquity and old python-apt" [High,Confirmed] https://launchpad.net/bugs/1277706
<xnox> bdmurray: not sure what you mean, we respun isos to have everything matching and the bug posted is using  Mythbuntu 12.04.3 "Precise Pangolin" - Release i386 (20130820) - 12.04.3 media
<xnox> bdmurray: during sru process we noticed that we both updated on the images, which we did for 12.04.4
<xnox> bdmurray: or you think we should be triggering ubiquity upgrade for 12.04.0, .1, .2 and .3 media? we'd need to test them...
<bdmurray> xnox: I'm suggesting that ubiquity gets updated and then tries to use code only available in the new version of python-apt
<bdmurray> xnox: notice how there are 2 different ubiquity versions in the log
<bdmurray> 2.10.26 and 2.10.29
<xnox> i see what you mean now.
<xnox> bdmurray: right, ubiquity in precise should have a tigher versioned depends on python-apt e.g. >= 0.8.3ubuntu7.2 and we did not do that. This way if somehow, for whatever reason ubiquity is upgraded in the live system (manually that is at the moment) an updated python-apt is also forced to be installed.
<bdmurray> ah, yeah that would fix it
<xnox> bdmurray: i'll prepare the SRU and test-plan to reproduce the bug.
<bdmurray> xnox: I don't think it should be a rush
<bdmurray> I mean it would be fine after 14.04...
<xnox> bdmurray: well assigning the bug to myself for now. indeed it's not a common code path to hit. Indeed 14.04 tasks are of the most priority at the moment =))))
 * xnox needs more vocabulary
#ubuntu-devel 2014-04-10
<bluesabre> hello sponsors!
<bluesabre> ah
<bluesabre> nvm
<bluesabre> :)
<slangasek> hallyn, stgraber: the debian/rules Vcs-* fields are defined as pointing to the branch where the package lives; please drop this field from the cgmanager package if the packaging isn't actually going to live there
<hallyn> slangasek: is there a field we can use for where the usptream lives?
<hallyn> (I assume you mean the debian/control Vcs-*)
 * hallyn pushing an update without that field
<hallyn> thanks
<slangasek> hallyn: yeah, debian/control is what I meant.  There's no such debian/control field for upstream Vcs, you could put it in debian/copyright
<Mirv> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv
<Unit193> Mirv: Happy piloting.
<Mirv> thanks, let's see what I can do today. it's the last day before final freeze at least.
<pitti> Good morning
<pitti> bdmurray: we don't use procmaps for automatic processing of python crashes; they are occasionally useful to look at in bug reports for developers, though
<pitti> bdmurray: like, finding out python extensions, third-party extensions/plugins, etc.; our client-side hooks check for that
<pitti> infinity: -base langpack refresh next Monday: does that sound ok? or rather tomorrow?
<infinity> pitti: Are those my only two options?
<pitti> infinity: any other option would involve prodding wgrant to do a manual LP export
<infinity> I imagine he has the skills to do that.
<infinity> But I can't think too many translations will change between tomorrow and Monday, so tomorrow would be fine.
<pitti> infinity: actually, scratch that; the other chance to enable "full langpack" would have been yesterday
<infinity> Monday, we should be well into RC-land, and hopefully only respinning for criticals.
<infinity> Hopefully.
<pitti> infinity: ack
<pitti> infinity: we've done it on Monday in the past few releases, so I assumed that was ok; but let me do the prodding
<infinity> pitti: Did we?
<wgrant> pitti, infinity: We can do it manually, but tomorrow seems to make sense to me.
<pitti> wgrant: I requested a full export on https://translations.launchpad.net/ubuntu/trusty/+language-packs now; could you please kick the cronjob so that it builds one in the next day or two?
<pitti> (I can also start the build on Saturday if necessary)
<infinity> pitti: So, if I get to pick timing, "over the weekend" would be best.
<pitti> infinity: ack
<wgrant> loganberry.canonical.com-launchpad:30 10 * * 2,4 nice -16 $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/language-pack-exporter.py ubuntu trusty --force-utf8-encoding -q --log-file=INFO:/srv/launchpad.net/production-logs/rosetta/language-pack-exporter.log
<infinity> pitti: The first RCs won't spin until Sunday night or Monday morning.
<pitti> wgrant: right, that matches with my "3,5" cronjob to build/upload the packages
<wgrant> Won't it automatically do its thing in 5 hours?
<wgrant> 4 hours
<pitti> wgrant: oh, right; I was off by a day
<bluesabre> hey pitti, are you running the show currently?
<pitti> wgrant: ok, then I'll check tomorrow morning, and ask you if it failed (as sometimes it just doesn't produce anything)
<pitti> bluesabre: "the show"?
<wgrant> pitti: Well, it doesn't not produce anything. It spams my inbox.
<wgrant> :)
<bluesabre> :)
<pitti> heh
<bluesabre> as in, are you up for doing uploady things?
<bluesabre> xubuntu-meta needs a refresh to take in one final change we rolled in last night
<pitti> bluesabre: I've been sponsoring half a day yesterday
<pitti> bluesabre: I can do some sponsoring, but not that much -- I've got to do some work, too :)
<bluesabre> right
<pitti> linux-exynos5 | 3.13.0-3.3    | trusty/universe         | source
<pitti> oh, so this came back? we removed the package some time ago
<pitti> or is that an error of some kind (bad sync)
<bluesabre> ok, looks like it may have been taken care of after all, sorry to bother you guys
<Mirv> yay for new -base langpacks, to get help translations in
<infinity> pitti: No, it's back, that's based on the current trusty kernel.
<Mirv> bluesabre: I'm the crippled pilot sort of since I don't have upload rights. what I tend to do is testing etc as needed, and then ping someone with upload rights.
<bluesabre> Mirv: ok, good to know.
<Mirv> today it seems I'm pretty crippled today by final freeze related work too, but I'll help at least if asked to help somewhere
<Mirv> the fact that pitti has a pilot turn scheduled a day before tends to also mean the queue is shortish :S
<infinity> Mirv: If one of your uploads is 5 minutes late because you were being nice and helping someone else, I think we'll cut you some slack.
<pitti> Mirv: I got it down from 34 to 14 yesterday, but there was some stuff which needed FFEs or fixing
<infinity> Realistically, actionable items in the queue should be pretty much 0 right now, unless there are some obvious, auditable, and simple bugfixes in there still.
<pitti> infinity: speaking of FFEs, do you have a feeling about bug 1305135?
<ubottu> bug 1305135 in autopkgtest (Ubuntu) "FFE: Provide ssh access to Qemu testbed for easier test debugging" [Undecided,New] https://launchpad.net/bugs/1305135
<Mirv> pitti: yes, waiting UIFe, FFe, and already uploaded stuff in there. only a couple that could use some work/testing.
<infinity> pitti: Looks sane to me.
<pitti> Mirv: already uploaded? I can help with setting stuff to "merged" (although by now core-devs ought to be able to)
<pitti> infinity: thanks
<Mirv> pitti: in unapproved queue, xfce4-indicator-plugin. I guess it's not right to set it merged before it leaves that queue.
<pitti> Mirv: *shrug*, there's nothing left to sponsor really
<pitti> Mirv: but your call
<pitti> Mirv: bug  1304214 looks like something which should still get in (but haven't checked)
<ubottu> bug 1304214 in ubuntustudio-lightdm-theme (Ubuntu) "[UIFe] New default wp for ubuntustudio-lightdm-theme" [Undecided,New] https://launchpad.net/bugs/1304214
<Mirv> it does, but it'd need that approval. although it's ubuntustudio specific, I could probably discuss with them directly since they're probably handling the docs by themselves too.
<Noskcaj> lp:~noskcaj/ubuntu/trusty/xfce4-xkb-plugin/lp-733563 still needs sponsoring
<Mirv> Noskcaj: thanks, it seems it's missing from the sponsoring report page (http://reqorts.qa.ubuntu.com/reports/sponsoring/). I'll look at it
<Noskcaj> micahg, thanks. Sponsors got unsubscribed after the first review for some reason
<dholbach> good morning
<Mirv> ok, I've verified this one, so if some core-dev would be kind to dget https://launchpad.net/~timo-jyrinki/+archive/ppa/+files/ubuntustudio-lightdm-theme_0.7.dsc and upload?
<didrocks> Mirv: doing
<Mirv> didrocks: thanks!
<pitti> stgraber: still here by any weird chance?
<pitti> stgraber: question for you in bug 1305395; not sure if slangasek wants that in trusty still, but in case he does it's a bit urgent (and the change is otherwise fairly straightforward)
<ubottu> bug 1305395 in systemd (Ubuntu) "systemd-login service not started on package install" [Medium,In progress] https://launchpad.net/bugs/1305395
<jamespage> pitti, fd 6 is a pipe
<pitti> jamespage: the strace doesn't say to where? i. e. not a named fifo?
<jamespage> pitti, looking at that now
<pitti> jamespage: if the strace doesn't reveal it, it might also help to attach gdb to the process and get a bt to see where it's spinning
<zyga> bdrung_work: hey, I noticed you've packaged versiontools
<jamespage> pitti, nothing in strace
<jamespage> pitti, gdb'ing now
<pitti> jamespage: you mean you don't see a call that opens fd 6?
<jamespage> pitti, no
<pitti> jamespage: oh wait, you attached strace to logind, you didn't start logind under strace, right?
<pitti> if that happens only after some hours, that would produce a lot of output indeed, so let's try with gdb
<jamespage> pitti, cgmanager_ping_sync
<pitti> jamespage: ah, so I suppose your cgmanager process might have died?
<pitti> root       310  0.0  0.0  23656  1440 ?        Ss   07:54   0:00 /sbin/cgmanager --sigstop -m name=systemd
<pitti> you shoudl have something like that
<pitti> jamespage: but even then it shoudln't loop
<jamespage> root       327     1  0 Apr09 ?        00:00:12 /sbin/cgmanager --sigstop -m name=systemd
<jamespage> I do
<pitti> jamespage: ok; at this point I'd hand this to stgraber, he knows much better what cgmanager_ping_sync() is supposed to do
<pitti> jamespage: thanks so far!
<bdrung_work> zyga, yes
<jamespage> pitti, np
<zyga> bdrung_work: thanks for doing that, I was interested in working on it myself as I wanted to use it in my work soon
<zyga> bdrung_work: is the module maintained in DPMT?
<jamespage> pitti, stgraber: I'll leave it spinning - if either of you want access and have IPv6 I can enabled that fairly easily
<bdrung_work> zyga, no. i put it under collab-maint. i don't mind moving it to DPMT (if they use git)
<zyga> bdrung_work: I noticed you provided a python3 version as well, thanks
<zyga> bdrung_work: I was working on 1.10 release
<bdrung_work> you're welcome
<zyga> bdrung_work: I could co-maintain the package if you want to
<zyga> bdrung_work: do you have any packages that depend on it?
<bdrung_work> zyga, help is appreciated
<bdrung_work> zyga, yes. gevent-socketio depends on it. that was the reason for packaging it
<zyga> I see, thanks
<apachelogger> pitti: ahoy, does that look sound to you: https://code.launchpad.net/~apachelogger/lightdm/pam-kwallet/+merge/215108
<pitti> apachelogger: superficially yes
<pitti> (but I don't know how kwallet works)
<apachelogger> almost exactly like gnome-keyring, the pam thingy was pretty much modeled after the gnome-keyring one from what I have been told
<pitti> apachelogger: ah, ok; so it's not related to money or bitcoins or so :)
<apachelogger> pitti: oh god no :P
<pitti> $ bzr whoami
<pitti> Your Name <name@example.com>
<pitti> WTH?
 * pitti uncommits, fixes that, and re-commits
<zyga> pitti: bzr test suite perhaps?
<pitti> zyga: yes, I did run that a couple of times
<pitti> but I didn't expect it to change my actual config
<zyga> pitti: it also gives you a gpg key you may want to get rid of
<pitti> eww!
<pitti> it should really set HOME=`mktemp -d` ..
<pitti> zyga: not that I can see; at least nothign with "bzr" or "example"?
<zyga> pitti: perhaps it managed to clean up for you, I saw some failures and it's still here (the gpg key)
<pitti> apachelogger: should I also upload the lightdm change to trusty?
<apachelogger> pitti: would be lovely
<pitti> apachelogger: hm, there are more changes in trunk than just that
<apachelogger> pitti: I can do an isolated upload then
<pitti> apachelogger: sounds better then
<pitti> I don't know how well these changes got tested, and whether they are meant for trusty
<apachelogger> aye, uploaded :)
<Laney> ISTR that update-manger wants Conflicts/Replaces to remove packages & Breaks/Replaces isn't enough
<Laney> is that right?
<cjwatson> Laney: yes
<Laney> ta
<Laney> Do reject mails from syncs work? :-)
<ScottK> Laney: If it's CI syncs, definitely not.  Debian syncs, not sure.
<Laney> ScottK: It's a Debian one in this case. You don't get "Waiting for approval", but do get "Accepted" (https://bugs.launchpad.net/launchpad/+bug/830614)
<ubottu> Launchpad bug 830614 in Launchpad itself "Email not immediately sent for copied packages which end up in NEW" [Low,Triaged]
<cjwatson> there definitely seems something wonky about syncs and mails, not sure about rejected but I'd expect that to be the same code path as accepted ...
<zyga> bdrung_work: do you intend to get versiontools in to trusty?
<zyga> bdrung_work: or are you fine with u-series?
<bdrung_work> zyga, i synced it to trusty (i need it to fix the build failure of gevent-socketio)
<zyga> bdrung_work: it's still in the new queue
<bdrung_work> yes
<cjwatson> *clicketyclick* no it isn't
<bdrung_work> cjwatson, thanks
<xnox> sergiusens: fginther: looking at https://code.launchpad.net/~xnox/notes-app/py32/+merge/210254/comments/510398 => http://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/6378/console it appears that the tests are executed with python2, yet python3 should have been used.
<xnox> sergiusens: fginther: am i missing any declaration to trigger the jobs to use python3?
<Mirv> I can't work on the piloting anymore, but if some core-dev wants to tinker a bit lmms would be "ready" aside from lintian non-cleanness also present in the current version in archives: bug #1291675 / lp:~timo-jyrinki/ubuntu/trusty/lmms/1.0.0_packaging
<ubottu> bug 1291675 in lmms (Ubuntu) "[FFe] LMMS 1.0.0" [Wishlist,Triaged] https://launchpad.net/bugs/1291675
<Mirv> it builds fine, was tested, and contains all the fixes Ubuntu Studio folks want to have there + matches upstream sources
<Mirv> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<jibel> pitti, any idea why apport tried to run 'system-image-cli' on a desktop in bug 1305804 ?
<ubottu> bug 1305804 in ubuntu-release-upgrader (Ubuntu) "could not upgrade from saucy to trusty" [Undecided,New] https://launchpad.net/bugs/1305804
<pitti> jibel: /usr/share/apport/general-hooks/ubuntu.py calls it if there's a /var/log/system-image/client.log
<pitti> jibel: so apparently this got installed once
<pitti> and then removed again
<pitti> jibel: that's when you run apport on a phone
<jibel> pitti, right, that's why I was surprised to see it when run on a desktop
<ev> stgraber: is there some trick to passing a loopmounted filesystem to a lxc container? I've tried lxc-device but I'm getting the rather helpful "cannot mount block device /dev/loop0 read-only" message inside the container.
<ev> pitti: how were you arranging some block devices for swift in your lxc deployment?
<pitti> ev: I don't; I just use /srv/swift/1 and just one volume
<pitti> ev: http://people.canonical.com/~pitti/scripts/setup-swift.sh
<ev> ah, so it uses the local fs? The charm doesn't seem to support that. Drat.
<pitti> ev: yes, it's not a charm; lxc-local doesn't currently work for me, and I don't really need it; see http://www.piware.de/2014/03/creating-a-local-swift-server-on-ubuntu-for-testing/
<ev> yeah, I did have a read through
<pitti> ev: it's just a script which you run as root in a fresh container or VM
<ev> though juju local does work for me, so I'm trying to get swift, glance, and rabbit in that :)
<ev> works as of trusty, that is
<ev> it was a car crash in saucy
<pitti> ev: I didn't bother with rabbit, as that's really just apt-get install rabbitmq-server
<pitti> bother to write some kind of setup script, that is
<ev> yeah, there's also lp:rabbitfixture, so I might leave that part off as well
<stgraber> hey pitti
<pitti> bonjour stgraber, Ã§a va ?
<stgraber> pitti: trÃ¨s bien et toi ?
<pitti> stgraber: je vais bien aussi, merci !
<pitti> stgraber: as-tu vu mon question dans le bug 1305395 ?
<ubottu> bug 1305395 in systemd (Ubuntu) "systemd-login service not started on package install" [Medium,In progress] https://launchpad.net/bugs/1305395
<stgraber> pitti: so wrt, bug 1305395, both changes look good to me. systemd will indeed talk through cgmanager if it's available, so the mount is unneeded and indeed blocked in containers
<pitti> stgraber: ah, good
<stgraber> pitti: though instead of keying on container_type, we could key on /sys/fs/cgroup/cgmanager/sock
<pitti> stgraber: but we should still mount it for "real" systems, right?
<pitti> stgraber: keying on /sys/fs/cgroup/cgmanager/sock would mean that we don't mount it on real iron any more either, though?
<pitti> that sounds quite a bit more regression prone, as I'm not sure that all software has been fixed to look into /run/systemd/ instead of /sys/fs/cgroup/
<pitti> stgraber: but in principle, cgmanager is being used on real iron now as well, right?
<stgraber> pitti: hmm, yeah, probably better to keep the mount around for old software and in the event where cgmanager fails, so yeah, let's go with container_type
<pitti> stgraber: ack, thanks for the review!
<stgraber> cgmanager isn't installed by default and won't be for 14.04, as the upstart cgroup support won't make it
<stgraber> it is however installed by default on any system that has LXC
<pitti> stgraber: ah, that's why I have it
<pitti> stgraber: can't live without LXC these days, really
<pitti> stgraber: (in other words, many thanks for this!)
<stgraber> thanks :)
<stgraber> yeah, once you adapt your workflow to use containers, it's hard to get back :)
<pitti> stgraber, slangasek: systemd_204-5ubuntu18_source.changes uploaded for your reviewing pleasure then
<stgraber> pitti: cool, will review it in a minute then
<infinity> stgraber: Dangit, I was going to trade pitti a systemd review for a kmod one. ;)
<infinity> stgraber: Now, I guess you get to review both.
<pitti> infinity: happy to review kmod anyway :)
<stgraber> infinity: you know that Martin isn't in ~ubuntu-release anymore right? :)
<infinity> stgraber: Yeah, but he can pretend.
<infinity> stgraber: I'm not concerned about a release ack, just a second set of sane eyes on the change.
<infinity> pitti: FWIW, yes, I did install that job locally, play with throwing modules in various files, move /etc/modules out of the way, etc, and check upstart logs.  It seems to DTRT.
<pitti> yes, scrutinizing the modules-load.d/ bits
<pitti> so that'll modprobe lp, ppdev, and parport_pc everywhere again due to /etc/modules-load.d/cups-filters.conf
<infinity> pitti: The run-parts bit is cargo-cult from the Debian sysv script, pretty much the rest is us, to be less forky and ugly.
<pitti> I doubt that anyone was missing the parallel port bits, but not having lp sounds strange
<infinity> pitti: If that's not something we want, we shouldn't be shipping that file, not relying on our kmod being broken WRT upstream, IMO.
<pitti> oh, that's also just for parallel port printers?
<pitti> infinity: yes, of course; just thinking aloud here
<pitti> infinity: and wondering how people could print without that; but I guess no dev has a parallel printer any more
<pitti> or a parport, for that matter :)
<infinity> Or something else loaded it anyway.
<infinity> Hard for me to tell now that it's loaded. :P
<infinity> Oh, no, one of them was verbose.
<infinity> [1244710.379097] ppdev: user-space parallel port driver
<infinity> That definitely happened when I was testing.
<pitti> infinity: ah, haha
<pitti> /etc/init/cups.conf also loads it
<pitti> oh, and /lib/modules-load.d/fuse.conf
<pitti> that will be new
<infinity> fuse.conf is a no-op, it's builtin.
<pitti> ack
<infinity> (A no-op with our distro kernels, that is, probably wanted when not running one)
<pitti> infinity, stgraber: so, kmod should not change the behaviour in the default install, and it looks ok to me
<stgraber> good because I accepted it already :)
<infinity> Oh, hrm, the only thing I didn't test is if that'll behave weirdly if $files is empty before entering the while loop.
 * infinity tests quickly to see if he needs a followup.
<infinity> Nah, seems fine.
<zequence> Any core-dev around, that could lend us some upload rights? Bug 1291675
<ubottu> bug 1291675 in lmms (Ubuntu) "[FFe] LMMS 1.0.0" [Wishlist,Triaged] https://launchpad.net/bugs/1291675
<zequence> This package has some major improvements to the released one. Has been tested and is pretty much ready to go.
<wgrant> pitti: Langpack export is about half done, so seems like it will work this time.
<bdmurray> mvo: are you planning on SRU'ing the fix for bug 1202754?
<ubottu> bug 1202754 in update-manager (Ubuntu Saucy) "update-manager crashed with SystemExit in exit(): 0" [High,Triaged] https://launchpad.net/bugs/1202754
<pitti> wgrant: splendid, thanks
<bdmurray> jibel: have you had a chance to test bug 1286161?
<ubottu> bug 1286161 in ubuntu-release-upgrader (Ubuntu Trusty) "13.10 -> 14.04 upgrade failed: initramfs failed to ugprade, udev is not configured yet" [High,In progress] https://launchpad.net/bugs/1286161
<mvo> bdmurray: I think that is a good idea
<bdmurray> mvo: Yes, I agree. I was more asking do you want to do it or should I?
<mvo> bdmurray: oh, if you have some spare cycles, you are very welcome to do it
<mvo> bdmurray: the aptdaemon upload from some minutes ago may also be worth getting
<bdmurray> mvo: okay, we'll see
<mvo> dobey: do you think there is a chance to get  lp:~mvo/software-center/lp1225885  reviewed and a upload before the final freeze? I'm happy to do the upload if you give me a hand with the current process of building the package
<dobey> mvo: how many hours 'til freeze?
<dobey> mvo: for upload, just deb-patch it
<xnox> dobey: 21:00 UTC on the dot (+ slippage)
<Laney> haha
<Laney> on the dot (not on the dot)
<dobey> it's a constantly moving, pale blue dot
<mvo> dobey: deb-patch? as in apt-get source / patch / dpkg-buildpackage -S / upload?
<dobey> mvo: yeah, as in drop it in debian/patches/
<mvo> ok
<dobey> mvo: if you're in a hurry, go for it. i'm not going to fight you on it :)
<mvo> dobey: muuuarrhhh :)
<mvo> dobey: will do it
<dobey> mvo: there was a patch from robert_ancell too, if you could go ahead and throw it in (if he didn't already)
<mvo> dobey: yeah, I was about to include both patches
<dobey> mvo: great, thanks. and welcome back :)
<mvo> dobey: thank you!
<dobey> now, to get some lunch. bbiab :)
<bdmurray> pitti: ddebs seem to be missing for libcairo-perl 1.104-1, libglib-perl 3:1.304-1, libgtk2-perl 2:1.249-2, and libpango-perl 1.224-2
<cjwatson> I moved those all to universe recently, if that helps track down the problem
<bdmurray> cjwatson: oh, hmm
<apachelogger> cjwatson: uefi stuff on kubuntu has regressed again
<bdmurray> cjwatson: Have you seen bug 1287222?
<ubottu> bug 1287222 in openssh (Ubuntu) "openssh-client 6.5 regression bug with certain servers" [High,Confirmed] https://launchpad.net/bugs/1287222
<cjwatson> bdmurray: yes, can't do anything about it
<cjwatson> apachelogger: ...
<apachelogger> cjwatson: I am going to drop that dreadful distributor override
<cjwatson> apachelogger: um
<cjwatson> apachelogger: what package(s) exactly do you intend to change?
<apachelogger> cjwatson: kubuntu-settings-desktop, which ships /etc/default/grubd./yayaydayda which sets GRUB_DISTRIBUTOR to kubuntu
<cjwatson> apachelogger: hm, right, I can't say that would make me sad
<cjwatson> apachelogger: remember to do the rm_conffile thing in a .maintscript file
<apachelogger> aye
<tgm4883> Are there any ubiquity heroes around? Mythbuntu is dangerously close to not being able to ship because Ubiquity is crashing in the live mode
<xnox> tgm4883: i've testing mythbuntu yesterday and ubiquity did work.
<xnox> tgm4883: did apport crash report appear and did you file a bug report?
<xnox> tgm4883: what's the bug number?
<tgm4883> xnox, did you check ubiquity in live mode, or just the installer?
<tgm4883> because it only crashes in live mode, which is weird
<tgm4883> superm1, is there a bug number on this?
<superm1> no crash reporter shows up
<superm1> it only crashes in live mode, removing they myth-services plugin fixes it, but i can't figure out why
<xnox> superm1: thanks, i can take a look debug this. But probably around 22-24 UTC, after my volleyball match.
<superm1> xnox: thanks for helping, i'll let you know if i figure it out
<tgm4883> xnox, any off the top of your head pointers to look at?
<tgm4883> we aren't seeing much in terms of logs and such
<xnox> slangasek: ^ can we get a post-FFF slippage exception for above critical mythbuntu issue by the looks of things
<slangasek> xnox: this falls under "critical installer bugs that are the only thing you're allowed to touch post-final-freeze", yes
<xnox> slangasek: ack. =)
<superm1> thanks
<tgm4883> thanks slangasek
<apw> Laney, you touched whoopsie-preferences last, seems we have missing/wrong B/R for P->T upgrades: bug #1306122
<ubottu> bug 1306122 in whoopsie-preferences (Ubuntu) "precise to trusty upgrade leads to file conflict on policy kit policy" [Undecided,New] https://launchpad.net/bugs/1306122
<Laney> you touch it, you own it? :)
<mvo> bdmurray: thanks for the apt upload for saucy! I was thinking we probably want to pick https://bugs.launchpad.net/ubuntu/+source/apt/+bug/957231 soonish too, what do you think? seems to be high on errors.u.c
<ubottu> Launchpad bug 957231 in apt (Ubuntu Saucy) "update-manager crashed with SIGSEGV in debListParser::LoadReleaseInfo()" [Undecided,New]
<apw> Laney, heh something like that, but you might have a better view for the recent touchingness
<apw> i am happy to fix it up as well
<bdmurray> mvo: that was me just releasing it to -updates, yes I agree with fixing that apt bug in saucy
<Laney> apw: Nope, I'd bet is a straight B/R missing
<mvo> bdmurray: cool, I will see what I can do tomorrow morning then
<apw> Laney, it has one on another packge from the same source, so i wondered if they fatfingered the name
<Laney> I think the split was done post-precise, when a-l-m-c-c was the thing
<apw> ahh
<Laney> which has since been renamed to a-l-m
<Laney> so we want both I guess
<apw> so both needed then
<apw> yeah
<bdmurray> mvo: we might need a test case, otherwise I'll have to query the database to find out if it is happening with the new version of apt. this is possible just some more work.
<Laney> apw: You do, I review in unapproved queue?
<apw> Laney, sure
<Laney> great
<mvo> bdmurray: aha, ok. I'm not sure if there is good way to create one, but I will scratch my head a bit about it
<bdmurray> mvo: well, if not we can just use errors to validate it - I've been surprised how many people use -proposed
 * mvo nods
<apw> Laney, the vcs link in this thing seems to be junk, did you find an appripriate branch
<Laney> apw: no, it is junk
<Laney> I think robert_ancell is/will/was/considered/smelt getting that back into shape
<apw> ok ...
<Laney> but in the meantime just use the archive
<apw> yep, will do
<bulletxt> Hi, Cups 1.7.2 came out today. Do you think ubuntu 14.04 will be able to get it into it ? I filled a bug on launchpad
<bulletxt> Please it's very important for me! There are some blocking bugs on 1.7.1 that is blocking my work
<bulletxt> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1306141
<ubottu> Launchpad bug 1306141 in cups (Ubuntu) "cups 1.7.2 into ubuntu 14.04" [Undecided,New]
<seb128> tkamppeter, ^
<seb128> bulletxt, not sure if the update is safe enough to get it, you might want to give specifics about your issue, selected fixes might be backportable if the update can't be done
<seb128> bulletxt, it's also possible that the update is done as a SRU after release
<bulletxt> this is the change log  https://www.cups.org/blog.php?L717      the worst bug for me is STR #4401
<bulletxt> it's only a bug fix release and security
<bulletxt> as clearly stated at the top (at least thats what they say)
<tkamppeter> seb128, thanks for the hint, I also got the mail notification of this bug some minutes ago. How many hours are left to final freeze for getting this done before?
<Laney> just under 4-ish
<seb128> tkamppeter, even if you don't make the freeze it might still be ok to upload
<seb128> they might approve it tomorrow
<seb128> or it can be recycled to a SRU
<pitti> doko: FYI, new python3.4 has (real) test failures and thus is stuck in -proposed: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-python3.4/ARCH=i386,label=adt/78/console
<tkamppeter> seb128, I will package it now ...
<seb128> tkamppeter, thanks
<Laney> Till Kamppeter set my printer on fire 10 seconds before Final Freeze
<doko> pitti, otp, will look later
<tkamppeter> Laney, what did I do?
<bulletxt> Laney:  don't worry I'm testing something like 8 printers connected to my server, from dyesub sublimination to professional Epson 3880 and others . So I'll let you know if 1.7.2 sets on fire my printer :)  I really need 1.7.2 lp command with 1.7.1 and below is broken
<Laney> tkamppeter: Was joking about the last minute update :P
<bulletxt> Well I have to go now hopefully I'll be back tomorrow.... tkamppeter thanks for the miracle  in advance :)   goodbye
<tkamppeter> bulletxt, np
<MacSlow> re
<dobey> well, guess we might need to move final freeze a bit :)
<delinquentme> Hey all! Wondering if anyone has a suggestion for a newbie to OS programing who happens to be a bit upset with the non-functional shortcut-key bindings in the default 12.04
<delinquentme> Is this something simple to fix?
<robru> delinquentme, what shortcut keys? System settings has a panel for changing keyboard shortcuts.
<delinquentme> robru, yeah it allows them to be changed ... but on reboot they're wiped
<dobey> delinquentme: eh? works fine here
<dobey> delinquentme: file a bug
<tkamppeter> seb128, new CUPS uploaded.
<tkamppeter> seb128, CUPS 1.7.2 is accepted now.
<ypwong> slangasek, regarding the new ubuntu kylin archive, will the debian source packages be published into the archive as well?
<ypwong> happyaron ^^
<seb128> tkamppeter, thanks
<slangasek> ypwong: they certainly should be
<ypwong> gotcha
<mwhudson> is it possible that do-release-upgrade says "no release available" when it should say "your network is broken"?
<sarnold> hrm, a friend is hitting bug 1302158 without using maas. he says he's "passing a loopmount of ubuntu-14.04-beta2-server-i386.iso to virt-install --location"
<ubottu> bug 1302158 in MAAS "Default Installer: No kernel modules were found" [Undecided,Invalid] https://launchpad.net/bugs/1302158
<cjwatson> in general your base image and your kernel have to be in sync
<sarnold> makes sense, I'm just surprised simplestreams (appears?) to be involved for an iso-based install
<cjwatson> I haven't looked at the bug 'cos should be going, just saying, "No kernel modules were found" is a standard d-i message for "your kernel and the pool on your image are out of sync"
<cjwatson> and doesn't involve simplestreams
<sarnold> ah! :) thanks
<sarnold> time for me to run too, lunch beckons. thanks cjwatson :)
<LBo> I'm trying to use `backportpackage` + `pbuilder-dist` to backport a packge for a different arch (i386)
<LBo> I can't find out how to specify the architecture
<LBo> I'm now using this command: `backportpackage -b -B pbuilder-dist modsecurity-apache -u ppa:leonbo/servers`
<LBo> Does anyone know how I can specify that it should build for i386?
<Noskcaj> LBo, use pbuilder-dist i386
<LBo> Noskcaj: thanks. backportpackage then gives this error: `Error: Unsupported builder specified: pbuilder-dist i386`
<Noskcaj> try pbuilder-dist trusty md64
<LBo> That doesn't work. It only accepts some parameters for -B:
<LBo> `Error: Supported builders: cowbuilder, cowbuilder-dist, pbuilder, pbuilder-dist, sbuild`
<barry> pitti: i guess we just have to accept two python interpreters on touch... for now
<Logan_> LBo: > the ARCH  and  DIST  environment is read by pbuilderrc(5) to select the correct base image
<Logan_> from backportpackage(1)
<LBo> Yeah, I tried that
<Logan_> so export ARCH=i386 and DIST=whatever in /etc/pbuilderrc
<Logan_> oh, that didn't work?
<LBo> Logan_: then when I did an `env` in my .pbuilderrc, it showed the ARCH & DIST env's but not with the values I set
<LBo> It looked like something overruled those
<Logan_> weird
<LBo> But I didn't set it in /etc/pbuilderrc.
<Logan_> oh, try that then
<Logan_> the manpages know all ð
<LBo> DIST=precise ARCH=i386 backportpackage -b -B pbuilder-dist modsecurity-apache -u ppa:leonbo/servers
<LBo> That was what I tried
<Logan_> I don't think you can set them in the command
<Logan_> because they're not environment variables, per sÃ©
<LBo> I'll try the /etc/pbuilderrc way
<LBo> I've added a static $DIST & $ARCH to my .pbuilderrc
<LBo> I get this message: `E: File /home/leon/pbuilder/precise-base.tgz does not exist`
<LBo> I don't think backportpackage passes the arch to pbuilder-dist
<LBo> I'll have another go at pbuilder plain
* infinity changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Final Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<LBo> Logan_: plan pbuilder works now
<LBo> I have no idea what went wrong when I did that a few hours ago
<Logan_> oh sweet
<LBo> Thanks for the help!
<Logan_> no problem ð
<LBo> For history's sake: this is the command I'm using know (and that seems to be working): ARCH=i386 backportpackage -b -B pbuilder -s trusty -d precise modsecurity-apache -u ppa:leonbo/servers
<doko> barry, stgraber: http://people.canonical.com/~doko/tmp/python3.4.debdiff
<tgm4883> superm1, do we know anything more on that live disk issue?
<maxb> 1ep[1;3D[1;3D[1;3D
<maxb> 11p1
<tgm4883> xnox, I know you said you were going to look at it. I was able to figure out that running ubiquity with sudo resolved the issue, so it looks like a priviledge issue. Not sure why it's failing to get that level of access in the live environment though
<superm1> tgm4883: i haven't figured much more out on it
<tgm4883> ok
<tgm4883> I've had to work on some vmware stuff for work, so I haven't looked at it in the last few hours
<slangasek> tgm4883, superm1: policykit/logind problem?
<superm1> i remember there was one that affected xfce based distros in the past, but i thought xnox fixed that
<xnox> superm1: well, the environment is different. previously all variables were kept - now pkexec is used so all envrionemnt variables are cleared.
<xnox> superm1: thus i band-aid in a few things (e.g. GTK_MODULES=overlay-scrollbar to get ubuntu scrollbars, etc.)
<xnox> tgm4883: thanks for the hint.
<tgm4883> xnox, yw, just doing what I can in between things at work
<superm1> the page is really simple page, just a few checkboxes, so I wouldn't expect it to be missing an environment variable to affect it, but maybe i'm nieve
<tgm4883> heading home now, ping me if you need somehting
#ubuntu-devel 2014-04-11
<xnox> superm1: i have a simple reproducer.... it's pointing at a gtk regression =)))
<hyperair> RAOF: okay, i found it. turns out it's ccsm > opengl > enable fbc
<RAOF> hyperair: You mean texture compression, or framebuffer object?
<hyperair> RAOF: if that's enabled, compiz blacks out when trying to accomodate to a change in the display configuration
<hyperair> RAOF: texture compression
<RAOF> Huh, fun.
<hyperair> mm
<hyperair> do you see the bug too?
<RAOF> hyperair: Not exactly the same as you; I instead get seizure-provoking 60Hz flicker between a previous mostly-correct frame and black.
<hyperair> ugh
<superm1> xnox: well that's actually great to hear
<superm1> can you share the simple reproducer?  whatever it is about what's happening in that page can probably be switched to something else to avoid hitting this bug in the short term
<superm1> and long term get the GTK bug fixed
<xnox> superm1: yeah, i'm trying to work on it. I think if i tweak/fake environment enough it may just work. bug #1306341
<ubottu> bug 1306341 in mythbuntu-common (Ubuntu) "ubiquity / mythbuntu assertion in gtkrecentmanager.c" [Undecided,New] https://launchpad.net/bugs/1306341
<xnox> superm1: the problematic things appear to be the "filechooser" buttons in tab_remote.ui but i'm checking things further.
<superm1> ah interesting
<xnox> superm1: looking at the glade file vs installer ui -> are the buttons to select configuration file actually used?
<superm1> xnox: they're used in something else that uses the mythbuntu-common package
<xnox> superm1: oh, ok.
<superm1> lemme double check if they can be ripped out though
<xnox> superm1: lemme check if that's the only issue.
<superm1> i'd be surprised if that was the only issue; since taking the services page / plugin out of the picture fixed it, not the remote one
<xnox> superm1: probably the plugins were removed in the wrong order. So nuking myth-services would also nuke myth-remote.
<superm1> ah
<xnox> superm1: since myth-remote is after myth-services.
<xnox> but i'll check that as well.
<superm1> the file chooser dialog was used for configuring a remote custom configuration; that whole thing is littered with bugs, i wouldn't mind just axing it if it fixes this
<superm1> i'll take out the associated code and see
<xnox> superm1: i'm aiming for a one-line fix only =)
<Logan_> xnox: to whom should I talk if I want to become part of ~udd?
<xnox> Logan_: anyone, but why would you want to? all you'll gain is commit access to lp:udd branch and that's it.
<xnox> Logan_: what are you after in terms of permissions/capabilities?
<Logan_> requeue_package.py ð
<Logan_> oh god I really need to turn off this automatic emoji replacement
<xnox> Logan_: start here http://www.canonical.com/careers/all-vacancies ; once you get one of those, we could sort you out access =)
<Logan_> if Canonical offered internships, I'd be all over that
<xnox> Logan_: it's running on a publically inaccessible machine, under an elevated celebrity account to push the branches to launchpad =
<xnox> =/
<Logan_> oh wonderful
<xnox> superm1: mid-air collision!
<xnox> superm1: http://bazaar.launchpad.net/~xnox/mythbuntu/fix-myth-passwords/revision/201
<xnox> superm1: but your way is fine as well. Please land that.
<xnox> superm1: the other bug, i'm fixing in ubiquity by doing this - http://paste.ubuntu.com/7233456/
<superm1> xnox: hah wow talk about funny timing
<xnox> superm1: seconds difference upon push.
<superm1> your way actually scales better for any changes in future
<superm1> i've got a tear out of the filechooser stuff too that appears to resolve things as well
<xnox> superm1: don't.
<xnox> superm1: all works fine with http://paste.ubuntu.com/7233456/ applied to ubiquity
<superm1> ok
<xnox> superm1: i'm landing that for ubiquity.
<xnox> superm1: if you are ok with myth-password change, then i can upload that as well.
<xnox> superm1: trumping your commit.
<superm1> yeah go ahead and upload that
<superm1> can you commit it to ~mythbuntu-dev bzr too?  I think all ~ubuntu-dev is able to
<Mirv> if there's a core-dev awake, we'd need a packaging ack for messaging-app https://ci-train.ubuntu.com/job/landing-015-2-publish/10/artifact/packaging_changes_messaging-app_0.1+14.04.20140410.1-0ubuntu1.diff
<Mirv> (tested + QA signed off)
<Mirv> there's not much to ack though
<xnox> superm1: both ubiquity & mythbuntu-live* packages uploaded. When they get accepted tomorrow, i'll ask for mythbuntu iso respin and i will test it out.
<superm1> xnox: awesome, thanks so much
<xnox> superm1: no problem, the HOME fix should actually also resolve a few things across the board - e.g. pango, dconf etc complaining. none of them were fatal so far...
<xnox> superm1: so I'm happy about it. Still - why gtk decides to assert is beyond me.
<pitti> Good morning
<pitti> barry: :(
<pitti> infinity: mmmmm, "final release of Saucy Salamander in a week." :)
<pitti> ah, and the followup mail :)
<pitti> barry: but thomi landed the AP branch to drop the deps
 * hyperair wonders where the zsh manpages are..
<StevenK> hyperair: Replaced by info pages, as far as I can see.
<hyperair> really?
<hyperair> i thought they used to be there together with the info pages
<hyperair> in fact, zsh-common still has a dangling zsh5 manpage link
<hyperair> symlink*
<hyperair> also...
<hyperair> hyperair@thinkpwn:~(1)% run-help autoload                                                                                                                                                                                     [ 1:49PM]
<hyperair> autoload is a shell builtin
<hyperair> meh
<hyperair> No manual entry for zshbuiltins
<pitti> infinity: and the langpack fun begins :)
<hyperair> xnox: ping. are the zsh manpages meant to be missing?
<StevenK> hyperair: Are they in the source package?
<hyperair> StevenK: dunno, i'll need to check.
<hyperair> StevenK: but debian has its manpages intact at least
<hyperair> StevenK: okay, for some reason we have a downstream ubuntu patch that disables building of docs
<hyperair> manpages included
<hyperair> and a changelog entry from xnox adding the patch
 * hyperair has no idea why
<StevenK> No bug referenced or anything?
<hyperair> nope
<hyperair> no dep3 headers either
<hyperair> just.. patch.
<StevenK> It's in main, but I seriously doubt it's on the CD, so WTF
 * hyperair shrugs
<hyperair> that's why i pinged
<StevenK> hyperair: It's a good plan, I want to know too.
<slangasek> hyperair: the explanation in the changelog says:
<slangasek>     - Keep using the upstream tarball that contains pre-generated docs as
<slangasek>       yodl is required to build them but the MIR hasn't been approved.
<hyperair> oh blargh
<slangasek> so the docs are assumed to be present in the upstream tarball
<hyperair> i see
 * hyperair didn't spot that entry
<pitti> wgrant: I'm disabling the saucy langpack build cron job now; please feel free to do the same on LP
<Mirv> if http://bazaar.launchpad.net/~timo-jyrinki/ubuntu/trusty/lmms/1.0.0_packaging/revision/45 looks correct (chiefly silencing pkg-has-shlibs-control-file-but-no-actual-shared-libs), then https://code.launchpad.net/~timo-jyrinki/ubuntu/trusty/lmms/1.0.0_packaging/+merge/215131 would be ready
<hyde> I just filed a bug report about patch (possibly duplicate, did not check....), but I wonder if someone here could shed some light on, how can command line argument handling of a program like patch get so broken, that it throws segfault?
<Mirv> but I hesitate with the shlibs, whether it should be there at all or if there should be some manual shlibs file
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1254028
<ubottu> Launchpad bug 1254028 in network-manager (Debian) "[precise] network manager set incorrect /64 prefix from dhcpv6 client" [Unknown,Confirmed]
<LocutusOfBorg1> hi, anybody wants to sponsor this?
<Mirv> mvo: would you have time to give DDTP a health check? ie. syncs from Debian (looks like last in Nov/Dec) + uploads to archive/mirrors (not sure how to check if done recently).
<Mirv> or if there are other people who know the DDTP magic
<caribou> pitti: can I come and bug you about apport for a few minutes ?
<pitti> caribou: just ask :)
<caribou> pitti: PM
<xnox> hyperair: bug #1242108
<ubottu> bug 1242108 in zsh (Ubuntu) "all zsh manpages are missing" [Medium,Triaged] https://launchpad.net/bugs/1242108
<hyperair> xnox: ah, thanks.
<hyperair> oh crap, my launchpad.net session was expired
 * hyperair tries to remember password
<infinity> pitti: The one to -announce was slightly more right, the -release readers get a treat.
<Chipaca> who should I pester about https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1304265 ?
<ubottu> Launchpad bug 1304265 in unity (Ubuntu) "Unity bugs out when changing screen size" [Undecided,New]
<seb128> Chipaca, try asking bregma about it
<Chipaca> seb128: ta, will do
<seb128> yw
<Chipaca> but first i think i'm going to grab me some lunch
<Laney> #ubuntu-unity more generally
<Chipaca> okie doke
<Chipaca> Laney: good point :)
<seb128> the channel is mostly ovetaken by unity8 discussion though, so unity desktop questions might not get a reply, check with bregma if that happens, he's leading the team working on the desktop issues
<doko> pitti, uploaded python3.4. fixed all the new testsuite errors, caused by moving around binary test cases which don't appear in the diff. there is one still failing, which I documented and disabled for now so that the autopkg tests pass
<infinity> mvo_: Since when does apt allow # as a comment char in configs?
<infinity> mvo_: It certainly didn't used to (which makes the aptdaemon change odd)
<cjwatson>   * [ABI break] support '#' in apt.conf and /etc/apt/preferences
<cjwatson>     (closes: #189866)
<cjwatson> apt 0.7.22
<infinity> cjwatson: Oh.  So maybe what I'm thinking of is that aptdaemon's tests failed when we tried to use #, not that apt didn't allow it. :)
<infinity> (I remember we added a config file with # and switched to // because of a failure somewhere)
<infinity> Probably the kernel autoremove stuff.
<apachelogger> any has a clue why kde-runtime is blocked from proposed migration?
<apachelogger> excuses says it's waiting for autopkgtest for libreoffice 1:4.2.3~rc3-0ubuntu2: RUNNING
<apachelogger> although that seems to have failed on a tooling exception
<mvo_> infinity: indeed, the kernelautoremove stuff
<infinity> mvo_: Right.  We switched to // thinking # wasn't supported, but that was probably because of the bug in aptdaemon. ;)
<mvo_> infinity: yeah, that sounds likely :)
<mvo_> infinity: anyway, thats fixed now and the other failures should be fixed too, one real bug in the py3 switching that probably prevernts dpkg from installing single debs, otherwise mostly missing dependencies etc
<ScottK> pitti: Would you please have a look at the latest libreoffice test on i386.  Something seems to have gone horribly wrong in Jenkins.
<DevilsOwn> Hello
<DevilsOwn> I wanted to ask something related to the ubuntu-server boot process
<DevilsOwn> anybody here?
<dobey> DevilsOwn: #ubuntu-server is probably a better place
<dobey> DevilsOwn: and just ask, don't ask to ask
<DevilsOwn> sure!
<bdmurray> mvo_: Do you know what would call "pkexec /usr/lib/update-notifier/package-system-locked"?
<seb128> bdmurray, http://ubuntu-codesearch.surgut.co.uk/search?q=package-system-locked suggests nothing
<bdmurray> seb128: hunh, that's a neat site
<seb128> bdmurray, indeed ;-)
<bdmurray> I'd received and authentication dialog with the message that search returned.
<mvo_> bdmurray: ubuntu-system-service might be
<doko> mvo_, suggestion here from PyCon ... lp: #1306682  can we still do this for trusty?
<ubottu> Launchpad bug 1306682 in command-not-found (Ubuntu) "recommend to use python3 when python is not found" [Undecided,New] https://launchpad.net/bugs/1306682
<jrwren> i don't think python would ever not be found. ubuntu doesn't run without python, does it?
<xnox> jrwren: both python and python3 have been removed from minimal ubuntu core installations a few cycles back.
<jrwren> xnox: good to know. thanks.
<xnox> doko: suggestion here from Greenwich, implement "from __future__ import unicode_str" =)
<doko> ynox: that's backward =)
<jrwren> hahaha, on 12.04 if you try to remove python-minimal, apt sasy "You are about to do something potentially harmful."
<xnox> doko:i think we do have overrides in command-not-found to do such a trick.
<xnox> jrwren: yes, it used to be marked essential, it isn't anymore. I think we did that in saucy or raring.
<jrwren> xnox: understood. I didn't mean to suggest you were wrong. 12.04 is definitely more than a few cycles back.
<jrwren> I just thought it was funny.
<jrwren> I've not seen that messge before.
<rbasak> I don't follow how this would work. "python"..."apt-get install python3!"...ok...<does it>..."python"..."apt-get install python3!"...?
<superm1> xnox: all the pieces look to have landed in the archive, can you respin the ISO now?
<rbasak> http://www.python.org/dev/peps/pep-0394/ is pretty clear that python must mean Python 2.
<rbasak> Well, "should"
<rbasak> doko: ^^?
<xnox> rbasak: it would work like this "did you mean python3 ? for python2 install package python"
<xnox> rbasak: we will not make python symlink to -> python3
<rbasak> xnox: ah. That makes sense :)
<doko> rbasak, we only make aunannounced version updates with ruby =)
<rbasak> doko: yeah I didn't think that you were suggesting changing the symlink. I just wondered how the message would help without causing an infinite loop. xnox's explanation works for me :)
<doko> rbasak, yep, just wanting to point people to the new version
<jhenke> hi, somebody here know why the daily installer from today installed libc* packages in version 2.19-0ubuntu5 while the archive just has 2.19-0ubuntu4?
<infinity> jhenke: Look again?
<infinity>  libc6 | 2.19-0ubuntu5      | trusty           | amd64, arm64, armhf, i386, powerpc, ppc64el
<infinity> jhenke: If "the archive" only has ubuntu4, you're using an out-of-date mirror.
<jhenke> infinity I had it query several time already
<jhenke> never had that before, was by default on mirror for germany
<jhenke> maybe somebody wants to check that?
<infinity> jhenke: Looks like their upstream (ftp.uni-kl.de) hasn't updated for ~8h
<infinity> jhenke: Probably just an temporary problem, but switching from de.archive.ubuntu.com to gb.archive.ubuntu.com for now would fix you up.
<jhenke> well yes I am not to the main mirror for the time being
<jhenke> just want to point out, so somebody might be able to tell the mirrors admin to check the machine
<mvo_> doko: let me check
<infinity> jhenke: Given the heartbleed madness this week, people taking services offline for a few hours here and there isn't something worth bugging them about, to be fair. :P
<infinity> jhenke: (Heck, my local government has shut down half their public-facing services for a good chunk of the week)
<jhenke> hmm, if you say so
<bdmurray> dobey: I feel like the SRU for bug 1306225 could be more informative, like have a hyperlink to the announcement.
<ubottu> bug 1306225 in Ubuntu One Client "The user should be informed about the u1 file service shutdown" [Critical,In progress] https://launchpad.net/bugs/1306225
<xnox> superm1: i don't have powers to respin, can you click the respin buttons on http://iso.qa.ubuntu.com/ ?
<xnox> superm1: or i'll poke ~cdimage people.
<xnox> superm1: i did upgrade in the livecd and tested and that worked fine.
<Laney> I don't think mythbuntu has that set up
<Laney> superm1: xnox: you want one?
<xnox> Laney: yeah i want mythbuntu i386 and amd64 respin.
<Laney> ok
<Laney> there
<xnox> Laney: ta!
<dobey> bdmurray: a link where? you're welcome to discuss it with beuno and others. i didn't make the patch, i'm just doing the packaging for it
<beuno> dobey, to the blog post?
<beuno> that seems to be what bdmurray is implying, which sounds sane
<dobey> yes, i was asking where in the UI
<dobey> ubuntuone-client has no UI, and links in notifications is not a nice thing
<bdmurray> beuno: right, there is no easy way for people to find out why or get more information.
<xnox> dobey: beuno: i presume the control panel shows "error syncing" maybe that could show a better message after 1st of june e.g.  "these services are no longer offered"
<xnox> ditto indicator-sync and/or cmd line utilities / logs that generated for syncing.
<dobey> xnox: i'd prefer to just not do anything
<dobey> bdmurray: well we've already e-mailed every user we have
<xnox> dobey: fair enough =) if people ignore planet, blogs, news sites, emails they recieved and refunds..... it's really their own fault by 1st of june ;-)
<dobey> xnox: well then they can figure it out and go to the web site and download a zip of all their data or something
<bdmurray> dobey: I think emails are easily missed, I don't recall receiving one and its not much work to point to the blog announcement is it?
<beuno> bdmurray, emails are still going out
<dobey> bdmurray: it depends
<dobey> bdmurray: and we couldn't do it in ubuntuone-client really, we'd have to put it somewhere there is actual UI
<rohan> hi: can someone familiar with xorg tell me if this bug needs any more info?
<rohan> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1282867
<ubottu> Launchpad bug 1282867 in linux (Ubuntu) "Many bugs in rendering with lockups, likely caused by SNA" [High,Confirmed]
<rohan> it is a pretty serious bug affecting intel GPUs on trusty
<dobey> yeah, don't file one bug that has a title of "many bugs" and don't say "likely caused by"
<dobey> assumptions aren't helpful
<rohan> dobey: and that was helpful how?
<rohan> did you even bother looking at the bugs, and the logs provided?
<rohan> and "many bugs" refer to graphical glitches, not launchpad bugs.
<dobey> no, because i'm not an intel driver developer, and the summary is not helpful to me even if i was
<dobey> you asked for help, i gave you some helpful advice; if you don't like it, don't complain about it
<rohan> sorry, but how is the summary not helpful?
<dobey> you're free to ignore if you wish
<rohan> no, you crticised without giving any constructive advice.
<dobey> as i said, it says "many bugs" and it is making an assumption about the cause
<rohan> the summary has the dmesg log outputs, and the corresponding driver and package versions
<dobey> whatever
<rohan> if i can do something to improve it, let me know, otherwise you are the one making assumptions :)
<rohan> also, my assumption was not stupid: disabling SNA actually fixed the problem, so it *is* likely caused by SNA
<dobey> sigh
<dobey> i didn't say it was stupid
<dobey> i said it was an assumption
<dobey> and i don't have time to have a stupid argument about that with you
<rohan> dobey: well then, you needn't have bothered looking at it and giving unconstructive suggestions, right?
<rohan> dobey: in the spirit that you're a developer and probably know more than me, i've updated the title of the bug.
<pitti> doko: yay, thanks
<pitti> ScottK: seems it's back to normal, jibel kicked it
<pitti> ScottK: and yes, jenkins is acting up a lot recently, mostly due to the unreliable ppc64el boxes; I'm working on a replacement system to avoid jenkins entirely :)
<ScottK> pitti: Thanks.  I overrode it so we weren't blocked, but it's good to know it's working again.
<pitti> ScottK: yep, https://jenkins.qa.ubuntu.com/job/trusty-adt-libreoffice/333/ is the latest
<pitti> 334 is currently running
<pitti> infinity, smoser: can you please kick wolfe-05? ssh takes ages, and sudo reboot is just stuck; I guess the zero-page memory corruption bug wreaked enough havoc
<pitti> I'd like to reboot, dist-upgrade, refresh the container, and put it back on jenkins duty
<infinity> pitti: Lemme have a look.
<infinity> pitti: 5, you say?
<infinity> pitti: Should be back.
<smoser> thanks infinity .
<smoser> pitti, did you want an entirely clean system ?
<jtaylor> cjwatson: broken grub-probe with lvm snapshots should probably go into the release notes for 14.04
<jtaylor> disabling the os-prober is probably a reasonable workaround for isntallation/upgrade
<jtaylor> I had a short look at why it breaks, but this issue is over my head :/
<cjwatson> jtaylor: I uploaded the fix today ...
<jtaylor> oh
<cjwatson> analysis in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1287436
<jtaylor> I just tried it, though maybe I did apt-get upgrade to early
<ubottu> Launchpad bug 1287436 in grub2 (Ubuntu) "grub-probe fails in the presence of snapshot logical volumes" [Undecided,Fix released]
<jtaylor> ah my mirror hasn't got it yet
<jtaylor> thanks
<jtaylor> I'll test it when its available
<cjwatson> Thanks.  I tested in a Xen guest with unstable
<jtaylor> its pretty easy to reproduce if you are using lvm, just create a snapshot and do update-grub2
<cjwatson> It wasn't obvious - first two or three guesses as to the cause turned out to be entirely wrong when I actually compared against 2.00's behaviour in detail
<cjwatson> Right, that's what I did
<cjwatson> 2.00's grub-probe actually didn't understand snapshots properly either, it's just that grub-mkconfig didn't fail in that situation
<cjwatson> I was initially confused because it worked with upstream 2.00, but that's because an entirely different bug in grub-mount (patched in my packaging) masked it
<bdrung> xnox: can you update app-install-data-ubuntu again for picking up the fixed sonic-visualiser (bug #1161283)?
<ubottu> bug 1161283 in sonic-visualiser (Ubuntu) "Problems reported with .desktop files for sonic-visualiser" [Medium,Fix released] https://launchpad.net/bugs/1161283
<bulletxt> thanks for updating cups 1.7.2 in ubuntu 14.04
<darkxst> can somebody upload bug 1300464 for me? it was ok'ed by infinity and cjwatson in -release
<ubottu> bug 1300464 in ubiquity-slideshow-ubuntu (Ubuntu) "Ubuntu GNOME Trusty Slides Update" [Undecided,Confirmed] https://launchpad.net/bugs/1300464
#ubuntu-devel 2014-04-12
<int_ua> http://developer.ubuntu.com/get-started/gomobile/ link is down
<int_ua> on http://design.ubuntu.com/apps
<tjaalton> is there a way to avoid changing the indicator menu theme when kubuntu-desktop is installed on ubuntu?
<tjaalton> text is black, and icons changed
<TBombadil> what's needed to get LP #1306813 fixed for trusty?
<ubottu> Launchpad bug 1306813 in libgwenhywfar (Ubuntu) "crash because double free in GWEN_Gui_free " [Undecided,Confirmed] https://launchpad.net/bugs/1306813
<TBombadil> best would be if libgwenhywfar could get synced with Debian, but I doubt this is feasible given the archive is already in Final Freeze...
<DanielConvissor> hi.  quick question about a bug or design decision.  been using ubuntu for about five years.  i'm now installing 14.04 to a new box via usb stick (downloaded trusty-desktop-amd64.iso from daily-live a couple nights ago).  using the manual partitioner, i set up /boot (primary), swap (primary), / (primary), /home (logical), then when I go to use the rest of the drive for an encrypted partition, a dialog comes up
<DanielConvissor> saying "an unsafe swap space has been detected".  so the question is... could the installer do the right thing and set up cryptswap, or something?  or do I, once again, not know what i'm talking about?
<rbasak> I'm not sure it's right for the installer to second guess you if you're using manual partitioning. If I understand what you're saying.
<rbasak> You have, by definition, told it that you will specify exactly what you want.
<DanielConvissor> that's one way to look at it. :)
<DanielConvissor> but there's no option to use cryptswap
<rbasak> I'm not sure about that side of things then, sorry. I know that it works if you do it by hand (I use it).
<rbasak> I think you might also be able to create an LVM partition and put an encrypted swap in there.
<rbasak> I've also heard noises about swapfiles being just as performant nowadays.
<rbasak> HTH
<DanielConvissor> wondering why the installer doesn't use cryptswap for all swap
<pitti> infinity, smoser: thanks! I upgraded wolfe-05 now and refreshed the container, sending it back to the salt mines :)
<pitti> smoser: nope, a simple reboot was enough
<DanielConvissor> will look into lvm
<pitti> infinity: will we flush trusty-proposed right after the release? there's an awful lot of cruft in it which will interfere with SRUs, and at least be confusing
<DanielConvissor> (n.b.:  manual partitioner doesn't provide lvm as an option)
<DanielConvissor> or maybe the installer is kvetching that the usb stick doesn't have encrypted swap?
<DanielConvissor> (i burned the iso to the stick directly via dd)
<DanielConvissor> if that matters
<DanielConvissor> may as well download the new daily-live iso, now that the final beta is out...
<kdeuser56> I am getting a bunch of errors for -dbgsym packages on fully updated trusty:
<kdeuser56> libkmediaplayer4-dbgsym : Depends: libkmediaplayer4 (= 4:4.13.0-0ubuntu1) but 4:4.12.97-0ubuntu1 is to be installed
<infinity> pitti: As with previous releases, anything in t-proposed that isn't meant to be an SRU will be copied to u-proposed and deleted from t-proposed.
<infinity> hallyn: No qemu 2.0rc2 for us?  It's been out for 4 days!
<infinity> hallyn: Or were you still hoping 2.0final would happen this weekend? :)
<infinity> hallyn: (If it does, please file an FFe and upload at the same time, if we choose to reject or delay it to an SRU, fine, but at least we'll have the choice and the upload in the queue to review)
<dupingping> Hi developers.
<dupingping> Do you know an error occurred in compiz?
<dupingping> compiz cascade mode is downed.
<dupingping> when i create 32 gnome-terminals as almost at the time.
<TJ-> dupingping: Please see https://help.ubuntu.com/community/ReportingBugs
<dupingping> Oh, I see.
<crawler2014> hi folks, while trying to build VDR from source I stumbled about a nasty problem with my packages:
<crawler2014> I've got a problem installing stuff because of libc6-dev-amd64_2.17-93ubuntu4_i386
<crawler2014> it blocks my complete software management, can't be fixed by -f install
<crawler2014> could anybody help me with this ?
<crawler2014> I really DON'T want to do a complete reinstall
<doko> cjwatson, congrats!
#ubuntu-devel 2014-04-13
<Carbon14> [05:05] <Carbon14> whats the difference beetwen ubuntu-touch and ubuntu-touch-preview [05:05] <Carbon14> can someone help me please
<carbon14__> shats the diferance btween ubuntu touch and ubuntu touch preview?
<voldyman> hey guys, there is this small bug in most of the indicators, https://bugs.launchpad.net/indicator-session/+bug/1301699
<voldyman> the fix branch has been approved but not merged, can someone please merge them?
<ubottu> Launchpad bug 1301699 in elementary OS "Indicators do not show in Pantheon" [Medium,In progress]
<xnox> carbon14__: preview was the old release based on quantal/raring. ubuntu touch is more recent developments.
<xnox> carbon14__: but one should use system-image updates anyway from http://system-image.ubuntu.com/ubuntu-touch/
<kdeuser56> ist http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ the initial version of linux 3.15?
<kdeuser56> i guess this is just a branch of 3.14 as the version number suggests
<kdeuser56> ah damn, I am an idiot, nevermind
<kdeuser56> sorry for the stupid question, but am I right that https://github.com/torvalds/linux contains all changes that will land in 3.15?
#ubuntu-devel 2015-04-06
<hjd> I stumbled across something strange here the other day: https://launchpad.net/ubuntu/+source/crawl shows that version 2:0.15.1-1 is packaged in Vivid.
<hjd> Looking at the code page (https://code.launchpad.net/ubuntu/+source/crawl), I can see that the branch for Vivid was last updated 2014-10-26. Which shortly after the version was packaged, makes sense so far.
<hjd> However, the actual commits in the branch doesn't seem to have updated since 2009 (https://code.launchpad.net/~ubuntu-branches/ubuntu/vivid/crawl/vivid). The latest commits are Ubuntu-specific, so it might not been updated when the package was synced from Debian. Anyone seen something similar, or know what's happened here?
<maxb> The automatic archive upload -> bazaar branch import tool never really reached the level of code maturity where it wouldn't break in a number of situations
<maxb> I imagine that's what's happened here
<maxb> http://package-import.ubuntu.com/status/crawl.html
<maxb> yeah
<maxb> Unfortunately there's no-one really working on the project right now, and given the uncertainty about the future of Bazaar, there probably never will be (IMO)
<hjd> maxb: Ah, ok. Thanks for digging up the underlying issue. :)
<cyphermox> good morning!
<infinity> xnox: What's your carefactor WRT upstart and its test suite?
<georg1982> hi, I am currently trying to use a nexus 5 as embedded device and installed ubuntu phone to ut
<georg1982> unfortunately root partition is too small (2GB)
<georg1982> how can I increase it?
#ubuntu-devel 2015-04-07
<psusi> cyphermox, I'm looking for someone other than cjwatson to pester about this and you seem to have done some work on ubiquity lately... could you have a look at bug #1418706?  It seems to be a very nasty bug in how ubiquity is executing the partman scripts and seems to me to be rather release critical, with 15.04 coming up fast... I suspect the underlying bug will cause many serious problems other than the one named in the bug.
<ubottu> bug 1418706 in ubiquity (Ubuntu) "Vivid: UEFI: blank drive incorrectly detected as existing BIOS-mode install" [Critical,Triaged] https://launchpad.net/bugs/1418706
<infinity> psusi: I think I already heaped that on his TODO over the weekend.
<psusi> hehe... ok, good, as long as it gets taken care of before release... I just get nervous that something this serious will be released ;)
<cyphermox> psusi: I'm already aware of it, and that's what I was looking at when you pinged
<psusi> whoohoo ;)
<cyphermox> it's kind of suspicious
<psusi> I'm available if you have any questions about it ;)
<cyphermox> but I need to setup my qemu to boot with EFI
<psusi> already did some preliminary tracing, just don't have the familiarity with ubiquity or the time to fix it myself... been real busy lately with my day job... damn FDA and silly MISRA requirements...
<psusi> here's the command I used to reproduce it: sudo qemu-system-x86_64 -enable-kvm -drive if=ide,file=/home/psusi/Music/isos/vivid-desktop-amd64.iso,media=cdrom -drive if=ide,file=/dev/faldara/test -vga std -m 1024
<cyphermox> thanks, that's helpful
<psusi> sorry, that was bios mode... make it this one: sudo qemu-system-x86_64 -enable-kvm -bios /usr/share/qemu/OVMF.fd -drive if=ide,file=/home/psusi/Music/isos/vivid-desktop-amd64.iso,media=cdrom -drive if=ide,file=/dev/faldara/test -vga std -m 1024
<psusi> after installing the ovmf package of course
<infinity> Yeah, I was going to mention the lack of '-bios /usr/share/qemu/OVMF.fd' on that first line.
<cyphermox> I already know the details for EFI bios :)
<psusi> kk ;)
<psusi> I looked over the partman logs and added a few set -x's and found that the visual.d script from partman-efi was actually creating the new partition prior to running the init.d scripts, which then detected the new, unformatted partition as an existing bios mode install.. the scripts are NOT supposed to be run in that order
<psusi> then of course, even when the condition is detected and the prompt displayed, ubiquity needs to wait for the reply instead of proceeding to the next task and leaving the prompt window orphaned/hung
<psusi> hrm... that reminds me... maybe a topic we might discuss at the next uds: debian now has support for running d-i under Xwin for a graphical install.. this may be a good replacement for ubiquity entirely?
<infinity> psusi: Using live-installer instead of base-installer, perhaps, but it would need some (a lot of) tweaking.
<infinity> psusi: Plus, ubiquity also doubles as oem-config, which bare d-i doesn't have an equivalent for.
<infinity> psusi: So, while convergence of the installers would be nice, it's non-trivial.
<psusi> ahh, didn't know about oem-config... yea.. convergence would be really nice ;)
<psusi> especially given some of the long standing and unfixed bugs in ubiquity, such as the fact that whenever grub-install fails, and you get the dialog box asking to pick an alternate location to install it to, any subsequent tries are doomed to failure because /proc, /sys, and /dev have already been unmounted from /target
<psusi> and the lack of raid support in ubiquity
<psusi> and the lvm support is really sad
<cyphermox> psusi: if you have a list of the bugs you feel are important, I can add them to some form of a todo list for me to get to eventually
<psusi> probably a good foundation for a discussion on whether to proceed with fixing those bugs, or converge with debian and abandon ubiquity instead.
 * psusi misses having beer time at face to face UDS
<psusi> anyone remember when it was called espesso instead of ubiquity?  Christ, how the years do go by...
<pitti> Good morning
<Unit193> Howdy.
<pitti> infinity: did you already talk to mbiebl about http://paste.ubuntu.com/10752817/ ? (I'd rather have his consensus for uploads to jessie)
<Mirv> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv
<LocutusOfBorg1> good morning developers
<seb128> hey LocutusOfBorg1
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv, Laney
<zyga> good morning
<zyga> vivid still prefers wifi over ethernet today
<mgedmin> very modern
<flexiondotorg> didrocks, Do you have a moment to help clear to fog in my mind regarding - https://bugs.launchpad.net/ubuntu-mate/+bug/1439388
<ubottu> Launchpad bug 1439388 in mate-tweak (Ubuntu) "Updated translations for mate-tweak [debdiff attached]" [Low,Incomplete]
<didrocks> flexiondotorg: what fog? did you try to apply the patch yourself?
<flexiondotorg> didrocks, I don't understand the remark about translators.txt not being in the patch. translators.txt is the output from a utility script and not intended for packaging. This is why it is missing from the debdiff.
<didrocks> not sure how you generated your patch, but it wasn't against upstream ones
<didrocks> flexiondotorg: it's in the pathc
<didrocks> diff -Nru mate-tweak-3.4.6/translators.txt mate-tweak-3.4.7/translators.txt
<didrocks> --- mate-tweak-3.4.6/translators.txt2015-03-10 19:29:50.000000000 +0000
<didrocks> +++ mate-tweak-3.4.7/translators.txt2015-04-01 21:01:28.000000000 +0100
<didrocks> flexiondotorg: open it and look :p
<flexiondotorg> I used dget -u -x to grab the existing package from Ubuntu. I created a new package locally and ran debdiff.
<didrocks> flexiondotorg: seems you didn't do that with the upstream tarball you provided, see my remark about the diffs
<didrocks> I took the time to list them all on purpose
<flexiondotorg> didrocks, Right. No idea how translators.* got in there. I'll re-create the diff.
<didrocks> flexiondotorg: translators isn't the only one to be wrong
<didrocks> flexiondotorg: so yeah, please always double check :p
<didrocks> flexiondotorg: once you have your debdiff, you need to:
<didrocks> dpkg-source -x <old_package>
<didrocks> wget your tarball, mv tarball_version.orig.tar.gz
<didrocks> cd old_package_dir/
<didrocks> patch -p1 < /path/to/your/debdiff
<didrocks> debuild -S
<didrocks> and that should succeed
<didrocks> if not, you did something wrong in the generation
<Mirv> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<flexiondotorg> didrocks, Thanks for the explanation. Very helpful.
<didrocks> flexiondotorg: yw ;)
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Laney> fail... retry later :(
<Odd_Bloke> I'm seeing failures of the CPC image builds on the buildds because cpio is missing; does anyone have any insight in to this issue?
<Odd_Bloke> mvo: ogra_: ^ ?
<ogra_> Odd_Bloke, i saw a fix for that uploaded somewhere
<ogra_> i think slangasek did it
<Odd_Bloke> ogra_: We're still seeing the failures at the moment; was the fix in livecd-rootfs, or somewhere else?
<ogra_> Odd_Bloke, https://launchpad.net/ubuntu/+source/live-build/3.0~a57-1ubuntu16
<Odd_Bloke> Ah, yeah, just got there.
<Odd_Bloke> Urgh, looks like we have a version of live-build lying around in our PPA; that'll be the problem.
<ogra_> hah, yeah
<tseliot> Riddell: switching between GPUs won't work in sddm, as it doesn't restart X on log out. So, for now, you might just want to add an entry with the DisplayCommand line in sddm.conf. No further patches are needed. Just make sure that /etc/X11/default-display-manager comes with sddm. I'll simply update gpu-manager not to exit when dealing with sddm
<pitti> hey tseliot, happy birthday!
<ogra_> oh !
<ogra_> happy birthday tseliot !
<tseliot> pitti, ogra_: thanks :)
<flexiondotorg> didrocks, Could you give this a once over and let me know if this suitable? https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1439380/comments/5
<ubottu> Launchpad bug 1439380 in mate-menu (Ubuntu) "Updated translations for mate-menu [debdiff attached]" [Low,Incomplete]
<flexiondotorg> didrocks, Test the patch applies cleanly and if this is suitable I'll prepare the other patch in the same fashion.
<flexiondotorg> didrocks, *I've tested the patch applies cleanly
<didrocks> flexiondotorg: please check with the patch pilot first rathe than direct ping :)
<didrocks> rather*
<flexiondotorg> didrocks, OK
 * flexiondotorg waits for a pilot.
<shadeslayer> mvo: any news on the rootfs for Kubuntu Plasma 5?
<Odd_Bloke> mvo: Any idea who I can poke to get a live-build patch looked at?  (Specifically https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1411310)
<ubottu> Launchpad bug 1411310 in live-build (Ubuntu) "[PATCH] Enable tuning of EXT images produced by lb_binary_rootfs" [Undecided,New]
<flexiondotorg> didrocks, I know you said not to ping directly. Sorry. But I've hit a snag. Need some advice, because I'm guessing this is something that has been seen before.
<flexiondotorg> https://launchpad.net/ubuntu/+source/mate-tweak/
<flexiondotorg> Has a patch accepted into the Ubuntu package.
<flexiondotorg> That patch was never shared with upstream (me).
<flexiondotorg> I have incorporated the fix upstream and have a new upstream tarball.
<flexiondotorg> But creating a debdiff between 3.4.6-0ubuntu2 and the new 3.4.8-0ubuntu1 results in a rejection.
<didrocks> hum? what rejection?
<flexiondotorg> One sec...
<didrocks> you need to remove the patch
<didrocks> after unapplying it
<flexiondotorg> didrocks, I have.
<didrocks> quilt pop -a
<didrocks> rm debian/patches/<your_patch>
<flexiondotorg> Oh, this is new information :)
<didrocks> vim debian/patches/series -> remove your patch
<flexiondotorg> didrocks, I don't have any patches. The patch has only ever existed in Ubuntu.
<didrocks> 13:53:48  flexiondotorg | Has a patch accepted into the Ubuntu package.
<didrocks> this contradicts yourself? ^
<flexiondotorg> didrocks, The patch was accepted into Ubuntu. Yes. I didn't not submit it.
<flexiondotorg> didrocks, The 'debian' packaging for mate-tweak is maintained in alioth
<didrocks> double negation "didn't not submit" -> you did submit?
<flexiondotorg> I did not submit the patch to Ubuntu.
<didrocks> flexiondotorg: I still don't get what you mean at all, if the patch wasn't in the ubuntu package, why talking about it?
<didrocks> and how would it interfere in your update?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-tweak/+bug/1433562
<ubottu> Launchpad bug 1433562 in mate-tweak (Ubuntu) "Translations are not reflected" [Undecided,Fix released]
<didrocks> so
<didrocks>   * debian/patches/translationfix.patch: added for fixing a wrong path.
<didrocks>     (LP: #1433562)
<didrocks> you did add the patch
<didrocks> right?
<flexiondotorg> No.
<flexiondotorg> I only saw that bug after it had been uploaded.
<didrocks> http://launchpadlibrarian.net/201198800/mate-tweak_3.4.6-0ubuntu1_3.4.6-0ubuntu2.diff.gz
<didrocks> -> the patch is in the package
<didrocks> so ubuntu has this patch
<didrocks> hence, follow what I told above to remove it, before updating ^
<Odd_Bloke> mvo: (I just resubmitted our livecd-rootfs MP as well)
<flexiondotorg> didrocks, OK. I will follow what you've explained. Thank for helping.
<flexiondotorg> didrocks, One last question though.
<flexiondotorg> didrocks, I am maintaining the package in Debian and, in general, syncing to Ubuntu.
<flexiondotorg> didrocks, Would a syncrequest from Debian (where that Ubuntu patch has never existed) still work?
<didrocks> flexiondotorg: sure, just justify why the diff between Debian and Ubuntu can be dropped in the bug report, and we can override the sync request with it
<flexiondotorg> didrocks, I'm not going to sync on this occasion. I think it is important I learn all these techniques.
<flexiondotorg> didrocks, Also forgive my typos. I have a badly mashed right hand and sometime my text prediction is a little off.
<didrocks> flexiondotorg: ah ok, so when you sync request, there is a process to read: https://wiki.ubuntu.com/SyncRequestProcess
<didrocks> heh, no worry :)
<flexiondotorg> didrocks, I'm familiar with the syncrequest process. I've used it quite extensively :)
<didrocks> flexiondotorg: see the lines about the diff between Ubuntu and Debian
<didrocks> or reread them rather :)
<flexiondotorg> didrocks, Will do :)
<flexiondotorg> didrocks, I've got this this - dpkg-source: info: you can integrate the local changes with dpkg-source --commit
<flexiondotorg> didrocks, I'm clearly missing a step here.
<flexiondotorg> didrocks, http://paste.ubuntu.com/10761683/
<flexiondotorg> What next?
<cyphermox> good morning!
<mdeslaur> hi cyphermox!
<didrocks> flexiondotorg: well, then, update your package with uupdate as you usually do
<wuzhongcheng> i need help
<wuzhongcheng> i"m a chinese
<wuzhongcheng> now i use puppy 5.7.1
<wuzhongcheng> i like ubuntu
<flexiondotorg> didrocks, I've never had to use uupdate before. I have just used it yet I am still in the position where I have rejections :(
<wuzhongcheng> hoe do you do
<wuzhongcheng> how do you do
<infinity> pitti: I'd had a long discussion with him on IRC about it, and he was on CC in my response to you afterward and didn't object to the "belt and bracers" approach of implementing both options, but it never hurts to ask again, I suppose.
<wuzhongcheng> :)
<wuzhongcheng> :)
<wuzhongcheng> sorry my english is bad
<didrocks> flexiondotorg: seems you need to read some packaging documentation :)
<flexiondotorg> didrocks, Well, I am doing :)
<flexiondotorg> didrocks, But I have rebuilt the debdiff about 4 different ways now and end up at the same place.
<rbasak> hallyn: https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1439988
<ubottu> Launchpad bug 1439988 in init-system-helpers (Ubuntu) "package init-system-helpers 1.22ubuntu4 failed to install/upgrade: trying to overwrite '/lib/init/apparmor-profile-load', which is also in package upstart-bin 1.13.2-0ubuntu9" [High,Confirmed]
<rbasak> hallyn: this was my mistake that you spotted - s/upstart/upstart-bin/ needed in Breaks/Replaces.
<rbasak> hallyn: I guess I'll just upload this fixed?
<dobey> wuzhongcheng: i think you are looking for #ubuntu as itis the general help channel
<hallyn> rbasak: oh?  but after i had said that i checked the pkg again and it actually was coming from upstart, not upstart-bin
<dobey> wuzhongcheng: i think there might be another channel for kylin too
<hallyn> rbasak: hm.  maybe i looked at the upstart version when i was doing that
<hallyn> rbasak: yes, please do, thx
<hallyn> grrr
<hallyn> s/upstart/utopic/
<hallyn> !4:s/upstart/utopic
<rbasak> hallyn: no, I think you were right.
<rbasak> So I'm confused now. I see it present in upstart_1.13.2-0ubuntu10_amd64.deb
 * rbasak checks 9
<hallyn> rbasak: changelog says it got moved, but maybe the changelog lied?
<rbasak> hallyn: I also see it in upstart_1.13.2-0ubuntu9_amd64.deb but also in upstart-bin_1.13.2-0ubuntu9_amd64.deb.
<rbasak> Only in upstart in ubuntu10.
<hallyn> weird
<rbasak> Easiest to just declare Breaks/Replaces against both in ubuntu10 I guess.
<hallyn> bc debian/upstart.install:debian/apparmor-profile-load lib/init/
<hallyn> yeah
<rbasak> I'll do it.
<hallyn> you'd think ppl would have gotten conflicts between upstart and upstart-bin then
<hallyn> rbasak: upstart-bin seems to be an empty package though, and depends on upstart.
<rbasak> Indeed. I don't see B/R across ubuntu9 upstart and upstart-bin that is relevant. Yeah - upstart-bin is an empty package now, but it wasn't in ubuntu9.
<hallyn> ok so b/r both is safest.  thanks
<rbasak> Anyway, I'll just fix it in init-system-helpers and not worry about the upstart side of things. That would be a separate temporary bug that is gone now.
<hallyn> right - again surprised there were no upgrade bugs due to that
<infinity> pitti: To be fair, when talking to him about it, he said he didn't want to do anything without your opinion.  You're like two parents who are never home at the same time. :P
<infinity> rbasak: You're seeing things, it wasn't in upstart_1.13.2-0ubuntu9_amd64.deb
<rbasak> infinity: now I look again and you're right.
<rbasak> The fix I uploaded should still be good. I presume having a slightly higher than necessary version for one of the Breaks/Replaces shouldn't matter.
<infinity> rbasak: Yeah, it'll be fine.  If LP ever gives me a diff.
 * infinity downloads it from the queue instead.
<infinity> rbasak: Minor complaint that (<= 1.13.2-0ubuntu10) is more safely written as (<< 1.13.2-0ubuntu11) in case people are building derivative packages from ours.
<infinity> rbasak: But since upstart has moved on to -0ubuntu12 since then, and it's unlikely anyone picked that day to fork, the point's probably moot.
<rbasak> infinity: point taken, thanks.
 * rbasak will amend his ways
<hallyn> 15:31 < infinity> rbasak: Minor complaint that (<= 1.13.2-0ubuntu10) is more safely written as (<< 1.13.2-0ubuntu11) in case people are building derivative packages from ours.
<hallyn> ah.  i've been looking for reasons to go one way or th eother
<hallyn> that makes sense
<infinity> hallyn: It's not exactly foolproof, as someone could build a 1.13.2-0ubuntu10billy02 that cherrypicks our changes from 11, but it's statistically safer to assume they didn't.
<infinity> hallyn: (much like it's statistically safer to assume 1.2.3-3ubuntu1 is similar to 1.2.3-3)
<rbasak> Also if they're going to cherry-pick changes from the future then they should get to keep the pieces when it breaks (since nobody else can).
<rbasak> cf. it makes sense to make things work by default when there are no related changes
 * infinity nods.
<pitti> infinity: haha; sounds good then :)
<hallyn> well, yeah, i am also inconsistent about whether i do 1.13.2-2test1 or 1.13.2-3~test1
<hallyn> but both are << 1.13.2-3, so taht's ok
<hallyn> i guess
<infinity> hallyn: Right.
<rbasak> 1.13.2-3~test1 is useful before 1.13.2-3 is published if you want 1.13.2-3~test1 to eventually upgrade to 13.2-3.
<rbasak> Say I'm testing something before upload in a PPA for example.
<infinity> Both upgrade, though.  So, meh.
<rbasak> Oh. -*2*. I see.
<pitti> infinity: so that change is in vivid-proposed now, FTR
<pitti> infinity: I'm just not sure whether we should squeeze it into jessie still
<infinity> My personal non-concrete rule for such things is "-2test1" is for a package that is "-2 with a quick patch on top" and "-3~test1" is "the package that will eventually be -3, but not quite ready yet".
<infinity> pitti: Well, I intend to file an unblock for the sysvinit upload I did to jessie, unblocking both together would make sense.
<hallyn> heh, logical
<infinity> pitti: It doesn't catch a lot of extra cases, but it still catches some different cases, so feels reasonable.
<pitti> infinity: ack
<infinity> pitti: I still would prefer doing it "right" in C, but at least this is provably non-invasive.
<Anupkumar> pitti: ping
<infinity> pitti: Oh, and I see you (hopefully) fixed your racy tests.  \o/
<mitya57> cyphermox, hi, can you please take a look at https://code.launchpad.net/~mitya57/network-manager-applet/lp1440009/+merge/255224 ?
<mitya57> I understand that it is an ugly hack, but it will be only for this cycle â the patch to solve it properly on our side is quite large to apply it during the final freeze.
<cyphermox> isn't there a way to integrate this better into the shell test?
 * mitya57 looks
<rbasak> pitti: could you respond to https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1436691/comments/19 please? I take it this isn't an issue as the manifest file doesn't reflect what will actually get installed?
<ubottu> Launchpad bug 1436691 in upstart (Ubuntu) "Essential files are missing" [High,Confirmed]
<rbasak> pitti: the only issues I've seen are on systems I suspect didn't use the normal installer path, which is why I asked for apport-collect. But I don't think that's the case here. It might just be that the user has a heavily customised system.
<infinity> rbasak: An upgrade should be pulling in systemd-sysv.  If that's not true for ubuntu-gnome, we've messed up somehow.
<rbasak> infinity: I don't think we're seeing enough bug reports for that to be the case. The few we're getting are I think users who have heavily modified their systems in some way, where we can't really expect to support the upgrade path.
<rbasak> I just want to get the bugs resolved and invalidated where appropriate.
<mitya57> cyphermox: Currently nm_shell_watcher thinks that if ShellVersion is not present, then it is gnome-shell but it is not properly initialized. I don't think I want to break that behaviour.
<infinity> Right, so #1436956 is clearly a non-standard install, but the sort we were afraid of...
<mitya57> cyphermox, So checking the XDG_CURRENT_DESKTOP is the easiest temporary solution.
<cyphermox> fair enough
<infinity> pitti: What was the reason we decided not to make init Essential, like Debian did?
<cyphermox> mitya57: can you upload or do you need sponsoring?
<mitya57> I can upload if you ack it
<infinity> pitti: It does seem to be biting people on upgrades without -minimal installed, as we feared would be the case.
<cyphermox> mitya57: just did :)
<mitya57> Thanks!
<pitti> Anupkumar: hello
<infinity> rbasak: I dunno, I might be in the minority, but I still see this as a real bug.  We can jump up and down and say "we don't support systems without ubuntu-minimal installed" all we want, but that doesn't make their upgrades less broken.
<infinity> pitti: ^
<pitti> rbasak, infinity: "init" should be essential, and pull in either systemd-sysv or upstart-sysv
<pitti> ah no, it's "required"
<infinity> pitti: Okay, so we just messed up and forgot to mark it Essential?
<pitti> maybe for schroots or so, where neither is required; xnox?
<infinity> pitti: Sure, neither is actually required in a chroot, but a tiny bit of chroot bloat to make upgrades actually work is a small price to pay (my Debian chroots have init installed).
<pitti> infinity: yes, I'm fine with making it essential
<pitti> +    - init: Drop Essential:yes, in Ubuntu upstart is not essential.
<pitti> was the changelog entry
<pitti> infinity: fixing race conditions> apparently not hard enough, argh
<infinity> pitti: D'oh.
<infinity> pitti: Alright, let's try making it Essential again and see if that blows up any of our carefully-orchestrated ubuntu/ubuntu-touch madness.
<infinity> It shouldn't, since we never remove "init", only swap its deps.
<pitti> infinity: right
<infinity> pitti: I'll toss that upload at the archive.
<infinity> pitti: Yeah, so, my vague recollection is that we actually intended to make it Essential as part of the systemd switch and just kinda maybe forgot. :P
<infinity> pitti: But I'm old, so I could be fabricating memories to make my life more pleasant.
<infinity> pitti: I suppose the other gross hack that would sort of work would be to have upstart "Recommends: systemd-sysv | upstart-sysv", but that would also break people who install without recommends (and a Depends would be a lie).
<infinity> pitti: So, meh.  One wart or the other, we can drop init out of Essential after 16.04, don't really care.  upstart was transitively Essential for years too, entirely by accident. :P
<teward> is jenkins broken again?
<strikov> Hi pitti. We have juju-1.22.0 uploaded to -proposed which passes juju team's QA tests (it can provision trusty and precise) and my manual adt-run against vivid image with upstart installed. It doesn't pass automatic adt-run due to the lack of systemd support. I made decision not to update autotests because we'll be required to revert all these changes back while packaging 1.23. Could you help us to manually move the package to release pocket?
<strikov> pitti: Additional information can be found in the bug: https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1416051 Thanks!
<ubottu> Launchpad bug 1416051 in juju-core (Ubuntu Trusty) "juju-core 1.22.0 is not packaged in Ubuntu" [Undecided,New]
<infinity> strikov: I thought the whole reason we weren't letting in was because of the lack of systemd support, and we were told that was happening ASAP.
<strikov> infinity: that is fixed in 1.23 which is in beta; my plan is to upload 1.22 and start to work on 1.23
<strikov> infinity: it usually takes some time because d/copyright is pretty complex for golang package
<infinity> strikov: "Start work on" doesn't sound as "ASAP" as we were promised weeks ago. :/
<strikov> infinity: well, we can't upload 1.23 until juju team releases it :) i can do *some* licensing checks earlier but we need to wait until the release anyway I think
<infinity> strikov: Anyhow, the bug log looks "good enough" for letting it in.
<infinity> strikov: But gating on juju upstream to polish off 1.23 rather than backporting/cherrypicking the required bits to support systemd is going to make the release team very grumpy with all of you, given that the release is 2.5 weeks out.
<infinity> strikov: Of course, the problem with your tests not passing in any way is also that your deps (like lxc) could break juju completely, and we'll never catch it.
<infinity> Well, not until it's too late.
<strikov> infinity: adt tests pass when i use vivid image with upstart installed; i may misunderstood your point but i run these tests that way to avoid missing anything which is verified by tests
<infinity> strikov: My point is that we re-run the tests automatically when your dependencies change.
<infinity> strikov: You miss out on the benefit of that when your tests can't be run automatically.
<strikov> infinity: Ah, that's a good point. I agree. The only argument I have is that I plan to upload 1.23 very soon. it won't have systemd issue.
<teward> hey infinity, do you have access to see whether a job that jenkins emailed me about actually exists?
<infinity> teward: Maybe.
<infinity> teward: Depends on the job, I suppose. :P
<infinity> pitti: So, making init essential plumps up my chroots by ~20-30 MB (depending on arch) after I'd just cleaned them out to make them init system free, but I don't think that's world-ending.
<infinity> Besides, chubby chroot is pleasantly alliterative.
<teward> infinity: well jenkins mailed me on a failure at https://jenkins.qa.ubuntu.com/job/vivid-adt-nginx/47 but I get 404s.
<infinity> teward: Ahh, the public mirror seems to be a bit behind reality.
<infinity> teward: 47 exists and did indeed fail, and 48 is in progress as a retry.
<infinity> And I completely forget who's in charge of the public mirror bits.
<teward> mmm
<teward> infinity: ok.  i don't have the private access so i have no idea what's up with the failures, if anything.
<teward> kinda curious every time i see those emails xD
<infinity> Ugh.  The failure was not yours, if that's comforting.
<teward> that's a positive.
<teward> 'tis all i really worried about :0
<teward> :) *
<infinity> I'm less enthused.
<teward> mmm
<teward> well i'm more comforted, but still curious, alas that's my nature :P
<infinity> mvo: test-apt-download-progress really, really, really doesn't like you.
<infinity> teward: Not sure what it was that broke your tests, actually.  It smells like an apt bug, but on a retry it was fine, so maybe just a weird archive inconsistency...
<teward> infinity: i've had nondeterministic failures in nginx builds too, so i'm used to seeing that every once in a while.
<teward> infinity: if it failed twice i'd be more concerned, but one fail and one complete on retry makes me even less concerned
<infinity> teward: Yeah.  Well, any failures concern me, because it's hard to have a stable baseline to compare to when none of the tests (or the infrastructure) are stable.  Getting there, though.  Slowly.
<pitti> strikov: yes, I already unblock packages which are held up by the failing juju
<pitti> strikov: why would you need to revert the changes? I thought you wanted to update the tests so that they work on any relese?
<pitti> infinity: sounds ok to me, especially as we can revert it in 16.10 if we care
<strikov> pitti: they will work w/o any changes at all :) on trusty they will test upstart (because it's default init there), on vivid they will test systemd
<strikov> pitti: i had an idea to test both systemd and upstart on vivid but came to conclusion that it's not needed
<strikov> pitti: because it leads to some corner cases when host runs vivid/upstart but juju-local lxc container runs vivid/systemd
<strikov> pitti: and i came to conclusion that simplest option is the best one
<infinity> strikov: FWIW, I already (grudgingly) let it in.
<pitti> strikov: ack
<infinity> strikov: But please push your upstream to get us 1.23 ASAP, like actually ASAP, and if you can work on the packaging from their current trunk, rather than waiting for the code to drop, that would be great too.
<strikov> infinity: pitti: thanks; i'll start looking into 1.23 tomorrow morning; will be using what i have for now
<pitti> strikov: yay
<mdeslaur> cyphermox: can you take a look at my debdiff in bug 1440166 when you get a minute?
<ubottu> bug 1440166 in network-manager-applet (Ubuntu) "network indicator displays notifications for virtual devices" [Undecided,New] https://launchpad.net/bugs/1440166
<infinity> pitti: FWIW, the occasional apt failures on systemd-sysv/systemd are probably because of the Pre-Depends, which should just be a Depends.
<infinity> pitti: Not that that isn't an apt ordering bug (it is), but making apt's life less painful there might be nice.  Unless systemd-sysv actually has a preinst that requires systemd.
<infinity> pitti: Which it doesn't.
<infinity> mbiebl: Was there a reason why systemd-sysv Pre-Depends on systemd instead of just Depends, or just an oops/misunderstanding of how dpkg deps work?
<teward> infinity: indeed.  i can understand that
<infinity> Ahh, eww.
<infinity>   * Add Pre-Depends on systemd to systemd-sysv, to avoid risking that the
<infinity>     sysv-compatible symlinks become dangling on a partial install.
<stormbrew-> infinity: I was told to bring this up with you (or doko? Who doesn't appear to be in here right now): There's a pretty severe bug in the libstdc++6 version 5 package in ubuntu-toolchain-r/test where std::error_codes are all comparing unequal: https://gist.github.com/stormbrew/e877b39aa060f19f16dc
<stormbrew-> (told by ogra_ in the #ubuntu-bugs channel)
<infinity> stormbrew-: Probably best to file a bug upstream or email doko, or both.
<infinity> stormbrew-: FWIW, it looks like it's an ABI break.  If you recompile with g++-5 from the same PPA, it returns 0 as you expect, it's only compiling with 4.9 and running with 5.0 that breaks.
<infinity> stormbrew-: But, yeah, I'd take that knowledge and file an upstream bug report and email doko about it before he decides to unleash that compiler on the world.
<infinity> stormbrew-: Upstream's answer might be "sucks to be you, we warned you that -std=c++11 was experimental", but still worth reporting.
<stormbrew-> ah, interesting. That's good to know. I'll do that as soon as I have the cycles for it, thanks.
<cyphermox> mdeslaur: yup
<cyphermox> mitya57: did you already upload your gnome flashback fix?
<mdeslaur> cyphermox: cool, thanks!
<cyphermox> nevermind, I see it was
<mvo> infinity: meh, is that test still failing?
<hallyn> ok, systemd continues to confound me:
<hallyn> ubuntu@lv1:~/new$ sudo systemctl stop libvirt-bin
<hallyn> ubuntu@lv1:~/new$ ps -ef | grep libvirt
<hallyn> ubuntu   19003   908  0 16:26 pts/1    00:00:00 grep --color=auto libvirt
<hallyn> root     25509     1  0 15:58 ?        00:00:00 /usr/sbin/libvirtd -d
<ubottu> Ubuntu bug 19003 in xorg (Ubuntu) "Error when trying to use other keyboard layout than us in breezy" [Medium,Fix released] https://launchpad.net/bugs/19003
<hallyn> systemctl stop doesn't seem to work
<hallyn> oh, bc systemd thinks that /etc/init.d/libvirt-bin stop is the way to stop it
<hallyn> pitti: ^ i guess we really do need a systemd unit for libvirt, or at least a aysvinit script back, bc the current way really is broken
<mbiebl> hallyn: http://paste.debian.net/165569/
<mbiebl> the sysv init script and the service file should have the same name
<mbiebl> or if they use different names, provide a symlink
<mbiebl> which package does provide /etc/init.d/libvirt-bin?
<mbiebl> is that an obsolete conffile?
<dobey> mbiebl: dpkg -S tells you what installed package owns it, if any
<mbiebl> dobey: I do know that
<mbiebl> (I do run Debian here, which doesn't ship /etc/init.d/libvirt-bin)
<Unit193> !find /etc/init.d/libvirt-bin vivid
<ubottu> Found: W:, W:, W:
<Unit193> !find /etc/init.d/libvirt-bin vivid
<ubottu> File /etc/init.d/libvirt-bin found in libvirt-bin
<infinity> mvo: It sure it.
<infinity> mvo: is...
<hallyn> mbiebl: hm, i was thinking that /etc/init.d/libvirt-bin was a wrpaper around the /etc/init/libvirt-bin (as it used to be at one point),
<hallyn> still i think it's better to provide a proper systemd unit for it than to figure out why the sysv script isn't working under systemd :)
<infinity> hallyn: Stopping works for me...
<hallyn> infinity: ok, good to know - must be something i've got locally then, thanks
<infinity> hallyn: http://paste.ubuntu.com/10766403/
<hallyn> infinity: i have no clue what's going on then, but on this instance it's 100% reproducible that libvirt doesn't die, and after the fact, systemctl status libvirt-bin shows:
<hallyn>   Process: 20817 ExecStop=/etc/init.d/libvirt-bin stop (code=exited, status=0/SUCCESS)
<hallyn> oh COME ON
<hallyn> now its gone away
#ubuntu-devel 2015-04-08
<Noskcaj> It appears http://qa.ubuntuwire.com/bugs/rcbugs/ is broken
<Noskcaj> wgrant, That's one of your pages isn't it? ^
<wgrant> Noskcaj: ajmitch knows that code better, I think, but I'll have a look if he doesn't.
<wgrant> It was probably the dist-upgrade last week.
<ajmitch> wgrant: I'll poke it & see
<wgrant> ajmitch: The webapp was working fine at the time, but maybe the import script is unhappy.
<wgrant> I didn't think to check that.
<ajmitch> partly because it's so old & outdated
<ajmitch> Noskcaj: fixed
<wgrant> ajmitch: Thanks. What was the issue?
<ajmitch> wgrant: using a python extension that linked to libapt_pkg for version comparisons
<ajmitch> not something packaged, so it just needed to be rebuilt
<wgrant> Ahh
<wgrant> We ran into the same problem with LP a couple of months ago.
<ajmitch> it's only about 10 years old
<ajmitch> plus there was a script trying to run python2.5 (since 2.4 was just too old)
<pitti> Good morning
<pitti> hallyn: ah, the init.d script is broken and doesn't actually stop virtd? that needs to be fixed then indeed (or a proper unit added)
<dholbach> good morning
 * mgedmin wants to ask about https://bugs.launchpad.net/bugs/1384188
<ubottu> Launchpad bug 1384188 in gfxboot-theme-ubuntu (Ubuntu) "Missing translations for 'Install Ubuntu GNOME' and 'Try Ubuntu GNOME without installing'" [Undecided,Fix released]
<seb128> cyphermox, ^ it might be one for you? (updating gfxboot-theme-ubuntu with a new translations export)
<seb128> mgedmin, ^
<pitti> infinity: can you please remind me and mbiebl_: why do we need *both* the sysvinit (update-rc.d) and the systemd trigger update?
<infinity> pitti: Different corner cases.  Either one addresses the simple "policy compliant deb that calls update-rc.d but not invoke-rc.d" case, but each addresses different cases that aren't that.
<infinity> pitti: sysvinit also covers the "install without a package, but use update-rc.d" case, and the trigger also covers the "install from a deb that doesn't use update-rc.d" case.
<infinity> pitti: Neither one addresses every possible corner case (only fixing systemd itself could do that), but both together cover enough that it's probably "good enough for now".
<pitti> infinity: ah, ok; the first case sounded a bit strange to me, but sure
<pitti> infinity: but as the latter would be an RC bug in that particular package, I'm not sure how happy the Debian release team would be about such a change two weeks before the release; or did you already happen to talk to them?
<infinity> pitti: I'll talk to them.  The fix is (I think) obviously non-invasive and not regression-inducing.  A tiny performance impact, but nothing worth fretting about (and a no-op on upgrades from wheezy, since systemd isn't running yet).
<pitti> ack; I'll do the commit/upload then
<infinity> pitti: Actually, I'm not sure the latter WOULD be a policy violation.
<infinity> pitti: Policy says "However, it must not be assumed by maintainer scripts that this method is being used, and any automated manipulation of the various runlevel behaviors by maintainer scripts must be performed using update-rc.d as described below and not by manually installing or removing symlinks."
<infinity> pitti: One could infer from that that if you wanted to install an init script that *doesn't* have rc.d symlinks and is only started/stopped by hand, you don't need to call upadte-rc.d
<infinity> pitti: And systemd should still be aware of those scripts, so you can start them properly.
<infinity> pitti: Later, there's a "should register with update-rc.d", but not a must.
<infinity> pitti: So, yeah, I'd say it's not RC to ship an init script with no runlevel, just weird.
<infinity> pitti: But having it fail to work would be RC, so...
<mbiebl_> morning pitti, infinity
<pitti> hey mbiebl_
<mbiebl_> just checked all the packages shipping init scripts in the Debian archive
<mbiebl_> i didn't find one which one installs without update-rc.d
<infinity> mbiebl_: To be clear, I didn't think the trigger would be necessary for packages in the archive.
<infinity> I just think it's still the right thing to do.
 * infinity shrugs.
<mbiebl_> infinity: hm, k
<infinity> (Well, it would have been necessary without the update-rc.d fix, but yeah...)
<mbiebl_> right
<mbiebl_> my impression from our discussion was, that we needed one or the other but not necessariliy both
<mbiebl_> (btw, thanks for the sysv upload)
<pitti> mbiebl_: so, I don't mind committing this to master if the RT agrees; it just feels way below RC to me
<infinity> pitti: I think it's right from a point of view of "polish", which isn't always "RC" in the "completely broken" sense, but it still seems right.
<infinity> pitti: But I can get a release ack before upload, if that makes you feel better.
<mbiebl_> pitti: something else I wanted to discuss with you (and possibly didrocks) is the default-display-manager behaviour
<mbiebl_> It just happened to me the other day, that I wanted to test a boot without graphical login
<mbiebl_> so I ran systemctl disable gdm.service
<mbiebl_> which did remove the display-manager.service symlink
<mbiebl_> upon reboot, gdm was running though
<mbiebl_> it took me a while to remember that the generator had created a start symlinks because of /etc/X11/default-display-manager
<mbiebl_> and I don't think it should do that
<mbiebl_> because /e/X/d shouldn't decide about the enabled/disabled state
<mbiebl_> only about which one is the configured one if multiple are installed
<didrocks> there are a lot of dms not transitionned in debian to use a systemd unit
<didrocks> that would mean, there is no way to ensure not 2dms (a systemd ones and an init-only one) would not be started
<didrocks> hence the whole work and discussion to have /etc/X11/default-display-manager as the source of truth
<darkxst> didrocks, except that is just a bunch of packaging hacks currently, no?
<mbiebl_> didrocks: it's ok to make /e/X/d decide which one is the configured default
<didrocks> darkxst: the d-d-m setting default? It's not, it's a generator
<pitti> well yes, obviously it'd be better to fix all the DMs in sid/vivid, but we aren't there yet (and freeze, etc.)
<mbiebl_> but the generator should not automatically re-enable services which have been disabled by the admin
<didrocks> mbiebl_: it's not if it's masked
<didrocks> which was your latest request, that is implemented IIRC
<darkxst> didrocks, isnt it generated by debconf?
<pitti> the link is
<didrocks> darkxst: it's a systemd generator, see above ^ we are not talking about the postinst thingy
<pitti> the systemd generator turns that into unit config
<mbiebl_> didrocks: I did remember that we discussed that a while ago and i think I mentioned the same issue back then
<pitti> mbiebl_: still better IMHO than attempting to start two DMs
<pitti> let's face it -- systemd can only do so much while we still have broken DM packages
<didrocks> mbiebl_: you were ok at the time that masking would be sufficient
<mbiebl_> pitti: two DMs are only started if you have a combination of native .service file and sysv init script
<mbiebl_> only sysv init scripts -> all existing ones have the check for /e/X/d-d-m
<didrocks> not nodm
<mbiebl_> only systemd units -> only one can provide the symlink
<mbiebl_> didrocks: nodm is broken, so I don't really care
<pitti> mbiebl_: precisely that was the case, no? e. g. gdm + nodm
<didrocks> well, that was one of the inputs to get it fixed though
<didrocks> we got bug reports about it
<didrocks> (doesn't impact ubuntu as we don't have nodm)
<mbiebl_> if nodm doesn't check /e/X/ddm it's also broken under sysv?
<darkxst> oh right, I see
<mbiebl_> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748668
<ubottu> Debian bug 748668 in slim "slim: Under systemd, randomly hijacks default-x-display-manager ignoring default selection" [Important,Fixed]
<mbiebl_> I don't see nodm mentioned there
<mbiebl_> it's about mixing non-systemd enabled DMs like slim with e.g. gdm
<didrocks> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770219
<ubottu> Debian bug 770219 in nodm "nodm does not start" [Normal,Open]
<didrocks> didn't start because another dm was started through systemd IIRC
<didrocks> (when doing some vm tests)
<didrocks> this is quite months old, don't remember exactly
<mbiebl_> doesn't look systemd specific
<mbiebl_> as said, the nodm package just looks broken and I don't think we should model around that package
<mbiebl_> didrocks: all I would do, if both a sysv DM is installed and a native systemd DM unit
<mbiebl_> and the display-manager.service symlink exists but doesn't match /e/X/ddm
<mbiebl_> is to runtime mask that service
<mbiebl_> easy and simple
<didrocks> I'll let you and pitti sorting it out, TBH, I'm a little bit tired about the bikeshedding around it
<didrocks> there was a need, we addressed it, was almost RC for some
<didrocks> if you want to drop it, ok
<pitti> tjaalton: I think I might have found a likely candidate for your "bridge does not come up" problem, I followed up to bug 1430675 (one-second check)
<ubottu> bug 1430675 in systemd (Ubuntu) "fails to set up a bridged network interface" [High,Incomplete] https://launchpad.net/bugs/1430675
<pitti> cjwatson: hm, did the RTM upload target/machinery change recently?
<pitti> cjwatson: on ubuntu-phone@ it was mentioned that the langpacks are out of date, and indeed https://launchpad.net/ubuntu-rtm/+source/language-pack-touch-es is from March 24
<pitti> cjwatson: but my cron build and upload logs show success (last log from yesterday), and the continued succession in https://translations.launchpad.net/ubuntu-rtm/14.09/+language-packs proves this too
<pitti> nothing in https://launchpad.net/ubuntu-rtm/14.09/+queue?queue_state=1 either
<pitti> so it seems they are just silently getting rejected now?
<tjaalton> pitti: oh, nice catch! sounds like it'll get fixed for me too
<tjaalton> I don't have the rcS.d symlink
<pitti> tjaalton: ah, you also don't have that link?
<pitti> tjaalton: great, thanks for confirming! this seems to be a rather widespread plague
<pitti> and it looks like it's already rather old, just got hidden by the networking upstart job
<tjaalton> yeah
<tjaalton> this install is 2,5y old
<cjwatson> pitti: Not as far as I know.
<cjwatson> Let's see what our logs say.
<pitti> cjwatson: hm, I recently had to renew the gpg key validity for language-packs@ubuntu.com, I wonder if that's related
<cjwatson> pitti: 2015-04-06 05:23:32 INFO    Failed to parse changes file '/srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20150406-052225-005790/ubuntu-rtm/language-pack-touch-ast_14.10+rtm14.09+20150405_source.changes': GPG verification of /srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20150406-052225-005790/ubuntu-rtm/language-pack-touch-ast_14.10+rtm14.09+20150405_source.changes failed: Verification failed 3 times: ["(7, 153, u'Key ...
<cjwatson> ... expired')", "(7, 153, u'Key expired')", "(7, 153, u'Key expired')"]
<cjwatson> pitti: Indeed.  How recently did you do that?
<pitti> cjwatson: on March 30 according to the file timestamps
<pitti> I updated it on macquarie, I guess I also need to update it on Launchpad somehow
<AntiSol> hello devs! I'm having a strange problem with patch and was hoping somebody could help: I'm trying to apply the patch from http://permalink.gmane.org/gmane.comp.file-systems.ext4/18338. I did apt-get source e2fsprogs and saved the patch from that page. when I do 'patch -p1 < patchfile.patch' it tells me that it's patching the files but it doesn't make any changes to the files. I also tried patch --verbose: http://paste.ubuntu.com/10771372/
<cjwatson> pitti: Did you push it to keyserver.ubuntu.com?
<pitti> ah! no
<pitti> done now
<cjwatson> pitti: Thanks, that should do the trick
<pitti> cjwatson: so, sorry for the noise, thanks for pointing out
<AntiSol> any ideas? I have checked that I have permissions, and patch gives a 0 return code. I have NFI what's going on
<pitti> cjwatson: http://keyserver.ubuntu.com:11371/pks/lookup?op=vindex&search=0x5E7C4A8E07EABA1B is updated, but I figure LP needs some time (cron?) to update its internal keys; I'll check tomorrow's cronned uploads then
<pitti> (my immediate re-uploads didn't work yet)
<cjwatson> pitti: There may be a cache between it and the keyserver, I forget.
<pitti> cjwatson: don't worry
<infinity> pitti: I got a "that seems sane" from adsb on both the sysvinit and systemd fixes, with the caveat that I ask KiBi, since it'll be a new udeb.
<infinity> mbiebl_: ^
<pitti> infinity: cheers
<infinity> mbiebl_: Did you decide you needed a systemd upload for other reasons (the ddm thing) too?
<pitti> infinity: it won't affect d-i/the udeb anyway, so that should be fine
<pitti> infinity: yes, I've backported a few other nice and safe fixes too
<infinity> pitti: Yeah, won't affect it except to trigger a respin if he's keeping d-i in sync with the archive.
<infinity> pitti: Okay, cool, if the upload is happening anyway, please backport the trigger, then.
<infinity> pitti: And we'll beg forgiveness from KiBi for the udeb churn. :)
<pitti> infinity: already committed to git
<infinity> pitti: Ta.  When the upload hits, I can submit the unblock bug for both, if you like.
<pitti> infinity: I'll send the systemd unblock, I can explain the other changes
<pitti> infinity: and for that trigger part refer to your conversation with adsb
<infinity> pitti: Alright, sysvinit unblock filed, I'll leave the systemd stuff in your capable hands.
<infinity> pitti: PS, let's never deal with two distros in freeze at the same time again, it's irksome.
<pitti> infinity: heh, tell me :)
<infinity> jodh: golang-juju-loggo?  Why the trailing "go"?  No other go packages seem to do that.
<jodh> infinity: that's it's name - https://godoc.org/github.com/juju/loggo
<infinity> jodh: I suppose I'd also question why we need Yet Another Logger (there seem to be a couple already), but whatever.  Tis the curse of a new language that everyone needs to NIH five times.
<infinity> jodh: Your build-dep is on debhelper 9, but debian/compat is 7.  Intentional mismatch?
<rbasak> juju-loggo? What's this for, OOI? Juju itself bundles the dep.
<infinity> rbasak: Given the uploader, I'm going to assume it's being used for something snaptastic.
<rbasak> I wonder if there's anything we can do to avoid duplication. That might mean a huge amount of pain though :-/
<jodh> infinity: that build-dep will be an oversight :)
<infinity> rbasak: Stop using a language/ecosystem that promotes bundling and static linking as the norm? :P
<rbasak> :-/
<Mate> hi. how could i get debug symbols for upstart=1.5-0ubuntu7.2? it's missing from precise-updates on ddebs.ubuntu.com (but arm* is there)
<infinity> Mate: The symbols do indeed seem to be missing, there's no way to get them back.  But you could try -0ubuntu7.3 from precise-proposed, which does have symbols on all arches.
<Mate> I have a core file to investigate
<Odd_Bloke> dannf: Would you expect a "error: no suitable video mode found." from GRUB when booting the arm64 UEFI image with -nographic?
<infinity> Odd_Bloke: Yeah.
<Odd_Bloke> Great!
<infinity> Odd_Bloke: We get the same misfeature on PPC, it's clearly a bug in both cases, but a mostly harmless one.
<Odd_Bloke> That just leaves me with "error: file `/boot/grub/fonts/unicode.pf2' not found."; /boot/grub/unicode.pf2 exists, and I can't see any reason for grub to look in that particular directory.
<flexiondotorg> infinity, I saw mention of PPC.
<flexiondotorg> infinity, There is a serious regression in X for PowerPC :(
<flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1434036
<ubottu> Launchpad bug 1434036 in xserver-xorg-driver-ati "ubuntu MATE 15.04 PPC/Lubuntu 15.04 PPC Xorg: Only black screen with blink cursor after update" [Medium,Confirmed]
<flexiondotorg> https://bugs.freedesktop.org/show_bug.cgi?id=89862
<ubottu> Freedesktop bug 89862 in Server/General "[PPC] xserver-xorg-core_1.17: Xorg doesn't start and signal 11 errors" [Normal,Reopened]
<hallyn> pitti: well no, the /etc/init.d/libvirt-bin script *looks* correct.  and sometimes it kills it fo rme.  but often it does not.  I haven't yet figured out why.
<tjaalton> flexiondotorg: does startx work?
<flexiondotorg> tjaalton, Good question. I don't know. I'll ask them to test that. My PowerPC test machine is at home so I can't test right now.
<Odd_Bloke> infinity: And do we expect to get a pause before boot continues, when we see that error?
<Riddell> tseliot: so d_ed pointed out a couple of issues with your displaystop patch :(  you also say it needs to set /etc/X11/default-display-manager ? what's that used for and do you know what sets it in the lightdm package? all these postinsts and config files are hard to follow
<dannf> Odd_Bloke: we know the cloud images have a mis-installed grub, that is being worked on
<dannf> Odd_Bloke: but yeah, for now you have to press a key to continue
<Odd_Bloke> dannf: I am, in fact, working on it. :)
<dannf> Odd_Bloke: oh, didn't "real name" you - cool, thanks! let me know what i can do to help
<Odd_Bloke> dannf: I've got to the point where we see an "error: no suitable video mode found." message, a (~10 second) pause and then boot continues.
<dannf> Odd_Bloke: yeah - grub has a boot delay there, but you can hit esc to see the grub menu - make-it-boot-now
<Odd_Bloke> dannf: So does what I've got sound like roughly what we'd expect?
<dannf> Odd_Bloke: sounds like it
<Odd_Bloke> OK, cool.
<dannf> i think the only remaining open issue was to make the boot non-interactive by fixing the grub install
<dannf> well - issue *for you* - i'm still working on fixing up various other bits for utopic/vivid, but that's all kernel
<Odd_Bloke> I'll see if I can iron out some of the hackiness that I've got in place, but I expect vivid dailies will be fixed by the end of the week.
<Odd_Bloke> (And probably other releases, but I'm only testing vivid ATM)
<dannf> awesome!
<dannf> yeah, utopic/trusty will need hand holding to boot even after the images are fixed. utopic should be fine after the next SRU cycle
<Odd_Bloke> dannf: The "fs0:; cd efi; BOOTaa64.EFI" dance is still fine for "non-interactive" boot?
<Odd_Bloke> (That is presumably the result of the BIOS that we're using, rather than the images?)
<dannf> Odd_Bloke: oh, no - that needs to be repaired
<dannf> Odd_Bloke: think about it in an openstack environment, where you can't talk to the vm until ssh is up
<Odd_Bloke> dannf: So when the "The default boot selection" countdown hits 0, we should be straight in to grub?
<Odd_Bloke> dannf: (Yeah, makes sense, I had just assumed that there was EFI/BIOS magic that did something something *waves hands*)
<dannf> Odd_Bloke: yeah. it could be a problem w/ the bios image as well - but i thought they had the right entries
<Odd_Bloke> dannf: http://paste.ubuntu.com/10774114/ is what I see.
<dannf> Odd_Bloke: and then [1] fails i take it?
<Odd_Bloke> dannf: Yep.
<dannf> Odd_Bloke: http://www.linaro.org/app/resources/WhitePaper/VMSystemSpecificationForARM-v1.0.pdf
<dannf> ^ that's what we're aiming for
<dannf> so the "firmware" should be defaulting to boot "\efi\boot\bootaa64.efi"
<dannf> Odd_Bloke: if manually running that works, and the firmware just isn't calling it correctly, then probably something to look at on our end
<dannf> Odd_Bloke: from your "dance" commandline, it looks like it might be under \efi, not under \efi\boot?
<Odd_Bloke> Ah, looks like we're creating \efi\bootaa64.efi
<Odd_Bloke> :)
<dannf> jinx :)
<Odd_Bloke> /kick Odd_Bloke JINX
<Odd_Bloke> dannf: OK, I'll get that in the right place and see if boot becomes non-interactive
<dannf> cool - hope that's it :)
<flexiondotorg> pitti, Anything I can do to help with https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875
<ubottu> Launchpad bug 953875 in ecryptfs-utils (Ubuntu Vivid) "Encrypted swap no longer mounted at bootup" [High,Confirmed]
<flexiondotorg> pitti, See my comments 61 and 62
<Odd_Bloke> dannf: Hm, if I enter the Boot Manager and Add Boot Device Entry, then I can boot using that option in the boot menu.
<dannf> Odd_Bloke: you  mean w/o moving it under 'boot\'?
<flexiondotorg> Will anyone be piloting today?
<dannf> Odd_Bloke: yeah - i'd expect that to work. but that wouldn't let us autoboot on someone else's complaint EFI firmware blob
<Odd_Bloke> dannf: No, having moved it under boot; it still didn't work having moved it.
<Odd_Bloke> dannf: The first option I have in the boot menu is "Linux (EFI stub) on virtio31:hd0:part0"; is that trying to load the kernel directly rather than go through grub?
<dannf> Odd_Bloke: ah, maybe
<dannf> Odd_Bloke: in that case, i think it's a bad fw blob. which blob are you using? i don't recall which one i suggested
<Odd_Bloke> dannf: http://people.canonical.com/~vorlon/edk2-aarch64/QEMU_EFI.fd.native
<dannf> oh, ok. i'll try to come up with a better one to test with.
<dannf> Odd_Bloke: do you have a cloudimage build i can use to do that, or should i just wait for a daily?
<Odd_Bloke> dannf: I'll push up something I've built locally for you, give me a minute.
<dannf> Odd_Bloke: ack
<tseliot> Riddell: grepping through the lightdm sources, I've found debian/lightdm.config which contains the following (stolen from xdm): http://pastebin.ubuntu.com/10774657/
<tseliot> Riddell: also, what I was saying is that my patch is useless since things won't work on log out anyway, as sddm won't restart X on logout
<Riddell> tseliot: so it's based on X restarting which sddm doesn't do?
<tseliot> Riddell: yep. So having a working login is the only thing we can get now (which is still better than a black screen)
<tseliot> Riddell: and for that we simply need: 1) the default display manager file, 2) a slight change in gpu-manager (which I only have to upload), and 3) the DisplayCommand entry in sddm.conf
<Riddell> tseliot: 3) is done, I guess I need to work out what this .config file is doing
<tseliot> Riddell: it's just debconf black magic. I think a simple copy & paste should work
<tseliot> Riddell: so, the .config file, and the relevant parts of .postinst and .prerm. You really can't miss them, as they have $DEFAULT_DISPLAY_MANAGER_FILE in them
<tseliot> copy & paste those parts and it should work
<mdeslaur> Riddell: can you test the fix for 1400730 please? Else, it will get superseded by a security update soon.
<Riddell> bug 1400730
<ubottu> bug 1400730 in libxext (Ubuntu Utopic) "libxext fills up .xsession-errors log files" [Undecided,Fix committed] https://launchpad.net/bugs/1400730
<Riddell> ah yes that's been on my todo list for months
<mdeslaur> Riddell: thanks
<Riddell> tseliot: nothing there seems to create DEFAULT_DISPLAY_MANAGER_FILE it only does something if it exists
<tseliot> Riddell: that's what the .config script does. I also forgot to mention the .templates file. This document explains how it works: http://www.fifi.org/doc/debconf-doc/tutorial.html#AEN113
<Riddell> tseliot: I think it's lightdm.postinst which makes the file
<tseliot> Riddell: if it doesn't exist, yes: echo "$DAEMON_NAME" > "$DEFAULT_DISPLAY_MANAGER_FILE"
<Riddell> right
<tseliot> you need debconf only to ask the user if more choices are available
<octoquad> Hi, for Remmina upstream patches, should this be provided as a debdiff or bzr branch for affected releases?
<freyes> octoquad, it's up to the maintainer of the package, but they usually prefer a debdiff
<infinity> dannf / Odd_Bloke: You shouldn't actually have to press a key to continue (despite the prompt claiming otherwise), it times out in a few seconds.
<infinity> dannf / Odd_Bloke: If that's not true, it's not the bug I'm thinking of, but I'm pretty sure it it.
<dannf> infinity: i think there are 2 bugs - one w/ the video error, the other due to a misinstalled grub spitting syntax errors
<infinity> dannf: Ahh, the syntax error thing is different indeed.  The video mode and "press any key to continue" bits, though, we see on PPC, and they're harmless, just annoying.
#ubuntu-devel 2015-04-09
<DerRaiden> morning/morgen
<pitti> Good morning
<twb> Dumb question: is it normal for EOLd packages to still have .dscs linked from packages.u.c ?  Because http://packages.ubuntu.com/lucid/cups links to http://archive.ubuntu.com/ubuntu/pool/main/c/cups/cups_1.4.3-1ubuntu1.14.dsc but the files *that* references are 404d (presumably because they're moved to the EOL server)
<twb> oh wait, I misread the error message
<twb> Ignore me, I'm just an idiot.
<jibel> pitti, where are the logs now with systemd? it used to be in /var/log/upstart/ is everything in syslog? I'm searching why whoopsie doesn't upload crash files on vivid
<pitti> jibel: it should be in syslog too, but everything goes into the journal
<pitti> jibel: "journalctl" -> everything; "journalctl -u whoopsie" -> everything from whoopsie
<jibel> pitti, thanks. I'll check that.
<pitti> (there's lots of more filters, but those are probably the two most common ones)
<pitti> jibel: so journalctl -u <servicename> is the direct equivalent of /var/log/upstart/<servicename>
<jibel> Cannot reach: https://daisy.ubuntu.com is a good reason to not upload crash files :/
<dholbach> good morning
<pitti> cjwatson: do you want a Debian bug for bug 1440070 / the patch in http://launchpadlibrarian.net/202605250/openssh_1%3A6.7p1-5_1%3A6.7p1-5ubuntu1.diff.gz ?
<ubottu> bug 1440070 in openssh (Ubuntu) "openssh-server attempts to connect to upstart and the connection is refused" [Low,Fix committed] https://launchpad.net/bugs/1440070
<cjwatson> pitti: Yes please
<cjwatson> pitti: Or I can give you git commit access if you like
<pitti> cjwatson: I'll file a bug then
<LocutusOfBorg1> Does anybody know how to contact Chris Arges?
<LocutusOfBorg1> about bug 1129409
<ubottu> bug 1129409 in fglrx-installer-updates (Ubuntu Utopic) "[SRU] Nvidia and AMD graphics drivers should indicate whether they provide libcuda.so.1, libOpenCL.so.1, etc." [Undecided,Confirmed] https://launchpad.net/bugs/1129409
<LocutusOfBorg1> seems he didn't upload the utopic fix :(
<pitti> infinity: FYI: https://tracker.debian.org/news/676575
<Riddell> tseliot: sddm today should make the /etc/X11/default-display-manager file
<tseliot> Riddell: ok, will it also come with an entry in sddm.conf?
<Riddell> tseliot: it'll use the default which points to the Xsetup script which does run /sbin/prime-offload
<tseliot> Riddell: ok, that would work. I'll push my change for gpu-manager in ubuntu-drivers-common, so that it doesn't abort when it finds sddm
<Riddell> tseliot: lovely :)
<tseliot> Riddell: done
<Riddell> tseliot: awooga, thanks for your help
<infinity> pitti: Excellent, now it just needs an unblock?
<tseliot> Riddell: you're welcome. If they ever add support for restarting X on log out, I'll be glad to complete support for hybrid graphics in sddm
<pitti> infinity: yes; I'd like to keep this in unstable for two days or so to get some field testing, so I was going to file the request on Sat
<infinity> pitti: Fair enough.  Since I uploaded sysvinit with a medium urgency, I figured that would take care of me anyway and filed the unblock with the upload.  That's 5 days for someone to file an RC bug and keep it out.
<infinity> pitti: And, indeed, you were a medium too, so...
<tjaalton> LocutusOfBorg1: that would be tseliot then, who packaged them
<tseliot> LocutusOfBorg1: I haven't backported the fix to utopic. It's only in trusty and in vivid for now
<LocutusOfBorg1> tseliot, I provided the debdiff in the bug
<LocutusOfBorg1> the fix is trivial
<tseliot> LocutusOfBorg1: right. I can upload that later
<LocutusOfBorg1> thanks
<shadeslayer> mvo: poke
<shadeslayer> mvo: Kubuntu core ?
<flexiondotorg> If there is someone piloting would they be good enough to look at the following please?
<flexiondotorg> https://bugs.launchpad.net/ubuntu-mate/+bug/1439388
<ubottu> Launchpad bug 1439388 in mate-tweak (Ubuntu) "Updated translations for mate-tweak [debdiff attached]" [Low,New]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1439380
<ubottu> Launchpad bug 1439380 in mate-menu (Ubuntu) "Updated translations for mate-menu [debdiff attached]" [Low,New]
<flexiondotorg> They are updated translations and bugs fix. I think today is the deadline for translations.
<Odd_Bloke> mvo: Thanks for the merge!
<ginggs> hi, anyone one in ubuntu-archive able to look at LP: #1432576 please?
<ubottu> Launchpad bug 1432576 in kissplice (Ubuntu) "Please remove 32-bit (armhf, i386 and powerpc) binaries" [Undecided,Incomplete] https://launchpad.net/bugs/1432576
<cjwatson> ginggs: done
<ginggs> cjwatson: thanks!
<flexiondotorg> Is there someone scheduled to pilot today?
<seb128> flexiondotorg, mvo and cjwatson
<flexiondotorg> seb128, Thanks.
<flexiondotorg> mvo, cjwatson When you're piloting I have some stuff that I think is time critical for today.
<cjwatson> I'm unlikely to do it today, sorry.  Doesn't fit very well into my LP work
<cjwatson> Trying to follow a long chain of stuff for new-style ddebs right now
<flexiondotorg> cjwatson, OK. Understood :)
<caribou> Any trick to investigate build failures caused by dependancies not being installed ?
<caribou> The Build-Depends-Indep: dblatex is correctly installed when I build with sbuild, but PPA builder doesn't want to include itg
<caribou> s/itg/it
<caribou> (on precise btw)
<geser> have you a link to a build log?
<caribou> geser: https://launchpadlibrarian.net/202635957/buildlog_ubuntu-precise-amd64.openafs_1.6.7-1ubuntu1.12.04.1_BUILDING.txt.gz
<caribou> geser: doesn't seem to install the Build-Depends-Indep
<caribou> geser: dkms & the other are not there either
<geser> caribou: but only for amd64, the build succeeded for i386
<geser> the amd64 build should only build arch-dep packages (indep is build by i386) and shouldn't need  B-D-I in the first place
<infinity> caribou: B-D-I is only installed when building arch:all packages.
<infinity> caribou: For local tests, that's "dpkg-buildpackage -B" versus "dpkg-buildpackage -b"
<cjwatson> Or sbuild --no-arch-all vs. -A
<caribou> cjwatson: -A is the answer, I got into the habit of *always* using this switch
<caribou> geser: infinity: thanks for the info
<infinity> caribou: Yeah, you should generally test once with -A, once without, if you're paranoid about getting it right.
<caribou> infinity: well, in that case, I'm paranoid about asking stoopid questions :-)
<LocutusOfBorg1> doko, hi, you there?
<LocutusOfBorg1> talking about the virtualbox gcc-5 build failure
<LocutusOfBorg1> I got the regression fixed tonight (I'm still testing the fix)
<LocutusOfBorg1> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693
<ubottu> gcc bug 65693 in rtl-optimization "[4.8/4.9/5 Regression] ICE in assign_by_spills, at lra-assigns.c:1419" [Normal,New]
<LocutusOfBorg1> do you think you can include in your next upload? do you fetch from trunk, right?
<LocutusOfBorg1> I'm building it locally ATM, not sure if I did everything correctly :)
<doko> LocutusOfBorg1, sure, but not this week
<LocutusOfBorg1> no problem, thanks!
<LocutusOfBorg1> the question was "do you fetch from trunk?" I'm wondering if they branched gcc-5 somewhere, and I don't want to look at svn jungle :)
<flexiondotorg> mvo, Please can you let me know when are you scheduled to pilot?
<infinity> doko: Is cgo disabled on powerpc intentionally, or is that an oops?
<Riddell> tseliot: david from sddm says they do restart X, pier says they do not but david says pier is wrong
<Riddell> sounds like a difficult topic :)
<ogra_> lol
<tseliot> Riddell: all I know is that XorgDisplayServer::stop() is not being called on log out, or I would see "Display server stopping..." in the log
<tseliot> Riddell: that's only called on shutdown, at least this is what I saw in my tests
<tseliot> Riddell: they stop X when they stop the greeter (in Display::stop() )
<mvo> flexiondotorg: what can I do for you?
<Riddell> tseliot: but not on logout?
<flexiondotorg> mvo, Hi :)
<flexiondotorg> mvo, Some sponsoring for Ubuntu MATE if possible. Got the time?
<mvo> flexiondotorg: I can squeeze it in, can you point me to the branches please?
<flexiondotorg> mvo, https://bugs.launchpad.net/ubuntu-mate/+bug/1439388
<ubottu> Launchpad bug 1439388 in mate-tweak (Ubuntu) "Updated translations for mate-tweak [debdiff attached]" [Low,New]
<flexiondotorg> mvo, https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1439380
<ubottu> Launchpad bug 1439380 in mate-menu (Ubuntu) "Updated translations for mate-menu [debdiff attached]" [Low,New]
<flexiondotorg> mvo, https://bugs.launchpad.net/bugs/1441030
<ubottu> Launchpad bug 1441030 in mate-control-center (Ubuntu) "Sync mate-control-center 1.8.3+dfsg1-2 (universe) from Debian unstable (main)" [Undecided,New]
<tseliot> Riddell: all I see is the Display::login() function, I really can't find the relevant logout function anywhere in the code
<tseliot> Riddell: so, either they have a hidden log out function that I can't find, or they simply stop X when they destroy the greeter object which, in turn, tells X to stop. It would help if somebody from sddm could confirm either theory
<hallyn> stgraber: https://bugs.launchpad.net/bugs/1392176
<ubottu> Launchpad bug 1392176 in linux (Ubuntu) "mounts cgroups unconditionally which causes undesired effects with cpu hotplug" [Medium,Confirmed]
<hallyn> odd thought that having kernel fix it would be uglier hack than quickly writing a hotplug listening daemon
<rbasak> Anyone have issues with Alt+<number> being swallowed since an upgrade to Vivid?
<rbasak> Anyone have issues with Alt+<number> being swallowed since an upgrade to Vivid? Esc <number> works but makes irssi pretty frustrating to use.
<Laney> rbasak: Check the "Switch to tab" keybindings in the preferences
<Riddell> tseliot: (alberto) meet sddm's d_ed (david)
<tseliot> hi d_ed
<infinity> rbasak: Terminal -> Preferences -> Shortcuts, to be exact.
<infinity> And I agree that eating Alt-anything is a dumb default. :/
<rbasak> Laney, infinity: that worked. Thanks!
<d_ed> tseliot: hey, my laptop died last week, so I don't have SDDM code at the moment. Cloning and looking now
<tseliot> d_ed: thanks. I was wondering what happens on log out and where the relevant code is, since I can't find a logout function, only login()
<d_ed> tseliot: so I can catch up, why should we be restarting X on logout?
<d_ed> yeah, logout is when the user session closes
<tseliot> d_ed: the thing is that, when switching between GPUs (hybrid graphics), we also need to switch to different libraries, and restart X to either enable or disable the discrete card, or X won't like it
<d_ed> m_auth is used to wrap both the greeter and the session environment
<d_ed> sorry, m_auth only wraps the session
<tseliot> d_ed: so what currently happens is that X is stopped only on shutdown (i.e. when the greeter stops), not on log out
<mvo> flexiondotorg: I uploaded both, thanks
<d_ed> yeah, there's a code comment here that makes no sense; we restart X depending on the return code of the session we started
<flexiondotorg> mvo, I just saw mate-menu and mate-control-center in #ubuntu-release. Many thanks!
<flexiondotorg> mvo, Anytime to look at mate-tweak too? - https://bugs.launchpad.net/ubuntu-mate/+bug/1439388
<ubottu> Launchpad bug 1439388 in mate-tweak (Ubuntu) "Updated translations for mate-tweak [debdiff attached]" [Low,New]
<tseliot> d_ed: where is that?
<mvo> flexiondotorg: sure, one sec
<flexiondotorg> mvo, Thank you :)
<d_ed> tseliot: Display::slotHelperFinished
<d_ed> this is called when the user session finishes
<d_ed> yet the comments don't reflect that
<infinity> doko: Nevermind my cgo question, was a gccgo-go thing.  Oops.
<tseliot> d_ed: so slotHelperFinished() is called when m_auth emits the finished signal i.e. when m_auth exits. Does m_auth exit on log out?
<d_ed> yes
<tseliot> d_ed: I don't see anything other than a black screen and a mouse pointer when I log out. Nothing in sddm.log either: http://paste.ubuntu.com/10783826/
<d_ed> oh
<tseliot> d_ed: [18:17:30.535] (II) DAEMON: Session started - was from when I logged in
<d_ed> you should have said
<d_ed> yeah, it's a bug I fixed last week
<d_ed> in
<d_ed> gnome keyring!
<tseliot> d_ed: oh, we need that fix then. Riddell ^
<d_ed> he's fixed it
<d_ed> I think
<d_ed> I assumed the fix was out
<d_ed> might be in ubuntu's staging or something
<d_ed> worst case remove the gnome-keyring line from /etc/pam.d/sddm
<tseliot> I'm updating my packages list to see if we have a new gnome-keyring...
<tseliot> d_ed: it seems to start even if I remove it from /etc/pam.d/sddm and there are problem upgrading here. But yes, the new package seems to be in the archive: https://launchpad.net/ubuntu/+source/gnome-keyring
<doko> infinity, cgo should be fully functional on powerpc now
<infinity> doko: Yeah, I had gccgo-go installed, which breaks the world.
<infinity> doko: Should probably have a Conflicts/Replaces from gccgo-5 to gccgo-go to force it off on upgrades.
<stgraber> infinity: so touchpad on the x240 works as it used to in trusty and utopic. If I turn off the touchpad, I can't click anymore at all. If the touchpad is on, I get the 3 buttons working but I can't scroll by using middle button + trackpoint.
<infinity> stgraber: Huh.  Is any of that a regression, or just a disappointing lack of progression?
<infinity> stgraber: Either way, I'd love to play with it in Austin when we both get there.
<infinity> stgraber: I have a feeling the top-button-touchpad models might just be problem children we can't enirely fix kernel-side, but I'd like to prove that theory wrong, given that we managed to fix the next generation.
<infinity> stgraber: And if we can fix just those ones via the X driver without messing with the new models, we should do that in the distro and ditch your hacks.
<stgraber> infinity: I don't think it's a regression, looks similar to what I had on stock trusty before going with the hacked up X driver. But yeah, we can certainly play with it in Austin and see if we can get something saner in the distro
<stgraber> infinity: my current hack is certainly unsuitable for the distro as it's about merging the synaptics and evdev code together in a single driver (which is about as ugly a hack as you can get :))
<infinity> stgraber: Yeah, I think I've seen some slightly more elegant hacks from synaptics upstream, we'll see if we can come up with something suitably targeted that obviously doesn't break the rest of the world in the process.
<infinity> stgraber: Do we know which models have that gross touchpad combo?  240, 440, 540, and X1C2?
<stgraber> infinity: yeah, sounds right. All the Haswell thinkpads
<hallyn> pitti: we need an equiv systemd unit to /etc/init/container-detect.conf.  whichnpkg should that go into? or does systemd already provide that?
<infinity> stgraber: FWIW, wgrant speaks rather highly of the *40 + *50 touchpad hybrid hack.  If you like real buttons.
<infinity> stgraber: But glad you have a non-hybrid to test on for now. :P
<infinity> hallyn: systemd has a check for containers.
<stgraber> infinity: yeah, still considering whether to do the hack or just ditch the 240 and switch to a 250 (just got to sell the 240 for that first)
<infinity> hallyn: ConditionVirtualization=container
<hallyn> ideally /bin/running-in-container could go inti init-shstem-helpers and work for both systemd and upstart
<infinity> hallyn: rgrep Virtual /lib/systemd/system
<hallyn> ideally /bin/running-in-container could go inti init-shstem-helpers and work for both systemd and upstart
<hallyn> grr
<hallyn> infinity: ill take a look at that thx
<hallyn> maybe running-in-container can use thT
<hallyn> and then apparmor can keep using that
<infinity> hallyn: If apparmor has a .service file, it should be using the Condition, not a hack.  If it's shipping an init script, I'd expect the current running-in-container to still work?  Or does it depend on upstart?
<infinity> Oh, it does.  status container-detect.  Ick.
<infinity> hallyn: So, a container-detect.service that only runs on the right condition would probably work.
<infinity> I guess.
<infinity> Gross hack, though.
<hallyn> infinity: yes, it seems just as well to move /bin/running-in-container to init-system-helpers and have it first check the systmd conditions, then the upstart ones
<hallyn> oh, i see.  systemd doesn't export htat information anywhere.
<infinity> hallyn: Probably, yes.  Bonus points if there's a sysvinit fallback too, but not really necessary in Ubuntu.
<infinity> hallyn: It could "export" it via having a unit with the right conditions that either starts or doesn't, so you could do the same status check.  But still feels super gross.
<hallyn> systemd-detect-virt
<infinity> Ah-ha.
<infinity> I assume that calls back to the same things that set those Conditions.
<infinity> So, that would be the "right" way.
<infinity> From outside the init system.
<infinity> Inside init, obviously the Conditions are the correct way.
<hallyn> right
<hallyn> but so i'll probably use that in running-in-container and move running-in-container from upstart->init-system-helpers.  That sound ok?
<infinity> Right.  And guard calling it with the usual [ -d /run/systemd/system ] check.
<infinity> Remember to bump the Breaks/Replaces on upstart/upstart-bin to the version where you remove the binary.
<infinity> And make it a << this time. :)
<hallyn> yup :)
<hallyn> thx, i'll do that in a bit when i have better internet
<infinity> hallyn: This has the potential side-effect that a bunch more packages might have grown an undeclared dep on init-system-helpers.  Do you have a handle on how many things call running-in-container?
<infinity> hallyn: (Granted, they probably all had undeclared deps on upstart before, so they're not getting much more broken, but we should still fix it)
<hallyn> i don't.  i was going to make upstart depend on init-system-helpers, but that's not perfect
<tseliot> d_ed: I've just reinstalled Kubuntu and log out works now (with today's image). I'll follow up on github for the merge request, as we can get hybrid graphics to work now. Riddell ^
<d_ed> thanks
<hallyn> infinity: it'll all do [ -x /bin/running-in-container ] && /bin/running-in-container as it does now, so nothing will be completel broken
<tseliot> d_ed: thanks for your help
<hallyn> just silently broken.  yay
<infinity> hallyn: Don't make upstart depend on i-s-h.  I'm running out the door, but we can talk about this more later this afternoon.
<hallyn> k
<hallyn> infinity: as far as the actual script, http://paste.ubuntu.com/10784798/ seems to work
<tseliot> d_ed: we're not quite there yet. sddm seems to stop. I'm not sure why http://paste.ubuntu.com/10784812/
<tseliot> d_ed: that's even before the greeter shows up (which it never does)
<hallyn> arges: time to scrap bug 1366868 ?
<ubottu> bug 1366868 in seabios (Ubuntu Trusty) "kvm: dompmwakeup fails if domain becomes pmsuspended" [Undecided,Fix committed] https://launchpad.net/bugs/1366868
<hallyn> oh, heh, you submitted it.  i was thinking you uploaded it
<infinity> hallyn: I'd probably write that as "if type=$(systemd-detect-virt -c); then echo $type; exit 0; else exit 1; fi", but to each their own.
<infinity> hallyn: Which allows them to add new container types without you having to fix the case statement.
<hallyn> infinity: oh, -c, hadn't noticed that.  sounds good
<infinity> hallyn: Double-check that -c exits non-zero under, say, qemu, but that's what I'd expect from the option and manpage.
<hallyn> infinity: yeah, it does
<hallyn> (fwiw this is bug 1442228)
<ubottu> bug 1442228 in lxc (Ubuntu) "lxc fails to start inside vivid container" [Critical,Triaged] https://launchpad.net/bugs/1442228
<hallyn> anyway it's getting late here so  i will either upload late after dinner, or tomorrow
<infinity> hallyn: Not sure you needed to keep my one-liner on a single line, that was just for the benefit of IRC. :P
<infinity> hallyn: Also, I realise it's cargo-cult from the previous iteration, but "if status foo; then thing; fi" is generally saner shell than "foo; if $?; then", since the latter is begging someone to miss the flow and insert a command between the call and the test.
 * hallyn looks
<hallyn> oh, that
<hallyn> yeah i'll re-flow it before uploading
<hallyn> at leset the one-liner;  the status one does get unwieldy if merged
<hallyn> well, not really i guess
<hallyn> so maybe http://paste.ubuntu.com/10786678/.
<infinity> hallyn: Yep, that looks nice.
<infinity> hallyn: The only other complaint would be the inconsistency between "type" and "[ -x", but pretty sure no one cares for a 23-line script. :P
<hallyn> infinity: upstart currently is Depends: init-system-helpers (>= 1.22ubuntu6) .  are you sure we dont' want to update that to make sure ppl don't lose /bin/running-in-container?
<hallyn> infinity: the -x is bc there are other 'status' programs
<infinity> hallyn: That guarantees nothing, as upstart isn't required to be installed.
<hallyn> so we really want to -x that path, whereas with the systemd tool i don't trust its path to never change
<hallyn> ok
<hallyn> not touching that then
<hallyn> ok, quick test build ... (http://paste.ubuntu.com/10787092/ and http://paste.ubuntu.com/10787094/)
<infinity> hallyn: Looks good, x2.
<infinity> hallyn: And the Breaks/Replaces will ultimately have the same effect as if you'd bumped the versioned dep anyway.  *shrug*
<hallyn> ok, this build test won't be very quick :(
<infinity> export DEB_BUILD_OPTIONS="parallel=$(nproc) nocheck"
<infinity> Because if you managed to break upstart's testsuite with this, lolz?
<hallyn> heh, no it's just that my vivid container is apparently behind and has huge update waiting
<hallyn> sigh, still going
#ubuntu-devel 2015-04-10
<hallyn> bleh
<hallyn> pod2man: unable to format script/dh_systemd_start.1p
<hallyn> pod2man: unable to format script/running-in-container
<hallyn> debian/rules:17: recipe for target 'override_dh_auto_build' failed
<hallyn> after dinner
<hallyn> interesting - upstart simply will not build on vivid with systemd.  make check fails
<arges> hallyn: i think i simply forgot about that bug.
<pitti> hallyn: so far we didn't need that, as there's ConditionVirtualization=
<pitti> ah, infinity already pointed to that
<pitti> that's for units, and systemd-detect-virt for scripts
<pitti> both of which are upstream, so we can eventually stop having the ubuntu specific container-detect.conf
<seb128> mvo, bdmurray, hey, is bug #1356823 something you are looking at? It's ranked issue nÂ°1 on e.u.c for vivid
<ubottu> bug 1356823 in aptdaemon (Ubuntu Vivid) "aptd crashed with AttributeError in _remove_from_connection_no_raise(): 'NoneType' object has no attribute 'Destroy'" [Medium,Confirmed] https://launchpad.net/bugs/1356823
<Odd_Bloke> dannf: Can you confirm that http://cloud-images.ubuntu.com/vivid/current/vivid-server-cloudimg-arm64-uefi1.img boots as you expect?
<Odd_Bloke> I've just tested it locally and it booted uninterrupted, but confirmation would be appreciated. :)
<seb128> Riddell, hey, bug #1442512 seems recent, maybe something wrong with your qt5 migration
<ubottu> bug 1442512 in apport (Ubuntu) "/usr/share/apport/apport-kde:11:same_key:QHash:value:QPropertyAnimation::updateState:setState" [Undecided,New] https://launchpad.net/bugs/1442512
<mvo> seb128: let me check
<seb128> mvo, danke
<Riddell> thanks seb128
<seb128> Riddell, yw!
<seb128> mvo, thanks for the fix ;-)
<mvo> seb128: thanks for raising the issue
<seb128> mvo, yw :-)
<LocutusOfBorg1> good morning
<Unit193> It'sabork.
<Odd_Bloke> I just hit "W: GPG error: http://archive.ubuntu.com vivid-updates Release: Unknown error executing gpgv"; anyone have any ideas what might be causing that?
<Odd_Bloke> (This is on a now-destroyed automated testing instance, so I can't do any poking around)
<pitti> tseliot: I'm fixing the ubuntu-drivers-common autopkgtests
<pitti> tseliot: is there an fglrx bug to track "known to not work with current vivid kernel/X.org" that I shouldl reference?
<tseliot> pitti: I think users file new bug reports about it every time
<pitti> ok
<pitti> tseliot: I just mark the two as expected failures for now, and fixed the others
<tseliot> pitti: fglrx shouldn't fail in vivid though. What's going on?
<pmjdebruijn> hi folks, I've been using live-build to make custom ISOs, which works reasonably well... however they do differ from official generated images in unexpected ways... genisoimage is used instead of xorriso for example
<pmjdebruijn> can anybody here shed some light on how official ubuntu ISOs are generated?
 * LocutusOfBorg1 hugs ginggs 
<ogra_> pmjdebruijn, live-build is only used for generating the rootfs (squashfs in case of the desktop isos) ... we have a master tool called cdimage that takes these rootfses and pipes them into debian-cd ... debian-cd then turns them into bootable images
<pmjdebruijn> aha
<ogra_> our configs for live-build live in the livecd-rootfs package btw
<pmjdebruijn> right
<pmjdebruijn> the live-build generated ISOs mis EFI support for example
<pmjdebruijn> ogra_: is there more documentation on that process, so I can replicate it?
<ogra_> https://code.launchpad.net/~ubuntu-cdimage
<ogra_> it isnt well documented beyond the source sadly, the setup is rather complex
<pmjdebruijn> ogra_: thanks for the hints
<caribou> debfx: would you have time to sponsor a backport to precise for openafs ? you've done the previous one
 * pmjdebruijn wonders if it'll be a better option to hack a bit on live-build :)
<tseliot> LocutusOfBorg1: I have just uploaded the fix for fglrx in utopic-proposed. The SRU team will have to approve it though
<pmjdebruijn> on another sidenote, anybody a clue why fonts-crosextra-caladea fonts-crosextra-carlito aren't included by default?
<pmjdebruijn> they are compatibility fonts (similar in concept to the Liberation fonts), but they replace Calibri/Cambria, which are popular in modern docx files
<pitti> tseliot: oh, not? well, the driver fails to build
<rbasak> pmjdebruijn: file a bug against the libreoffice package to recommend them, perhaps?
<tseliot> pitti: do you have any logs?
<pitti> tseliot: it was hidden by another error in the tests (apt slightly changed behaviour apparently), but with that fixed they fail
<LocutusOfBorg1> thanks tseliot
<pitti> tseliot: building manually, hang on
<tseliot> LocutusOfBorg1: np
<tseliot> pitti: ok. BTW it's the fglrx-core that builds the modules, not fglrx any more
<pmjdebruijn> rbasak: possibly, I was wondering if there was a general font-inclusion council or something? :)
<pitti> tseliot: oh! then I figure the test needs to be adjusted to that
<tseliot> pitti: right :)
 * pitti does that then
<pitti> oh, and please let's not paper over this by adding force-badtest in britney, please
<tseliot> ?
<pitti> tseliot: such a test override was added by the release team when u-d-c started failing
<tseliot> pitti: oh, ok
<dholbach> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<rbasak> pmjdebruijn: no idea. Ask in #ubuntu-desktop maybe?
<pitti> tseliot: ok, all fixed, and uploaded
<tseliot> pitti: thanks!
<LocutusOfBorg1> dholbach, hi, do you think I can ask to merge transmission/experimental?
<LocutusOfBorg1> it has finally fixed the systemd transition
<LocutusOfBorg1> https://packages.qa.debian.org/t/transmission/news/20150410T103425Z.html
<dholbach> LocutusOfBorg1, hum... Unable to find transmission in Debian suite "experimental".
<dholbach> ah, incoming
<dholbach> LocutusOfBorg1, sure - feel free to merge it!
<LocutusOfBorg1> thanks :)
<LocutusOfBorg1> I don't think the actual transmission can rebuild in vivid clean environment
<LocutusOfBorg1> pitti, did libsystemd-daemon-dev still exist in vivid?
<pitti> LocutusOfBorg1: it still does, yes (although deprecated)
<LocutusOfBorg1> I have some code that does sd_notify and on debian I add -lsystemd, on utopic -lsystemd-daemon
<LocutusOfBorg1> what on vivid?
<pitti> LocutusOfBorg1: libsystemd-dev and -lsystemd are preferred
<LocutusOfBorg1> on utopic doesn't work :(
<pitti> LocutusOfBorg1: libsystemd-daemon-dev is just for backwards compat
<pitti> LocutusOfBorg1: no, but we are talking about vivid here, don't we?
<LocutusOfBorg1> wonderful, so after utopic systemd will be really unified
<LocutusOfBorg1> I like it
<LocutusOfBorg1> wow a new systemd upload! :)
<mbiebl> LocutusOfBorg1: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintainers@lists.alioth.debian.org;tag=libsystemd
<LocutusOfBorg1> yes mbiebl; I was looking at debian 763297 already
<ubottu> Debian bug 763297 in release.debian.org "transition: libsystemd" [Normal,Open] http://bugs.debian.org/763297
<mgedmin> cyphermox, https://bugs.launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/+bug/1442586 looks like one for you (according to seb128)
<ubottu> Launchpad bug 1442586 in gfxboot-theme-ubuntu (Ubuntu) "gfxboot-theme-ubuntu needs an update with new translations export" [Undecided,New]
<nemo> http://www.bq.com/fr/ubuntu.html  *sigh*
<nemo> EU only
<ogra_> nemo, where would you want it beyond that ?
<ogra_> the radio is limited to EU frequencies
<nemo> there are EU-specific frequencies? O_o
<nemo> http://en.wikipedia.org/wiki/GSM_frequency_bands huh...
<nemo> guess all my other phones work across any bands
<nemo> anyway. doesn't seem to be EU exclusive
<nemo> "In Africa, Europe, Middle East and Asia, most of the providers use 900 MHz and 1800 MHz bands."
<shadeslayer> mvo: pokety poke @ kubuntu-core :(
<ogra_> well, the point is you can only get 2G in the US with it
<nemo> 2G GSM (850/900/1800/1900)
<nemo> 3G HSPA+ (900/2100)
<nemo> off the phone specs
<nemo> so. GSM-1900 is used in US and Canada according to that wikipedia page
<nemo> ah. 2G. eh. who cares
<nemo> still take it
<ogra_> btw, #ubuntu-touch is our phone channel
<nemo> anyway. looks like it really is "Works in most of world for 3G, and Americas for 2G" so that doesn't quite the same as "EU only"
<nemo> m'k. thanks.
<ogra_> well, there is that FCC thingie too :)
<nemo> again that seems to presuppose the world consists of US and EU
 * nemo shrugs
<nemo> anyway. what I gather is that it probably would work if I ordered it
<ogra_> i think someone said he spotted one or two on ebay
<Sweet5hark> Hi, Im looking for someone from the ubuntu-sru team. This one should actually be rather easy: can you drop the pending LibreOffice 4.2.8/trusty update?  https://launchpad.net/ubuntu/+source/libreoffice/1:4.2.8-0ubuntu1
 * Sweet5hark hopes that dropping an SRU is easier than approving one ...
<pmjdebruijn> anything wrong with that?
<Sweet5hark> pmjdebruijn: are you asking about the libreoffice SRU?
<pmjdebruijn> yes (though I'm not from the ubuntu-sru team, just a curious bystander)
<Sweet5hark> pmjdebruijn: nothing wrong with the package itself functionally, just the changelog has a misleading line and I try to avoid LTS people to have needlessly too many updates as a new one will be there soon ...
<pmjdebruijn> ah cool :)
<pmjdebruijn> btw, tnx for your work on the lovely libreoffice ppas :)
<Sweet5hark> yeah, those are for the guys who cant get enough updates ;)
<pmjdebruijn> hehe
<pmjdebruijn> well, for some applications it's rather nice to get out-of-band updates for file format compatibility and such
<pmjdebruijn> Sweet5hark: on a different note, slightly abusing the situation, now you're here, are you aware of fonts-crosextra-caladea and fonts-crosextra-carlito? they might be nice Recommends for libreoffice
<LocutusOfBorg1> why pbuilder-dist vivid has upstart installed^
<LocutusOfBorg1> ?
<LocutusOfBorg1> pitti, ^^^ :)
<fionnan> anyone know of a good guide for using docker on ubuntu snappy?
<Sweet5hark> pmjdebruijn: on libreoffice 4.4 packages those are Suggests of libreoffice-writer ...
<LocutusOfBorg1> I was trying to undestand why sid has no cpio by default and ubuntu has, and upstart seems to be the clue
<pmjdebruijn> Sweet5hark: oh? doesn't everybody ignore Suggests? I really meant Recommends though :)
<pmjdebruijn> they are very very nice to have installed if one comes across docx files
<mitya57> Recommends will mean pulling those fonts into the desktop images, which will increase their size
<pmjdebruijn> is that currently a significant issue? considering the 700MB boundary has already been crossed?
<davmor2> Sweet5hark: https://developer.ubuntu.com/en/snappy/guides/ maybe?
<pmjdebruijn> those two font package can be very helpful in making "document look right" on ubuntu by default
<pmjdebruijn> and they will add less than 3MB uncompressed
<davmor2> Sweet5hark: sorry that was for fionnan
<davmor2> fionnan: https://developer.ubuntu.com/en/snappy/guides/
<fionnan> davmor2: cheers
<davmor2> fionnan: no guarantee but it's a good place to start
<fionnan> davmor2: yup, I've read through most of those docs and they're really helpful, just a bit stuck trying to get docker to load a file now
<fionnan> incidentally, I think I've found a mistake in the documentation here https://developer.ubuntu.com/en/snappy/guides/
<fionnan> I think this line `ec2-import-keypair -f ~/.ssh/snappy-rsa snappy-key`
<fionnan> should be `ec2-import-keypair -f ~/.ssh/snappy-rsa.pub snappy-key`
<davmor2> fionnan: there should be a report an issue button on the bottom of the page that should take you to launchpad with the page details in the bug
<fionnan> davmor2: thanks, found it!
<pmjdebruijn> Sweet5hark, mitya57 those extra fonts are particularly valuable in business environments
<mitya57> pmjdebruijn: Please read https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps carefully.
<mitya57> These fonts packages are the exact case for "Suggests"
<rbasak> One use case for the libreoffice package is to provide an equivalent for MS Office. If the fonts provide the equivalent of defaults for Word, then maybe " The Recommends field should list packages that would be found together with this one in all but unusual installations." is justified?
<rbasak> Use case "I receive an emailed .docx and expect it to open and print identically as it appeared to the sender".
<seb128> dpm, pitti, do you know if there is an issue with the vivid langpack? they didn't get an update for a while, https://launchpad.net/ubuntu/+source/language-pack-gnome-fr for example is from 20150316
<fionnan> anyone know if there is a channel for snappy noobs to ask for help?
<pmjdebruijn> rbasak: yes, @use-case, that's exactly what everybody expects
<rbasak> pmjdebruijn: if a bug doesn't already exist, I suggest you file one and make your case there.
<pmjdebruijn> fair enough
<pmjdebruijn> against libreoffice then, right?
<rbasak> Yes
<rbasak> I suggest you cover in detail the bits that you're summarised here. Eg. the default font as will appear on a .docx.
<dpm> seb128, I don't know, I've be been a bit out of touch with langpacks lately, sorry
<dpm> fionnan, indeed there is, try #snappy
<seb128> dpm, no worry
<fionnan> thank dpm!
<fionnan> s/thank/thanks/
<seb128> dpm, btw it might be worth pointing the translators the click store categories, I did it to the -fr team and they already translated those ;-)
<cjwatson> seb128: There was a problem with the langpacks key being out of date on the keyserver - pitti fixed that, but I don't know if there's been a retried upload since
<seb128> cjwatson, ok, thanks, who can retry? is that a pitti thing?
<dpm> seb128, I know, it's back on my list after you and ogra were looking at the template yesterday, but busy day today
<cjwatson> seb128: Not as simple as a retry, apparently ...
<cjwatson> 2015-04-06 05:23:32 INFO    Failed to parse changes file '/srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20150406-052225-005790/ubuntu-rtm/language-pack-touch-ast_14.10+rtm14.09+20150405_source.changes': GPG verification of /srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20150406-052225-005790/ubuntu-rtm/language-pack-touch-ast_14.10+rtm14.09+20150405_source.changes failed: Verification failed 3 times: ["(7, 153, u'Key ...
<cjwatson> ... expired')", "(7, 153, u'Key expired')", "(7, 153, u'Key expired')"]
<seb128> :-(
<cjwatson> Odd - the keyserver itself seems to have accepted the expiration update
<cjwatson> Oh, wait, that log is four days old
<cjwatson> pitti pushed the update on 2015-04-08
<cjwatson> seb128: So yeah, I think it's a pitti thing to retry
<seb128> cjwatson, great, thanks for looking
<rbasak> infinity: looks like powerpc failed for lack of the same syscall number as your arm64 fix. https://github.com/docker/libcontainer/pull/517 suggests you're working on it already?
<mvo> shadeslayer: meh, sorry, incredible busy currently :/
<shadeslayer> :(
<shadeslayer> Can I bribe you with chocolate
<shadeslayer> :P
 * shadeslayer is trying to setup his own live-build scripts to build a rootfs at the moment
 * pmjdebruijn uses the ubuntu-defaults-builder wrapper around live-build
<shadeslayer> pmjdebruijn: won't work for making just a plain rootfs
<shadeslayer> which is why I need to do more customizations
<shadeslayer> looking at https://git.linaro.org/ci/ubuntu-build-service.git/blob/HEAD:/sid-armhf-debian/configure
<pmjdebruijn> ah nevermidn then
 * pmjdebruijn hides back in his corner
<soee_> tseliot: i have info from Riddell that you are working on nvidia drivers for 15.04? Could you give me some info what is the current problem - why they wont work (bootking ends with black screen)?
<flexiondotorg> What is the mechanism for re-opening a bug on LP?
<flexiondotorg> As of today's daily images this is broken again - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1436937
<ubottu> Launchpad bug 1436937 in ubiquity (Ubuntu) "Temporary OEM user not removed after end user setup" [High,Fix released]
<tseliot> soee_: I think I've just got it to work with hybrid graphics now. But I would still like to fix the memory leak of the displayScript qProcess never being deleted
<soee_> tseliot: cool, so it all shoudl work before Vivid final release ?
<tseliot> QProcess::startDetatched seems to fail too
<tseliot> soee_: I certainly hope so
<soee_> tseliot: wo what packages it is related ?
<tseliot> soee_: right now the only part missing (my patch does it) is a hook in sddm to run a script on log out
<tseliot> so sddm is the package
<sunweaver> Trevinho: hi!
<Trevinho> sunweaver: hi
<sunweaver> I am DD in the Debian MATE packaging team and want to take over maintenance for bamf in Debian.
<Trevinho> sunweaver: oh, finally someone! :)
<sunweaver> I see there is a 0.5.0 tarball on the launchpad project page.
<sunweaver> but you ship some 0.5.1 version in Ubuntu versions already.
<Trevinho> sunweaver: yep, it's not the latest tough
<Trevinho> sunweaver: yes, you need a release?
<sunweaver> actually yes.
<sunweaver> esp. one that works without libunity-webapp.
<Trevinho> ricotz: was asking the same few days ago...
<sunweaver> ;-)
<sunweaver> ricotz actually enrolled me in maintaining bamf...
<Trevinho> sunweaver: well, even that one does not need it (it's an optional dependency)
<sunweaver> yeah, I see that.
<sunweaver> I checked out the latest (V-series) package in Ubuntu
<sunweaver> and saw that unity-webapp stuff has been reduced to a minimal.
<sunweaver> I'd be happy about something recent as a tarball release.
<Trevinho> sunweaver: so... I can do that in a bit...
<Trevinho> sunweaver: yes, actually we could even remove it at all
<sunweaver> whatever...
<sunweaver> ping me here, once I can run uscan --report-status again... ;-)
<sunweaver> 0.5.x will be pushed to Debian experimental first.
<sunweaver> then plank will receive an update 0.9.x
<Trevinho> sunweaver: ok, nice
<soee_> tseliot: thank you for this informations
<sunweaver> and if that works well and we don't pee on someone else's package (have to check reverse build dependencies in Debian still), I will upload to unstable.
<tseliot> soee_: np
<sunweaver> Trevinho: thanks! Waiting for a ping from yours.
<Trevinho> sunweaver: there are a couple of branches that are waiting also, so maybe it's better to include these as well
<tseliot> Riddell: so, now it even works on log out here. I only need to close that leak that was already there
<Riddell> tseliot++
<Trevinho> it might take some more time to get the builders but, not much
<sunweaver> Trevinho: take your time.
<sunweaver> I just wanted to get the stone rolling...
<cousteau> can this bug with libcairo be fixed for Ubuntu 12.04?  https://bugs.launchpad.net/inkscape/+bug/759154
<ubottu> Launchpad bug 759154 in Inkscape Devlibs "Open paths with aligned endpoints are closed in cairo-based exports (PDF/PS/EPS)" [Medium,Triaged]
<dholbach> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<tseliot> d_ed: I think I've fixed the two issues. All seems to work fine. See my last commit
<tseliot> Riddell: so, I have a couple of patches that I can merge into one (since they really complete hybrid graphics support). That patch + "DisplayStopCommand=/sbin/prime-switch" in the conf file should do it
<Riddell> tseliot: awooga
<tseliot> Riddell: here's the unified patch: http://people.canonical.com/~amilone/0001-Add-support-for-DisplayStopCommand.patch
<tseliot> I can now switch between GPUs when I log out :)
<d_ed> tseliot: do you plan on updating the github request?
<infinity> rbasak: Yeah, I'll fix powerpc and upload.
<infinity> rbasak: Well, "fix" powerpc.  I'll fix upstream's code so it builds, but I think the toolchain has some issues that make the binaries a bit broken. :P
<rbasak> infinity: OK, thanks.
<pitti> cjwatson, seb128: RTM langpacks are working now, so the LP import for the updated key took < Â½ day
<pitti> ah, vivid langpacks are behind too? they only run weekly
<pitti> I'm on the road now, but opened a tab as a reminder; I'll prod this in the next days (probably on Sat or so when I arrived in Austin)
<tseliot> d_ed: I did
<tseliot> d_ed: but I did git push -f as I had previously pushed the wrong commit
<d_ed> tseliot: ah, found it on your repo. The pull request still shows the one from 8 days ago
<d_ed> I don't understand github yet
<soee_> d_ed: i think if tseliot updates hes branch that had pull request it pull request wont be updated
<soee_> or maybe i wrong since i havent been using github for a while
<soee_> well i was wrong i think, pull request contains both commits https://github.com/sddm/sddm/compare/master...tseliot:master
<tseliot> soee_, d_ed: the pull request should contain the two relevant commits. But yes, they are also in my master branch
<soee_> tseliot: so it has to be only merged now ?
<tseliot> soee_: yes. Then Riddell will include the changes and add DisplayStopCommand=/sbin/prime-switch in scripts/Xstop or in the .conf file
<soee_> tseliot: who can merge it ?
<tseliot> soee_: ok, so, if we're talking about upstream, d_ed can. In Ubuntu, Riddell will deal with it
<Riddell> tseliot: you also need to edit data/CMakeLists.txt to install Xstop
<Riddell> tseliot: uploaded to archive https://launchpad.net/ubuntu/+source/sddm/0.11.0-0ubuntu10
<asac> apw: ogasawara: so i have a kernel source package by paolo and wonder where i can find the config he uses in there
<asac> where do i look?
<asac> ogra_: slangasek: any idea?
<infinity> asac: Getting it out of the source package is actually sort of tough, cause it's a split config.
<infinity> asac: If you build a binary package, though, it's installed at /boot/config-$(uname -r)
<asac> oops
<asac> ok lt me try to find it in https://launchpad.net/~p-pisati/+archive/ubuntu/misc/+files/linux-image-3.19.1-4-generic-bcm2709_3.19.1-4.4_armhf.deb
<asac> infinity: thanks ... got it!!!
<infinity> asac: NP.
<asac> infinity: so i found he doesnt have CONFIG_BLK_DEV_DM
<asac> how can i enable it?
<asac> that looks really to make sense from the error i am getting
<asac> [  348.917047] device-mapper: table: 254:0: thin-pool: unknown target type
<asac> [  348.924052] device-mapper: ioctl: error adding target to table
<infinity> (base)adconrad@cthulhu:~/build/linux/ubuntu-vivid$ rgrep CONFIG_BLK_DEV_DM debian.master/
<infinity> debian.master/config/config.common.ubuntu:CONFIG_BLK_DEV_DM=y
<infinity> debian.master/config/config.common.ubuntu:CONFIG_BLK_DEV_DM_BUILTIN=y
<infinity> debian.master/config/annotations:CONFIG_BLK_DEV_DM                              y mark<ENFORCED> note<LP:#560717>
<infinity> asac: If that's based on a master config, it should be enabled, unless he's explicitly disabled it for your flavor.
<asac> infinity: its not in the boot/config
<asac> infinity: its something derived from a nice BSP kernel :)
<infinity> asac: If it's not based on a master config, well.  Whee.  But root around in debian.$flavour/config
<asac> https://launchpad.net/~p-pisati/+archive/ubuntu/misc/+files/linux-bcm2709_3.19.1-4.4.dsc
<Unit193> FWIW, in upstart sshd is Restart=always, but in systemd it is Restart=on-failure.
<tseliot> Riddell: right, I tested using sddm.conf, so I didn't catch that. I'll fix that
<soee> tseliot: did you tried propriety drivers ?
<tseliot> soee: yes, I tested that with intel+nvidia binary (hybrid graphics)
<soee> tseliot: just tires it with updated sddm, ends up witb black screen when sddm shoudl load
<soee> *tried
<tseliot> soee: what hardware configuration are you using?
<soee> tseliot: dell witg intel  + nvidia
<tseliot> soee: is that vivid?
<soee> tseliot: yes
<soee> all worked fine in utopiv when we had lightdm
<soee> *utopic
<soee> after switch to sddm i couldn't use nvidia profiel anymore
<tseliot> soee: make sure ubuntu-drivers-common is at least 1:0.4.2
<soee> Installed: 1:0.4.4
<soee> also when i switch to nvidia profile and try to boot
<tseliot> soee: can I see /var/log/gpu-manager.log and /var/log/Xorg.0.log?
<soee> tseliot: http://paste.ubuntu.com/10794728/
<soee> tseliot: and http://paste.ubuntu.com/10794734/
<soee> i just uninstalled nvidia-prime and drivers because i culdnt boot
<tseliot> soee: you're using intel+nouveau, there's no nvidia. Also no nvidia-prime means no functioning nvidia binary on your system
<soee> tseliot: yes i remoed them to be able to boot
<soee> i couldn;t login but here the problem was that somehow .Xauthority changed owner to root
<soee> so sddm could not login me
<tseliot> soee: ok, please wait until all is in place (sddm, including the Cmake addition, and the change in XStop), then try again
<tseliot> I think we'll fix it next week
<soee> tseliot: i tried nvidia-prime + new sddm and i could login
<soee> after i have installed propriety drivers, black screen only
<soee> reboot
<soee> tseliot: without drivers i can login but http://paste.ubuntu.com/10794811/
<tseliot> Riddell: I've just made another merge request to fix CMakeLists.txt: https://github.com/sddm/sddm/pull/399
<tseliot> soee: as I said, it's better if you wait until everything is in place
<tseliot> d_ed: see https://github.com/sddm/sddm/pull/399
<d_ed> tseliot: thanks
#ubuntu-devel 2015-04-11
<Unit193> james_w: Can I poke you about https://bugs.launchpad.net/bzr-fastimport/+bug/1014291?  It's still valid and the patch still fixes the issue.
<ubottu> Launchpad bug 1014291 in Bazaar Fast Import "Export from bzr / Import to git results in a deleted file re-appearing" [Undecided,New]
<Unit193> lp 430347, lp 268933 being somewhat related.
<ubottu> Launchpad bug 430347 in Bazaar Fast Import "Delete of entry in renamed directory not reproduced correctly in fast-export" [Medium,Triaged] https://launchpad.net/bugs/430347
<ubottu> Launchpad bug 268933 in Bazaar Fast Import "bzr-fast-export exports rm+mv incorrectly" [Medium,Confirmed] https://launchpad.net/bugs/268933
<dontdieych> Hello, I have question about patching ubuntu asterisk package with additional patch. Plz drop me any clue about this. https://gist.github.com/dontdieych/e15561c835d30b858ab8
<lucas> what was the name of the ubuntu webapp used to collect improvement requests from users?
<lucas> in approx 2008-2012
<melodie> hi
<melodie> I would like to ask if, considering the actual state of methods in Ubuntu Trusty, it would be possible to get the new user's default configuration to be copied *from a /usr/share/that_remix* to his home directory : in an Openbox only remix ?
<melodie> I have looked into the adduser.conf file and found there is only /etc/skel mentioned
<melodie> I know all the official Ubuntu versions have their configs in the /usr/share directory. I just have no idea what configuration file makes them copied to the new user's directory, so if someone could point me in the right direction?
<hjd> lucas: Sounds like you're thinking about Brainstorm (http://askubuntu.com/questions/321289/ubuntu-brainstorm-site-down-dead)
<rbasak> melodie: in general we don't do it that way. Instead stuff is arranged to default to the right thing in the absence of something relevant in the user's home directory.
<rbasak> So I don't think there's any existing mechanism that you can be pointed to, except maybe that packages could drop things into /etc/skel in theory.
<melodie> rbasak so far no one could tell me how stuff is arranged to default to "the right thing" :D
<melodie> I have had a look at the files in Lubuntu, and it seems very very complex
<melodie> with files in /etc/xdg/lubuntu which are desktop files (I think I remember, not even sure now what type) and files into /usr/share/lubuntu
<melodie> but what makes it go there, no idea
<melodie> and also there is this user file always recreated in the user .config/openbox/ directory: lubuntu-rc.xml pointing to the files in /usr/share/lubuntu/rc.xml : impossible to get rid of it when trying to make a pure openbox session and tweak it.
<melodie> I guess I will just have to make a test iso to see how things are going
<lucas> hjd: ah thanks!
#ubuntu-devel 2015-04-12
<nabukadnezar43> hello, i was wondering whether systemd is default on ubuntu 15.04?
<nabukadnezar43> or rather "will" be default?
<Noskcaj> sidi_, Are the issues in bug 1439685 in ubuntu? We're carrying a few patches. Also, are .1 and .2 safe for an upload this late in the cycle? we only have 3.14
<ubottu> bug 1439685 in gpaste (Ubuntu) "Please update package to 3.14.3" [Undecided,New] https://launchpad.net/bugs/1439685
<sidi_> Noskcaj, sorry im unaware of an existing bug, I only know upstream fixed it
<sidi_> talked to the dev
<sidi_> s/he told me the .3 release was exclusively about fixing the memory corruption when copying images
<sidi_> Noskcaj, oh sorry, re-reading. No the bug was upstream, but 3.14.2 is generally unusable, and shouldnt be used
<sidi_> to the point where I would backport that if I was maintaining a distro. 3.14.3 is *not* a feature release in any case
<Noskcaj> unfortunately, .1 is a feature release. I don't use gnome, so i can't test if affects ubuntu.
<sidi_> Noskcaj, it's a systematic memory corruption, 100% reproducible. it affects everyone everywhere and vivid is shipping that broken version
<Noskcaj> sidi_, I'll take a look up upstream git and package it
<Noskcaj> sidi_, It might be worth having your patch apply on ubuntu's gpaste, not upstream 3.14.2
<infinity> Noskcaj: I was going to suggest that an FFe might be appropriate, but looking more closely at the 3.14 -> 3.14.3 diff, upstream broke ABI without an SONAME bump, which doesn't inspire confidence.
<Noskcaj> infinity, That's why i wasn't going 3.14 -> 3.14.3
<Noskcaj> I was wanting to just backport upstream's 3.14.2->3.14.3 changes, which i think is what sidi_'s patch is
<Unit193> https://bugs.launchpad.net/ubuntu/+source/mariadb-10.0/+bug/1429725/comments/10
<ubottu> Launchpad bug 1429725 in mariadb-10.0 (Ubuntu) "package mariadb-server-10.0 10.0.16-2~exp1~ubuntu1 is uninstallable" [High,Confirmed]
<YokoZar> Is it too late to sync a package?  I just noticed we still have an ancient ubuntu version and the debian one is better
<Unit193> You can requestsync it, at least.  Is it a minor package?  Just fixes or new features?
<YokoZar> Fixes
<Unit193> Well, you're going to have to tell them the name, request a sync, or something.  ESP won't work.  And, I do hope so, the mariadb package in Ubuntu is kind of full of fail.
#ubuntu-devel 2016-04-11
<cpaelzer> good morning
<pitti> juliank: the libgcrypt20 libs and its deps libgpg-error0 and libc6 don't have any conflicts/breaks
<pitti> Unit193: yes, but as I said with sysv init scripts there is no generic fix as the scripts don't declare how they behave
<pitti> Good morning
<Mirv> flexiondotorg: mate-menu and mate-session-manager in unapproved queue now
<andrewsh> hello guys
<andrewsh> how do NMUs and sponsored uploads work in Ubuntu?
<andrewsh> in other words,
<andrewsh> if the maintainer isn't responsive, and I have a bug to fix, and a patch fixing the bug, and a bzr branch with that fix and a bunch of packaging improvements, and it's a Ubuntu-only package (not in Debian), who should I prod to get that uploaded?
<dholbach> andrewsh, subscribe the 'ubuntu-sponsors' team to the bug report
<dholbach> and thanks for fixing it!
<andrewsh> dholbach: okay, I did. also, is creating something like this the right thing? https://code.launchpad.net/~andrew.sh/adium-theme-ubuntu/adium-theme-ubuntu-lp1235472/+merge/291487
<andrewsh> oops, it seems I proposed the merge to a wrong repository
<cjwatson> Often better to just attach a patch.
<cjwatson> The bzr import infrastructure is creaky and failing and due for replacement.
<andrewsh> cjwatson: I attached patches, but there are more changes in the branch
<andrewsh> as I fixed up the packaging too (so I could build my own package version locally)
<cjwatson> andrewsh: My advice stands :)
<cjwatson> You can always attach a debdiff against the previous source
<cjwatson> Then you also won't get confused about which branch to merge into (since there really isn't a correct target branch now)
<andrewsh> ha
<mwhudson> if you want to work in a vcs locally, you can always gbp import-dsc to make a git repo to play around in
<Laney> infinity: merci for the glib2.0 fix
<Laney> Guess I should have downloaded an lp chroot eh
<infinity> Laney: It's not the chroot that needed fixing, it's the base system.
<infinity> Laney: As in, the machine running sbuild.
<Laney> oh, wat
<infinity> Laney: Turns out that systemd without libpam-systemd ends up putting everything in one tiny little cgroup of doom, and you can fork bomb yourself into oblivion with zero effort.
<andrewsh> mwhudson: which is nearly what I did initially (I just did git add . & git commit)
<andrewsh> &&, even
<infinity> (Awesome design)
<mwhudson> andrewsh: ah yep, that works too i guess :)
<smb> cjwatson, Do we already have a bug report for Ubuntu about needing changes in (backported, too) apt-cacher-ng to handle by-index?
<cjwatson> smb: It's already fixed in xenial.  I'm not aware of a bug about SRUs.
<cjwatson> (by-hash, not by-index, BTW)
<smb> cjwatson, sorry confused the terms. So I probably need to open one as well
<smb> Since the proxy likely runs on not Xenial
<cjwatson> smb: Makes sense.
<cjwatson> I had enough to do, but feel free :)
<pitti> smb: add SRU tasks, please don't open new bugs specifcially for SRUs
<andrewsh> cjwatson: well, I did as you suggested :)
<andrewsh> I hope that fix still can get into the release
 * andrewsh is very afraid of jumping in right before the release after having to argue with jcristau in Debian :)
<smb> pitti, how to do that if the problem has already been fixed in Xenial?
<infinity> pitti: There wasn't an LP bug for https://launchpad.net/ubuntu/+source/apt-cacher-ng/0.8.9-1ubuntu1
<infinity> smb: Just go ahead and file one.
<pitti> ah, it was a Debian bug, ok
<smb> bug 1568754
<ubottu> bug 1568754 in apt-cacher-ng (Ubuntu) "Backport request to support by-hash in apt-cacher-ng" [Undecided,New] https://launchpad.net/bugs/1568754
<infinity> smb: s/backport/SRU/
<infinity> Oh, you do mention the SRU later.
<smb> infinity, bah actually I had thought I removed that part before
<smb> I fixed it now
<infinity> smb: There, accepted your tasks and linked the xenial fix.
<smb> infinity, ack, thanks
 * infinity goes to get some sleep; it's going to be a long week.
<alkisg> pitti: hi, could I please ping you again about LP: #1487679? It appears to be Ubuntu specific, not solvable from the nbd-client side, as *any* sysvinit service (not only rcS ones) that has *only* the "Required-Start: $network" header, creates a dependency cycle.
<alkisg> I think the Ubuntu-specific network-manager patches are to blame for this.
<ubottu> Launchpad bug 1487679 in nbd (Ubuntu) "Breaking ordering cycle by deleting job nbd-client.service/start" [Undecided,Triaged] https://launchpad.net/bugs/1487679
<pitti> alkisg: our nbd package is unmodified, so Debian's is in rcS too
<alkisg> pitti: yes, and it works fine in debian
<alkisg> It doesn't create a cycle
<pitti> well, I doubt that
<alkisg> I tried in Stretch and I saw no complains
<alkisg> But even if I remove the rcS bit from its headers, I still get a dependency cycle in ubuntu
<alkisg> So I think that this issues is different from the one you have in mind
<pitti> the difference might be that in Debian NetworkManager-wait-online.service is not enabled by default
<pitti> so NetworkManager does not block network-online.target
<alkisg> Let me try to disable that in Ubuntu...
<alkisg> systemctl disable?
<pitti> well, this isn't a solution
<alkisg> Just to see if it's a symptom
<pitti> if you use NM, then NM-wait-online must be enabled, otherwise the whole idea of network-online.target breaks
<alkisg> In comment #8, I mention the 2 lines that are different in ubuntu vs debian, that I applied to debian and caused the issue there too
<alkisg> -After=network-pre.target dbus.service, +Wants=network.target, +Before=network.target
 * pitti followed up to the bug
<alkisg> Ty!
<rbasak> xnox: any progress with the rsyslog FTBFS please?
 * rbasak is trying to get all libmysqlclient18 rdepends rebuilt for src:mysql-5.6 removal.
<infinity> rbasak: I fixed it with the same thing that fixed glib2.0 ... You're welcome.
<rbasak> Thanks!
<pitti> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160401-xenial.html should really show when a newer version is sitting in -proposed
<cpaelzer> rbasak: I've a few dpdk fixes piling up - personally I'd like to wait until upstream settled on a "final" fix (preliminary available)
<cpaelzer> rbasak: looking at the Final Freeze I wonder if it would be recommended to prep and do the upload in the state as is
<cpaelzer> rbasak: and only SRU in case it changes or any follow-on issues are identified?
<xnox> pitti, cyphermox - is it normal for dbus messages from networkmanager to/from dnsmaq to be rejected? bug #1568787
<ubottu> bug 1568787 in network-manager (Ubuntu) "resolveconf does not reliable receive nameserver information from network manager" [Undecided,New] https://launchpad.net/bugs/1568787
<pitti> xnox: not sure if it's "normal", but I think we've had these for quite some time
<xnox> pitti, my problem is that every once and a while i loose nameserver resolution and I am struggling to debug it. E.g. i am connected to wifi & vpn, all via network-manager yet my nameserver settings do not appear to be in the dnsmasq that is running on 127.0.1.1 and then i am at a loss.
<seb128> speaking about n-m, cyphermox I guess you saw that the update is blocked on proposed due to autopkgtest issues?
<xnox> no actual config files in /run/NetworkManager that are helpful.
<xnox> i wonder if new NM is better.
<infinity> xnox: Did you catch my ping in backscroll about s390x booting degraded because cpacfstatsd.service fails?
<xnox> infinity, i have not. and that's not nice indeed.
<xnox> infinity, i'll take a look now.
<infinity> xnox: We might also want to look at breaking up s390-tools even further.  Or something.  It's trying to pull stuff into minimal that really doesn't seem minimal (perl, sg3-utils...)
<infinity> xnox: But I'll talk to you about that after I've slept.
<infinity> libfuse2 ... Why does s390-tools want fuse? :P
 * infinity goes to bed.
<cpaelzer> to infinity 's dreams - I think they fuse-mount their dumps via zgetdump -m
<tjaalton> any idea why zsh in xenial tab-completes usb-media like "/media/tjaalton/Ubuntu$'\001'6.04\ LTS\ amd64"?
<tjaalton> hm, it's just for umount
<smb> mvo, Bothering you because your name is somehow attached to the whole thing. I think I saw this in other places but cannot remember where. Right now there seems to be a common behaviour in Xenial that one does an apt-get update and gets a "AppStream cache update completed, but some metadata was ignored due to errors." Do you know whether some fix is already on its way?
<smb> And could it be that this is about trying to get dep11/Components-<arch>.yml but only having a dep11/Components-<arch>.yml.gz in the archive
<mvo> smb: unfortunately I don't know the answer to this, I would have to dig, but maybe Laney knows, he was working on this particular integration
<Laney> https://github.com/ximion/appstream/issues/32
<smb> Laney, Hm... yes that one. Guess that means no fix yet. Not sure this helps but I see some messages when having apt-cacher-ng in the pipeline which look like its probably missing the compressed Components
<smb> At least there are unsuccessful attempts to access the *.yml uncompressed file variant
<Laney> That would be a different problem
<Laney> the message on that bug report comes after an apt update
<smb> Yes, I get the same on the Xenial side
<smb> But let me re-try with the appstreamcli cmd
<smb> ... after upgrading the rest. have not done so since last friday
<ximion> Laney: the bug above ^ will not have any huge consequences (like fw updates being ignored), but it still is a bug - basically, the quick validation is a bit too strict here
<ximion> will fix that today
<smb> Laney, Hm, ok the errors about the uncompressed files are gone now and the appstream problem is the same as reported (some component check in some firmware)
<Laney> smb: k, should be fixed soon then
<smb> Laney, ack and luckily (for me) not needing further changes to old apt-cacher-ng versions
<cyphermox> xnox: I don't see these rejections.
<cyphermox> seb128: I know, I was looking yesterday. I'm trying to figure out whether it's expected -- I think it is, there's a small change in the MAC address
<seb128> cyphermox, k, good, let me know if I can help with anything
<xnox> cyphermox, interesting, so it's me.
<cyphermox> xnox: as I told Tony on Friday, you may need to tick "Use only for the resources on its network" checkbox for IPv6 in the VPN config if you find that you only lose DNS if you're connecting to VPN on wifi
<xnox> hm, interesting
<xnox> looking at my configs I already ignore ipv6 on the vpn connection
<dasjoe> cking: hi, I'm running into issues with 16.04 on a ZFS rpool. As you may be aware I am following rlaager's guide with some minor modifications, as of now grub-probe can not detect / to be ZFS. Do you have any suggestions?
<cking> urm, well, last time I tried it, I got it to work, so I'm not sure.  what differences are you making when folloing his notes?
<dasjoe> cking: I'm using less datasets than he is, but this rpool setup has worked well for a few months by now. I just ran a generic upgrade through aptitude which segfaulted, followed by two "apt-get dist-upgrade" to get to a consistent state
<cking> hmm. I  don't know off the top of my head, the only way is for me to follow his notes and see what's up
<dasjoe> Log started: 2016-04-11  16:22:39 â starting from "Log started: 2016-04-11  16:22:39" is what aptitude logged
<dasjoe> cking: nevermind, I think. aptitude just removed the kernel, due to it not being configured correctly. I'll reinstall the kernel and grub should understand ZFS again
<cking> heh. that could be a reason why it's not working :-/
<dasjoe> cking: nope, still stuck here: http://paste.debian.net/432172/
<dasjoe> cking: "chmod -x zz-update-grub" let me finish configuring the kernel, but grub-probe tells me "grub-probe: error: unknown filesystem."
<dasjoe> cking: I have to go now, I'll be back later (hopefully)
<cking> ok, I'll try and find some time to see if I can reproduce this
<sil2100> infinity: hey! DMB meeting - will you be able to attend?
<smoser> infinity, is there a bug for hwe-x installer kernel/initramfs ? if not, do you want one ? i'm getting asked about maas image information for trusty + hwe-x and i depend on that.
<cyphermox> smoser: what is the bug?
<smoser> https://bugs.launchpad.net/maas-images/+bug/1568918
<ubottu> Launchpad bug 1568918 in livecd-rootfs (Ubuntu Trusty) "Add support for lts-xenial kernel flavours in trusty " [Undecided,Confirmed]
<smoser> cyphermox, ^ the bug is just lack of such things.
<cyphermox> ah
<seb128> Mirv, congrats ;-)
<Mirv> thank you seb128 :)
<ginggs> could someone have a look at autopkgtest for paraview please? it says 'test in progress' for s390x, but I suspect that to be a lie
 * smoser wants to publicly thank cjwatson, mvo (and all others who were involved) for the slaughter of hash sum mismatch errors
<smoser> http://www.chiark.greenend.org.uk/~cjwatson/blog/no-more-hash-sum-mismatch-errors.html
<alkisg> +1 from me for the very nice blog entry :)
<dasjoe> cking: grub-probe seems to successfully query "zpool status", see its strace -f: http://paste.ubuntu.com/15764929/
<smoser> ogra_, around ?
<smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1563296
<ubottu> Launchpad bug 1563296 in cloud-init (Ubuntu) "support cloud-init networking with snappy" [Medium,Confirmed]
<smoser> you opened that bug for cloud-init breaking snappy system boot.
<smoser> now i think the reverse is happening.
<smoser> on apt based system, i *think* that ubuntu-snappy (or ubuntu-snappy-cli) is writing in /etc/network/interfaces.d/eth0 and wreaking havoc
<infinity> mvo: ^
<ogra_> smoser, yo
<ogra_> smoser, infinity, that got fixed by moving the seed to ubuntu-snappy-cli
<ogra_> ubuntu-snappy ships the firestboot systemd job that sets up the interfaces file from snappy config data
<ogra_> firstboot
<ogra_> the seed got changed to only use the -cli package now
<smoser> ogra_, ok. that makes me much happier.
<ogra_> not sure all changes are in the archive yet ... i know mvo wanted to land something today
<ogra_> but it is being handled if it isnt fixed yet
<smoser> seed still shows ubuntu-snappy
<smoser> ogra_, is there a bug ?
<smoser> if not, i'll file one and make the changes in the seed right now.
<smoser> i'd rather not wait a day and a set of images if i dont have to
<ogra_> not sure, mvo worked on it (and spent actually some full workdays and the weekend on it)
<smoser> :-(
<ogra_> i thought it was ready for landing today
<smoser> well.. id ont want to step on toes.
<ogra_> (and i thought the seed change had already landed ... )
<smoser> well, http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/view/head:/cloud-image
<ogra_> the solution is that desktop installs shouldnt have any snappy systemd units though ...
<smoser> definitely says ubuntu-snappy
<smoser> gah
<ogra_> ah, not sure he looked at the cloud seed ...
<smoser> ogra_, i'll take it from here.
<smoser> thank you for your help.
 * ogra_ checks the desktop seed
<ogra_> yeah, server and desktop both have -cli already
<ogra_> so adjust cloud to that and you shoould be fine
<smoser> hm..
 * smoser wonders if we want to recommend only
<ogra_> up to you :)
<ogra_> deskto only recommends ... server depends
<infinity> smoser: I think recommends is probably the right answer for this cycle, since we're not including any snaps by default, and users might want to reclaim the space.  Promoting that to a depends by 18.04 would probably be The Right Thing, if we're also snapping in the default install(s).
<smoser> infinity, i think so to.
<smoser> infinity, ok. pushed that change. and the ubuntu-snappy to ubuntu-snappy-cli
<smoser> should we re-build ubuntu-meta ?
<infinity> smoser: I'll grab that.
<smoser> thank you.
<mvo> infinity: yes, that is fixed, we want to land a new upload tonight that fixes this even harder
<infinity> mvo: I'm all for fixing harder. ;)
<smoser> hey.
<smoser> slangasek, wrt bug 1505839 ... the 'esc' is much nicer.
<ubottu> bug 1505839 in debian-installer (Ubuntu) "Unable to install from text mode interface" [High,Triaged] https://launchpad.net/bugs/1505839
<smoser> compared to backspacing N times to get rid of stuff through the F6
<F4S4K4N> I'm looking into possible porting Ubuntu to another ISA, is there a place documenting the build procedure from scratch more or less?
<F4S4K4N> Or should i just look at the packages in a minimal install, build those from the ubuntu repo, install them and go from there?
<cyphermox> pitti: roaksoax_ found an issue with the ifname code in systemd, at least specifically for the USB devices (where the MAC is encoded in the name)
<cyphermox> pitti: the name come to a length of 15 characters, and IFNAMSIZ is 16; so you can't use labels, since that would get you past the limit of IFNAMSIZ
<slangasek> smoser: so... sure, I understand "nicer", but o_O that people are relying on this particular interface which I didn't know was there despite having tested Ubuntu images for nigh on a decade.  What do you have that relies on this interface? Is it just this third-party "cloud image creation" tool?
<cyphermox> that can be verified by running ifup on an enx device
<smoser> slangasek, well. yeah, to my knowledge its just 'packer'. although if i were automating installation of ubuntu from cd and i'd seen that that worked, i'd have done the same.
<slangasek> smoser: sure, I understand; it's still unsupported from my POV and not something I want us to commit to fixing
<smoser> my first thought was basically the same as yours
<smoser> i dont know how you decide if something is "supported" or not
<smoser> nothing that i'm aware of describes F6 as a 'supported' intereface.
<slangasek> smoser: it's not part of the install experience that we validate
<smoser> and to my knowledge, i dont know that we have any automated test that woudl test F6^H^H^H^H^H either
<smoser> this is clearly an unintended bug. rather than just a changed interface.
<rbasak> IMHO a new release is a good time to change an interface.
<smoser> i looked quickly at both diffeernces in the isolinux/ dir on thte cds and in syslinux source and didn't see anything obvious between 15.05 and 15.10
<smoser> rbasak, its not an interface.
<cyphermox> slangasek: smoser: fwiw I may be testing the wrong thing but esc, esc, enter does get me a command-line interface without issues here, it doesn't just switch back to the gfx
<smoser> changing an interface by design and unintentionally regressing are differen things.
<smoser> this is the latter.
<rbasak> https://xkcd.com/1172/
<cyphermox> scratch that
<smoser> cyphermox, it does in deed
<smoser> yeah. and then try to do something :)
<cjwatson> I imagine it's a bug in gfxboot-theme-ubuntu FWIW
<slangasek> cyphermox: the issue reported is that trying to boot by typing a boot command there doesn't work
<rbasak> If it was never intended, and we accidentally break it in a new release, then that's fine.
<cjwatson> ... happy debugging
<cyphermox> yeah, I saw
<smoser> *nothing* works . not even 'help'
<slangasek> smoser: I am not disputing that it is a bug; I am disputing that it is a bug that we care about
<rbasak> Especially if there's some way to provide the behaviour they're after.
<cjwatson> quite possibly prompted by new syslinux, but still
<smoser> cjwatson, but we didnt'g et a new syslinux
<cjwatson> we did, just not a very much newer one
<teward> nacc: i was actually going to poke you about 7.0.5 since I saw a notice on it
<smoser> see my last comment there. it was broken between 3:6.03+dfsg-5ubuntu1 and 3:6.03+dfsg-8ubuntu2
<cjwatson> yes I saw that
<smoser> right.
<rbasak> And provided that we aren't interested in supporting that use case.
<cjwatson> but if you have not read gfxboot-theme-ubuntu's code you can have no conception of how delicate and weird it is
<nacc> teward: yeah, i talked to ondrej about it, he didn't think it was worth doing another FFe -- but im also planning on filing a dotrelease update request for php7
<teward> nacc: though, as a security person, I'd still say 7.0.5 vs. 7.0.4, to keep updated (but as long as you and ondrej are on the same page, and things're backported where necessary, all's good)
<cjwatson> it is totally plausible that sneezing on syslinux could have broken something
<teward> nacc: makes sense.
<smoser> look at the changes though http://paste.ubuntu.com/15767880/
<rbasak> Perhaps the act of rebuilding it changed something?
<cjwatson> it's entirely believable.  somebody is going to have to don the waders and debug gfxboot
<cjwatson> could actually be in gfxboot rather than gfxboot-theme-ubuntu I suppose
<cjwatson> I notice gfxboot didn't change at all; perhaps it needs a rebuild or something
<smoser> i'm sypathetic to slagaseks' point of view, because i can definitely see myself arguing that. indeed i *did* argue it when i first read thsi bug.
<cjwatson> speaking as somebody who has debugged this stuff in the past (and is not going to do it now :-) ), I have no idea how long it would take to track this down
<smoser> but this is much more something that should work then something that worked by happenstance. and i'm weary of saying anything inadvertantly broken between a release that wasnt documented as "will work" is thus up for calling unsupported.
<cjwatson> if I had been asked to estimate this while on foundations I would have said anything from a day to a week
<cjwatson> I would agree that it's a bug but I don't suppose foundations has a whole lot of time to spare before 16.04
<smoser> :-(
<cyphermox> this is going to be "fun"
<rbasak> Is there a different way to cover their use case instead?
<smoser> well, yes.
<smoser> a.) cloud image
<smoser> b.) netboot cd
<smoser> c.) F6 + 47 (not 48) backspaces
<rbasak> None of those seem particularly great :(
<smoser> (the number is wrong, but the the piont is that you have to get the number right, and if we say that is the supported interface, then we have to keep the number right)
<smoser> actually, i think a and b are valid
<smoser> c seems like crap to as a workaround.
<rbasak> Simulating keypresses is pretty broken though.
<smoser> yeah. thats why netboot cd is valid
<smoser> you dont. you get kernel, you pass it cmdline you want.
<smoser> i have to run
<rbasak> Me too
<smoser> thanks you all for discussion.
<nacc> slangasek: can you point me again to the dotrelease SRU documentation? I had it open before but seem to have lost it
<slangasek> nacc: do you mean https://wiki.ubuntu.com/StableReleaseUpdates?
<nacc> slangasek: maybe, you had referred me at some point to documentation when we discussed php7.0 having dotrelease updates
<slangasek> nacc: probably the subsection of that page about micro release exceptions
<nacc> slangasek: thanks, will review
<mvo> infinity: new snappy is upload under the new "snapd" source package name. it would be wonderful to get a review from the release team for this (and ubuntu-core-launcher, ubuntu-core-config, initramfs-tools-ubuntu-core but all of those are small). thanks a bunch !
#ubuntu-devel 2016-04-12
<Pharaoh_Atem> anyone have any idea what's causing this? http://fpaste.org/354429/46042524/
<Pharaoh_Atem> this is the full log here: http://fpaste.org/354435/25442146/
<pitti> cjwatson: hm, I'm getting hash sum mismatches in a container apt-get update again, was this disabled again?
<pitti> cjwatson: indeed http://archive.ubuntu.com/ubuntu/dists/xenial/by-hash/SHA256/ has nothing from today, latest update is from yesterday morning
<infinity> pitti: http://archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/by-hash/SHA256/
<infinity> pitti: That's up to date.  I'm not even sure what's meant to be in that top-level by-hash dir.
<infinity> Oh.  Contents files, probably.
<infinity> And those aren't updated more than once a day.
<pitti> ah, thanks
<cpaelzer> good morning
<pitti> infinity: hm, I forgot which page I really mean instead of the outdated https://wiki.ubuntu.com/ReleaseChecklist -- do you know?
<pitti> infinity: I was wondering when to disable Launchpad crash reports in apport
<infinity> pitti: https://wiki.ubuntu.com/ReleaseProcess
<infinity> pitti: It claims -7 days
<pitti> ah, thanks; so on Thursday
<infinity> pitti: Any time nowish would probably be fine.  Though, with the new NM having just landed, we might want to keep repots verbose for a bit.
<pitti> I have another bug fix to go along with disabling LP reports
<pitti> infinity: ok, so actually aiming for Thu might be good then, to give a few days for NM
<pitti> infinity: oh, btw -- I promised that I'd do a fresh langpack upload on Friday evening, but it turns out I'll be AFK from Friday noon to about Saturday evening
<infinity> pitti: Yeah.  I trust NM upstream as much as I trust stgraber to reach things on the top shelf.
<pitti> rotfl
<pitti> so, I'll cron the generation, but I can't self-accept them
<pitti> or, if you are happy with an upload on Sunday, that would work for me
<infinity> pitti: That's fine.  If they can magically end up in the queue somehow, I can get them.
<infinity> pitti: Or Sunday.  Don't care that much, really.
<infinity> pitti: I'm sure I'll spin a new set on Sunday when I land in London, and I'm equally sure we'll do another set during the week. :P
<pitti> infinity: given that it requires an off-the-schedule export from LP via webops and I usually do a coarse diff review before uplaod, that actually sounds better then
<pitti> infinity: ok, Sunday it is then
<pitti> wgrant: so what do we need to do to arrange a full xenial langpack export on Friday? (I already ticked the "full export" box, but cron would only run on Sunday)
<pitti> wgrant: can we pre-schedule this with an extra cron job? or should we do it live on Friday morning?
<wgrant> pitti: Easiest to just manually kick it off on Friday.
<pitti> wgrant: ack, thanks
<dholbach> Could somebody take a look at snapd in NEW?
<dholbach> (please :-))
<dholbach> it'll build the ubuntu-snappy package from now on
<dholbach> and is required for a milestone today
<dholbach> brb
<pitti> cyphermox: hm, latest NM drops the .upstart file, was that on purpose? now NM doesn't start any more under upstart
<pitti> cyphermox: I noticed because "adt-run --testname cmdline-upstart-boot systemd" fails now
<pitti> it still has a sysv init script, but it doesn't get enabled on package install apparently
<infinity> mvo: If ubuntu-snappy and ubuntu-snappy-cli have both become snapd, how is snapd avoiding the same issues that you previously split the package to deal with?
<infinity> mvo: Ahh, ubuntu-core-snapd-units?
<pitti> cyphermox: filed/tracked as bug 1569204
<ubottu> bug 1569204 in network-manager (Ubuntu Xenial) "xenial regression: does not start any more under upstart" [Critical,Triaged] https://launchpad.net/bugs/1569204
<andrewsh> hey guys, I'm having graphics issues on Ubuntu for the first time (previously I had them on Debian only), who should I prod: https://www.dropbox.com/s/dtq4o4p0mxrgusf/2016-04-12_08-28-01.png?dl=0
<andrewsh> that's Xenial, for the record
<mvo> infinity: exactly
<pitti> cyphermox: also, do you know why NM does not seem to log to syslog any more?
<Mirv> TheMuso: since I would not want to start my core-dev career with a botched ubiquity upload, please consider reviewing and sponsoring https://code.launchpad.net/~timo-jyrinki/ubiquity/kubuntu_slideshow_i18n_lp1512834/+merge/291581 (debdiff https://launchpadlibrarian.net/253401826/ubiquity_2.21.54_2.21.55.diff.gz).
<Mirv> TheMuso: it'd also be possible to do ./copy-package --from=~timo-jyrinki/ubuntu/grilo --from-suite=xenial --to=ubuntu --to-suite=xenial-proposed ubiquity if happy
<Mirv> I got a confirmation it's working on another channel (and in the bug report)
<dholbach> thanks to whoever reviewed snapd
<dholbach> snapd is in binNEW now
<infinity> dholbach: You're welcome, and now I should sleep.
 * dholbach hugs infinity 
<dholbach> you're a hero
<dholbach> mvo, ^
<cjwatson> pitti: Do you have -oDebug::Acquire::http=true output?
 * mvo hugs infinity
<xnox> pitti, have you seen bug #1566465 ?
<ubottu> bug 1566465 in linux (Ubuntu Xenial) "[regression]: Failed to call clock_adjtime(): Invalid argument" [Medium,Confirmed] https://launchpad.net/bugs/1566465
<xnox> i'm not sure if that's a kernel or systemd bug.
<ogra_> woah
<ogra_> pitti, that last systemd update in trusty just turned my screen off
<ogra_> (for about 30sec or so)
<pitti> ogra_: bug 1473800
<ubottu> bug 1473800 in systemd (Ubuntu Trusty) "restarting logind during systemd update causes screen to lock" [Medium,Fix released] https://launchpad.net/bugs/1473800
<ogra_> heh
<ogra_> didnt lock
<pitti> ogra_: the fix was SRUed in the latest update, but it can only apply for any updates from now on, not for updates from previous versions *to* this one
<pitti> well, same thing
<pitti> X becoming confused when logind restarts
<ogra_> yeah
<ogra_> obviously my card then powers off the HDMI ports so that i get "no signal" on all three screens ... that was quite scary
<pitti> xnox: I didn't yet, no; putting on list of things to look at
<doko> jamespage, marcoceppi: python-libcharmstore doesn't have any copyright information except for the debian/copyright. Please could you add a LICENSE file, or add the license to the source files?
<jamespage> doko, I referred to the committed LICENSE file in the upstream codebase - is that not sufficient to clarify the licensing?
<doko> jamespage, but this file is not in the package which is sitting in NEW
<jamespage> doko, yes that's why I added a comment to d/copyright...
<doko> hmm
<jamespage> doko, if you are not comfortable with that approach, I'll ask marcoceppi to make a new release...
<pitti> cjwatson: http://paste.ubuntu.com/15783270/
<cjwatson> pitti: Well, the URLs that your apt-cacher-ng is reporting as 404 do exist ... which exact package version of acng is that?
<pitti> 0.8.9-1ubuntu1, shoudl be current xenial
<cjwatson> I haven't actually directly confirmed that my fix to the built-in configuration works.
<cjwatson> You could try putting "PfilePatternEx: /dists/.*/by-hash/.*" in acng.conf
<pitti> I wonder what the "de.archive." things in the debug output are
<pitti> maybe I have that mirror in some schroot config, and that's the one acng cached
<cjwatson> That's acng's repository mapping
<cjwatson> Surely it shouldn't be caching the 404 though
<cjwatson> Hm, maybe it is
<pitti> no, not that, but if it caches some de.archive.u.c. bits and pretends they are from archive.u.c. that migth cause some collisions without by-hash/ ?
<doko> jamespage, ok, accepted
<cjwatson> HTTP/1.1 404 Not Found
<cjwatson> X-Original-Source: http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/source/by-hash/SHA256/8b81701065e3fa4957c5df3c6edc6a6f55301b7e20ac04d6a0aa19881b852320
<cjwatson> That sure looks like negative caching to me
<pitti> /var/cache/apt-cacher-ng/uburep/dists/xenial/main/source/by-hash/SHA256/*.head only has "200", no 404s, but maybe these are hidden somewhere
<pitti> meh, I moved /var/cache/apt-cacher-ng/uburep/ away, restarted acng, and I still get teh 404 and de.archive.u.c.
<pitti> where does this X-Original-Source come from..
<cjwatson> pitti: Can you find 8b81701065e3fa4957c5df3c6edc6a6f55301b7e20ac04d6a0aa19881b852320 anywhere?
<pitti> no, neither with find nor with grep
<cjwatson> Or 6966a83abdd3fc2582ee280fa45561c6a6ffa1ca37cba6e891072a98e431ce66
<pitti> also doesn't exist at all in the cache
<cjwatson> Hmm
<cjwatson> http://de.archive.ubuntu.com/ubuntu/dists/xenial/universe/source/by-hash/SHA256/6966a83abdd3fc2582ee280fa45561c6a6ffa1ca37cba6e891072a98e431ce66 *is* 404
<cjwatson> So maybe acng is configured to try de.archive in preference, and reports its 404 as if it were for archive
<pitti> neither the  container nor my host use de.archive
<pitti> yeah, some built-in mirror selection perhaps
<cjwatson> de.archive is presumably in /etc/apt-cacher-ng/backends_ubuntu
<pitti> ah yes, it is
<cjwatson> This must be something to do with how the Remap-* stuff works, I think
<pitti> and if I drop the de. from /etc/apt-cacher-ng/backends_ubuntu then everything works
<pitti> cjwatson: many thanks for finding /etc/apt-cacher-ng/backends_ubuntu! I wasn't aware that it remaps mirrors like that
<dholbach> pitti, do you have an idea why http://paste.ubuntu.com/15783673/ might come up in the autopkgtest of snapd for some arches and not for others?
<pitti> dholbach: maybe ca-certificates is pre-installed in VMs but not containers
<dholbach> pitti, ah, that might be
<pitti> dholbach: armhf and s390x run in LXC; i386, amd64, and ppc64el run in scalingstack instances
<pitti> so if pass/fail maps to these two sets of arches, that smells like a missing "ca-certifictes" test dep
<dholbach> nice catch
<dholbach> pitti, is this something which could be fixed in the infrastructure? should I file a bug?
<pitti> dholbach: you mean cleaning up  ca-certificates from instances? yes, we could do that
<pitti> except on lcy01, which still doesn't allow me to build custom images as that times out
<pitti> so it can't be reliable
<dholbach> oh... cleaning... I thought adding ;-)
<dholbach> well, at least make the list of packages the same, if that's possible :)
<pitti> dholbach: not entirely possible, as scalingstack instances need some more packages to actually boot/work than a container
<pitti> we can approximate it, though
<pitti> although cf. the lcy01 bug, we run tests on the (very fat) standard cloud images there
<pitti> (RT has been pending for a few months)
<cjwatson> pitti: I followed up to https://bugs.debian.org/819852 with a summary of this
<ubottu> Debian bug 819852 in apt-cacher-ng "apt-cacher-ng: support by-hash index files" [Normal,Open]
<cjwatson> (should appear in a couple of minutes)
<pitti> cheers!
<doko> xnox, infinity: is this post-release material? https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1564918
<ubottu> Launchpad bug 1564918 in glibc (Ubuntu) "glibc/s390: Save and restore fprs/vrs while resolving symbols." [High,New]
<dholbach> pitti, ok
<xnox> doko, infinity - last glibc upload was from before that bug was filed. It certainly is SRU candidate, if we don't take it in. There are more comments on https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1563784
<ubottu> Launchpad bug 1563784 in Ubuntu on IBM z Systems "S390: glibc should not be configured with lock elision." [Critical,Incomplete]
<xnox> the lock elision one is claimed to be critical.
<xnox> maybe it's worth taking both in. At the moment I am strugling to find any benchmark that does show that lock elision is good. So far i get things that widely range from 0.5x - 3x in performance, on multiple reruns. I'm guessing lpar is busy elsewhere, and I'm not getting the CPU resources I think I am.
<Son_Goku> anyone have any idea whatâs causing this? http://fpaste.org/354429/46042524/
<alex116> I am using the gadget-fs to create a serial interface to communicate over USB. When I test it with microcom, I have to restart microcom after disconnecting the USB port. In a c++ program, would this be the equivalent of closing the file descriptor from which I am reading and opening it again?
<mdeslaur> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur, infinity
 * dholbach hugs mdeslaur 
 * mdeslaur hugs dholbach back
<rbasak> Who should I talk to about akonadi's mysql backend and kubuntu?
<rbasak> shadeslayer: around? Not sure who to ask.
<shadeslayer> hi there
<rbasak> I thought I had akokadi covered with the MySQL 5.7 transition, but just realised that it hardcodes dependencies on -5.6-.
<shadeslayer> rbasak: I'm not really working on Kubuntu per se these days, but can have a look I guess, or maybe yofel
<rbasak> mysql-server-core-5.6 specifically.
<rbasak> I'd like to switch that to 5.7. I can do it, but I thought a heads-up was appropriate given the time we are in the cycle.
<shadeslayer> right, best to tell yofel I think
<yofel> rbasak: go ahead
<rbasak> Thanks.
<rbasak> I hope it has good test coverage!
<yofel> I totally missed that because the upgrade went fine as virtual-mysql-server-core covered 5.7
<rbasak> Also mysql-client-core-5.6 but I'm less concerned by that.
<rbasak> yofel: ah so it's not actually using 5.6 right now?
<rbasak> (we haven't deleted 5.6 yet - still getting through the reverse deps)
<yofel> not on my machine, but I also run the full server, so that probably pulled 5.7 in
<rbasak> OK
<rbasak> I'll build and dep8 test locally first.
<rbasak> Sorry about this. I've been following http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.xenial/rdepends/mysql-5.6/ and didn't realise that didn't cover the flavors until just now.
<yofel> np. As I said, worst case the virtual dep would've covered 5.7, even if that's not why it's there originally
<rbasak> yofel: my concern is any behaviour change by making it use 5.7 by default on the server.
<rbasak> You can get 5.7 to work very similarly to 5.6 but some defaults have changed. Skuggen (upstream) can help us with that if needed.
<yofel> hm... right
<rbasak> superm1: ^^ the same applies to mythtv :-/
<superm1> rbasak: what behavior change?
<superm1> it seems that 5.7 is being pulled in fine in our ISO's right now for mythbuntu
<superm1> and it sounds like upgrades will just keep 5.6 and not actually transition to 5.7 right?
<Skuggen> If you  have mysql-server-5.6 and not mysql-server, yes
<Skuggen> superm1: Some packages have had failures because 5.7 uses different default settings for sql modes, at least
<Skuggen> Though the one I'm thinking of was a bunch of tests that more than anything seemed to be testing the server configuration
<Skuggen> http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-mode-setting the first line lists the defaults now. In 5.6 it was only NO_ENGINE_SUBSTITUTION
<cyphermox> pitti: it probably just doesn't log to syslog with the specific set of options you picked, but NM definitely does log to syslog
<superm1> Skuggen: oh.. yeah mysql-server is what we had, so yes i guess that means upgrades will come up to 5.7
<superm1> can you make mysql-server resolve to mysql-server-5.7 | mysql-server-5.6 to avoid that happening?
<rbasak> superm1: we want to remove 5.6.
<superm1> oh
<superm1> so the hope is that 5.6->5.7 is a smooth transition then, i see
<Skuggen> Yeah
<rbasak> I'm fairly confident about the upgrade path for the data.
<Skuggen> Mostly it should be, unless you rely on the old default behavior
<rbasak> mysql_upgrade etc.
<Skuggen> i.e. things like trunkating out-of-range values instead of throwing an error
<Skuggen> Or auto-creating users that don't exist if you try to grant them privileges...
<superm1> i don't think those two scenarios should affect myth stuff
<rbasak> Yeah my concern was that 5.7 would refuse something previously permitted, causing things to break, etc. I don't expect anything subtle. I expect things to error out if it's not right.
<rbasak> If you've been testing 5.7 already, then I think we'll be good.
<superm1> OK
<rbasak> https://bugs.launchpad.net/ubuntu/+source/neutron-vpnaas/+bug/1567899 is an example of the sort of thing we've seen
<ubottu> Launchpad bug 1567899 in neutron "alembic migration failure with mysql 5.7" [Undecided,In progress]
<rbasak> Fixes are usually pretty straightforward.
<rbasak> (so far)
<rbasak> And we've touched quite a few packages now.
<pitti> cyphermox: I picked the options that are in the upstart job, i. e. none
<cyphermox> pitti: yeah, I figure, but that should have logged normally ;)
<mitya57> Mirv, hi, I've committed a change to qtbase's ubuntu branch that backports upstream fix for tray icons on Xubuntu/Lubuntu.
<mitya57> Mirv, are you planning a new upload before Xenial release? Or can I upload it on my own?
<rbasak> cp: '/etc/localtime' and '/var/lib/schroot/chroots/xenial-amd64/etc/localtime' are the same file
<rbasak> Anyone else seeing that with mk-sbuild on Xenial?
<rbasak> mk-sbuild runs cp -a on /etc/localtime. In my case, they *point* to the same file.
 * rbasak tries -P
<rbasak> That worked.
<dholbach> pitti, I'm trying to run snapd through a local autopkgtest to avoid uploading umpteen times due to missing test depends ... I tried both lxc and cloud image (following instructions from one of your last blog entries and from packaging.u.c): http://paste.ubuntu.com/15792347/ - both fail for me ... is there a known working way? or should I ask somebody else? :)
<pitti> dholbach: lxd> do you have an "lco:" remote? the images.linuxcontainers.org image is now available by default as images: (and the latest autopkgtest also updated the documentation)
<pitti> dholbach: please run --- lxd -d ... to enable debugging
<dholbach> pitti, yep, I added that following https://www.piware.de/2015/12/whats-new-in-autopkgtest-lxd-maas-apt-pinning-and-more/ :)
<pitti> dholbach: if you do "lxc launch lco:ubuntu/xenial/amd64 x1", does that work?
<dholbach> error: Get http://unix.socket/1.0: dial unix /var/lib/lxd/unix.socket: connect: no such file or directory
<pitti> dholbach: seems you don't actually have lxd installed?
<dholbach> ouch sorry, it's been a long day already
<dholbach> thanks pitti
<mdeslaur> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<nacc> elbrus: ping
<pitti> apw: hey Andy
<pitti> apw: still remember bug 1531768?
<ubottu> bug 1531768 in linux (Ubuntu) "[arm64] locks up a few minutes after booting" [Medium,Confirmed] https://launchpad.net/bugs/1531768
<pitti> apw: I have an instance with current xenial running for about two hours, chugging through a loop of tests, and so far it works fine
<pitti> apw: TBH, I mainly tell you this in a public channel to coerce it to fail again :-)
<apw> pitti, :)
<pitti> but yeah, trying to trigger Murphy's law deliberately fails because of Murphy's law
<smoser> cjwatson, sorry to bother. bug 1505839 you suggested yesterday gfxboot-theme-ubuntu as the likely source of the issue
<ubottu> bug 1505839 in debian-installer (Ubuntu) "Unable to install from text mode interface" [High,Triaged] https://launchpad.net/bugs/1505839
<smoser> but that package is unmodified from vivid (works) to wily (fails)
<cjwatson> yes, I know.  syslinux/gfxboot/gfxboot-theme-ubuntu are tightly coupled though
<cjwatson> I don't actually know what the problem is here, it would take hours of investigation to establish more and I don't have that time
<smoser> ok. yeah. that makes sense then.
<cjwatson> but in the past, it has sometimes been the case that changes to one of those required changes to others
<smoser> thanks
<cjwatson> it's not *necessarily* the case that a change to syslinux would require a change to one of the others; this is just an educated guess
<smoser> yep
<doko> finally, gcc-5-cross-ports migrated \o/
<cjwatson> doko: ah yes, I was just going to tell you
<cjwatson> infinity: ^-
<Mirv> mitya57: hi. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-046/+packages is landing soon first.
 * Mirv notices lacks one git push
<mitya57> Mirv, so after that mine is OK for upload? Or do you want me to go through the CI Train too?
<Mirv> mitya57: ok, pushed, I think you could upload ubuntu8 directly too
<Mirv> we're only doing the QA for the vivid+overlay 5.4.1 anyway
<mitya57> ACK, will upload directly after that one lands
<Mirv> so general smoketesting would be ok
<mitya57> I've built that in my PPA, and some people tested the fix
<nacc> Pharaoh_Atem: ping
<rbasak> pitti: I'm getting an odd error with adt-run on a package that has a test that needs a built tree: dpkg-genchanges: error: cannot read ../akonadi_15.12.1-0ubuntu4.dsc: No such file or directory
<rbasak> http://paste.ubuntu.com/15794227/
<rbasak> Any ideas?
<Mirv> mitya57: I mean, you could skip the wait for silo 046 upload ubuntu8 (or combine it into new ubuntu7) already to save time because freezes are so near.
<pitti> rbasak: hmm, not off-hand; can you please file a bug with a reproducer? sorry, TB meeting now, then dinner
<Mirv> mitya57: I would then only publish the vivid-overlay part of 046 when it's approved
<rbasak> pitti: OK, np.
<pitti> slangasek, kees, infinity, mdeslaur, stgraber: TB meeting reminder
<mitya57> Mirv, ok, will combine with ubuntu7 then
 * slangasek nods
<mdeslaur> pitti: ack
<highvoltage>  Ã;#Ã;/win 8
<Unit193> That's a new take on it.
<Mirv> mitya57: thanks
<rbasak> pitti: bug 1569434
<ubottu> bug 1569434 in autopkgtest (Ubuntu) "adt-run fails with "dpkg-genchanges: error: cannot read ../akonadi_15.12.1-0ubuntu4.dsc: No such file or directory"" [Undecided,New] https://launchpad.net/bugs/1569434
<pitti> cheers
<rbasak> pitti: quick question if you're able: what version of autopkgtest runs when I upload? I was about to Just Upload given that I can't easily locally test, but just thought that might cause issues in xenial-proposed perhaps?
<pitti> rbasak: production just runs straight out of git, so usually git master or maybe a few commits behind
<rbasak> OK thanks
<Pharaoh_Atem> nacc: pong
<nacc> Pharaoh_Atem: so i just took a look at the upstream PHP7.0 changelog ... while at least this one is arguably all bugfixes (http://php.net/ChangeLog-7.php) [I'd need to check on the hugepage chagne which seems a functional change and the libzip thing, although irrelevant to us, since we link to our libzip], looking at the upstream NEWS file (which maybe 7.0.6 or 7.1.0 depending on the upstream track,
<nacc> aiui) http://git.php.net/?p=php-src.git;a=blob;f=NEWS;h=dfbc707d7abcddd2a13eba8df4d41508a211ca31;hb=HEAD, I get a bit more worried -- a few lines of "Implemented"
<Pharaoh_Atem> they've already branched php7.0.6
<nacc> so they have
<nacc> Pharaoh_Atem: ok, so the 7.0.x will be selective backporting of bugfixes from the master?
<Pharaoh_Atem> yes
<Pharaoh_Atem> nacc: https://github.com/php/php-src/blob/PHP-7.0.6/NEWS
<nacc> Pharaoh_Atem: i'm just trying to get some reassurance that will be true :)
<Pharaoh_Atem> there's not much in the way of reassurance with the PHP people
<Pharaoh_Atem> but the best I can say is that they seem to be following that model for now
<nacc> right, but if i file a SRU request, I need to back it up somewhat -- otherwise I'm individually backporting stuff as bugs get filed in ubuntu
<Pharaoh_Atem> git master is a scary place for LTS distros
<Pharaoh_Atem> historically with the php versioning scheme, it follows a structure similar to Python
<Pharaoh_Atem> where major.minor.patch is more or less supermajor.major.minor
<Pharaoh_Atem> nacc: given we don't expect the supermajor to change for a while, the major version will largely be incremented for feature implementations, while the minor version is incremented for bugfixes
<nacc> Pharaoh_Atem: ack, thanks
<Pharaoh_Atem> If Ubuntu is okay with that for Python and Perl, I don't see why they aren't okay with it for PHP
<rbasak> Pharaoh_Atem: PHP has a poor track record in this area.
<Pharaoh_Atem> rbasak: *sigh*
<rbasak> Pharaoh_Atem: historically, Ubuntu is OK with it only after a case has been made. I expect that it was made and accepted for Python and Perl if indeed it is done in Ubuntu.
<rbasak> superm1: I uploaded mythtv ubuntu4 dropping the 5.6 deps. FYI, I think the "| mysql-server-5.7 | mariadb-server" is redundant (and for client too) since maria and mysql both agree in Debian to always provide virtual-mysql-{client,server} but I didn't change that - not my call and also probably a good idea to change as little as possible at this stage in the cycle.
<superm1> rbasak: thanks for the heads up, the main reason everything was called out is that we use the same packaging on all distros in a backports PPA
<superm1> that tracks upstream's stable -fixes branch
<superm1> but i think virtual-mysql-server should still resolve that properly
<rbasak> superm1: ah, OK. In that case you may have to wait until virtual-mysql-* appears in the oldest release to which you backport.
 * rbasak isn't sure when that might be.
<rbasak> That's the sort of the reason I had in mind for not touching it :)
<rbasak> Actually
<rbasak> I'm sorry.
<rbasak> That upload probably wasn't needed at all in that case.
<rbasak> It's an alternative. Sorry, my fault.
<nacc> tsimonq2: just to be clear, do you mean the missing articles throughout the document? (the, a)?
<tsimonq2> nacc: huh
<tsimonq2> *huh?
<nacc> tsimonq2: re: php7.0 serverguide review
<tsimonq2> ohhhhh
<nacc> tsimonq2: sorry :)
<tsimonq2> no it's alright :)
<tsimonq2> what specifically are you talking about? have you read my inline comments?
<nacc> tsimonq2: yeah, the ones that all refer to l130 review, i'm just trying to understand what you meant :)
<teward> nacc: i'm lost or i'd know what you and simon were talking about (saw 'php7.0' and 'serverguide')
<tsimonq2> teward: he submitted an MP to the server guide
<nacc> teward: i'm submitting a MP to fix up server guide
<teward> links are nice
<tsimonq2> relating to PHP
<nacc> https://code.launchpad.net/~nacc/serverguide/php7.0/+merge/291655
<tsimonq2> nacc: so basically what I meant was to keep it consistent when referring to the terminal
<nacc> tsimonq2: you mentioned "weird wording" -- most of what i have found is missing "the"s or "a"s
<nacc> tsimonq2: oh i see!
<nacc> tsimonq2: is there a standard preferred way to refer to it?
<teward> tsimonq2: there's a comment inbound from me
<tsimonq2> nacc: I don't know anything specific, maybe you have an idea, but it just looked weird :)
<tsimonq2> teward: alright :)
<nacc> tsimonq2: ack ... i will at least make it consistent
<tsimonq2> nacc: and it's not all line 130
<tsimonq2> :)
<nacc> teward: Pharaoh_Atem: we should also document fpm, no?
<nacc> teward: and nginx and php?
<teward> nacc: nginx will come later
<nacc> teward: k
<teward> we can probably add that later
<teward> nacc: did you draft Release Notes items for php7.0?
<nacc> tsimonq2: right, i just meant a bunch of comments (afaict) were "see l130" -- wanted to clarify that
<nacc> teward: nope, on my todo for today
<nacc> teward: having not done it before, do you have a pointer to where is tart?
<nacc> *i start
<teward> nacc: never had to write a release notes item in my entire Ubuntu-ness.  rbasak is my guide, i worked off his drafts for the HTTP/2 stuff
<Pharaoh_Atem> nacc: well, we have php7.0-fpm configs available now
<Pharaoh_Atem> so why not?
<nacc> rbasak: --^ ? any pointers to where to start for php7.0 release notes?
<teward> nacc: though, when you write it, it would be sufficient to make a note for php fpm that this breaks older nginx configurations, and need to be updated for PHP7.0 default paths.
<teward> nacc: though if you feel comfortable linking to my blog, i"ll have something posted for it by Saturday
<nacc> Pharaoh_Atem: care to write something up? and send a MP?
<rbasak> nacc: maybe https://wiki.ubuntu.com/WilyWerewolf/ReleaseNotes for style?
<tsimonq2> teward: reiterating my point ;)
<nacc> rbasak: thanks
<rbasak> And similar URL scheme for previous releases.
<teward> tsimonq2: actually, correcting your suggestion.
<teward> tsimonq2: E:BadGrammar
<rbasak> nacc: you can also edit https://wiki.ubuntu.com/XenialXerus/ReleaseNotes directly.
<rbasak> (which we'll do in the end when transferring from bugs anyway)
<tsimonq2> teward: oh :P
<teward> tsimonq2: switch PHP Apache for Apache PHP
<tsimonq2> yep ack
<Pharaoh_Atem> nacc: how exactly do I do this?
<nacc> teward: ack
<rbasak> https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Ubuntu_Server is blank right now :)
<teward> lol
<tsimonq2> ruh roh
<nacc> Pharaoh_Atem https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/UbuntuServerGuide
<teward> rbasak: regarding release notes, did you see my notes on your bug for the HTTP/2 stuff under the release notes tracker on LP?
<rbasak> teward: yes - no longer applicable to nginx, right?
<teward> rbasak: correct - HTTP/2 is in Xenial
<teward> as of 1.9.14
<teward> and tested to confirm it works
<rbasak> Great. Thanks!
<teward> thanks to infinity asking for OpenSSL tests :P
<teward> rbasak: you're welcome.
<Pharaoh_Atem> nacc: atm I'm doing a wonderfully annoying set of merges and cleanups related to libvirt-php, but I may have something to contribute in relation to the server notes for php7
<nacc> Pharaoh_Atem: luckily it's not tied to the release schedule, afaict
<nacc> Pharaoh_Atem: so when/if you can
<Pharaoh_Atem> certainly
<nacc> Pharaoh_Atem: it seems like a nice-to-have documentation
<Pharaoh_Atem> well, it's a good thing to have
<Pharaoh_Atem> we want people not using mod_php7.0 as much as possible
<nacc> teward: tsimonq2: do you think "enter the following at the terminal prompt" or "enter the following in the terminal prompt" is more correct? I use the former normally
<rbasak> I'd say "at"
<nacc> rbasak: ack, thanks
<nacc> tsimonq2: can i push to the same branch to update the merge, or do i need to request a new merge?
<nacc> with a corresponding new branch
<teward> nacc: "at"
<teward> nacc: BTW, nginx + php7.0 data at http://dark-net.net/?p=125
<teward> i'll set up a 'nice link' when i'm not busy beating the Internet to death for being laggy
<teward> that's also aggregated on Planet
<teward> nacc: I strongly suspect people will want php5 back at some point - there's another post on that on my blog as well.
<teward> (also Planet aggregated)
<nacc> teward: ack, updated locally, pending an answer to my last question for a fresh MP
<nacc> teward: they have trusty for that
<teward> nacc: yes, but you know the people who 'must have the latest'
<teward> >.>
<nacc> teward: inasmuch as I don't know what "back" is in this context; there is no "back" :)
<nacc> teward: as you suggest in the post, you can use a PPA, but then you're relying on the PPA's owner
<teward> indeed
<teward> nacc: i was just giving you an FYI
<teward> no need to include it in release notes
<teward> but linking to my post regarding the php7.0 transition, and updating existing sitei configs is still relevant
<nacc> teward: ack, we know it's a potential issue, but well broadcasted (as much as I can) and ack on documentation links/needs
 * teward just added the other post in order to make a note that if people get annoyed there is a non-supported solution)
<teward> indeed.
<nacc> teward: i'm also going to try and set up an env to test using lxd and/or adapt to just have xenial with appropriate redirection to trusty containers and host php5 + php7 at the same time, both in supporte environments
<teward> rbasak: probably should add something for nginx about the php7.0 transition, though i'm tempted to leave that on nacc's section
<teward> nacc: ah, cool, let me know how that goes :)
<nacc> teward: it was rbasak's suggestion  (sort of)
<teward> indeed
<nacc> tsimonq2: fyi, the tabulation issue is inconsistency in the file itself (tabs vs. spaces)
<teward> tsimonq2: add that to the list - "fix indentation inconsistencies"
<teward> you've just given yourself that task :P
<nacc> teward: do you know the answer to my prior question? should i push to the same branch and will lp handle that properly or should i send a new MP with a new branch?
<teward> nacc: i didn't see that question.  #launchpad may be able to help?
<nacc> teward: np, good point
<teward> nacc: does libapache2-mod-php exist as an installable object in Xenial?
<nacc> teward: yes, it's a virtual pkg that depends on libapache2-mod-php7.0
<nacc> teward: the ubuntu/debian preference going fwd is to use unversioned metapacakges
<teward> nacc: ack
<teward> nacc: I don't have merge powers, not sure why i'm on the approvers list on this one
<nacc> teward: just wanted you to review
<nacc> teward: as you already reviewed the other :)
<teward> ack
<teward> I've made a comment that it looks OK to me, but my 'review' is listed as "Abstain"
<teward> simon's got more review say in this than I unfortunately
<nacc> teward: fair enough, wasn't aware it was that formal, sorry!
<teward> nacc: I'm treating it as formal :)
<teward> no problem though
<teward> glad to be in the loop :)
<teward> tsimonq2: ^ just as an fyi
<teward> i know you're not here right now thoug
<nacc> teward: ack, thanks
<teward> nacc: now, if it were an nginx section, I'd be asserting myself as needing to review it, due to being the one working on nginx right now; highly doubt the documentation team would mind heh
<nacc> :)
<nacc> slangasek: so php7.0.5 has a bunch of security fixes, etc. pacakged by debian now; if i file and am granted a SRU exception for php7.0 microreleases, will that mean i can just request a merge as appropriate?
<teward> nacc: thought it was decided the fixes were backported and not as important to get included?
<teward> (i.e. to not need the FFe)
<nacc> teward: i just did a quick review -- upstream claims they are pretty important, and at least one is a BC unbreak
<nacc> teward: i also just want to understand the policy :)
<teward> :P
<jtaylor> hm apparmor is spamming me with dnsmasq messages since the update today
<tyhicks> jtaylor: since you updated to apparmor 2.10.95?
<jtaylor> seems to actually be from yesterday, yes 2.10.95
<tyhicks> jjohansen, sarnold: fyi ^
<tyhicks> jtaylor: there should have been no changes in apparmor 2.10.95 that would cause that
<tyhicks> jtaylor: I'll do some digging
<jtaylor> operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/dnsmaq" name="run/dbus/system_bus_socket"
<tyhicks> jtaylor: for now, you can follow https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1569316
<ubottu> Launchpad bug 1569316 in apparmor (Ubuntu) "Log flooded with run/dbus/system_bus_socket wr denied" [Undecided,New]
<jjohansen> what other packages were updated at the same time?
<jtaylor> ah yes looks like that
<jtaylor> a bunch I hadn't updated in a couple days, I can dig out the history if needed
<tyhicks> it would be helpful
<tyhicks> I'm going to begin trying to isolate the apparmor package update to determine if it was a change in there
<jtaylor> I'll disable aa-notify for now ;)
<jtaylor> please don't hack me now D:
<sarnold> tyhicks: hah, talk about fun timing
<sarnold> jtaylor: thanks for the report :)
 * tyhicks defines fun differently
<slangasek> nacc: it wouldn't be requesting a merge; we wouldn't track arbitrary packaging changes from Debian as part of a microrelease exception
<nacc> slangasek: ok, so we'd be actually repackagind from upstream via uscan/uupdate?
<slangasek> nacc: yes
<jtaylor> tyhicks: attached the apt history to the log
<nacc> slangasek: ok, thank you for clarifying
<jtaylor> s/log/bug
<nacc> slangasek: so at that point, do we still need to enforce our orig tarballs match debian's? if debian has already packaged the same version?
<tyhicks> jtaylor: thank you
<infinity> nacc: Yes.
<nacc> infinity: thanks, just trying to understand all the bits so i can make it as easy as possible
<infinity> nacc: You can only have one orig per upstream version, so while your 16.04 SRU uploads might be forked from Debian, your 16.10 uploads wouldn't be.
<nacc> infinity: ack
<infinity> nacc: So, you want the correct orig in 16.10, then uupdate with the same orig in 16.04
<nacc> infinity: got it
<infinity> nacc: If Debian is using pristine upstream tarballs (are they?) you can certainly agree in advance how the orig will be obtained and skip ahead.  Or agree that they use yours if you're ahead.  But it's definitely less hassle to use the same one.
<nacc> infinity: does that imply we can't sru 16.04's php7.0 until 16.10 opens (e.g., with 7.0.5 as currently available) [again, presuming a microrelease SRU exception were to be granted]
<infinity> nacc: No, it doesn't imply that, it just implies that it would be in your best interest to make sure you and Debian will use the same 7.0.5 orig, regardless of who uploads first.
<nacc> infinity: got it
<nacc> infinity: i believe debian is using pristine tarballs, but i'll review it to be sure
<infinity> nacc: If the watch file grabs by URL and does gpg validation, that's a pretty good sign. ;)
<infinity> nacc: But best to just make sure you and ondrej agree on what the method is (bonus points for the method being codified in the package), so you don't step on each others' toes.
<nacc> infinity: ack, will do
<nacc> teward: fyi, i put some notes in https://wiki.ubuntu.com/XenialXerus/ReleaseNotes will try and flesh it out more too
<tsimonq2> nacc, teward: I'm back, what's up?
<jderose> nacc: might be nice to mention apt 1.2 and its shiny new DropPrivs feature :)
<nacc> jderose: oh i was just updating for php7 :)
<nacc> tsimonq2: sent an updated MP
<tsimonq2> nacc: k cool
<tsimonq2> nacc: and if you pushed to the branch, the MP would have updated :)
<nacc> tsimonq2: ok i wasn't true, the guide mentions needing to put a new branch for every push, which seems confusing :)
<tsimonq2> yeah :)
<infinity> jderose: iz a wiki. ;)
<infinity> jderose: *hint*
<tsimonq2> nacc: reply incoming
<jderose> infinity: is a wiki indeed, just crazy busy with something else ATM :P maybe later i'll have a chance
<smoser> hey
<smoser> anyone know how /run/network/ifstate gets initialized ?
<smoser> i'm seeing that /lib/open-iscsi/net-interface-handler may end up populating it before it gets initialized. so /lib/open-iscsi/net-interface-handler does what it wanted (to make it appear like the iscsi root device nic is already up)
<smoser> but that runs to early, and something else stomps it
<teward> tsimonq2: scrollback is important
<teward> tsimonq2: also, assign yourself to "Fix the inconsistencies with indentation - tabs and spaces should not exist simultaneously" issue
<tsimonq2> teward: is that a bug already or no?
<tsimonq2> s/bug/bug report/
<teward> tsimonq2: nope, but nacc identified it as a problem
<tsimonq2> k I'll do that in like 30 mins
<smoser> slangasek, ^ or xnox ^ or pitti ^ (/me knows that 2 out of those 3 certainly should be EOD)
<slangasek> smoser: ifupdown creates that file the first time it brings an interface up
<smoser> slangasek, how does it know its the first time ?
<slangasek> smoser: because the file isn't there yet
<smoser> not true
<teward> nacc: ack on the ping, looking now
<smoser> i write it before it does, and then it truncates it
<smoser> s/i/lib/open-iscsi/
<slangasek> smoser: did you take a lock before you created it?
<smoser> how do i take a lock ?
<teward> nacc: s/configuration step/configuration change/ on the nginx bulletpoint,  but since it's a wiki I'll edit.
<slangasek> smoser: ifupdown/main.c; it appears you need an fcntl(F_SETLK) on /run/network/.ifstate.lock
<smoser> i'm pretty sure i'm not racing with it.
<smoser> as this is running from udev
<smoser> on the added lo event
<smoser> which would later bring it up
<smoser> slangasek, that make sense ?
<smoser>  /lib/open-iscsi/net-interface-handler (http://paste.ubuntu.com/15800985/) is running via udev rule on a RUN+=
<smoser> and i even had it runnign from a IMPORT (meaning it ran right then) and still saw the issue
<tyhicks> jjohansen, sarnold, jtaylor: the new network-manager is what triggered the "disconnected path" denials (the new apparmor was *not* the cause)
<tyhicks> jjohansen, sarnold: that's the case for the dnsmasq denials - I'm not sure about dhclient yet
<jjohansen> tyhicks: thanks
<slangasek> smoser: I don't think it's safe to assume that 'added lo' doesn't race other network interfaces
<slangasek> whether you're tripping the race or not in this case, I'm sure there is a race there
<sarnold> tyhicks: nice find :)
<TheMuso> Mirv: If nobody else has looked at your merge by now, I can have a look.
<seb128> cyphermox, hey, did you see bug #1568336?
<ubottu> bug 1568336 in ppp (Ubuntu) "pppd crashed with SIGSEGV in plugin_init()" [Medium,Confirmed] https://launchpad.net/bugs/1568336
<seb128>   1646: 	option_error("Plugin %s is for pppd version %s, this is %s",
<seb128> in the nm plugin :-/
<nacc> slangasek: what/who should i subscribe to the microrelease-exception request for php7.0?
<xnox> smoser, haha
#ubuntu-devel 2016-04-13
<xnox> pitti, there are no color escape code processing on LPAR & z/VM, instead one sees the color escape codes verbantim and one has to read it like matrix.
<xnox> https://github.com/systemd/systemd/pull/3025/files
<cjwatson> Why isn't that a terminfo thing?
<cjwatson> I mean if you say TERM=dumb systemctl status blah.service then you don't get colour escape codes, for instance.
<cjwatson> Maybe bits of systemd should be terminfoing harder, but that patch seems pretty wrong :)
<xnox> cjwatson, hm, that's about log messages pid 1 prints to console, and it defaults to LogColor=yes unconditionally irrespective of terminfo
<xnox> there is no terminfo when pid1 starts, or is there already inherited from initramfs?
<xnox> at the moment it really just does LogColor=yes all the time to whatever is boot messages console.
<xnox> this is not about systemctl
<smoser> slangasek, yeah, there is definitely a race in that code, but it should only end up being a double-add
<smoser> ie, if it checks with grep and then before appending the entry is there, then it could add it twice. or two things racing on open writes, but i dont think i'm hitting that.
<smoser> i'm hitting the file being written and then truncated.
<slangasek> smoser: erm, ifupdown does atomic replaces of that file
<smoser> hhm..
<smoser> so do you have thoughts on how open-iscsi could add a record there. to indicate that the interface that holds the root filesystem is already up?
<smoser> im' sure there are better ways to do what its trying to do, but the intent is 2 fold
<smoser> a.) get mark the interface up so ifup doesnt try to bring it up and fail
<smoser> b.) populate resolvconf with stuff from initramfs
<smoser> slangasek, so how does ifupdown know that it is the "first" ?
<smoser> i'm pretty certain i'm writing that file before any interfaces are brought up. because i'm writing it through udev, which would bring said interfaaces up.
<cyphermox> TheMuso: hey, not sure if you're done with the fixes you were making in ubiquity, but if you weren't, you'll want to pull again, I did an upload for more translations and vt switching.
<smoser> fudge.
<smoser> good night.
<TheMuso> cyphermox: I personally was done with ubiquity last week, was just helping out Mirv get some stuff in. Thanks anyway.
<cyphermox> ok, well thanks for the changes :)
<TheMuso> np
<slangasek> smoser: mm. it's the first because the file doesn't exist yet
<darkxst> infinity, I have take2 of the casper fix (inject systemd unit) on bug 1561302 if you have time to have a look
<ubottu> bug 1561302 in casper (Ubuntu) "gdm won't allow passwordless login" [Critical,Triaged] https://launchpad.net/bugs/1561302
<Mirv> TheMuso: cyphermox: thanks a lot, both for ubiquity and to cyphermox for u + u-s-u translations update
<cpaelzer> good morning
<TheMuso> Mirv: np
<pitti> Good morning
<pitti> smoser: you mean ifupdown removes an existing /run/network/ifstate on boot that o-iscsi wrote in the initramfs?
<lathiat> i discovered ifupdown2 last week, I need to investigate that with more enthusiasm.  otherwise systemd-networkd needs a lot of work.
<pitti> smoser: it's handled in main.c, and I only see it being opened in "r" or "a+" mode (when it removes an entry)
<pitti> smoser: perhaps better file a bug to collect information, easier to read than a smeared-out IRC conversation?
<pitti> xnox: saw your PR, thanks
<pitti> xnox: I suppose that's something which could land in an SRU?
<xnox> pitti, yeah, if it's merged upstream. Or like if we upload systemd for any other reason it would be nice to pick that thing up too. it is mostly cosmetic.
<pitti> xnox: yeah, as soon as it lands I'll cherry-pick it into the Debian tree (which I merge from, we are up to date in xenial)
<Mirv> xnox: I'm seeing multiple ICE:s on s390x only despite multiple retries on qtdeclarative + qtbase autopkgtests: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtdeclarative-opensource-src
<Mirv> pitti: ^ those are also the only reason the two packages are stuck in proposed now
<pitti> ah, I just retried a few s390x tests
<pitti> (and this morning too)
<pitti> Mirv: I figure we don't care that much about Qt on s390x, so I'm okay with force-skiptesting Qt
<Mirv> pitti: here are url:s to four successive icing rocs builds for example http://pastebin.ubuntu.com/15805849/
<Mirv> pitti: well I know xnox cares, he enabled it :)
<pitti> oh, ok
<Mirv> but maybe mostly build wise
<Mirv> and not like running phone on his mainframes
<pitti> Mirv: so, if these aren't too urgent, we can keep them for a while for xnox/doko to investigate, I don't mind either way
<Mirv> and these new compiler crashes are unlikely due to Qt changes and more likely due to gcc...
<pitti> but I guess it'd be enough to file a bug with the URL to the build log and let them pass
<xnox> pitti, yeah forcing should be fine. but compiler shouldn't ICE either.
<pitti> can someome file a gcc bug?
<Mirv> pitti: either is fine for me too, as long as they eventually get in
<Mirv> filing
<xnox> pitti, well i'm guessing Mirv doesn't have easy s390x access =) trying to reproduce rocs ICE
<doko> Mirv, s390x-linux-gnu-g++: internal compiler error: Killed (program cc1plus)
<caribou> hmm, I did a mistake on my vsftpd upload, it went to Wily instead of xenial so it is waiting in Unaproved Wily's queue
<doko> looks like you're running out of memory. maybe half the parallelism?
<caribou> what needs to be done to have it removed ?
<xnox> caribou, ping anybody in #ubuntu-release to reject it.
<caribou> xnox: thanks!
<Mirv> xnox: doko: you can make this bug #1569750 prettier
<ubottu> bug 1569750 in gcc-5 (Ubuntu) "s390x new ICEs" [Undecided,New] https://launchpad.net/bugs/1569750
<pitti> caribou: rejected
<caribou> pitti: thanks ! didn't even have time to ask !
<caribou> (in  #ubuntu-release I mean) :)
<pitti> caribou: de rien :)
<caribou> that's what happens when you do that type of work during training
<pitti> caribou: mÃªme pas mal -- that's why we have unapproved queues :)
<xnox> caribou, also we know suspect you are not running xenial =)
<caribou> yeah, I still hate that
<doko> Mirv, did you read what I wrote?
<Mirv> doko: now I did. xnox can look into it if he can reproduce it. it hasn't happened earlier (previous qtbase landing last week) so it's a bit suspicious regarding what has changed.
<doko> ok
<xnox> Mirv, well the autopkgtests on s390x run in lxd containers so share resources. not reproducible on a standalone zvm.
<xnox> Mirv, the rules file looks crazy
<pitti> LXCs have a memory limit of 1.8 GB (for ages), and the whole box has 4 GiB, so they shouldn't stomp on each other's feet much
<xnox> i have no idea how to disable parallel build.
<xnox> pitti, right, and the whole zvm shares memory with other zvms, I have totally seen performance fluctuations.
<doko> xnox, strip parallel=% from DEB_BUILD_OPTIONS, and explicitly append parallel=1
<pitti> sorry, they have 26 GB in total, and 8 parallel runners (the above was armhf)
<pitti> xnox: oh, this is overcommitted?
<pitti> anyway, there wasn't anything running this morning when I retried
<xnox> horum, weird.
<xnox> doko, but this is autopkgtest.... or does the autopkgtest set redicious parallel= setting?
<doko> ginggs, https://launchpad.net/ubuntu/+source/gdcm/2.6.3-3ubuntu2 are you aware of anything that changed in b-d's?
<doko> xnox, well, it's building the package first
<doko> pitti, but yes, autopkg tests maybe should print out the value of DEB_BUILD_OPTIONS, and maybe available memory, swap and cpu's
<doko> ahh, dh_auto_build '--buildsystem=kf5' --parallel
<doko>         make -j8
<xnox> dh_auto_build '--buildsystem=kf5' --parallel
<xnox> 	make -j8
<xnox> yesh
<xnox> but from an autopkgtest i don't see that it compiles the whole thing.
<xnox> pitti, Mirv - why is rocs doing a full build? and with -j8?
<ginggs> doko: going to have a look
<Mirv> xnox: I think that's what most kde packages do in their autopkgtests
<Mirv> xnox: but I'm not familiar with rocs
<xnox> Restrictions: build-needed
<xnox> however, no idea where -j8 is coming from then.
<xnox> adt itself?
<pitti> export DEB_BUILD_OPTIONS=parallel=$(grep -c ^processor /proc/cpuinfo | sed 's/^0$/1/')
<pitti> yes
<pitti> (from bug 1399177)
<xnox> pitti, do you know about $ nproc ?
<ubottu> bug 1399177 in autopkgtest (Ubuntu) "adt-run should parallelize builds as necessary by default" [Wishlist,Fix released] https://launchpad.net/bugs/1399177
<Laney> nproc!
<Laney> high five
<pitti> xnox: yes, but only after I added that :)
<pitti> not sure where I stole that from
<xnox> pitti, right but 3.25GB of ram is not enough for -j8 of c++ code
<xnox> pitti, because it's 8 cores in all runners, should be divided by number of runners or some such. Can you half that number somehow? when using lxc/lxd runners?
<pitti> xnox: yes, I'll think about how to do that; most preferably, by only giving one or two CPUs to each container
<xnox> pitti, right that would work too.
<pitti> I adjusted bug 1569750 accordingly
<ubottu> bug 1569750 in Auto Package Testing "s390x new ICEs" [Undecided,New] https://launchpad.net/bugs/1569750
<doko> that probably also explains why we had test failures for mariadb-10.0 which disapparead after disabling the parallel build
<pitti> does this also do a package build in its autopkgtest?
<pitti> it's already expensive enough for all those KDE packages
<doko> anybody familiar with gbp?
<pitti> I'm using it quite regularly
<infinity> pitti: You stole that grep/sed from launchpad-buildd, because it had to work on series' before nproc(1) existed. ;)
<pitti> ah, that was probably it :)
<pitti> but it exists on precise, so we should be okay
<mwhudson> doko: the main thing with gdb is to use import-orig and nothing else
<mwhudson> doko: :-)
<mwhudson> er
<mwhudson> gbp
<pitti> gbp buildpackage is kinda the main point, gbp clone is nice, and gbp pq rather useful
<doko> mwhudson, pitti: I now just synced sparkleshare, there was no delta left ...
<doko> was just wondering about the ubuntu diff
<mwhudson> oh right, pq sounds nice, i've never really used it in anger
<pitti> doko: yeah, if the appindicator bits went to Debian and we synced, having an ubuntu branch is also obsolete
<xnox> pitti, looking at our initramfs: ${recovery:+--startup-event=recovery} -> surely that's upstartism that does not work with systemd.
<pitti> xnox: right, that would just be "recovery"
<pitti> as per friendly-recovery.service
<xnox> pitti, and i take it the phone/touch stuff cannot really boot into upstart recovery, can it?
<pitti> xnox: I'm not entirely sure, but it's rather hard to set boot params there and -ENOKEYBOARD either
<pitti> xnox: so I'd say "no" is a pretty safe answer indeed
<doko> jamespage, could you have a look at the openstack test rebuild ftbfs at https://launchpad.net/ubuntu/+archive/test-rebuild-20160401/+build/9502328 ?
<jamespage> doko, going to point that to coreycb > https://launchpad.net/ubuntu/+archive/test-rebuild-20160401/+build/9502328
<infinity> xnox: systemd's works fine because it just reads cmdline.
<infinity> xnox: If you're suggesting tearing out the upstartism, don't.
<xnox> ok
<Mirv> pitti: did bzoltan ping you about one armhf "Test in progress" https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-016/excuses.html that doesn't seem to be really running (has been there for 18 hours at least)
<bzoltan> Mirv: I am not sure if pitti has seen my lines on the ci-eng
<Mirv> bzoltan: he's not on the channel so I doubt it
<bzoltan> Mirv:  possible... I used the android client what did not show
<Mirv> bzoltan: you used _what_ client! :D
<bzoltan> Mirv:  shame on me, shame on me...
<bzoltan> Mirv:  I wish to have a quassel client for ubuntu touch
<infinity> xnox: What are the odds I can talk you into moving all those new s390-tools perl utilities into an s390-tools-perl package or something?  Alternately, not shipping s390-tools in minimal.
<infinity> xnox: (It's trying to yank perl and all its deps to priority:important, which isn't ideal)
<infinity> Normally, I'd just set an ignore override in priority-mismatches, but perl's a bit of an oddball to ignore.
<otto_> Is this the correct channel to contact release-team as documented at https://wiki.ubuntu.com/FreezeExceptionProcess#Milestone_Freeze ?
<infinity> otto_: -> #ubuntu-release
<xnox> infinity, i'll be happy with that, if none of the essential tools are written in perl (i don't think any are)
<xnox> infinity, also note the sysconfig upload (and the auto-accepted s390-sysconfig-writer) packages =) you may want to review it
<infinity> xnox: I skimmed, but I'm not really awake enough to be on the hook for reviewing.
<xnox> infinity, in general - purge a tonne of bash scripts that were imported from debian that were imported from suse; instead use the tool written in C to generate and use minimalistic udev rules, which use builtins only.
<xnox> and the generated udev rules are simply stored in /etc/udev/rules.d like one would normally expect.
<infinity> xnox: For bonus points, making s390-tools mawk-compatible and dropping the gawk dep would be awesome, but meh.
<xnox> the problem is old hwup/hwdown stuff, relied on WAIT_FOR_SYS= in udev rules to wait for devices to be fully there, and then fork to loads of bash. But systemd-udev has removed support for that, so things are really broken when one has many devices, and on typical mainframes one does have a lot of devices.
<xnox> infinity, to be honest we don't need s390-tools in minimal per-se.
<xnox> howerver IBM will wine if it's not there.
<xnox> it only needs to be there on full installs, and is mostly uterly useless in e.g. containers
<pitti> so, ubuntu-standard then?
<xnox> yeah.
<pitti> speaking of which, we still put ureadahead into minimal
<infinity> Yeah, if I had my way, it would be standard.  And zipl would be packaged separately and actually installed in the target by zipl-installer.
<pitti> it should really move to ubuntu-desktop and perhaps ubuntu-server, but we so much don't want it in containers and stuff
<infinity> Which currently isn't an installer at all. :P
<xnox> infinity, i'm totally for moving s390-tools to standard, but let me check. E.g. i'll need to check that e.g. sysconfig stays in minimal, and doesn't pull s390-tools back in.
<xnox> infinity, quite.
<xnox> infinity, and then i want to have something generate /etc/zipl.conf similar to e.g. update-grub, with all installed kernels getting a stanza, and having something to control all the kernel parameters, etc.
<infinity> xnox: That'd be nice, but perhaps a bit ambitious for the next week.
<infinity> Though, given it's a simple yaboot/silo config style, it's much easier to write than grub.cfg.
<infinity> I wish grub were that readable.
<xnox> infinity, so we need zipl + sysconfig-hardware packages on bare metal installs, and i think something in the installer already tries to install sysconfig-hardware on the system, thus e.g. splitting zipl into standalone package and have sysconfig-hardware depend on it should do just the right thing.
<xnox> and then we can drop s390-tools into standard.
<infinity> xnox: Don't think sysconfig-hardware should depend on zipl.  We should just follow the example we follow for all bootloaders and install it out-of-band.
<xnox> ok
<infinity> xnox: So, for d-i, zipl-installer should install it in the target before setting it up.
<xnox> right
<infinity> xnox: And for cloud images, we'll just add it to the install list.  Easy peasy.
<doko> barry, are you looking at https://launchpad.net/ubuntu/+archive/test-rebuild-20160401/+build/9500466 and https://launchpad.net/ubuntu/+archive/test-rebuild-20160401/+build/9501296 ?
<infinity> That won't actually fix my perl woes, mind you (perl is optional, not standard), but it would still look less ugly. :P
<infinity> Splitting the perl utils out would probably still be nice.
 * xnox ponders where perl is used
<infinity> sower@z13-028:~$ dpkg -L s390-tools | xargs grep bin/perl 2>/dev/null
<infinity> /lib/s390-tools/zipl_helper.device-mapper:#!/usr/bin/perl -w
<infinity> /lib/s390-tools/cpumf_helper:#!/usr/bin/perl -W
<infinity> /usr/sbin/chcpumf:#!/usr/bin/perl -W
<infinity> /usr/sbin/ziorep_config:#!/usr/bin/perl
<infinity> /usr/sbin/chmem:#!/usr/bin/perl
<infinity> /usr/sbin/ziomon_fcpconf:#!/usr/bin/perl
<infinity> /usr/sbin/ip_watcher.pl:#!/usr/bin/perl -w
<infinity> /usr/sbin/lsmem:#!/usr/bin/perl
<infinity> /usr/sbin/lsluns:#!/usr/bin/perl
<infinity> /usr/bin/ts-shell:#! /usr/bin/perl -W
<infinity> /usr/bin/lscpumf:#!/usr/bin/perl -W
<infinity> /sbin/zfcpdbf:#!/usr/bin/perl
<infinity> /lib/s390-tools/chreipl_helper.device-mapper:#!/usr/bin/perl -w
<infinity> There. :P
<pitti> mvo: goget-ubuntu-touch build deps on three NBS packages (http://people.canonical.com/~ubuntu-archive/nbs.html); is that still on your list, or on Sergio's, or someone else's?
<xnox> right. and i am not re-writing zipl/chreipl_helper from perl this week and those are needed to generate/install the right zipl to boot with device mapper
<xnox> other bits are optional-ish
<infinity> xnox: Yeah, but if those are shipped with zipl, they get out of minimal.
<xnox> true.
<infinity> xnox: Since minimal doesn't include bootloaders on any other arch.
<xnox> package name - zipl or s390-tools-zipl ?
<infinity> Oh, chreipl_helper.device-mapper and zipl_helper.device-mapper are the same file. :P
<xnox> yes, symlinks
<infinity> xnox: I think it's probably important enough to warrant top level namespace.
<infinity> xnox: But your call.  And it would be nice if we can get this all back to Debian some day, so we're not horrible forked forever.
<infinity> s/horrible/horribly/
<xnox> we forked pretty agressively, and are feeding changes back.
<xnox> but it is slowish.
 * infinity wonders if he should give up on sleep and just go buy a 2L thing of Coke to reanimate.
<xnox> infinity, to be honest.... drop s390-tools & sysconfig-hardware out of minimal, make zipl-installer install those two packages -> jobs done.
<xnox> or like move them to ubuntu-standard
<infinity> xnox: True, we could just make zipl-installer pull the whole shebang in.
<ginggs> doko: gdcm builds fine locally, I think there might be something in -proposed that it doesn't like
<infinity> xnox: FWIW, sysconfig-hardware has no deps outside of minimal, so it's fine.  Unless it doesn't make sense to have it in, say, containers.
<xnox> infinity, new one grows a dep on s390-tools
<xnox> for chzdev/lszdev
<infinity> Oh.
<infinity> Heh.
<xnox> however that is all good
 * doko looks at one more juju package in NEW
<infinity> xnox: Kay, yeah.  Moving them from minimal to boot, and making installers pick them up might be the Right Thing.
<infinity> xnox: Then a debootstrapped or container setup won't have them, which sounds correct.
<xnox> and our s390-sysconfig-writer already had apt-install sysconfig-hardware but i dropped that (not sure why)
<xnox> but i think i do want to add
<xnox> apt-install s390-tools sysconfig-hardware in zipl-installer
<xnox> for zipl & initramfs-hooks
<xnox> and then we can drop both out of minimal.
<infinity> When does s390-sysconfig-writer run?
<infinity> I'd assume before the bootloader install.
<infinity> So it probably wants to install the things it intends to use.
<doko> ginggs, it wants to link with libproj9 (according to ubuntu1), but there is no libproj* being installed, so I assume there are dependencies /b-d's dropped
<infinity> But no harm in both of them doing it, apt-install $(already_installed_thing) doesn't hurt.
<pitti> -y
<pitti> ah sorry, apt-install, ignore me
<ginggs> doko: ah ok, so one of gdcm's build-deps dropped libproj9 as a dep?  can we just add libproj9 as a build-dep to gdcm then?
<doko> ginggs, better the -dev package
<ginggs> doko: libproj-dev yes.  shall i test and upload?
<doko> ginggs, please do, you became our "science" specialist ;p
<doko> ahh, that is -med ... anyway
<ginggs> doko: no problem, i'll do it
<xnox> infinity, well new one doesn't run anything from target, it simply writes out generated udev rules to /target/etc/udev/rules.d
<xnox> yeah, but zipl-installer really should make sure zipl is in target.
<doko> mwhudson, sinzui: juju-mongodb-tools's debian/copyright seems to miss the license for vendor/src/golang.org/x/
<cpaelzer> hi, we were wondereing about a missing dbgsyms package - openvswitch-switch-dpdk-dgbsym in particular
<cpaelzer> it was there the last few weeks just fine, but now seems gone
<cpaelzer> there was no rebuild since then
<cpaelzer> and the launchpad pages about it look ok https://launchpad.net/ubuntu/+source/openvswitch/2.5.0-0ubuntu1/+build/9328367 and https://launchpad.net/ubuntu/xenial/amd64/openvswitch-switch-dpdk-dbgsym/2.5.0-0ubuntu1
<cpaelzer> The only thing that was around that package is that they were dropping out of main due to the changes how dependencies were handled
<cpaelzer> they were seeded back in two days ago
<cpaelzer> others build by the same source are still there: openvswitch-dbg openvswitch-common-dbgsym openvswitch-switch-dbgsym openvswitch-testcontroller-dbgsym openvswitch-vtep-dbgsym openvswitch-ipsec-dbgsym
<xnox> cpaelzer, you do have ddebs repository enabled right?
<cpaelzer> any guidance / idea what might have happened to the package?
<cpaelzer> xnox: sure the other dbgsyms come in just fine
<cpaelzer> the package also is no more in http://ddebs.ubuntu.com/dists/xenial/main/binary-amd64/Packages
<cpaelzer> so it is really missing in the archive
<cpaelzer> I hope tht was the right place to check
<xnox> i see [   ]	openvswitch-switch-dpdk-dbgsym_2.5.0-0ubuntu1_amd64.ddeb	10-Mar-2016 14:44	1.2K	  in http://ddebs.ubuntu.com/pool/universe/o/openvswitch/?C=M;O=D
<xnox> cpaelzer, s/main/universe/
<doko> mwhudson, sinzui: juju-mongodb-tools: and vendor/src/golang.org/x/ reference a LICENSE file which doesn't exist in the sources. Please add it
<cpaelzer> xnox: so it is related to the main/universe changes then
<xnox> cpaelzer, which is not published.
<cpaelzer> the dbgsyms package didn't make it back into main
<xnox> pitti, things look slightly inconsistent on ddebs.ubuntu.com the ddebs are there, but not "published"
<cpaelzer> jamespage: on reseeding openvswitch-swicth-dpdk would we have needed another step to re-main the dbgsyms as well^^ ?
<xnox> cpaelzer, do you need it, or do you need it published? =)
<doko> mwhudson, sinzui: rejected for now. afaics the other license information, and the packaging seem to be okish
<xnox> cpaelzer, download with $ wget http://ddebs.ubuntu.com/pool/universe/o/openvswitch/openvswitch-switch-dpdk-dbgsym_2.5.0-0ubuntu1_amd64.ddeb
<cpaelzer> xnox: I don't need it like - right now
<cpaelzer> I just wanted to make sure it gets back in before release time
<cpaelzer> and IFF that identifies a general issue get some others back in
<pitti> xnox: how do you mean? http://ddebs.ubuntu.com/dists/xenial/main/binary-amd64/Packages.xz has symbols for 2.2.0-0ubuntu6 and that's the current version
<infinity> Looks like perhaps a bug in how ddebs handles (or doesn't) component changes.  Or maybe it's just a "be patient" thing.
<doko> afk for a while
<pitti> oh, openvswitch, not dpdk
<xnox> pitti, not really. openvswitch-switch-dpdk-dbgsym is not there.
<jamespage> cpaelzer, hey - your dpdk change looks OK from my perspective - what testing has it had?
<cpaelzer> pitti: we were looking for openvswitch-switch-dpdk[-dbgsyms] 2.5.0-0ubuntu1
<xnox> pitti, the ddeb is in universe pool, and in none of the Packages files.
<infinity> Yeah.  I just promoted it in the last day.
<infinity> pitti: Does ddebs track component moves, or need some sort of cleanup run to find them, or...?
<cpaelzer> jamespage: it was through 4 types of autotests (i386, amd64, amd64 + cpu features, amd64 + cpu features + low memory) and all those fixes came to existance due to testing, so they were kind of tested from the beginning
<pitti> infinity: it just takes the archive's Packages and builds a corresponding archive for the ddebs it finds, nothing too clever
<pitti> infinity: so in principle it should
<infinity> pitti: But in practice... :P
<cpaelzer> jamespage: unfortunately I can't test not-yet uploaded with my CI yet (known TBD), but as soon as it is I'll run it against various more tests /tetspmd, l2fwd, openvswitch-switch-dpdk benchmarking)
<cjwatson> It's a shame ddeb-retriever doesn't routinely log everything to a file
<pitti> but it wouldn't re-run for that package if there aren't new ddebs, so maybe that's some weird cache effect
<cjwatson> pitti: it should get a new binary publication
<pitti> so, no off-hand idea
<cjwatson> unless it thinks it's not new just because it has the file
<jamespage> cpaelzer, ack
<cjwatson> pitti: ah yes, so look in the "try to install ddebs from publishing history records" block
<cjwatson> pitti: I think that decides it exists (because it's in ddeb_map at the right version/arch) but doesn't check component
<pitti> cjwatson: but shouldn't that mean that /pool would be wrong too?
<pitti> I thought this was only an index creation problem
<infinity> pool is wrong.
<cpaelzer> jamespage: also all but one fix of that upload are already upstream accepted (=extra testing & review)
<infinity> It's in universe in the pool, when it should have moved to main.
<pitti> ah, that would make more sense then
<xnox> infinity, uploading zipl-installer that has apt-install s390-tools & sysconfig-hardware. Once that's in, and migrated, we can demote both to ubuntu-standard or some such.
<infinity> xnox: They're both in boot already, they can just be dropped from minimal, probably.
<xnox> yeah.
<infinity> xnox: If all installers always install those packages, and they're not needed in non-hardware (ie: container/chroot) contexts, that should be enough.
<cpaelzer> xnox: s390-tools should be around everywhere - IMHO I'd drop it from nowhere
<infinity> cpaelzer: Why?
<xnox> cpaelzer, buildd chroot does not need
<xnox> cpaelzer, docker image does not need it
<xnox> cpaelzer, etc.
<cpaelzer> yeah ok, the virtual cases - ok you got a point
<cpaelzer> but if possible we should try to not open up a chance that anybody might end up on real HW without s390-tools
<xnox> cpaelzer, in practice it will be available on all installed systems that boot with zipl.
<infinity> cpaelzer: If you only need it in the places where you'd need, say, bootloaders or a kernel, then it doesn't belong in minimal.
<cpaelzer> xnox: will it be in the install environment as well?
<xnox> cpaelzer, when you say install environment, i have no idea what you mean =) no, zipl is not available in d-i and never was.
<xnox> s390-tools-udeb only ships dasdfmt & fdasd. very recently i've added chzdev and lszdev.
<infinity> There's a tiny subset of s390-tools in the d-i env.
<infinity> Yeah, those.
<cpaelzer> if the install has any issues or something that brings people to "exit to console" people would expect s390-tools to be around to debug
<xnox> cpaelzer, good luck to them =)
<cpaelzer> xnox: hehe
<xnox> cpaelzer, and no, they really don't.
<cpaelzer> xnox:  I know how to get that shit out of sysfs :-=
<cpaelzer> well i'm ok - thats the H in my IMHO, then keep it as is and we only consider it in case someone else complains ok?
<xnox> cpaelzer, they can do anna-install openssh-client and then do scp of things they do need, in and out.
<infinity> cpaelzer: No one's complained much yet (in fact, people just seem to be signing the praises of how we suck less than our competitors), so let's not invent problems for them to complain about. ;)
 * infinity declares sleep a lost cause and goes shopping.
<cpaelzer> infinity: I know a few I expect to just wait in the wings to start yelling at us - but I'm totalyl fine and also happy about the feedback so far
<cpaelzer> just rich tooling in install env is something they really asked for, so far they just asked me verbally
<cpaelzer> I might just redirect them to officially report it in case they REALLY want it
<infinity> cpaelzer: There's always going to be some "you're not RHEL" style feedback, which we generally should push back on with "no, we're not, learn Ubuntu instead of asking us to be RHEL", but there are legitimate requests too.
<jamespage> cpaelzer, ok - uploaded - release team will need to ack that as well
<infinity> cpaelzer: If we're missing some handy tools for debugging in our udebs, we can certainly add some.
<infinity> Though, parts of s390-tools have dependencies that pretty much require a full Linux env to get going.
<infinity> And we're not doing that.
<cpaelzer> infinity: yeah I think the dependencies are what breaks us from getting all the useful ls* tools
<bzoltan> pitti:  would you be able to check one armhf "Test in progress" https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-016/excuses.html that doesn't seem to be really running
<infinity> Our installer is busybox and a bunch of C, not a full Linux with perl and python and every whiz-bang library.
<xnox> cpaelzer, ls* tools are excessive. i did add lszdev which is a small compiled binary and it does most of what the rest of ls* tools do. or rather those that matter during installation: qeth, dasd, zfcp
<cpaelzer> I think due to xnox adding lszdev we have the basics which is great
<cpaelzer> yes - we just thought the same
<cpaelzer> jamespage: thanks I just saw it popping up in #ubuntu-release
<xnox> cpaelzer, "we" -> there are more than one person behind cpaelzer nick?
<xnox> =)
<xnox> anyway, need to fix more bugs.
<cpaelzer> xnox: no, you were more or less writing the same than I did that lszdev will cover most whats needed
<xnox> ah, ack.
<infinity> xnox: zipl-installer change looks sane to me.
<infinity> xnox: I'll make the same change for cloud images, and when that's all migrated, un-minimal those two packages and see how my reports love me.
<xnox> oh it would be really nice to do it properly - that is have rootfs-livefs install those two in the disk1.img only, and not in the lxc/lxd tarball
<xnox> unlike other bootloaders....
<infinity> xnox: "unlike other bootloaders"?  Do the lxd images have grub in them?
<xnox> infinity, ...
<infinity> xnox: Legitimate question, I don't use lxd. :P
<xnox> they do have grub-legacy-ec2 i believe
<xnox> and bits of removed grub
<coreycb> jamespage, doko: I'll take a look at that python-pint ftbfs
<doko> lifeless, any idea about http://bugs.debian.org/802124 ?
<ubottu> Debian bug 802124 in src:pyjunitxml "pyjunitxml: FTBFS: test_erroring_test (junitxml.tests.test_junitxml.TestJUnitXmlResult) fails" [Serious,Open]
<doko> pitti, ^^^ you NMUed three years ago. the package is unused. just seeded. ok to remove it from the seed?
<pitti> doko: absolutely, please kill it; probably just seeded to consistently keep all binaries in main, I suspect
<pitti> bzoltan: retried
<bzoltan> pitti:  thanks
<doko> Laney, could you have a look at the development seed in the desktop section, and remove Python2 binary packages?
<infinity> xnox: Was the block-proposed on s390-sysconfig-writer just so it would get review?
<doko> cjwatson, you added python-gpod to the development seed in 2007. can it be removed (no python3 package)?
<xnox> infinity, it was there such that i am here to rebuild d-i
<xnox> which i am.
<xnox> because old d-i + new sysconfig-hardware is tested to work correctly, but is ugly =)
<infinity> xnox: Heh.  Kay.  We'll, let's hold off until all those bits migrate *and* I demote things I need to, then we can redo d-i and spin a test ISO to make sure it all looks sane.
<xnox> right yes
<xnox> in that case d-i upload is a bit pre-mature. Or like do not accept it.
<infinity> xnox: Removed the tag.
<xnox> infinity, i thought d-i builds with proposed enabled, no?
<infinity> xnox: It does.  I want to make sure everything looks right with the seed changes I committed and after I mangle overrides, etc.
<infinity> xnox: In theory, none of that should affect d-i, but...
<xnox> =)
<infinity> xnox: Anyhow, temp rejected for now, I'll accept a bit later.  Going to go find caffeine.
<xnox> cool
<doko> pitti, can we remove python-libapparmor from thesupported seed? the python3 module is there too. oth there is no python3-ufw package
<ginggs> doko: gdcm uploaded.  I was unable to find where libproj9 was dropped though, I even checked in Debian unstable and gdcm still builds there.
<pitti> doko: I think we should remove all python-* from the seeds
<pitti> we want to move to py3, after all
<doko> pitti, sure, if people agree ...
<doko> jdstrand, we have a python-ufw package, but no python3-ufw package
<pitti> I thought we already agreed to that on some ML a few weeks/months back
<infinity> pitti: Did we agree to drop all the python stuff, or update it to py3?  I thought the whole point of that seed was to have a set of python modules we claim we support.
<doko> ohh, ok, then I'll remove all of them
<infinity> (Not that I care at all if it all goes to universe)
<doko> infinity, there are some which don't have a python3 package
<pitti> moving to python3-* for those that exist sounds fine
<pitti> and dropping the others
<infinity> doko: Personally, I'm happy to see them all drop out unless they have seeded rdeps.
<cjwatson> doko: I don't care about anything I added to the development seed in 2007
<infinity> But my opinion of python isn't high. :P
 * infinity scratches his head at britney.
<cjwatson> (2006, actually)
<pitti> mine is very high, but I mostly treat them like libfoo -- if they have rdepends in main, fine, but otherwise don't bother
<infinity> cjwatson, pitti: Any ideas why britney would be doing the "trying to remove package" thing for something that doesn't exist in either unstable *or* testing?
<cjwatson> infinity: Which package?
<infinity> cjwatson: ubuntu-snappy.  Top of excuss.
<cjwatson> It must be somewhere or it wouldn't know the name.
<infinity> Ahh.  Old version of golang-snappy-dev hanging around.
<infinity> Will sort.
<pitti> hm, it was removed 15 hours agbo
<pitti> https://launchpad.net/ubuntu/+source/ubuntu-snappy/+publishinghistory
<cjwatson> pitti: it's NBS
<xnox> pitti, on ubuntu, may I use /usr/lib/modules-load.d ? and i don't see /lib/modules-load.d to exist, does it?
<cjwatson> goget-ubuntu-touch b-ds on it
<xnox> pitti, or what is the ubuntu-ish/debian-ish way to load modules?
<infinity> Yeah.  Silly goget.
<pitti> xnox: /usr/lib/modules-load.d/ should be fine
<pitti> xnox: /lib/m-l.d  might work, but the manpage doesn't document it thus we don't want to advertise it
<xnox> pitti, right, and reading source code it does support /lib/m-l.d when built with SPLIT_USR
<xnox> in my case the thing is in /usr anyway, so /usr/lib will do fine.
<pitti> . o { /usr merge !!! } *sigh*
<pitti> xnox: hm, so it turns out cgroups don't have a knob to say "2 CPUs", just "assign CPUs 0 and 3"
<pitti> so, no cgroup magic for this
<xnox> =(
<xnox> pitti, but i thought lxd/lxc had extended syntax to "give me 50% cpus"
<xnox> or some such.
<xnox> summon stgraber ^ =)
<pitti> xnox: I googled around and searched the manpages, didn't see anything
<xnox> =(
<infinity> $(($(nproc) / 4)) ?
<xnox> pitti, doing it by hand is, well hard. I think adt-lxc should realise it sees _all_ cpus, but shouldn't use _all_ of them.
<pitti> there is lxc.cgroup.cpuset.cpus and lxc.cgroup.cpu.shares
<pitti> I'd actually like to resource-limit the container itself to only 1 CPu
<xnox> pitti, and thus in adt -> if in lxc/lxd, use soemthing like no more than 2 CPUs.
<xnox> pitti, and you don't care which CPU.
<doko> jamespage, rbasak: the server-ship seed has python-libvirt. can this be replaced by python3-libvirt?
<pitti> yeah, I guess adt-virt-lxc will need to grow a --num-cpu argument and write a /usr/local/bin/nproc that spits out that number
<xnox> doko, OMG somebody ported that beast!!!!
<pitti> we configure the memory limit from outside, so I guess we also need to configure #cpus from outside
<doko> jamespage, rbasak: the server-ship seed has python-urlgrabber. can this be removed?
<infinity> mvo: goget-ubuntu-touch build-deps on a bunch of stuff that doesn't exist anymore (golang-goconfigparser-dev, golang-snappy-dev, golang-uboot-go-dev) ... What's the plan?
<mvo> pitti, infinity: the version in proposed fixes this
<coreycb> jamespage, doko: there's a fix in the upload queue for the python-pint ftbfs
<mvo> infinity: however there is a ubuntu-emulator/i386 unsatisfiable Depends: ubuntu-emulator-runtime
<mvo> infinity: I have no idea where this comes from, maybe sil2100 has an idea?
<pitti> mvo: oh, how's that? https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.34-0ubuntu1 doesn't have any dependency changes
<mvo> pitti: it does not? let me check, if so this is an imcomplete upload :(
<pitti> I don't think britney is clever enough to recognize dependencies from foreign architectures, this might need hinting?
<pitti> mvo: http://launchpadlibrarian.net/251805206/goget-ubuntu-touch_0.33-0ubuntu3_0.34-0ubuntu1.diff.gz
<mvo> pitti: sorry, this is confusing https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.33-0ubuntu3
<mvo> pitti: that is the one that dropped the dependencies
<pitti> mvo: ah, there were several uploads done to -proposed
<infinity> Oh, can fix.
<mvo> pitti: yes
<infinity> Sec.
<pitti> mvo: ack, danke!
<mvo> thank you and sorry again for letting this linger for so long
<infinity> Oh.
<infinity> That's not britney being wrong.
<infinity> mvo: ubuntu-emulator-runtime is in multiverse, universe packages can't depend on it.
<infinity> That was never caught before, but britney's been taught to honor components.
<pitti> ah, so goget-ubuntu-touch needs to go to multiverse too?
 * infinity wonders what makes Android non-free.
<infinity> Yeah, goget would need to go to multiverse.
<infinity> Or android to universe, if it's suitable.
<infinity> But I assume someone had good reason for assuming it's not.
<infinity> mvo: So.. Welcome to multiverse, I guess.
<infinity> Just ubuntu-emulator, mind you.
<infinity> The rest can stay in universe.
 * infinity fixes now.
<pitti> qtcreator-plugin-ubuntu recommends: ubuntu-emulator
<infinity> pitti, mvo: Should fix itself shortly.
<pitti> I suppose that should be lowered to a Suggsets?
<infinity> pitti: Ugh.  Yeah, either a suggests, or that also needs to move.
<mvo> infinity: yay
<infinity> pitti: I guess a suggests, given its an ubuntu-sdk rdep.
<infinity> pitti: Care to toss a quick fix up?
<pitti> infinity: yup, coming (direct bzr commit/upload)
<pitti> je suis core-dev
<infinity> That'll kill all but 2 things from NBS.
<infinity> Almost there.
<pitti> smc is still FTBFS due to uninstallable build deps
<pitti> (haven't investigated yet)
<pitti> zr: ERROR: Cannot lock LockDir(chroot-93174736:///~ubuntu-sdk-team/qtcreator-plugin-ubuntu/trunk/.bzr/branch/lock): Transport operation not possible: readonly transport
<pitti> meh
<pitti> https://code.launchpad.net/~pitti/qtcreator-plugin-ubuntu/dep-fix/+merge/291748
<pitti> infinity: wow, you accepted that upload fast :)
<pitti> (or does "Task: ubuntu-sdk" count as unseeded and it got auto-accepted?)
<infinity> pitti: Yeah, it was auto-accepted.
<infinity> Though, I was only 2 seconds behind.
<infinity> Got the LP "screw you, queue state invalid" return.
<infinity> Ahh, lovely, with the new meta, minimal-amd64 and minimal-s390x are identical.
<jdstrand> doko: re python-ufw and python3-ufw. that is correct. ufw itself is python3 and what you might expect in python3-ufw is in ufw (along with the ufw command). python-ufw is something I support even though nothing in main uses it. if you want to take python-ufw off the supported seed, that's fine
<jdstrand> pitti: ^
<doko> jdstrand, ok, doing then
<barnes> in 16.04 lxc seems as default installed why is not that a choice to make in the installation?
<barnes> 16.04 server that is
<pitti> jdstrand: thanks
<cyphermox> good morning
<xnox> barnes, lxd specifically is now always available on server and cloud installations. and it's now part of what defines Ubuntu Server product.
<xnox> barnes, note this is a development channel, questions like yours are probably better asked on e.g. #ubuntu-server for the future.
<xnox> or #ubuntu+1 channel for development releases support =)
<barnes> xnox: thanks for your answer, but still i don't see the awsomeness to include it in every install without the option to decide about it in the installation
<xnox> barnes, the awesomeness is that everyone gets to interract with it =) even if it is with $ apt remove lxd =)
<xnox> barnes, maybe it should be a task in task-select, which is selected by default, but one can untick it or something.
<doko> pitti, I didn't understand the smc b-d uninstallability issue either
<xnox> barnes, dunno, open a bug report against lxd package on launchpad =)
<doko> Mirv, tjaalton, is it ok to demote these driver packages? http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<barnes> xnox: yes an untick box would be enough, or an lts server minimal installation
<xnox> barnes, well, open a bug report about that.
<pitti> doko: ah, did you demote libiberty and friends? I re-promoted them yesterday as per slangasek's request as rdepends of these still need to be fixed to add Built-Using: to track the static/linked code copies
<doko> pitti, ok, didn't know
<pitti> libirman libiberty drac eperl gnu-efi libatomic-ops
<tjaalton> doko: the vaapi/vdpau things? guess so, as nothing depends on them
<tjaalton> doko: which reminds me.. I should be able to enable opencl support in mesa now? it wouldn't pull clang in main anymore :)
<doko> tjaalton, sure
<tjaalton> cool, diff getting smaller
<barry> doko: i've looked at both pyjunitxml and configglue failures.  both are really upstream bugs that haven't gotten any traction in a long while.  i looked again at both but don't really have any good ideas for fixes.  i've been looking at the lua failures on powerpc.  those are likely due to c/c++ linkage issues.  tough ones
<doko> barry, pyjunitxml was seeded. removed it from the seed. lets see if it demotes
<barry> doko: +1
<doko> tjaalton, demoted
<pitti> tseliot: can we get rid of at least some of the 5 nvidia-XXX versions that we have in xenial?
<pitti> tseliot: -310 and -319 are FTBFS even
<Mirv> pinging both Timos does work if one doesn't remember which one does what :)
<tjaalton> :)
<doko> heh, it worked =)
<tseliot> pitti: sure, how many of them do we have in the archive?
<pitti> http://paste.ubuntu.com/15811195/
<pitti> tseliot: ^ (doesn't fit in IRC even)
<pitti> tseliot: I figure we need some of the names as transitional packages for upgrades from trusty and wily
<pitti> e. g. the nvidia-319 binary is now built by the nvidia-graphics-drivers-331 source, but we still have the nvidia-graphics-drivers-319{,-updates} source in xenial
<tseliot> pitti: 331 is what we shipped in 14.04, then superseded by 352
<tseliot> 310 and 319 are really old
<doko> cjwatson, ./supported-development-common seeds python-launchpadlib. should that be replaced by python3-launchpadlib?
<pitti> tseliot: and I think nvidia-graphics-drivers-331 is missing transitional packaes for 319-updates?
<tseliot> pitti: 331 has transitional packages for 319, 331-updates <- 319-updates
<pitti> tseliot: ah
<pitti> tseliot: nvidia-319 is already a transitional in trusty, so I figure we can completly remove the two -319 sources from xenial, and even drop the transitionals from -331?
<cjwatson> doko: probably, yes
<doko> I mean, both are in main anyway
<pitti> doko: did you re-promote these static libs? or should I?
<doko> pitti, please do. I thought you would do it
<pitti> ack
<tseliot> pitti: yes, although 331 is already transitional in 14.04 (in updates). We have 361 in xenial
<pitti> tseliot: so, -304, -310-updates, and -319{,-updates} should go/
<pitti> ?
<cjwatson> doko: it's slightly awkward, the python 2 version is still very much more widely used, but it's not going to hurt anything if it drops out to universe somehow
<tseliot> pitti: 304 is a legacy driver, same as 340
<doko> ahh, finally GCC 4.9 should demote
 * smoser just can't believe he's the only oen that finds this terribly annoying
<smoser>  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1521302
<ubottu> Launchpad bug 1521302 in unity (Ubuntu Xenial) "gnome-terminal maximize than un-maximize behaves odd" [Medium,Confirmed]
<pitti> tseliot: well, removing nvidia-graphics-drivers-310-updates nvidia-graphics-drivers-319 nvidia-graphics-drivers-319-updates would help as these are  exactly the three packages which are FTBFS :)
<tjaalton> tseliot: this might be a time to drop -updates, no? they aren't really used anyway
<pitti> tseliot: so if 304 still actually works, fine to keep it
<tseliot> tjaalton: sure, that would actually make maintenance a little easier
<pitti> tseliot: oh right, -331 is already transitional in trusty, so should that go too?
<pitti> tseliot: please just tell me which versions to keep and drop, easier than this boolean question/answer game :)
<tjaalton> true
<tjaalton> ;)
<tseliot> pitti: ok, you can drop 1) 310 and 319 ( plain and -updates flavours) ; 2) 331 ( plain and -updates)  only the source, not the transitional packages (provided by 352)
<tseliot> tjaalton: I would need to add transitional packages in 361 and 340 in order to remove the -updates flavours
<tjaalton> right
<pitti> tseliot: done, thanks!
<tseliot> pitti: thanks to you ;)
<tseliot> tjaalton: I'm going to do that now
<tjaalton> cool
<stgraber> xnox, pitti: lxd either supports you giving "50%" of the CPU time (all cores visible) or giving a specific number of CPUs in which case it will pick the least loaded cores for your container and re-balance when something changes
<stgraber> https://www.stgraber.org/2016/03/26/lxd-2-0-resource-control-412/
<pitti> stgraber: ah, lxd -- I didn't see this with lxc
<pitti> we still use lxc in production (I'm working on moving armhf to lxd in scalingstack, this seems unblocked now)
<stgraber> yeah, that's lxd only as it requires an active daemon processing uevents and such to allow for the balancing
<xnox> lxc config set my-container limits.cpu 2 -> nice
<pitti> stgraber: OOI, how do you tell apart "give cpu number 2" vs "give 2 CPUs"?
<stgraber> 2 vs 2-2
<pitti> ah, clever :)
<stgraber> well, other way around
<pitti> (not that I'd ever care about pinning specific CPUs to a container)
<pitti> stgraber: cheers!
<pitti> anyway, going to finish the adt-run override  for parallel=N now, I have 70% of it ready now
<pitti> as moving over production to lxd will still take a bit
<sil2100> Laney: hey! I had a question regarding the last DMB meetings you had - do you remember if candidate Phillip Susi was reviewed?
<sil2100> I see he certainly doesn't have the privilages he requested for, but maybe he got rejected or something
<Laney> sil2100: umm, lemme check
<Laney> sil2100: doesn't look like it
<Laney> probably worth a mail
<sil2100> Laney: yeah, I was just about to send one with a reschedule question but wanted to make sure he wasn't just rejected
<sil2100> Laney: thanks
<xnox> sil2100, well....
<pitti> xnox, doko: hm, I reduced to parallel=2 now (from 8), and it still fails that way
<pitti> xnox, doko: and this is perfectly reproducible manually (on s390x)
<pitti> still fails with -j2, works with -j1
<pitti> so, no parallelism for s390x, I take it
<infinity> xnox: Huzzah.  s390-tools and sysconfig-hardware demoted to optional.  Going to let your d-i through now.  Will you have a chance to do a quick test install tonight to see if everything's cool, or will that wait for tomorrow?
<pitti> doko: http://people.canonical.com/~ubuntu-archive/nbs.html \o/
 * pitti makes a flushing noise
<infinity> pitti: \o/
<infinity> And I just cleared out http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt
<infinity> It's almost like we're getting close to release.
 * pitti looks at smc and ugghs
<pitti> # apt-get install libcegui-mk2-dev
<rbasak> There will be more NBS from src:mysql-5.6 removal :-/
<pitti>  libcegui-mk2-dev : Depends: libfreetype6-dev but it is not going to be installed
<pitti> # apt-get install libcegui-mk2-dev libfreetype6-dev
<pitti> -> works
<infinity> rbasak: mysql-5.6 removal should be smooth enough, once we get there.
<infinity> pitti: Lemme look.
<pitti> (doing that in an amd64 xenial-proposed schroot)
<pitti> # apt-get install libcegui-mk2-dev libsdl1.2-dev libsdl-image1.2-dev  libsdl-mixer1.2-dev libsdl-ttf2.0-dev
<pitti> that also works
 * pitti tries to decipher http://paste.ubuntu.com/15813463/
<pitti> looks like some conflict between libpng12-dev and libpng16-devtools
<pitti> ah, this alreayd affects xenial, not only -proposed
<infinity> Huh.  apt-get installing the build-deps doesn't fail.
<pitti> infinity: with apt-get install <list of packages> or "apt-get build-dep smc"? the latter sure does fail here
<infinity> pitti: Yeah, build-dep fails, list-of-build-deps doesn't.  Curious.
<cjwatson> build-dep -oDebug::pkgProblemResolver=true   may help
<infinity> cjwatson: Already done.
<infinity> http://paste.ubuntu.com/15813463/
<pitti> that's the ... yes
<cjwatson> ah right
<pitti> libpng16-devtools Conflicts: libpng12-0-dev and libpng12-dev, and it somehow looks like the latter is being pulled in through something else
<cjwatson> probably a virtual package somewhere
<infinity> libpng16-devtools isn't involved at all when I do list-of-deps, though.
<infinity> Which is fun.
<pitti> libsdl-image1.2-dev only depends on the virtual libpng-dev, so apt would ideally pick the 16 one, not the 12
<dpb1_> hi all -- on xenial, EFI, my grub has a debian background and 'gnu/linux' menu items instead of 'ubuntu'
<infinity> Ah.
<dpb1_> what could I have done to cause that
<cjwatson> libsdl-image1.2-dev might have to pick one at least temporarily
<cjwatson> i.e. a preferred real alternative
<infinity> libcegui-mk2-dev depends libpng16-dev, which depends libpng16-devtools
<infinity> And everything else wants libpng12.
<cjwatson> it probably works if libpng12-dev is removed from the archive or if libpng16-dev appears first, and otherwise is undefined.  or something.
<pitti> indeed, libpng12-dev is main, 16 still universe
<cjwatson> (er, disclaimer, I can't remember whether we've done the 16 transition)
<pitti> it seems we intend to keep 12 for now
<pitti> and "apt-get install libcegui-mk2-dev libsdl1.2-dev libsdl-image1.2-dev  libsdl-mixer1.2-dev libsdl-ttf2.0-dev" installs 12
<infinity> So, libcegui-mk2-dev probably want to be pinned to libpng12 for now.
<infinity> And that should resolve smc.
 * infinity grabs the cegui-mk2 source.
<pitti> that's a good theory
<infinity> Looks like the correct theory.
<pitti> libpng16-dev | libpng-dev â libpng-dev
<pitti> that workss
<pitti> I edited /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial_universe_binary-amd64_Packages in the schroot to verify
<pitti> and now build-dep is hunky-dory
<infinity> libpng16-16 Has no rdeps, so we've clearly not transitioned.
<infinity> And libpng16-dev's only rdep is libcegui-mk2-dev
<infinity> So, I'll fix that and we're good.
<pitti> yay
 * pitti stands by to review in unapproved
<xnox> infinity, i will be able to.
<xnox> infinity, so accept that d-i whenever you can/want, i'll test it, and then i'll ask ibm to test too to make sure it's all good on their mega huge mainframes too.
<xnox> cause i only have little z systems =)
<infinity> xnox: Well, little is enough to make sure we got the zipl-installer bits right.
<xnox> =)
<infinity> xnox: And later, I'll want a test that I didn't break the cloud images, but that can wait for tomorrow.
<infinity> Or whenever the next daily spits out.
<infinity> xnox: d-i accepted and building.
<doko> lamont, your postfix upload is stuck with failing autopkg tests
<lamont> doko: that has been the subject of my session on the scalingstack instance where it is failing
<lamont> which I believe I just figured out
<lamont> now to understand wtf that host is doing with its hostname
<pitti> mvo: are the depends: removals in http://launchpadlibrarian.net/253632879/snapd_1.9.1.1_1.9.2.diff.gz deliberate? changelog doesn't mention them
<lamont> doko: and -3 uploaded to address the issue
<doko> hmm, I should re-enable running the tests for openjdk-8 ...
<Pharaoh_Atem> nacc: I've revised my libvirt-php patchset to work on top of the current git HEAD: https://www.redhat.com/archives/libvir-list/2016-April/msg00731.html
<nacc> Pharaoh_Atem: cool
<Pharaoh_Atem> nacc: the patch set is also available from git directly: https://gitlab.com/Conan_Kudo/libvirt-php7/commits/php7-review
<nacc> Pharaoh_Atem: did you get any feedback?
<Pharaoh_Atem> yes
<Pharaoh_Atem> he couldn't apply it to get HEAD, which I fixed by during a lot of evil surgery on the commits
<Pharaoh_Atem> *git HEAD
<xevious> Is there a version of pbuilder available for trusty that's capable of creating chroots for xenial?
<Pharaoh_Atem> and he said he couldn't compile it, which I could not reproduce, so I asked for more info
<Pharaoh_Atem> I tested on CentOS 7 and Fedora 23 to get a sample of old and recent, and it worked fine in both
<Pharaoh_Atem> it also worked on ubuntu xenial, so... *shrugs*
<sarnold> xevious: iirc I had slight trouble setting up the schroot for xenial on trusty because debootstrap didn't have the right symlink..
<sarnold> xevious: making a symlink from xenial to gutsy in /usr/share/debootstrap/scripts/ make my sbuild work well enough, perhaps that's all it takes for you too
<xevious> sarnold: Is there a workaround?
<mvo> pitti: it is deliberate, not sure why its not in the changelog, its auto-generated with git-dch
<xevious> Nice. I'll give that a shot.
<mvo> pitti: probably "+    - debian: remove unneeded dependencies from snapd" - its a bit too terse  I guess
<xevious> sarnold: It's creating a chroot, at least. We'll see if it's xenial when it's done.
<sarnold> xevious: hehehe
<xevious> It worked. Thanks!
<sarnold> \o/
<seb128> awe, cyphermox, could you look at bug #1569649? seems like a regression in the nm init script for an issue was fixed earlier in the cycle
<ubottu> bug 1569649 in network-manager (Ubuntu) "NetworkManager-wait-online.service not enabled after network-manager installation " [Undecided,New] https://launchpad.net/bugs/1569649
<nacc> slangasek: is my best bet for getting review of the php7.0 sru request to add it to the TechnicalBoardAgenda page?
<seb128> it claims the patch from bug #1515446 resolves the issue
<ubottu> bug 1515446 in network-manager (Debian) "network file systems in FSTAB no longer mount at boot with NetworkManager" [Unknown,New] https://launchpad.net/bugs/1515446
<seb128> cyphermox, awe, bug #1569613 also seems a new issue
<ubottu> bug 1569613 in network-manager-applet (Ubuntu) "/usr/bin/nm-applet:11:g_hash_table_remove_all_nodes:g_hash_table_remove_all_nodes:g_hash_table_remove_all:nma_icons_reload:g_closure_invoke" [Undecided,New] https://launchpad.net/bugs/1569613
<awe> seb128, sure... in the middle of some touch testing, but will take a look
<seb128> awe, thanks
<awe> np
<seb128> cyphermox, bug #1569590 and bug #1569484 and bug #1569301 seems also new issues worth investigating
<ubottu> bug 1569590 in network-manager (Ubuntu) "wireless card disabled in network-manager" [Undecided,New] https://launchpad.net/bugs/1569590
<ubottu> bug 1569484 in network-manager-applet (Ubuntu) "Auto Ethernet connection profile appears. Wifi does not work anymore." [Undecided,Confirmed] https://launchpad.net/bugs/1569484
<ubottu> bug 1569301 in network-manager-pptp (Ubuntu) "cannot connect pptp-vpn after upgrading via apt from 1.0.* to 1.1.93" [Undecided,New] https://launchpad.net/bugs/1569301
<seb128> cyphermox, awe, I can try helping to have a look but I'm at a sprint this week so limited debug cycles
<cyphermox> ok
<seb128> it also seems the apport hook needs to be updated
<seb128> Error: Object 'nm' is unknown, try 'nmcli help'
<seb128> cyphermox, thanks
<cyphermox> I'll look once I'm done with ubiquity
<cyphermox> pptp failure is due to a bug in either ppp or pptp or whatever, but I haven't managed to debug that yet
<cyphermox> (in fact, I have a hard time getting a good backtrace)
<awe> seb128, can you tag these bugs and/or send an email with a list?  I'm trying to land for the phone now, but will definitely help
<cyphermox> awe: pptp/ppp failure is a good starting point fwiw ^
<awe> also fyi, rc2 landed yesterday as well
<seb128> awe, sure, can do
<awe> cyphermox, sure, but seb128 just rattled off 1/2 dozen issues, so we should try and track 'em all
<awe> ;)-
<seb128> just looking at recent reports
<cyphermox> awe: there are bug reports, that's how we track bugs
<seb128> I think the upgrade works for most users so it's good
<awe> yes cyphermox, I know
<seb128> but there seem to be a few regressions worth investigating
<awe> we also use tags
<cyphermox> seb128: if you want to help with the NM bugs, I would suggest making them rls-x-tracking if it's fine with the release team
<seb128> good idea
<awe> cool
<seb128> pitti, bts I see report logs having "systemd-timesyncd[483]: Failed to call clock_adjtime(): Invalid argument" is that a known issue?
<cyphermox> awe: ^ that's where we track release bugs -- http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-x-tracking-bug-tasks.html#
<awe> cyphermox, right, only 500 bugs on that list...
<awe> er, 510
<cyphermox> awe: ignore that stuff, it's separated by teams and whatnot
<cyphermox> awe: I'll get that huge list dropped to something more manageable, linux-raspi2 should be listed as a kernel package I think ;)
<cyphermox> also, disabling the Fix Committed/Fix Released helps
<seb128> cyphermox, awe, https://bugs.launchpad.net/ubuntu/+bugs?field.tag=nm11issue
<awe> thanks seb128
<seb128> yw
<barry> doko, slangasek i captured what little i know about the lua ftbfs on powerpc in LP: #1570055, but that's about all i can do at this point
<ubottu> Launchpad bug 1570055 in lua5.3 (Ubuntu) "FTBFS on powerpc" [Undecided,New] https://launchpad.net/bugs/1570055
<nacc> rbasak: is it possible that hte mysql-5.7 migration may have affected dbconfig?
<rbasak> nacc: absolutely, yes. We patched dbconfig
<rbasak> IIRC
<nacc> rbasak: ok, so it should work as in the archive now? or is that still pending in proposed?
<rbasak> Hmm.
<rbasak> Looking
<rbasak> Sorry, I was thinking of libdbi-drivers
<rbasak> dbconfig had some dep8 issues perhaps, but they're all resolved now.
<nacc> rbasak: was just trying to test a drupal7 rebuild and it didn't seem to like the passwords as generated by dbconfig, but if i manually went into mysql and set the same password, then it worked
<rbasak> We're talking dbconfig-common right?
<nacc> rbasak: ack
<Skuggen> dbconfig-common was affected by a change in 5.7 that we patched in 5.7
<nacc> 2.0.4ubuntu1 is what is installed in this env i tested in
<Skuggen> Tests failing with an error message about empty value for port
<rbasak> Ah. Now I remember. Thanks :)
<nacc> Skuggen: ack, i saw that as well with my uptodate xenial
<rbasak> Could you be hitting bug 1567098?
<ubottu> bug 1567098 in mysql-5.7 (Ubuntu) "Cannot log in as root user when not root Unix user" [High,New] https://launchpad.net/bugs/1567098
<nacc> rbasak: this was a non-root suer
<nacc> "drupal7" :)
<rbasak> Some tests are affected by this. When mysql-server-5.7 is installed no root password is set.
<rbasak> Previously this worked as non-root (blank root password allowed).
<nacc> yeah i recall a previous discussion about that
<rbasak> Now it only works as root (Unix auth over socket only).
<Skuggen> But dbconfig-common passed its dep8 tests with the updated mysql in proposed?
<Skuggen> nacc: How does it initialize the database?
<rbasak> The newest mysql-5.7 hasn't been accepted by the release team yet.
<Skuggen> This was fixed earlier, though
<Skuggen> Had to be to get it into the archive in the first place, iirc
<rbasak> Which fix do you mean?
<rbasak> Ports was, but bug 1567098 wasn't I think?
<ubottu> bug 1567098 in mysql-5.7 (Ubuntu) "Cannot log in as root user when not root Unix user" [High,New] https://launchpad.net/bugs/1567098
<Skuggen> Oh, sorry, wrong bug :)
<Skuggen> Yeah, but that one only affects the root user
<rbasak> nacc: is it possible and not difficult for you to test against ppa:mysql-ubuntu/mysql-5.7?
<rbasak> That has the fix for the 098 bug
<Skuggen> nacc: Do you have the code in dbconfig that tries to set the password handy?
<rbasak> For sbuild, something like --extra-repository="deb [trusted=yes] http://ppa.launchpad.net/mysql-ubuntu/mysql-5.7/ubuntu xenial main" (or add the apt key and then no need for trusted=yes)
<nacc> rbasak: yeah it'll be easy for me to test
<nacc> Skuggen: let me look in the drupal code, one sec
<nacc> Skuggen: http://paste.ubuntu.com/15818808/ I think
<Skuggen> I gave up trying to understand dbconfig-common fully when we were trying to fix the ports issue, unfortunately
<Skuggen> So you can log in as root, alter the password of the user and then it works?
<nacc> Skuggen: let me start back over in a fresh container, now that i've got drupal working :) -- will ping if it reproduces clearly and with steps
<Skuggen> Thanks. And test as rbasak suggested
<nacc> Skuggen: ack
<Skuggen> It's possible dbconfig-common is denied access when trying to set the password for the user
<Skuggen> Though if the root user still has an empty password the newest version won't fix that, since it still requires unix root to log in in that case
<slangasek> nacc: add to the TB agenda page is good, I also recommend starting the discussion on the TB mailing list so you're not waiting until the next TB meeting
<nacc> slangasek: thanks
<slangasek> nacc: btw, regarding 7.0.5 fixing a behavior regression in 7.0.4, that's the sort of thing that it's preferable to fix before release so that users don't come to rely on the broken behavior on Ubuntu
<nacc> slangasek: ack, absolutely -- i've got a bug open for it, i guess i should jsut backport to 7.0.4 regardless of the SRU discussion
<nacc> will do that today
<Skuggen> nacc: I tested with phpmyadmin, and it also creates a user and sets the password, and that seems to work fine
<lifeless> doko: looking
<lifeless> doko: its the change in __qualname__ in Python 3.x; there's a patch being reviewed upstream at the moment
<lifeless> doko: https://code.launchpad.net/~garyvdm/pyjunitxml/consistant_test_ids/+merge/291497
<pitti> seb128: known, bug 1566465
<ubottu> bug 1566465 in linux (Ubuntu Xenial) "[regression]: Failed to call clock_adjtime(): Invalid argument" [Medium,Confirmed] https://launchpad.net/bugs/1566465
<seb128> pitti, thanks
<seb128> pitti, do you know if anyone from the kernel team is looking at it?
<pitti> seb128: sorry, no; I haven't looked at it at all yet, I just overheard the number yesterday
<seb128> k
<seb128> seems like an annoying issue/something we might want to fix for release
<Unit193> FWIW: New cronic in Debian fixes a cvs, predictable tmpfiles.
<rbasak> Unit193: looks like ginggs already synced it.
<lamont> I have settings -> keyboard->shortcuts->typing->compose set to capslock, and I notice that the capslock key is now a capslock key... wtf?
<xnox> lamont, have you not noticed that keybindings are not preserved on every unity upgrade before?
 * cjwatson hugs ~/unity-settings which has instructions on the superset of everything I've needed to restore across upgrades for the last couple of years
<lamont> xnox: you'll note that cjwatson was more helpful than you. :p
<lamont> thanks for hte protips
<Unit193> It's cjwatson, he's master of all the things...
<dobey> lamont: i noticed that same problem on my laptop :-/
<cjwatson> well.  the existence of ~/unity-settings in my home directory is not actually of much practical help to anyone else
<lamont> cjwatson: I was just coming to that conclusion
<lamont> cjwatson: halp where get how do?
<lamont> cjwatson: maybe a pastebin?
<cjwatson> lamont: eh, well, mine is http://paste.ubuntu.com/15820302/ but it's totally specific to my preferences
<lamont> and for hilarity, fixing my compose key was as simple as disabling it and then changing it back to capslock.
<lamont> sigh
<lamont> which package gets that bug report?
<seb128> xorg-server?
<seb128> or unity-settings-daemon
<seb128> (but u-s-d didn't change for a while and I doubt anyone is going to read/pick up your bug there)
 * lamont can't find "ubuntu unity plugin" in ccsm
<lamont> which clearly means I'm missing a package, but ...
<seb128> "unity"
<lamont> ah... cjwatson line 11 wants "-> desktop" in front of it
<cjwatson> believable.  I probably jotted it down years ago
<mwhudson> doko: for https://bugs.launchpad.net/ubuntu/+source/juju-mongodb/+bug/1558336, should we put the golang.org/x/crypto/LICENSE file that upstream removed back?
<ubottu> Launchpad bug 1558336 in juju-mongodb (Ubuntu) "[needs-packaging] juju-mongo-tools3.2 in xenial, wily, and trusty" [Wishlist,New]
<mwhudson> doko: or is just correcting debian/copyright sufficient?
<mwhudson> (or we could remove the golang.org/x/crypto vendor copy from the tarball entirely, we don't use it)
<mwhudson> anyone? tl;dr upstream removed a LICENSE file from a package they vendor, do we need to put it back (or remove the package, we don't use vendored copy)?
#ubuntu-devel 2016-04-14
<slangasek> barry: for extra fun, I see that lua5.3 includes both /usr/bin/luac5.3 - supposedly built with gcc - and /usr/bin/lua5.3 - supposedly built with g++.  Both segfault.
<slangasek> barry: oh, n/m, one of those is lua 'compiler'.  but anyway, both in terrible shape...
<nacc> elbrus: ping, re: cacti, when you get a chance
<Pwnna> how do i make openjdk7 not depend on tzdata-jaava?
<Pwnna> is that even possible?
<Pwnna> i'm trying to.. forward port openjdk7 into xenial for my own use.
<Pwnna> i guess my question is if i just go into the rules file and put with_tzdata=no, what will happen?
<nacc> Pwnna: not sure i fillow, xenial has openjdk-7-jdk, no?
<Pwnna> nope
<Pwnna> it's removed
<slangasek> well, I don't see why you would try to "forward port" openjdk7 instead of just installing both openjdk-7 and tzdata-java from 14.04
<Pwnna> i want to ppa it
<Pwnna> because installing a debian package raw is kinda meh.
<Pwnna> what's the impact of switching tzdata to no?
<Pwnna> i could also create a package in the ppa that just has the files from tzdata-java
<sarnold> what's wrong with openjdk-8 or openjdk-9 (-9 is in universe..)
<Pwnna> unfortunately, i'm trying to build android and CyanogenMod requires 7
<nacc> Pwnna: why not just run trusty in a container or vm then?
<Pwnna> nacc: so slow.
<sarnold> aha. eww. :)
<Pwnna> VM is slow.
<Pwnna> haven't tried container yet
<nacc> Pwnna: containers aren't slow? try using lxd ;)
<Pwnna> i could debootstrap into a chroot even
<Pwnna> is true
<Pwnna> but that setup will not play nicely with my automated setup for now
<cpaelzer> good morning
<darkxst> bdmurray, cyphermox: we still need the gnome-session inhibitor to block screensaver, logind does not block user session idle monitors!
<darkxst> bug 1565177 ^
<ubottu> bug 1565177 in ubuntu-release-upgrader (Ubuntu) "screensaver is not disabled during release upgrade" [High,In progress] https://launchpad.net/bugs/1565177
<showaz> dovecot: auth: Error: LDAP: binding failed â¦ Strong(er) authentication required, BindSimple: Transport encryption required
<showaz> how can fixed samba-4.3.8?
<showaz> ......
<pitti> Good morning
<mwhudson> aaargh dh-golang in trusty is impossibly ancient
<pitti> mwhudson: -backports?
<mwhudson> probably a good idea
<pitti> mwhudson: if it's backwards compatible and you have some good arguments it could even be SRUed, but this depends on what you need to do
<mwhudson> also i was exaggerating a bit, i can cope in this case by not running the tests :-)
<mwhudson> pitti: yeah, i'll think about SRU, if we want to keep lxd etc up to date in trusty it'll help
<pitti>  lxd | 2.0.0-0ubuntu1~ubuntu14.04.1 | trusty-backports/universe | source, amd64, arm64, armhf, i386, ppc64el
<pitti> mwhudson: it couldn't be much more up to date
<mwhudson> it _should_ be compatible, and there are hardly any go-built things in trusty anyway
<Laney> stgraber is already doing lxd backports
<pitti> these are done mostly automatically
<pitti> trusty-backports followed xenial with pretty much every lxd upload
<mwhudson> i guess this means lxd avoids using new dh-golang features
<mwhudson> which is perhaps fine
<showaz> DisplayLink support ubuntu http://www.displaylink.com/downloads/ubuntu
<dholbach> pitti, HAPPY BIRTHDAY! :-D
<pitti> \o/ thanks!
<doko> slangase`, is there a reason you uploaded lua 5.1 and 5.2 but not 5.3?
<pitti> doko: btw, did you see? http://people.canonical.com/~ubuntu-archive/nbs.html
<doko> pitti, yes. what was the solution for smc?
<pitti> doko: removed from xenial with "FTBFS (Debian bug #812096), needs porting to CEGUI 0.8.4, removed from Debian testing, no rdepends"
<ubottu> Debian bug 812096 in src:smc "smc: FTBFS: configure: error: Package requirements (CEGUI-OPENGL >= 0.7.2) were not met:" [Serious,Open] http://bugs.debian.org/812096
<pitti> doko: it's still in -proposed if it ever gets fixed
<pitti> doko: at least cegui itself got fixed along the way
<pitti> â© 23 bottles of FTBFS on the âª â«
<pitti> ... wall
<pitti> doko: are you looking at cross-toolchain-base? (ubuntu patch that patches debian/ does not apply) or should I take a look?
<pitti> and I still can't reproduce the gnupg-doc FTBFS
<pitti> looking at vigraimpex ATM
<doko> pitti, yes, waiting for one last glibc upload
<pitti> doko: ok, ignoring that one
<pitti> barry, doko: python-configglue> latest upstream version 1.1.3.post0 is just as broken; but python3-configglue has no reverse dependencies, so we could just remove the binary and keep python-configglue (one rdepends); WDYT?
<pitti> not much point shipping a module with syntax errors
<pitti> doko, barry: I uploaded this to unapproved now; feel free to reject if you have a better idea
<pitti> I followed up to bug 1504288
<ubottu> bug 1504288 in configglue "Test suite failure with Python 3.4 & 3.5" [Undecided,In progress] https://launchpad.net/bugs/1504288
<showaz> apt install php5-cli -> However the following packages replace it: php7.0-cli:i386 php7.0-cli (E: Package 'php5-cli' has no installation candidate)
<showaz> ubuntu server 16.04
<showaz> why php5 err?
<pitti> showaz: php5 is gone from xenial, as the error message says; use php7
<showaz> backport ?
<showaz> pitti: php7 broken compatibility, now 16.04 only use HHVM/PHP-LiteSpeed-SAPI
<showaz> 5.6+
<cjwatson> showaz: http://dark-net.net/?p=128
<pitti> showaz: sorry, I don't know much about php other than that we moved to 7.0
<cjwatson> showaz: or http://blog.dustinkirkland.com/2016/04/php7-in-ubuntu-16.04-lts.html
<showaz> thanks but php7 no need, support software 25%
<cjwatson> showaz: did you actually read the first link at all?
<showaz> pitti: thanks!
<cjwatson> (I don't care about PHP at all, I just saw these go past on planet and thought they might be of use to you.)
<pitti> cjwatson: I'd like to add another 6 month's worth of 16.XX milestones to https://launchpad.net/ubuntu/+milestones -- where can I do that/
<pitti> ?
<pitti> (using my TB credentials while I still have them)
<pitti> oh, https://launchpad.net/ubuntu/y-series/+addmilestone apparently
<cjwatson> er no
<cjwatson> pitti: https://launchpad.net/ubuntu/xenial/+addmilestone surely
<cjwatson> pitti: unless you mean 16.10?
<pitti> cjwatson: oh, why xenial? 16.05, 16.06 etc. are Y surely?
<cjwatson> oh, right, I thought you meant 16.04.X
<cjwatson> as you were
<pitti> cjwatson: ah, I guess at some point we want those as well, but for now just the next six months of targetting blueprints or bugs
<cjwatson> sure
<pitti> ok, done
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity, mterry
<cyphermox> darkxst: right, that's what I was saying :)
<tseliot> pitti: I have just uploaded nvidia-361 and nvidia-340 with transitional packages, so that we can get rid of the -updates flavours
<tseliot> tjaalton: ^
<pitti> tseliot: ah great, thanks! (don't see them in unapproved yet)
<tjaalton> tseliot: thanks
<tseliot> pitti: yes, I haven't received an email about the uploads either
<cjwatson> tseliot: one of our haproxies fell over, will need to recover the upload
<cjwatson> tseliot: just leave it for now
<tseliot> cjwatson: oh, ok, thanks
<pitti> ah, I suppose that's also the reason why launchpad.net feels like a pit of tar right now
<cjwatson> yes
<sil2100> bdmurray: hey! I got in touch with the two remaining people on our list and confirmed their readiness to apply on the next meeting - I updated the agenda with regards to that
<sil2100> bdmurray: thanks for clearing out the list!
<sil2100> bdmurray: (the DMB applicant list of course)
<stgraber> Laney, mwhudson: I do remember testing our initial packaging with trusty's dh-golang and finding some issues which had me avoid some specific bits in the xenial packaging
<stgraber> can't remember the details though, that was over 6 months ago
<LocutusOfBorg> can anybody please ignore ruby-saml testsuite? the same issues are on debian-ci, and I think they aren't important, at least seems that packaged depending on it works anyway
<pitti> LocutusOfBorg: hm, would be interesting if the failure started with the -proposed version or due to some other changes
<pitti> http://autopkgtest.ubuntu.com/packages/r/ruby-saml/xenial/amd64/ sure does look like the former
<pitti> as there was a pass in between for a different trigger
<pitti> same for http://autopkgtest.ubuntu.com/packages/r/ruby-omniauth-saml/xenial/amd64/
<LocutusOfBorg> I guess ignoring is fine then?
<pitti> well, no, I'm saying the opposite
<pitti> the current version in xenial passes, the one in -proposed doesn't
<LocutusOfBorg> damn ruby clueless
<pitti> ignoring would be fine if xenial's would now fail as well as it got broken due to some other changes
<LocutusOfBorg> I don't know how to fix them
<pitti> ruby cluelessness> make that two :)
<slangasek> doko: I uploaded lua5.3 several hours /before/ the other two
<LocutusOfBorg> pitti, the testsuite from the old and the new saml are completely different
<LocutusOfBorg> and there seems to be  lot of new tests added
<LocutusOfBorg> and somewhere at the begin gem2deb-test-runner is doing a mv of the library, so the chdir doesn't work anymore
<gQuigs> pitti: I can't think of any other tests to do on https://bugs.launchpad.net/ubuntu/+source/telepathy-qt5/+bug/1538772 (except if some one wants to test it on the phone)
<ubottu> Launchpad bug 1538772 in telepathy-qt5 (Ubuntu) "Stop build-depending on libfarstream-0.1-dev and gstreamer 0.10" [Undecided,Confirmed]
<gQuigs> btw, with that change, and screenlets removal 1566635, the rest of the gstreamer0.10 packages should be removable
<Pici> @5
<udevbot> Error: "5" is not a valid command.
<Pici> oopw.
<pitti> gQuigs: ah, thanks; I think it needs to be looked at more closely -- I noticed (later on) that our -qt5 package has a ton of touch patches, not sure if they are all upstream now
<gQuigs> ah ok
<LocutusOfBorg> pitti, I think I fixed saml, thanks
<LocutusOfBorg> it was just a testsuite error
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<LocutusOfBorg> pitti, can you please make ruby-saml testsuite against proposed ruby-omniauth-saml?
<LocutusOfBorg> BTW ruby-saml 1.1.2-1ubuntu1 is dinstalling I guess
<nacc> mterry: thanks for your uploads!
<mterry> nacc, yw!  thanks for the patches  :)
<nacc> mterry: i'm presuming you might have permission to do so (I do not) can you mark the task for wordpress as invalid as well in LP: #1315888 ?
<ubottu> Launchpad bug 1315888 in php5 (Ubuntu Trusty) "Zlib functions (gzopen etc.) are undefined while gzopen64 etc. exist" [High,In progress] https://launchpad.net/bugs/1315888
<mterry> nacc, naw, I don't have permission.   Not a dev for that project  :-/
<teward> nacc: should be pointed out that they don't use Launchpad
<nacc> mterry: oh i see that's how it works, ok, i wasn't sure :)
<teward> their tracker appears to be upstream trac, is there an upstream ticket?
<mterry> nacc, but doesn't hurt to have it there -- bug won't appear open to ubuntu tracker even though there are other tasks.  All I generally care about is the ubuntu tasks  :)
<nacc> mterry: ack
<nacc> teward: well, there shouldn't be -- in that there is no wordpress bug?
<teward> nacc: different issue - release notes on php7.0, do you want me to update the link to my dark-net.net post on the nginx-side with the pretty url?
<nacc> teward: sure, that'd be great
<teward> nacc: not sure, though the evil thing would be to remove the WordPress task where possible - or just leave it.  as mterry said, more important the Ubuntu task is addressed ;)
<teward> nacc: updated that link
<nacc> teward: thanks!
<Son_Goku> nacc: the patches are IN! https://libvirt.org/git/?p=libvirt-php.git;a=summary
<Son_Goku> nacc: Iâve been requested to do some testing before he marks it as 0.5.2 and releases it to wild
<nacc> Son_Goku: sweet, if it gets tagged soon, i'll file the SRU bug :)
<nacc> Son_Goku: well, i'll file hte bug regardless, but mean i'll work it :)
<Son_Goku> welp, he broke the build
<Son_Goku> it doesnât work on php7 anymore :(
<Son_Goku> nacc: he changed the zend_ulong to zend_ulong64, which doesnât exist
<nacc> :)
<nacc> Son_Goku: glad you're testing!
<Son_Goku> I need to find an equivalent to unsigned long long in php
<nacc> Son_Goku: was it a documented change?
<Son_Goku> he changed the patch mid-flight
<Son_Goku> my version uses zend_ulong, but he switched it during the review
<nacc> ah
<tseliot> pitti: hey, can you approve nvidia-graphics-drivers-340 too , please?
<tseliot> or cjwatson ^
<Son_Goku> nacc: easy enough to fix
<Son_Goku> nacc: I need to head into the office though, otherwise Iâll catch hell :P
<Son_Goku> bbs as Pharaoh_Atem
<nacc> Son_Goku: np, thanks!
<Son_Goku> nacc: go ahead and file the request, so that you can get the wheels greased
<nacc> slangasek: for SRU'ing (presuming that's the case for libvirt-php + php7 support), is it appropriate to have one large patch that backports the upstream php7 support in d/patches? or should it be 1:1 with the upstream commits?
<slangasek> nacc: I don't have a particularly strong preference, there are pros and cons of both representations given that source package uploads are not git repos
<nacc> slangasek: ack, i think there are a lot of commits in this case, so one is a bit easier :)
<slangasek> nacc: right, for "lots of commits" a unified diff is usually easier to review too
<nacc> slangasek: yep, thanks!
<LocutusOfBorg> please run ruby-saml 1.1.2-1ubuntu1 testsuite against ruby-omniauth-saml in proposed thanks
<Pharaoh_Atem> nacc: so git HEAD + https://www.redhat.com/archives/libvir-list/2016-April/msg00929.html makes it work on php7
<nacc> Pharaoh_Atem: yeah, the tricky part is we need to backport :)
<nacc> Pharaoh_Atem: i can start doing that today, will probably need your help to test via PPA?
<Pharaoh_Atem> nacc: certainly
<nacc> Pharaoh_Atem: thanks, will try to get something to you after lunch
<Pharaoh_Atem> okay, cool
<nacc> Pharaoh_Atem: what's the first commit in the git series that adds php7 support? don't have the ML post handy
<Pharaoh_Atem> nacc: a71cb51dd9bb8805ae1b0e7e29f79e57164655bb
<nacc> Pharaoh_Atem: ack, thanks!
<Pharaoh_Atem> nacc: gitweb: http://libvirt.org/git/?p=libvirt-php.git
<Pharaoh_Atem> nacc: git url:  git://libvirt.org/libvirt-php
<nacc> Pharaoh_Atem: thanks!
<Pharaoh_Atem> nacc: here's the patch: http://paste.fedoraproject.org/355585/46065977/
<Pharaoh_Atem> that goes on top of the git HEAD
<Pharaoh_Atem> nacc: I suspect you'll have to roll up all the patches from 0.5.1 release, though
<nacc> Pharaoh_Atem: we're probably going to have to find a better alternative, given that we're on 0.4.8 :)
<Pharaoh_Atem> O.o
<Pharaoh_Atem> how the hell did that happen!?
<nacc> debian only recnelty moved up, if i had to guess
<Pharaoh_Atem> aww geez
<nacc> slangasek: for something broken like libvirt-php, is it possible to sync with debian at this point? or should i just pursue what i was originally planning which was a backport?
<nacc> slangasek: not that syncing alone will fix the issue, but willmake the backport far more reliable (I think)
<Pharaoh_Atem> nacc: apparently... Ondrej pulled in the first version of my patches?
<nacc> 0.5.1-31-ga005c2d with PHP 7.0 support
<nacc> but that's from mar 25
<nacc> how's that possible?
<Pharaoh_Atem> I have... no idea
<nacc> and that's not a defined hash?
<Pharaoh_Atem> I didn't even submit the patches until April 8
<Pharaoh_Atem> I'm confused :(
<slangasek> nacc: still possible to sync; non-broken package that someone else maintains > broken package in the archive
<nacc> slangasek: ack, will verify this bit and then file the bug then
<Pharaoh_Atem> nacc: I have *no idea* where that comes from
<nacc> Pharaoh_Atem: e-mailing ondrej, will cc you
<Pharaoh_Atem> because none of my branches have that commit object hash
<Pharaoh_Atem> nacc: okay
<doko> lifeless, uploaded https://launchpad.net/ubuntu/+source/pyjunitxml/0.6-1.1ubuntu1  debian doesn't have your 0.7 release
<dstufft> doko: Just to let you know, I'm poking at setuptools in Ubuntu 16.04. I see that it's version 20.3.1 and there was a string of releases trying to restore backwards compatability when it got broken in version 20.2. I see you do have packaging 16.6 and I know at least some of the fixes were actually in that lib and just pulled into a newer setuptools, double checking to make sure _all_ the fixes were like that.
<dstufft> Ok yea, python3-pkg-resources on Ubuntu 16.04 still has the regression. (Can test it using python3 -c "import pkg_resources; pkg_resources.Requirement.parse('multiprocessing; python_version == \'2.5\' and platform.python_implementation != \'Jython\'')")
<doko> dstufft, setuptools has way too many regressions in it's way too many releases ;p  maybe start working with release candidates, and have longer stabilization periods?
<doko> at this point, I'd just like to pull in fixes
<dstufft> doko: I don't actually work on setuptools itself, I think it needs to slow down myself (this is why pip is still fast, but not nearly as quick as setuptools does)
<dstufft> I just happened to notice the version number
<dstufft> and knew of the issues
<doko> barry, ^^^
<dstufft> doko: So, I *tihnk* and I'm still verifying, that the fixes were contained within the packaging library, but y'all didn't unvendor the packaging lib from inside of pkg_resources in setuptools
<dstufft> so you have the right version of the packaging lib in the archives, but python3-pkg-resources isn't using it atm
<dstufft> doko: for whatever it's worth, the delta between the version you have (20.3.1) and the latest version (20.7.0) is mostly adding more tests, fixing the regressions caused by 20.2 and some misc erata from switching from hg to git (updating links, etc). It's probably roughly about six of one, half a dozen of the other for backporting specific fixes and backporting a new version - https://github.com/pypa/setuptools/compare/20.3.1...v20.7.0
<dstufft> but either way is OK with me
<dstufft> I just know that this caused a bunch of packages to not be installable (the regression that is) and I really want 16.04 + python packaging to be in a good state :]
<dstufft> (anything in pkg_resources/_vendor/packaging is just changes that came from pulling in packaging 16.6)
<doko> dstufft, can you file a FFe?
<dstufft> What is a FFe
<dstufft> I'm happy to do it though :]
<doko> https://wiki.ubuntu.com/FreezeExceptionProcess
<dstufft> doko: Ok, it says I need to have a package ready to go and stuff. I have to pick up my daughter from the bus in ~5 minutes so I don't have time right this minute to try and figure out how to update a package. I'll see if I can figure that out when I get back
<doko> dstufft, I'm uploading to debian, so you can reference it
<dstufft> okay
<barry> dstufft: let me know if you need any help with that
<barry> (the ffe)
<doko> dstufft, setuptools stopped distributing the CHANGES.txt ?
<dstufft> I think they just renamed it to CHANGES.rst
<dstufft> so that it renders on GitHub
<dstufft> If it's not in the tarball maybe they forgot to update a reference
<doko> no, not in the tarball
<doko> next regression :-/ 	Rename CHANGES and README files for nicer rendering on Github.
<dstufft> $10 says they forgot to update MANIFEST.in
<dstufft> is that important? I don't know if y'all use that file or not. I can see if Jason can do a 20.7.1 that fixes that if it is
<doko> renamed files produce a diff ...
<dstufft> Ok, gotta go get Alyssa from the bus stop, will be back in 20-30 and I'll see if I can figure out how to file a FFe (unless barry or someone feels like doing it instead, either way is fine with me). Let me know if you want a 20.7.1 with CHANGES.rst inside of it and I'll poke jaraco or someone who can release setuptools and ask them
<dstufft> bbs
<barry> dstufft: ping me when you get back.  i'm working on another ffe atm
<barry> pitti: still around?
<doko> dstufft, barry: despite this version inflation, the changes look pretty small if you ignore the renaming noise
<barry> doko: cool.  still want an ffe?
<doko> well, I'll upload so that people can have a look at the diff
<barry> doko: sounds good.  while you're at it, are you able to reject the webob sync?  on further testing, i think it's not worth syncing it now
<dstufft> barry: ok I'm back now :]
<barry> dstufft: cool.  see scrollback
<doko> barry, dstufft: http://launchpadlibrarian.net/253841863/python-setuptools_20.3.1-1_20.7.0-1.diff.gz
<barry> doko, dstufft yeah, minus rename, docs, and tests it's not so much stuff
<doko> barry, so please check with infinity
<dstufft> I think the only actual code changes which aren't required are A) Some small refactoring and B) changing an exception handler from catching ImportError to just an Exception
<barry> doko: ack
<dstufft> (B) shouldn't affect Ubuntu at all b/c it's in Windows code
<barry> infinity: hi!
<dstufft> barry: so I just file a bug against python-setuptools asking for a FFe and explaining why?
<barry> dstufft: the bug wants a stylized description: https://wiki.ubuntu.com/FreezeExceptionProcess
<barry> dstufft: anything you don't know, just ping me
<dstufft> barry: https://bugs.launchpad.net/ubuntu/+source/python-setuptools/+bug/1570587
<ubottu> Launchpad bug 1570587 in python-setuptools (Ubuntu) "[FFe] Please update to bugfix release 20.7" [Undecided,New]
<dstufft> maybe I did that wrong, I Tried to copy other bugs I found in https://bugs.launchpad.net/~ubuntu-release/+subscribedbugs
<infinity> It's fine.
<doko> dstufft, please subscribe ubuntu-release
<barry> dstufft: that looks good.  i've subscribed ~ubuntu-release
<barry> heh
<dstufft> oh yea, I was gonna do that once someone told me I didn't totally screw it up since i don't know if that is going to cause someone to get an email or not
<dstufft> Thanks a lot!
<mwhudson> i think the people on ~ubuntu-release get enough mail that one more isn't really noticeable :-)
<lifeless> doko: ack; I need to get on that
<bdmurray> seb128: I just upgraded a vm from W to X and keep getting a dialog that says "An update is needed ... to show all installable apps." Clicking Yes just shows the dialog again.  Is that known?
<slangasek> Backtrace:
<slangasek> /lib/i386-linux-gnu/libSegFault.so(+0x2671)[0xf7769671]
<slangasek> I dunno, I think that might be your problem right there
<slangasek> at least you didn't load libKernelPanic?
<nacc> heh
<seb128> bdmurray, I mentioned it to attente earlier but he doesn't get it ... could you report against gnome-software?
<attente> seb128: bdmurray: do either of you have a /var/lib/app-info directory?
<seb128> I don't
<attente> ok.. so that explains the dialog, but i'm not sure why it's reprompting for it
<attente> hold on. let me try something here
<bdmurray> attente: I have no app-info directory
<tsimonq2> is there documentation for what release pockets are used for the release assigned to the devel alias (currently Xenial)?
<cjwatson> tsimonq2: I don't really understand the question.  The release pocket is a singular thing; maybe you mean something else?
<attente> bdmurray: seb128: does gnome-software launch when you click on yes?
<seb128> yes
<cjwatson> (and "pocket" is terrible terminology we were lumbered with years back, but anyway)
<bdmurray> attente: the first time it did, now it just stays open
<seb128> attente, it starts, displays the refresh icon, then displays the dialog again
<tsimonq2> cjwatson: for example, xenial-proposed, xenial-updates, etc. I am talking about the xenial-* portion
<tsimonq2> get what I mean?
<cjwatson> tsimonq2: OK, so the reason I was confused is that when people say "the release pocket" [of xenial] that means specifically xenial, not xenial-anything
<attente> probably the easy fix is to make sure it only asks when the g-s is actually launched explicitly by the user
<attente> but it's really weird that it asks more than once
<tsimonq2> cjwatson: yeah, I get what you mean. Do you have an answer to my question?
<cjwatson> tsimonq2: Launchpad has a rather hardcoded set of five pockets: release, security, proposed, updates, and backports
<cjwatson> tsimonq2: the suites (series + pocket) that those turn into for the xenial series are xenial, xenial-security, xenial-proposed, xenial-updates, and xenial-backports
<cjwatson> you can see that in http://archive.ubuntu.com/ubuntu/dists/
<tsimonq2> cjwatson: which ones are used in development?
<tsimonq2> s/development/development releases/
<tsimonq2> cjwatson: like, are backports and updates really used?
<cjwatson> tsimonq2: the model for the last few years has been that, when a series is in active development, all uploads go to -proposed and are migrated to release by proposed-migration; after the series is marked stable, -proposed switches to being a staging area for SRUs awaiting verification, and -{security,updates,backports} come into use
<cjwatson> tsimonq2: the post-release suites (-security, -updates, -backports) aren't used before release because there's no point - things should just be uploaded to -proposed.  (there is a slight fudge factor here in the few days before release.)
<tsimonq2> cjwatson: that's what I needed to know, thank you
<cjwatson> I'm sure this is documented somewhere, but it was quicker to explain it than to find the link
<doko> mesa-opencl-icd/amd64 unsatisfiable Depends: libclc-r600 (>= 0.2.0+git20150813)
<doko> mesa-opencl-icd/amd64 unsatisfiable Depends: libclc-amdgcn
<doko> tjaalton, ^^^
<tjaalton> doko: universe
<tjaalton> demote it
<doko> tjaalton, mesa-opencl-icd?
<tjaalton> yes
<doko> done
<doko> slangasek, stokachu: are you aware of the juju-core autopkg test failures? or should mgz join this channel too if he uploads?
<slangasek> doko: they are documented in the FFe bug. mgz has said he is working on them.
<slangasek> and afaik mgz was not the uploader
<doko> ta
<slangasek> (but he is in #ubuntu-release)
<doko> he's mentioned as uploader
<stokachu> i ve been doing the upload for them
<stokachu> I want aware of the test failures though
<stokachu> wasn't*
<slangasek> stokachu: the tests are upside-down and broken.  Hopefully there are fixed versions coming soon.
<stokachu> so they just did a release today I need to verify that then
<doko> just seeing that openstack is now entangled with juju
<stokachu> slangasek: one sec getting balloons in here
<stokachu> slangasek: they are telling me beta4 and 1.25.5 should have fixed them
<stokachu> which im about to upload
<slangasek> stokachu: "beta4 and 1.25.5" - this was only ever broken in juju-core 2.0; so hopefully they're telling you the right thing ;)
<stokachu> slangasek: looks like 2.0~beta4 has the fixes
<stokachu> slangasek: juju 2.0 beta4 looks to have autopkgtests in the relevant debian/tests directory
<stokachu> and contains the fixes for the lxd dependency
<slangasek> stokachu: so did the last upload.  they were just untested and broken.
<slangasek> ok
<slangasek> and the sudo dependency, and the needs-root declaration
<slangasek> ?
<stokachu> lemme find out.. ive asked them to join here
<stokachu> mgz_: hey slangasek had some questiosn wrt sudo dep and needs-root declaration
<stokachu> and making sure that the autopkgtests were passing
<mgz_> slangasek: wotcha. fixed the autopackagetests for 1.25.5, have the 2.0-beta4 ones... very likely fixed
<mgz_> needs-root is mostly needed for test setup, we drop privs with the normal-user.sh script
<doko> likely?
<mgz_> I'm running again with a fix for the last issue I saw
<slangasek> mgz_: yes; so the updated package now includes both the needs-root declaration, and the sudo dependency so that normal-user.sh is able to drop privs?
<mgz_> slangasek: yup
<slangasek> ok
<balloons> mgz_, and you are adding jujutest to lxd in normal_user.sh yes?
<mgz_> yeah, done that
<mgz_> currently wondering if this is going to work in nested lxc
<mgz_> it's... a bit to quiet and hung atm
<mgz_> wonder if it's hung not being able to get base lxd image
<mgz_> just hung inside an lxc command doing who knows what
<mgz_> I love lxd.
<balloons> my xenial image is complaining about locales, and adt won't use a persistent image so . . .
<stgraber> mgz_: is it the first time you're using nested lxd?
<Odd_Bloke> balloons: Are you using a daily xenial image, or a release one?
<stgraber> mgz_: if so, did you set security.nesting=true on the container, if you don't lxd will keep crashing, with systemd helpfuly respawning it, leading to the client being stuck
<Odd_Bloke> balloons: (release will be beta, which is known to have a locale problem which has been fixed in dailies for a couple of weeks)
<mgz_> stgraber: this is an adt test
<balloons> I believe I've tried both, but that might not be true
<mgz_> it's a totally fresh environment
<balloons> Odd_Bloke, sounds like indeed I'm not getting a daily
<balloons> i'm trying lxc launch ubuntu-daily:16.04 xenial-daily
<stgraber> mgz_: oh, yeah, lxd isn't going to work inside the lxc based adt environment
<balloons> but it matters not, as adt won't take a persitent image
<mgz_> okay, so I upload what I've got and hope it works then I guess
<balloons> stgraber, I built an image with adt-build-lxd.. seemed ok
<balloons> lol, other than the xenial issues. trusty works fine
<mgz_> the 1.25 local provider is happy, the lxd provider tests... not so
<stgraber> balloons: yeah but that's not what the adt runners are using yet
<balloons> stgraber, oh. So having it work for me using that isn't a good test then?
<balloons> mgz_, I agree, if everyone else is on board then. Sounds like a proper local test isn't going to be easy to come by.
<stgraber> balloons: right, amd64, i386 and ppc64el are VM based, the rest (maybe with the exception of arm64) is using good-old lxc with a custom profile which isn't compatible with running lxd
<stgraber> and IIRC the lxd based adt runners don't have nesting support enabled yet
<mgz_> okay, so changing the lxd tests back to isolation-machine and going with that
<stgraber> so usually for container stuff we just look at the results on amd64, i386 and ppc64el and consider every other failures as expected
<balloons> ahh.. I had thought those all got moved over. I remember pitti talking about support for this in Jan
<slangasek> balloons, mgz_, stgraber: and juju-core already passed its tests on armhf+s390x, which implies they've been deliberately skipped; whereas amd64,i386,ppc64el, the VM-based ones where the tests should run, were failing because of the test bugs
<stgraber> balloons: he added lxd support to autopkgtest upstream, yes, that code just isn't used in production yet :)
<mgz_> slangasek: there's a difference between the last branch failing, and getting the next upload actually running good tests
<mgz_> even with this rollback the coverage on armhf/s390 should be a little better
<mgz_> but I have less confidence lxd will actually work as I can't get it to locall
<mgz_> y
<slangasek> mgz_: I'm saying, armhf and s390x with their lxd-based runners are already doing "the right thing" (approximately), you just need the lxd tests running on the VM-based runners, for which a local test with nested lxd is probably a waste of time
<mgz_> (in the adt environment)
<balloons> so perhaps a schroot with lxd?
<balloons> still the same perhaps
<xnox> slangasek, some have argued that we should run autopkgtests in multiple environments e.g. in qemu, in lxd, and bare-metal.
 * xnox guesses lxd qualifies as bare metal.
<slangasek> xnox: I think that would be testing something other than the packages...
<seb128> bdmurray, does your apt-get update displays some error due to repos with errors (like the google talk one)? that was the issue for me why it was asking again to refresh
#ubuntu-devel 2016-04-15
<bdmurray> seb128: ah, there was a problem with a repo
<bdmurray> seb128: it seems like something other people will run into though
<seb128> bdmurray, k, so gnome-software should handle that better
<seb128> yeah
<seb128> shouldn't impact the default install though
<seb128> so probably fine to fix in a sru
<flexiondotorg> infinity, I've just seen you release freeze email.
<flexiondotorg> I've got a number of bugs fixes in the sponsor queue, is there any reason I can have those included?
<psusi> can I poke anyone familiar with my work over the years to endorse my application for core-devel? https://wiki.ubuntu.com/PhillipSusi/DeveloperApplication2
<seb128> slangasek, do you plan update freetype from 2.6.1 to 2.6.3 before release? Just saw https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-March/016293.html that claims that the update might fix some security issues, just pointing it in case if that's something that got overlooked
<slangasek> seb128: I do not; see LP: #1521299
<ubottu> Launchpad bug 1521299 in freetype (Ubuntu) "Please merge freetype 2.6.3-3 from Debian testing" [Wishlist,Triaged] https://launchpad.net/bugs/1521299
<seb128> slangasek, k
<infinity> flexiondotorg: You can get them in, just be quick about it.
<pitti> Good morning
<pitti> LocutusOfBorg: thanks! No *saml* on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html any more and ruby-saml landed, so I figure that's sorted out
<pitti> stgraber, balloons: note, we don't have lxd based runners in production right now, I'm still setting these up; production uses good old lxc (as root)
<stgraber> yeah, that's what I thought :)
<pitti> stgraber: I thought for classic lxc 1 nesting should work OOTB; do I need to enable anything specific for that?
<pitti> I have a custom apparmor profile which allows mounting
<pitti> wgrant: hey, how are you?
<stgraber> depending on kernel you may also need an extra include for the nesting.conf file we ship in /usr/share
<pitti> wgrant: can we do that full langpack export now? (the "full" box is ticked)
<pitti> stgraber: trusty kernel for armhf (newer ones don't boot on the calxeda) and xenial kernel for s390x
<wgrant> pitti: For xenial? Sure.
<pitti> wgrant: right, for xenial
<infinity> pitti: Eh?  Newer ones don't boot on Highbank?  Since when?
<hallyn> any of the libc-savvy people in here know whether there is a (seemingly unwritten) rule that ttyname should return something under /dev?
<infinity> pitti: If that regressed, it was an accident, not intentional.
<pitti> infinity: not sure if I tried a vivid kernel, but vivid or wily; it gets stuck very early, missing some block device driver or so
<infinity> pitti: So we lost a CONFIG in a rebase, probably.  I wish someone had mentioned it.
<hallyn> actually maybe that's moot
<infinity> hallyn: It should be able to be any path, surely?
<hallyn> libc seems to only do paths under /dev
<hallyn> i'm trying to find if there is any reason why returning /proc/self/fd/0 is not ok, if that resolves to a valid device which isn't bound in the current mntns
<hallyn> really i guess it's the same question as the one raised by pt_chown
<sarnold> .. to which the answer is surely "More booze!"
<hallyn> it might be
<rharper> \o/
<hallyn> bc while i thin it's ok to return /proc/self/fd/0 if that points to /dev/pts/20 and that doesn't exist,
 * rharper hands out 750s 
<hallyn> the problem remains that if there *is* a /dev/pts/20 i can't tell if that's the right one or not
<hallyn> oh i can,
<hallyn> nope, wrong again
<hallyn> drat so now i have to go through and actually read that long thread again.
<sarnold> I don't see any systemcalls that look helpful; I'm not sure this is a solvable problem
<sarnold> you may not be able to do a 100%-correct job on this one
<stgraber> hallyn: can't stat it?
<hallyn> that's what i was trying - ah yeah the major/minor are actually helpful
<stgraber> right, I was thinking of comparing the major/minor of the /proc/ entry to that of the device in /dev, if it matches, return that, if it doesn't, return the /proc path
<hallyn> so if the readlink is stat()able then compare major/minor of the resulting path to the lstat of /proc/self/fd/0,
<hallyn> if not the same, then still return "/proc/self/fd/0"
<hallyn> should work
<stgraber> yep
<sarnold> .. can you check that the /proc/self/fd/0 is actually a tty device?
<hallyn> it already does that
<stgraber> yeah, libc actually does that part right
<hallyn> so what libc does right now is readlink the name, then stat the result.
<hallyn> if that gives -ENOENT then it returns null.  else it returns the link value
<hallyn> but both of those can be wrong
<stgraber> which is why the "tty" command right now exits 0 but prints an error which confuses quite a few things :) Because it is a tty, but ttyname returns an empty string
<hallyn> ok, so my patch will add some overhead, but i think it's worthwhile
<sarnold> heh
<stgraber> hallyn: ttyname isn't something that's called all that often, a tiny overhead to have it DTRT should be fine
<sarnold> .. and heck even if it is called all the time, being correct may be that much more important :)
<hallyn> agreed.  i'll try to get that and the new kernel patch <sob> sent tomorrow
<hallyn> heh, yeah
<hallyn> in fact it also will fix the "other kerfuffle which will not be named"
<hallyn> all right, to the batcave.  thanks gents.
<stgraber> also leaving for the night, talk to you tomorrow
<hallyn> \o
<cpaelzer> good morning
<pitti> wgrant: just to confirm, is this running now?
<wgrant> pitti: Yep
<pitti> wgrant: cheers
<wgrant> np
<flexiondotorg> Can I request some sponsoring assistance please?
<flexiondotorg> infinity, Has said I need to get my bug fixes in promptly.
<flexiondotorg> They are mostly Syncs from Debian and some small updates.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1570554
<ubottu> Launchpad bug 1570554 in mate-menu (Ubuntu) "Sync mate-menu 5.7.1-1 (universe) from Debian unstable (main)" [Undecided,New]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1570652
<ubottu> Launchpad bug 1570652 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 16.04.8 bug fix and translations [dsc attached]" [Undecided,New]
<flexiondotorg> https://bugs.launchpad.net/bugs/1569732
<ubottu> Launchpad bug 1569732 in caja-dropbox (Ubuntu) "Sync caja-dropbox 1.12.0-3 (multiverse) from Debian unstable (non-free)" [Undecided,New]
<flexiondotorg> https://bugs.launchpad.net/bugs/1569731
<ubottu> Launchpad bug 1569731 in mate-tweak (Ubuntu) "Sync mate-tweak 3.5.10-1 (universe) from Debian unstable (main)" [Undecided,New]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1569320
<ubottu> Launchpad bug 1569320 in ubuntu-mate-settings (Ubuntu) "ubuntu-mate-settings 16.04.5 release [.dsc included]" [Undecided,New]
<infinity> flexiondotorg: Have you given any thought as to whether MATE will be an LTS release for 16.04?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-meta/+bug/1568773
<ubottu> Launchpad bug 1568773 in ubuntu-mate-meta (Ubuntu) "Please update ubuntu-mate-meta package" [Undecided,New]
<flexiondotorg> infinity, Yes, we are absolutely doing LTS.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/x2goclient/+bug/1569310
<ubottu> Launchpad bug 1569310 in x2goclient (Ubuntu) "FFe: Sync x2goclient 4.0.5.1-1 (universe) from Debian unstable (main)" [Undecided,New]
<infinity> flexiondotorg: I was going to send an email out for flavours to pick 3/5 (or not LTS) based on the fact that everyone's done this before, and I just realized that you haven't. :P
<flexiondotorg> That is my sponsor requests.
<flexiondotorg> infinity, Yeah, this is new.
<flexiondotorg> We just assumed we'd be doing 5 years.
<flexiondotorg> And thet is what we're up for.
<flexiondotorg> infinity, I've posted all most sponsoring bugs above. Any chance you can process those?
<infinity> flexiondotorg: So, traditionally, letting a flavour be LTS requires a bit of a plan of how you intend to commit to maintenance for your N chosen years, send to the techboard mailing list, and we'll +1/-1 based on exposure to you over the past few cycles and the sanity/realism in your plan.
<infinity> flexiondotorg: I can try to look at your bugs in a bit.  It's late here, and I'm grinding away at my own stuff, so we'll see.
<flexiondotorg> infinity, OK, will send mail later.
<flexiondotorg> infinity, So if I can another sponsor to process my bugs that is fine right?
<flexiondotorg> infinity, All that is required is to unblock them?
<infinity> flexiondotorg: If your community is spread fairly thin or lightly-staffed (which I suspect is true right now), you might want to go for 3 instead of 5.  Gives you a year overlap with 18.04, instead of 3.
<flexiondotorg> infinity, OK. I'll give that some thought.
<infinity> flexiondotorg: If all your sponsorship requests are things that would be valid SRUs, any old sponsor will do, we'll review in the queue.
<flexiondotorg> What constitutes the MATE bit in Ubuntu MATE is actually very small.
<infinity> flexiondotorg: If they're massively FFe-breaking gross, not so much.
<flexiondotorg> infinity, Everything is a fix.
<flexiondotorg> infinity, In the spirit of your email adding these fixes will make Ubuntu MATE "good enough".
<infinity> flexiondotorg: Sure, I realize your package set is pretty small, but so is your team, so judge accordingly.  IMO, 5y LTS is really only meaningful if you're targetting slow-moving environments (large corporation rollouts, etc).  Most average users would upgrade from 16.04 to 18.04 withing days/weeks of update-manager telling them to anyway, so the extra 2 years is just a burden.
<infinity> flexiondotorg: But your call, obviously.  Last LTS, the flavours were split about 50/50 on 3/5.
<flexiondotorg> infinity, So one deployment we know we'll have is for several large remote terminal server deployments.
<flexiondotorg> inaddy, Hence the x2goclient FFe.
<flexiondotorg> infinity, For how many years are point release images mades? Like 16.04.1, 16.04.2 etc.
<infinity> flexiondotorg: Last point release is 16.04.5, which coincides (within a week or so) with 18.04.1
<infinity> flexiondotorg: Which is ~3mo after 18.04 release.
<infinity> flexiondotorg: So, after that, it's just SRUs for critical fixes, but no more installer validation and ISO madness.
<flexiondotorg> OK, so with in the 3 year LTS window.
<flexiondotorg> It would seem 3 years is sufficient then.
<flexiondotorg> I'll discuss with the X2Go guys.
<flexiondotorg> Do I need to file a plan for 3 year LTS?
<infinity> flexiondotorg: Yeah.  The 3/5 decision is entirely your call, those last two years are generally easier (fewer fixes you're willing to consider "critical" when you can just tell people to upgrade to the next LTS instead), though worth noting that when something *needs* to be fixed in 4yo software, the backporting can suck. :P
<infinity> flexiondotorg: But we need the email regardless.  The 3/5 thing is just something you need to mull over in the next few days so we can set the right number in LP and have it show up right in packages files.  And once it does, you're stuck.  So choose wisely. :P
<flexiondotorg> infinity, Thanks for the advice.
<darkxst> dholbach, is there an existed FFe for seeding snappy? or do I need to file one?
<flexiondotorg> darkxst, When I did it I filed an FFe just for Ubuntu MATE.
<infinity> darkxst: Don't bother filing, just seed snapd (as a recommends, if you want to follow what most are doing) and upload a refresh of your meta.
<darkxst> infinity, ok cool, will do
<flexiondotorg> infinity, Can you refresh ubuntu-mate-meta please? https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-meta/+bug/1568773
<ubottu> Launchpad bug 1568773 in ubuntu-mate-meta (Ubuntu) "Please update ubuntu-mate-meta package" [Undecided,New]
<flexiondotorg> It's a tiny update.
<infinity> flexiondotorg: Refreshing.
<flexiondotorg> infinity, ty!
<infinity> flexiondotorg: I don't see any cheesiness in that update (thought I do see some other bits)
<infinity> Wait, no.
<infinity> I see no changes.
<infinity> I'm not awake enough. :P
<infinity> flexiondotorg: Oh, that bug is ancient.  I've uploaded your meta much more recently.
 * infinity just closes it.
<darkxst> infinity, can you take a look at the casper part on bug 1561302 ?
<ubottu> bug 1561302 in casper (Ubuntu) "gdm won't allow passwordless login" [Critical,Triaged] https://launchpad.net/bugs/1561302
<elbrus> nacc: I see your pings regarding cacti, but I don't see what you want... (sorry, I have been busy the last days)
<pitti> stgraber: ok, lxd is now running for autopkgtests :) (https://plus.google.com/+MartinPitti/posts/QJnjsUci4Wi)
<pitti> Laney: ^ FYI
<pitti> apw, jdstrand: do you have an interpretation of the regression in http://autopkgtest.ubuntu.com/packages/l/linux/xenial/ppc64el/ ?
<pitti> that openssl version should be a functional no-change (just some patch cleanup)
<Laney> pitti: nice
<Laney> are the SS instances long running?
<pitti> Laney: well, they tend to auto-destruct after a day or two
<pitti> Laney: but in principle they are meant to, yes
<Laney> ya, that bug
<pitti> Laney: autopkgtest-cloud/tools/armf-lxd-slave.userdata has everything to set them up, though, so it's simple to spin up new ones
<pitti> Laney: (for nova boot --userdata)
<pitti> Laney: this still needs logic for the controller node to run workers automatically, see/register the available remotes etc., so still a PoC
<pitti> but it can help with the backlog for sure
<pitti> and we can collect some experience with hit
<pitti> it
<pitti> mvo: FYI, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd regression
<mvo> pitti: did anything in infrastucture change? it looks like an io error/timeout from a store download
<pitti> mvo: not that I know of; something could have changed in the scalingstack config behind my back of course
<pitti> mvo: but given that 1.9.2 passed *after* the 1.9.3 failure, I doubt that (http://autopkgtest.ubuntu.com/packages/s/snapd/xenial/amd64/)
<mvo> pitti: interessting
<pitti> and that's consistent across all arches
<mvo> pitti: hrm, we actually test more now than in 1.9.2 :/ this is why it fails, i.e. the failure in 1.9.3 are network releated and we did not use network before AFAICS
<pitti> ah, that would explain it indeed then
<pitti> mvo: store access might not work through a proxy then?
<pitti> we set http_proxy and friends in /etc/environment and in the test env
<mvo> pitti: thats possible, I don't think we tested this
<mvo> pitti: let me check that, thanks, thats useful
<pitti> mvo: we can also give you access to a production instance where this fails, if needed
<pitti> but I'm running out of time today (I took half-day off, need to run in 3 mins, sorry)
<mvo> pitti: that would be nice, I suspect its because we use https for everything
<pitti> if Laney has time he might be able to help
<mvo> pitti: ok, who else could help?
<pitti> mvo: we set https_proxy too
<mvo> pitti: ta
<mvo> pitti: run and thanks for your help
<pitti> Laney: we have a "jump host" (instance name "debug") in prodstack, ssh to that, ssh-import-id lp:mvo, then from there folks can ssh to an instance of a manual adt-run with -s
<pitti> you can't directly ssh from outside to a scalingstack instance
<Pharaoh_Atem> nacc: libvirt-php is building and passing the php extension build system tests
<Pharaoh_Atem> on php7
<Pharaoh_Atem> nacc: so once you build a ppa package, I can test it
<LocutusOfBorg> hi, question: today is the last day to sync stuff from debian?
<LocutusOfBorg> correct?
<rbasak> LocutusOfBorg: if seeded, then we're already past final freeze. The release team will consider essential fixes though, see the announcement.
<LocutusOfBorg> rbasak, I *need* to have virtualbox in
<LocutusOfBorg> :)
<LocutusOfBorg> xorg 1.18 fixes, and kernel too
<LocutusOfBorg> as usual, I have to break stuff
<LocutusOfBorg> damn broken dinstall
<LocutusOfBorg> can't ubuntu sync from incoming.d.o? (citation needed)
<rbasak> LocutusOfBorg: you can still sync, subject to the freeze criteria. I believe.
<LocutusOfBorg> sync from incoming?
<rbasak> No, I don't think that works.
<LocutusOfBorg> :(
<rbasak> Launchpad needs to have imported into launchpad.net/debian for sync to work, AIUI.
<LocutusOfBorg> --no-lp?
<rbasak> I don't know.
<LocutusOfBorg> I tried once, but failed
<rbasak> You could just upload what you uploaded as an Ubuntu delta. It wouldn't make any difference now this close to release.
<rbasak> (though you'll need to sync once again in X+1)
<LocutusOfBorg> I would like to avoid that, but yeah
<cjwatson> with dak broken, if it can't wait for dak to be fixed, it would have to be manual in some way.
<LocutusOfBorg> indeed
<cjwatson> rbasak: there's always ~build1 or similar
<rbasak> cjwatson: ah, OK
<cjwatson> we did actually arrange for incoming to have acls that would let us sync from it, but never got round to setting that up in LP; there were concerns about making sure we could correctly handle unaccepts and suchlike
<jdstrand> pitti: regarding http://autopkgtest.ubuntu.com/packages/l/linux/xenial/ppc64el/ it seems to have resolved itself?
<sruli> hi, is secureboot implemented in 16.04? will it warn user if a unsigned kernel is loaded?
<sruli> i am referring to Launchpad bug 1401532
<ubottu> Launchpad bug 1401532 in grub2 (Ubuntu) "GRUB's Secure Boot implementation loads unsigned kernel without warning" [Wishlist,In progress] https://launchpad.net/bugs/1401532
<superm1> cyphermox: i don't know if you've had reports of this yet, but i've noticed the new NM sometimes thinks my wifi device turned into an ethernet device
<superm1> i noticed https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1569590 but it's not an ath* device on my machine
<ubottu> Launchpad bug 1569590 in network-manager (Ubuntu) "wireless card disabled in network-manager" [High,Triaged]
<doko> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815633  please update the symbols file ... solution: remove it :-/
<ubottu> Debian bug 815633 in ilmbase "ilmbase: symbols file update for kfreebsd" [Important,Fixed]
<cyphermox> superm1: right
<doko> hmm, the openexr test failure succeeds locally
<nacc> Pharaoh_Atem: ack, thanks
<Pharaoh_Atem> nacc: no problem
<nacc> Pharaoh_Atem: was that the version in unstable? -- aka can you check debian unstable as it is now?
<mgz_> pitti: how do you want patches to autopkgtest?
<Pharaoh_Atem> nacc: give me a second, I'll check
<nacc> Pharaoh_Atem: thanks, it might still be publishing tbh, but rmadison shows a newer version in usntable from what we saw yesterday
<Pharaoh_Atem> nacc: it's a slight fork
<Pharaoh_Atem> nacc: http://anonscm.debian.org/cgit/pkg-php/libvirt-php.git/log/
<Pharaoh_Atem> it doesn't yet match upstream
<Pharaoh_Atem> also, I've figured out where those weird git hashes are coming from
<Pharaoh_Atem> he's managing it as an in-tree repository, like with php, which means that you can't rely on the git revs to match upstream for snapshots
<nacc> Pharaoh_Atem: ah ack, makes sense
<Pharaoh_Atem> personally, not a fan of that
<Pharaoh_Atem> it makes things more complicated then it needs to be
<Unit193> Are there any other repos besides the Ubuntu one that support by-hash?  I'm wondering if I implemented it correctly.
<cjwatson> Unit193: not to my knowledge
<cjwatson> well, PPAs support it too, but same code
<cjwatson> Unit193: there's https://wiki.debian.org/RepositoryFormat#indices_acquisition_via_hashsums_.28by-hash.29
<seb128> bdmurray, hey, did you see bug #1570947
<ubottu> bug 1570947 in ubuntu-release-upgrader (Ubuntu) "Trusty to Xenial upgrade KeyError: 'SUDO_UID'" [Critical,Confirmed] https://launchpad.net/bugs/1570947
<seb128> seems to be due to the landing you did today with the change from darkxst
<seb128> jibel, willcooke, ^
<Unit193> cjwatson: Ah, re-reviewing did answer it, thanks.
<cjwatson> Unit193: Cool.  The tricky bit is dealing with expiry, which depends how clever you want to be.
<Unit193> Indeed, no idea how I'm going to deal with that one.
<hallyn> smb: meh, looks like i need to make wgrant a mmember of the libvirt-maintainers group so he can use the lp git tree :)
<bdmurray> seb128: I didn't, thanks
<cjwatson> Unit193: The algorithm in LP isn't (I think) too hard to read if you want inspiration.
<smb> hallyn, I'd say there's worse people to be added ... :)
<Unit193> Might be handy.
<hallyn> wish we had an official UDD-style tree
<cjwatson> Unit193: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/archivepublisher/publishing.py#L1008 (_updateByHash) is the entry point
 * hallyn makes a note to straighten that out in the xenial tree later, not now
<cjwatson> ByHashes (and its child ByHash) is defined further up in that file.
<cjwatson> ArchiveFile is in lib/lp/soyuz/model/archivefile.py, although the details are quite LP-specific.
<cjwatson> (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/soyuz/model/archivefile.py)
<Unit193> Thanks, though I don't believe this adds much benefit to me it still might be handy, moreso if I can upstream it.
<hallyn> stgraber: sarnold: fwiw http://sourceware.org/ml/libc-alpha/2016-04/msg00391.html.
<ubottu> sourceware.org bug 2016 in libc "argp --help infloop, via ARGP_HELP_FMT envvar" [Normal,Reopened]
<rbasak> tjaalton: how did you merge apache2? Looks like you inadvertently reintroduced http2.load which led to https://bugs.launchpad.net/ubuntu-release-notes/+bug/1531864/comments/5
<ubottu> Launchpad bug 1531864 in Release Notes for Ubuntu "HTTP/2 disabled in Apache httpd" [Undecided,New]
<hallyn> let's see hwo i get roasted
<hallyn> ubottu, go home, you're drunk
<ubottu> hallyn: I am only a bot, please don't think I'm intelligent :)
<stgraber> infinity: see http://sourceware.org/ml/libc-alpha/2016-04/msg00391.html I mentioned that issue here a little while back
<ubottu> sourceware.org bug 2016 in libc "argp --help infloop, via ARGP_HELP_FMT envvar" [Normal,Reopened]
<bdmurray> darkxst: you might be interested in bug 1570947
<ubottu> bug 1570947 in ubuntu-release-upgrader (Ubuntu) "Trusty to Xenial upgrade KeyError: 'SUDO_UID'" [Critical,Confirmed] https://launchpad.net/bugs/1570947
<seb128> bdmurray, it's like 2am for him so I doubt he's going to be around
<hallyn> sbeattie: ugh, i didn't group-reply with that email.  do you mind replying to it with a 'ok' or something so the list sees it? :-)
<seb128> bdmurray, maybe cyphermox or infinity can help you there?
<alkisg> stgraber: ltsp is completely broken in 14.04, but no one is interested in doing an SRU for ~50 bugs. On the other hand, the newest xenial ltsp package works fine in 14.04. Is there any way in the ubuntu policy to get the newest ltsp backported to 14.04?
<stgraber> alkisg: as an SRU, no, unless it's a bugfix only release but I doubt that'd be the case. You can request a backport though at which point users would be able to run say: apt-get -t trusty-backports install ltsp-server
<stgraber> alkisg: which would get them the backported package
<alkisg> stgraber: that will still leave the normal way to install ltsp broken. No ways around that, right?
 * alkisg directs people to do an SRU or use his ppa, just to make sure he isn't pointing them wrong...
<stgraber> alkisg: right, we do not push new features in existing releases. If upstream LTSP was making bugfix-only releases (as is the case for many other projects), then those could go in without the paperwork for every individual bug, but getting a complete new release full of new features through SRU isn't allowed by policy, no
<alkisg> OK, ty
<alkisg> Maybe the policy should allow replacing a broken version with a fixed newer version with new features, but that's a bigger talk, not for now...
<rbasak> dholbach: mate-menu> snap
<ogra_`> rbasak, that is not how to create snap packages :P
<nacc> heh
<nacc> one day ...
<rbasak> ogra_`: ?
<infinity> stgraber: How is that not a kernel/namespace bug?
<rbasak> Oh
<rbasak> :)
<ogra_`> :)
<infinity> stgraber: Why would /proc/self/* ever point to something in another namespace?
<stgraber> infinity: you can absolutely pass fds between namespaces, or in this case have an open fd before switching to another namespace (setns)
<infinity> stgraber: Sure, but isn't the point of /proc/self that it should be internally consistent with the process's state?  If the path differs in the current namespace, I'd expect it to be updated to match.
<stgraber> infinity: the main reproducer for the issue is getting a shell inside a container. To do that, the user spawns a process on the host, that process then setns into the container and execs a shell. It's still attached to the user's pts device on the host (and should be as we want it to be an interactive shell)
<stgraber> infinity: the container has its own devpts instance on /dev/pts so /proc/self/fd/0 points to a path in the host namespace
<stgraber> infinity: readlink on /proc/self/fd/X gives you the path which was provided at fd open time, it doesn't give you the path the file is currently at
<infinity> stgraber: Yes, hence my assertion that this is a kernel bug. :P
<infinity> stgraber: I'm not sure how returning the link to (effectively) nowhere is significantly more helpful than the current broken behaviour.
<infinity> stgraber: You still can't use it for anything.
<stgraber> infinity: because you can absolutely open /proc/self/fd/0 and it'll work fine
<infinity> Even if it's a symlink to a file that doesn't exist?
<stgraber> yep
<infinity> *raise brow*
<stgraber> infinity: http://paste.ubuntu.com/15853488/
<stgraber> infinity: that's the linux kernel for you, and it's something people have been relying on for a while, so ain't gonna change
<stgraber> infinity: the fix hallyn submitted fixes the "tty" command, as well as screen, byobu, ... anything which uses ttyname
<kirkland>  (woot)
<infinity> stgraber: This also implies that the kernel knows where the *real* fd/0 lives, which furthers my assertion that this is a bug in procfs. :P
<stgraber> infinity: the kernel knows but it can't show you that path
<stgraber> infinity: that path is completely outside the scope of your container so you can't possibly reach it
<infinity> stgraber: No, but if, in the current namespace, the path is unresolvable, the least it could do is remove the link to nowhere.
<infinity> stgraber: And show fd/0 as a file instead of a link.
<infinity> stgraber: Anyhow, meh.  Also obviously not a glibc regression, so we'll get there if we get there, or SRU later.
<stgraber> infinity: I agree it would make sense for the kernel to do that, unfortunately I don't see this changing due to it being basically API at this point (it's been like that forever) and I don't believe there is any precedent for a /fd/ entry to be anything but a symlink
<stgraber> (or well, a symlink looking thing)
<stgraber> infinity: and yeah, not a regression, just an annoying issue that a lot of our users ran into or will run into (do-release-upgrade fails for example). I don't think we should rush it though which is why hallyn sent the fix upstream rather than distro-patching
 * cyphermox -> lunch
<tjaalton> rbasak: huh? with git, mut far from kbd until sunday
<rbasak> tjaalton: OK. Well, it went wrong. Thought you should know.
<tjaalton> ok, can't check what went wrong
<tjaalton> sorry
<hallyn> stgraber: i'm having to postpone my reply bc i'll be too snarky right now.  not sure how i'm *expected* to react to that...
<hallyn> "so you want me to make my eyes bleed more with your ugly-ass coding style but don't want to actually take the patch bc you think fixing a security issue has securiyt implications?  Do you not see the relevance to the ptchown disaster?"
<infinity> hallyn: You might want to skip the bit about GNU coding standard (we almost all agree it's ugly, but picking a new standard and reindenting millions of lines would be worse).
<infinity> hallyn: But feel free to challenge Florian on security concerns.
<infinity> hallyn: Most of the time, you'll be wrong, but he can take a healthy debate.
<ogra_> geez ... doing a do-release-upgrade with the canonical vpn enabled is really badly killing bandwidth
<hallyn> infinity: yeah i think i'm cranky from a too-much-email morning;  i'll replywhen i'm not whiny
<sarnold> hallyn: nice patch. pity about the coding standards, I like your version just fine ;)
<sarnold> hallyn: I agree with infinity, at the very least push back on asking him to describe what yours introduces -- or why the current behaviour isn't worse..
 * hallyn finally got some breakfast, maybe that's my problem
<hallyn> sarnold: nah even my version made my eyes bleed.  And ebiederman couldn't follow the flow he said bc of the 2 spaces :)
 * hallyn looks for the gnu coding style guide
<sarnold> hallyn: if it were longer I might have come to the same conclusion :)
<hallyn> still wonder whether i should also do it for ptsname.c.  i probably should.
<hallyn> that's the most immediately obvious security relevant one
<hallyn> wowzer:
<hallyn> Please use formfeed characters (control-L)
<hallyn> to divide the program into pages at logical places (but not within a function).
<sarnold> I'm still stunned whenever I see that in source
<rbasak_> Well, it's handy if you want to print out the source :-P
<rbasak> (you do that, right?)
<mdeslaur> what? I don't think I've ever seen that
<mdeslaur> sarnold: what source, you've made me curious :)
<mdeslaur> I'm not sceptical, I just want to know which source to mock
<sarnold> mdeslaur: coreutils
<sarnold> I was reading nproc the other day..
<sarnold> $ grep -r ^L . | wc -l
<sarnold> 1290
<hallyn> 1290?  wowzer
<mdeslaur> that grep is wrong, try again
<hallyn> hm, i may have lied to Florian.  *can* i verify that the device is devpts?
<hallyn> yeah major should be never-changing
<sarnold> mdeslaur: it was umt download, so all releases.. and I used ^V^L of course to construct the ^L ..
<sarnold> mdeslaur: oh it's also got loads of cscope hits :/
<mdeslaur> hah! I see them now...wow, insane
<hallyn> wtf.  'git checkout' just overwote my changes.  normally it says 'no you have changes'...
<hallyn> ok i really *am* having a bad friday
<xclaesse> Hello
<xclaesse> I just upgraded to ubuntu 16.04, and now when I try to ssh to servers that has my DSA key in authorized_keys, it says Permission denied (publickey).
<xclaesse> with ssh -v I see that it tries to use id_rsa but not id_dsa
<xclaesse> is that a recent change because DSA is not considered safe anymore?
<mdeslaur> xclaesse: dsa is disabled in openssh 7.0 for security reasons, yes
<mdeslaur> xclaesse: you can re-enable it, see here: http://www.openssh.com/legacy.html
<mdeslaur> xclaesse: or ideally use rsa or something else
<xclaesse> mdeslaur, ok thanks
<xclaesse> mdeslaur, I knew DSA was considered weak nowadays, just need to temporaly re-enable it so I can copy my new RSA id :)
<mdeslaur> xclaesse: yeah :)
<mdeslaur> sarnold: I'm almost done with a patch to add linefeeds to apparmor, I just need to print it all out to test. Are we aiming for letter, legal or A4 paper?
<sarnold> mdeslaur: lol
<sbeattie> mdeslaur: please make sure it fits on 3x5 index cards.
<mdeslaur> sbeattie: I used to own one of these: http://i.ebayimg.com/00/s/MTIwMFgxNjAw/z/8OMAAOSwaA5WkxOq/$_12.JPG?set_id=880000500F
<mdeslaur> no linefeeds necessary :)
<sbeattie> hehe
<sarnold> wow, 24, 32, _and_ 40 columns?
<Pici> whoaaa
<hallyn> sarnold: used to?  wtf!
<mdeslaur> hallyn: I no longer have it. I'm such a fool. I called it...Rosebud.
<seb128> cyphermox, trying today's daily in a virtualbox (which is online), the first page has the "download update" option disabled (can't be clicked), is that a known issue?
<hallyn> mdeslaur: yeah, there are a few things i wish i'd never given up :)
<cyphermox> seb128: no
<cyphermox> try to reset the online state too
<seb128> cyphermox, install is ongoing atm, going to try once it's done
<nacc> Pharaoh_Atem: so are you saying the debian version (pacakged already) is not complete?
<Pharaoh_Atem> nacc: no, it's not
<Pharaoh_Atem> in fact, it's got the wrong fix, according to Michal and Remi
<Pharaoh_Atem> it can cause stack mashing or something like that
<ashwin> where can I get the .config file for ubuntu trusty for kernel v4.2 ? I just made a minor change and want to recompile the kernel
<hallyn> this gets better and better
<Unit193> hallyn: Do you want to go back to bed and try the day over?
<sarnold> ashwin: /boot/config*
<hallyn> so use 2 spaces for indent, but then use a tab if there are 8 spaces.  check
<sarnold> hallyn: that alone is probably why we're not all using hurd right now.
<seb128> cyphermox, reconnecting doesn't work, it says it's disabled because there is no internet connection ... unsure if that's a vb issue or a side effect of the nm 1.1 update
<seb128> jibel, ^
<hallyn> Unit193: maybe
<hallyn> is that an option?
<ashwin> sarnold: Thanks!! Gotta improve my google-fu :)
<sarnold> ashwin: it's not an easy one to search for
<sarnold> ashwin: the kernel team actually p7ublishes their configs somewhere, but I can never find the site when I want it
<hallyn> sarnold: i woulda sucked it up if i wasn't also chastised for unthinkingly adding a signed off by
<sarnold> hallyn: wha?? o_O they don't do the origin-thing/
<Unit193> sarnold: I don't suppose you mean their git? (http://kernel.ubuntu.com/git/)
<sarnold> Unit193: probably this http://kernel.ubuntu.com/~kernel-ppa/configs/trusty/
<sarnold> Unit193: my issues with git is something else entirely..
<Pharaoh_Atem> nacc: that package needs to be rebased on the current git master
<cyphermox> seb128: probably a bug in NM, but in part made easier to reproduce because virtualbox is evil and broken
<Pharaoh_Atem> nacc: also, it should be treated as 0.5.1+ snapshot date, since he hasn't decided what it'll be released as
<seb128> cyphermox, let me know if need debug info from me or if you can reproduce
<Unit193> sarnold: Also, FWIW.  Netsplits left you unidentified.
<sarnold> Unit193: gah I keep forgetting that I never set up certfp over here once they added it..
<Unit193> Yeah that one is a fantastic backup.
<cyphermox> seb128: any details you can add to the bug report are helpful
<ashwin> sarnold: Yup, and page where that was had config for an old version (not 4.2 that is on trusty's linux-generic)
<hallyn> sarnold: lots of people don't do it, but few act as though their git repo will segfault if it sees one
<infinity> ashwin: The config for your installed kernel is /boot/config-$(uname -r), that's the easiest place to grab it.
<Unit193> infinity: Not that you are too interested, but for the insane trying out dracut in Xenial is pretty darn easy now, just have to drop a shell wrapper in /usr/sbin/update-initramfs for kernels that call it directly (but triggers take care of it later.)
<infinity> Unit193: Yeah, I'm not sure I consider that a feature. :)
<ogra_> ugh
<nacc> Pharaoh_Atem: taht's why it's 0.5.2~
<nacc> Pharaoh_Atem: means precedes 0.5.2
<nacc> Pharaoh_Atem: i'm 99% sure ondrej just took your ML change ... is it actually wrong?
<hggdh> which package should I assign on a bug about hostnam being called with -b at busybox time (xenial)?
<infinity> hggdh: "At busybox time"?
<infinity> hggdh: You mean in the initramfs?
<hggdh> infinity: yes
<infinity> hggdh: initramfs-tools, but I'm kinda curious why you think that's a bug.
<hggdh> infinity: bad parameter: http://picpaste.com/busybox_error_16.04-b4eZkmJt.JPG
<infinity> hggdh: Ah.  Well, that would indeed be a bug. ;)
<infinity> hggdh: One almost no one sees because most people don't have an /etc/hostname in their initrd.
<hggdh> infinity: heh. And because it flashes very fast on boot time
<hggdh> I will open a bug on it. I understand it is most probably not bad, but anyways.
<infinity> hggdh: I'm not even sure how you have an /etc/hostname.  Can you give me an "rgrep hostname /usr/share/initramfs-tools" ?
<hggdh> infinity: http://paste.ubuntu.com/15859220/
<ogra_> uuh
<infinity> hggdh: Ahh, zfs.  Yeah, not a common thing yet, hence the lack of complaint.  Will fix.
<hggdh> infinity: need a bug for that?
<sarnold> heh, have I rebooted since creating my pool? :)
<infinity> hggdh: Nah.
<sarnold> I don't recall seeing that screen..
<infinity> The -b argument there is entirely pointless anyway, since we test for /etc/hostname first.
<infinity> (The whole point of -b is to behave sanely if the -F arg isn't there)
<hggdh> infinity: thanks, sir
<infinity> Oh, two bugs.  The redirection there is bad too.
<infinity> Though, in your case, that showed the first bug. :P
<infinity> hggdh: Fixes uploaded.
<nacc> Pharaoh_Atem: ok, can you file a bug or e-mail ondrej with clarification?
<nacc> Pharaoh_Atem: unless your last e-mail was clarifying enough
<Pharaoh_Atem> nacc: I think it was clarifying enough
<Pharaoh_Atem> nacc: though actually, I should probably elaborate
<rbasak> reverse-depends still claims gnokii-smsd-mysql [amd64] but chdist disagrees. What is reverse-depends querying? Is it possible that it's behind?
<rbasak> "reverse-depends libmysqlclient18" that is.
<infinity> rbasak: It queries a private DB built against the archive.  It can certainly lag by a few hours.
<infinity> rbasak: http://paste.ubuntu.com/15859911/ <-- What's being done about the *-5.6 rdeps?
<rbasak> infinity: mythtv is an alternative so false positive. I can rebuild percona for 5.7 - no significant change in client so it should work equally well with 5.7 (and maybe I can unversion them while at it).
<rbasak> Skuggen is looking at pinba.
<rbasak> gnokii and kodi are done - database lag.
<rbasak> tarantool-lts as well IIRC.
<rbasak> So getting there.
<rbasak> bareos too - db lag probably
<rbasak> cfengine3 Skuggen has a debdiff for me.
<rbasak> ntopng done, db lag.
<rbasak> infinity: trafficserver is a painful one actually. A major version update in -proposed has FTBFS for various reasons on various archs, Debian too. So I wonder if we could try rebuilding only the version in the release pocket after deleting the proposed version maybe?
<infinity> rbasak: I can try the release version in a devirt PPA without proposed enabled.
<rbasak> Thanks. Note I haven't tried the release version at all yet.
<rbasak> pinba I'm the most concerned about right now.
<infinity> rbasak: https://launchpad.net/~adconrad/+archive/ubuntu/staging/+packages
<rbasak> Thanks, I'll watch it.
 * rbasak goes to bed
<rbasak> (check it in the morning I mean)
<infinity> rbasak: Anything runtime you need to check, or if it's correctly-linked and doesn't FTBFS, do you want to call it good?
<rbasak> infinity: if it doesn't FTBFS I'm calling it good.
<infinity> rbasak: Well, no such luck there .:)
<infinity> rbasak: Will have to look later.  But it's broken right now.
<rbasak> powerpc and s390x are already broken in the release pocket. Looks like ppc64el is a regression though.
<infinity> mvo: Are you eating or sleeping between these snapd releases?
<mvo> infinity: no
<mvo> infinity: but fortunately there is a deadline
<mvo> infinity: I mean, the end is near and all that
<mvo> infinity: thanks and sorry for the bombardment
#ubuntu-devel 2016-04-16
<darkxst> bdmurray, I can take a look now, or are you already on it?
<bdmurray> darkxst: I've uploaded a fix now.
<darkxst> bdmurray, ok thanks
<alexlist> https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1571166
<ubottu> Launchpad bug 1571166 in squid3 (Ubuntu) "package squid3 3.3.8-1ubuntu16.2 failed to install" [Undecided,New]
<infinity> alexlist: That's not the version in 16.04, so a curious report already. :P
<infinity> alexlist: Can you attach the apt term log from the upgrade?
<alexlist> infinity: https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1571174
<ubottu> Launchpad bug 1571174 in squid3 (Ubuntu) "package squid3 3.3.8-1ubuntu16.2 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [Undecided,New]
<infinity> alexlist: Can you try upgrading ufw first, on a hunch?
<infinity> alexlist: I might need to do some fiddling to force upgrade order there.
<alexlist> infinity: you mean manually installing the xenial ufw on a wily box? Sure, can try...
<xpheres> hello, I'm trying to create a scope from ubuntu sdk, however there are no virtual device to do it and I can not add an armdevice to qt
<xpheres> anyone knows why this happens?
<ogra_> hmm, vlc upnp support seems broken in xenial
<r1nuz> Question, i'm trying to read eglibc code. If I get it using apt-get source eglibc it will be automatically patched to the way it's used in ubuntu, correct?
<r1nuz> Also, if I wanted to find what build configuration is used in the actual distributed version, where could I find that?
<alexlist> infinity: http://pastebin.ubuntu.com/15873401/ -> started ubuntu 15.10 in privileged docker container, installed squid-deb-proxy and ufw, installed ubuntu-release-upgrader-core, installed xenial ufw, ran release upgrade without issues. Will amend bug report.
 * ogra_ files bug 1571199 
<ubottu> bug 1571199 in libupnp (Ubuntu) "vlc broken with latest libupnp" [Undecided,New] https://launchpad.net/bugs/1571199
<xpheres>   p, li { white-space: pre-wrap; }  Starting /usr/bin/ubuntu-html5-app-launcher... Setting import path to:   [0416/165255:FATAL:setuid_sandbox_client.cc(126)] Check failed: IsFileSystemAccessDenied().
<xpheres> why?
<tumbleweed> r1nuz: yes. The build configuration is what you see in the package
<r1nuz> tumbleweed: thanks, so when i run make without ./configure first it should build the way it's distributed?
<r1nuz> because when i try, i get:
<r1nuz> $ make
<r1nuz> Makeconfig:42: *** missing separator.  Stop.
<tumbleweed> r1nuz: when you run dpkg-buildpackage -B
<tumbleweed> (on the same ubuntu release)
<r1nuz> tumbleweed: awesome, thanks :)
<r1nuz> will that also create the proper Makefile btw?
<r1nuz> guess i should read the dpkg manpage
<r1nuz> (what i secretly really want is the appropriate Makefile config so that i can use unifdef to make the libc sources more readable but consistent with my distro)
<tumbleweed> I have no experience in the eglibc package, but I'd expect it to be a little complex and weird
<cjwatson> r1nuz: debian/rules is the entry point for the packaged build system.  And what tumbleweed says
<r1nuz> tumbleweed cjwatson thanks
<r1nuz> looks like dpkg-buildflags might be what i want
<cjwatson> no
<cjwatson> what I said is what you want
<cjwatson> dpkg-buildflags is a small piece
<cjwatson> that's generic distribution-wide flags basically, not package-specific changes, of which I'm sure glibc has many
<cjwatson> if you want to understand an Ubuntu (or Debian) source package, start with debian/rules
<r1nuz> oh debian/rules file, i see
<r1nuz> thanks
<r1nuz> appreciate it
<cjwatson> you'll have to chase up a lot of references from there
<r1nuz> ah well, i enjoy a good rabbithole :)
<cjwatson> but normally at least the set of configure flags and such is in there
<cjwatson> (I think in glibc's case it may actually be in an included makefile under debian/rules ...)
<tumbleweed> the best might be to build it and read the build log (or just read the log for the most recent ubuntu build)
<r1nuz> where could i find that latter log? for the most recent build?
<tumbleweed> https://launchpad.net/ubuntu/+source/eglibc
<r1nuz> thanks
<tumbleweed> follow the links through to a version, and then an architecture
<cjwatson> and note that Ubuntu switched back to glibc after 14.04, so if you're based on anything newer than that then you want https://launchpad.net/ubuntu/+source/glibc instead
<r1nuz> ah good to know, still on 14.04 for this machine
<ShalokShalom_> hi there :)
<ShalokShalom_> is it true, that snappy is something like the Google Play Store?
<ShalokShalom_> no mirrors anymore?
<ShalokShalom_> no forks?
<teward> ShalokShalom: https://developer.ubuntu.com/en/snappy/#tour <-- start here?
<teward> !crosspost | ShalokShalom
<ubottu> ShalokShalom: Please don't ask the same question in multiple Ubuntu channels at the same time. Many helpers are in more than one channel and it's not fair to them or the other people seeking support.
<ShalokShalom> i post in each related room
<ShalokShalom> some people are just in one room and i aim to reach them as well
<teward> it's better to pick one room, ask, and if nobody answers in 15 minutes, try another one.
<teward> rather than just post in every room at once
<ShalokShalom> teward: why do you link me a post, which doesnt answer my questions?
<ShalokShalom> this page shows only the pros
<Umeaboy> Hi!
<Umeaboy> I keep forgetting the answer, the installer terminal output can be translated WHERE?
<Umeaboy> The terminal like window that appears when you click the arrow when the installation starts.
<Umeaboy> I hope someone knows what I mean.
<Umeaboy> I want to translate it more.
<Umeaboy> I searched for bash, but that seems to be fully translated now.
<Umeaboy> Should I check with ubiquity?
<infinity> Umeaboy: That output is intentionally not translated so that bug reports are readable by the developers.
<Umeaboy> OK.
<Umeaboy> infinity: What about when you install updates in the terminal window then?
<cyphermox> Umeaboy: it can't be translated anywhere special, that's just the output from whatever gets run as part of the install, mostly debug information for the developers as infinity pointed out
<cyphermox> you'll see some pieces *are* translated, those are the ones that would be translated on the installed system, from commands an user would run and care about
<cyphermox> ie. "Installing $package" or "Preparing to unpack $package"
<cyphermox> we translate the "high level" messages that show just above the terminal window so users still know what is happening
<Umeaboy> OK.
<Umeaboy> cyphermox: What parts of Ubuntu are need to be more translated? I wish launchpad only would show me the stuff that needs to be translated and hide thoose that are finished.
<Umeaboy> It currently can't.
<Umeaboy> At least I haven't found a way to do so.
<cyphermox> I don't know off hand. You would have to look at https://translations.launchpad.net/ubuntu/ which will display the languages your launchpad page says you know, and then click on a langauge, that will show all the different bits and pieces
<cyphermox> from there you dig in in the fourth column which is "untranslated", sometimes there are numbers there
<cyphermox> for example, if you scroll to the bottom of https://translations.launchpad.net/ubuntu/xenial/+lang/es
<cyphermox> there are four untranslated strings for gnome-software and also four for nm-applet
<cyphermox> we're past the translation deadlines though, so your work may only go in later
<Umeaboy> cyphermox: OK so Xenial is about to be released now?
<dax> thursday
#ubuntu-devel 2016-04-17
<Umeaboy> OK
<Umeaboy> What's the standard kernel installed on Xenial atm?
<Umeaboy> 4.4.5?
<dax> linux-image-4.4.0-18-generic
<Umeaboy> dax: Hope fully that'll solve my nouveau issue forever.
<Umeaboy> I have to use a workaround sometimes.
<LocutusOfBorg> can any core-dev please retry numpy/emcee numpy/sunpy testsuite?
<LocutusOfBorg> emcee is dinstalling right now
<ginggs> LocutusOfBorg: retrying
<LocutusOfBorg> ginggs, emcee needs a little more time I think
<LocutusOfBorg> but sunpy is good
<ginggs> LocutusOfBorg: rmadison python-emcee now shows 2.1.0-5 in xenial-proposed, retrying again
<LocutusOfBorg> ginggs, can you please also try s390x aplpy?
<LocutusOfBorg> not sure what went wrong
<LocutusOfBorg> BTW emcee migrating shortly to release
<ginggs> LocutusOfBorg:  aplypy retrying. i'm going to have to wait until emcee has migrated to release and try again
<LocutusOfBorg> yes, sure, I was just saying that the testsuite is fixed, so lets see aplpy
<LocutusOfBorg> emcee accepted, in a few minutes it should be good
<LocutusOfBorg> thanks
<LocutusOfBorg> PASS!
<LocutusOfBorg> it should be good to retry now ginggs
<ginggs> not yet, rmadison still showing 2.1.0-5 in xenial-proposed
<LocutusOfBorg> strange
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/emcee I see it in release since 6 minutes
<LocutusOfBorg> anyhow, when you are good :)
<LocutusOfBorg> I really want to see it migrate :D
<ginggs> rmadison says go go go
<LocutusOfBorg> :)
<LocutusOfBorg> good rmadison is good
<LocutusOfBorg> s390x is green, but I don't see the other tests
<LocutusOfBorg> amd64 is good
<LocutusOfBorg> ppc64el too :)
<ginggs> LocutusOfBorg: python-numpy = valid candidate
<LocutusOfBorg> yeah!
<LocutusOfBorg> :)
<LocutusOfBorg> thanks
<voldyman> so today i rebooted my laptop into windows 10, the dell touchpad utility allowed me to configure multitouch gestures like the mac, if i were to implement this for linux or ubuntu specifically how would i go about that?
<voldyman> can this be done in userspace?
<nikow_> Hello developers. Some packages in the Ubuntu are pretty outdated. One of them is zpaq. I think, it will be easy to keep it updated, but i need to know how to make packages. Will i find all needed informations about making own packages on http://packaging.ubuntu.com/ or i need look in some other sources too, because for example, http://packaging.ubuntu.com/ is outdated or something?
<ogra_> infinity, hmm, is it normal that there is no udev in the ubuntu-core tarballs ?
<ogra_> (not snappy ... the minimal rootfs)
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily/current/xenial-core-armhf.manifest onyl shows libudev
<flexiondotorg> ANyone here I can discuss a release critical issue for Ubuntu MATE?
<flexiondotorg> We have a proposed fixed, I nned someone who understand grub better than I do to help determine if the fix is sensible.
<flexiondotorg> https://bugs.launchpad.net/ubuntu-mate/+bug/1571242
<ubottu> Launchpad bug 1571242 in ubuntu-mate "Ubutnu MATE 16.04 Grub Install Fails in UEFI Mode" [Undecided,New]
<infinity> ogra_: Yes.
<ogra_> k
<infinity> pitti: Reverted your snapd/ppc64el hint in favour of fixing powerpc-utils instead. :P
<doko> fixed libsecret ftbfs on s390x, got new ones on amd64 and i386 :-/
<doko> amd64 succeeded. so retry i386 until it succeeds ...
<YagoGG> I would like to contribute this summer, but right now my C/C++ knowledge is quite limited. Which reference/books are recommended to get a good understanding of C and/or C++, if you already have programming experience with other languages?
<psusi> can anyone familiar with my work over the years sponsor my application for core-devel? https://wiki.ubuntu.com/PhillipSusi/DeveloperApplication2
<doko> pitti, please have a look at the cantor autopkg test failures
#ubuntu-devel 2017-04-10
<mwhudson> i presume it's more or less standard policy that tzdata changes end up getting SRUed?
<Unit193> Pretty normal.
<Laney> zul: Your neutron is still failing tests.
<tsdgeos> was a pleasure working for Canonical! /me waves
<bdmurray> barry: What did you say about the pyclean package install failure issue?
<barry> bdmurray: it just looks like pyclean is being run by python3 which makes no sense given that py3clean should be run by python3
<bdmurray> barry: so presumably a local configuration issue?
<barry> bdmurray: my guess is that this is another case of someone pointing /usr/bin/python to /usr/bin/python3
<barry> which no one should do
<dobey> or if you're going to do it, you should at least remove all the python2 stuff, and pin those packages so they can't be installed again
<bdmurray> barry: Maybe we should check for that in apport?
<barry> bdmurray: that would actually be very helpful for debugging these cases because it seems like it might not be an uncommon thing for people to do, even though they have to manually toggle the symlink
<bdmurray> barry: bug 1681528 if you are interested
<ubottu> bug 1681528 in apport (Ubuntu) "Include information about python versions" [Undecided,New] https://launchpad.net/bugs/1681528
<barry> bdmurray: thanks
 * xnox feels kind of bad for flying united
 * xnox hopes the fares will go down even further
<ogra_> wel, according to some news sites you might need to use ships to leave your country after brexit :)
<jackpot51> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1681566
<ubottu> Launchpad bug 1681566 in update-manager (Ubuntu) "nvidia-375 DKMS module not recompiled on upgrade to 17.04" [Undecided,New]
<jackpot51> Updating from 16.10 to 17.04 is broken on NVIDIA systems
<bdmurray> could you add your upgrade log files found in /var/log/dist-upgrade?
<jackpot51> Will do
<jackpot51> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1681566/+attachment/4859865/+files/dist-upgrade.tar.gz
<ubottu> Launchpad bug 1681566 in ubuntu-release-upgrader (Ubuntu) "nvidia-375 DKMS module not recompiled on upgrade to 17.04" [Undecided,Confirmed]
<jackpot51> bdmurray: Maybe it should be moved to nvidia-graphics-drivers-375?
<bdmurray> jackpot51: I found something else suspicious
<jackpot51> bdmurray: What is it?
<bdmurray> jackpot51: Do you know what the system76-driver-nvidia package does?
<dmj_s76> Why yes!
<dmj_s76> bdmurray: It just depends on nvidia-375 and ubuntu-driver-common.  It also installs some xorg quirks to handle a few specific gpu/display combinations.
<bdmurray> So in apt-term.log we can see dkms building the driver for the 4.8 kernel - around line 4100
<jackpot51> Right. It does not trigger for 4.10
<jackpot51> On line 4928, it should have run
<jackpot51> And 5256
<bdmurray> 4928? Mine only goes to 10 er 4823
<dmj_s76> Line 5450 shows it loading nvidia dkms modules for 4.8
<jackpot51> Oh, sorry. There are \r's that are counted as newlines
<dmj_s76> Line 5450 -> 4141
<bdmurray> The suspicious thing I saw was in main.log re nvidiaUpdate() and "no old nvidia driver installed" but that probably isn't causing this
<jackpot51> I wonder where that comes from
<bdmurray> ubuntu-release-upgrader's DistUpgradeCache.py
<bdmurray> It looks like its for transitioning from different driver version numbers, but I'm guessing a bit.
<bdmurray> Regardless ubuntu-drivers-obsolete.pkgs seems a bit old to me
<jackpot51> bdmurray: Any ideas on how to fix this?
<bdmurray> jackpot51: Could you test w/o the system76 ppa?
<jackpot51> Sure thing bdmurray
<bdmurray> jackpot51: thanks!
<Zta> I'm trying to build a package from some random app. I want to properly fill in the Depends: section of my DEBIAN/control file.  Is there a tool for this? I mean something that analyses (ldd) the binary and looks up the epoch version?
<Zta> So that given a binary I get "Depends: liballegro4.4, libc6 (>= 2.14), libgcc1 (>= 1:3.0), libgif7 (>= 5.1), libjpeg8 (>= 8c)"
<Zta> I've scripted it in bash for now, but it's not pretty
<tarpman> Zta: sounds like you might be working one or two levels too low. the stuff that goes in the binary package (DEBIAN/ and such) is normally auto-generated by the dpkg-dev tools (dpkg-gencontrol and friends). the specific tool you're looking for is called dpkg-shlibdeps. at a higher level, most packages use debhelper to orchestrate the build. start here: https://www.debian.org/doc/manuals/maint-guide/
<Zta> Thanks!
<Zta> I'll look into this tomorrow.
<cardboard64> my touchpad stops working after some time on 17.04
<cardboard64> how can I troubleshoot that?
#ubuntu-devel 2017-04-11
<mwhudson> sigh i should just always pass -sa to dpkg-buildpackage, at least when i have a fast connection on hand
<Unit193> I started doing  debuild -tc -sa  a bit ago too...  Added it to pbuilderrc.
<mwhudson> eh i think i ~always pass -S too, so -tc wouldn't get me much?
<mwhudson> building is for chroots
<Unit193> Yeah, but I still do it. >_>
<mwhudson> heh
<cfoch-always> hi
<cfoch-always> I read that Ubuntu will have GNOME by default
<cfoch-always> I contribute to GNOME
<cfoch-always> but I suppose that there must be some modifications of GNOME that are particular to Ubuntu
<cfoch-always> how can I contribute in those parts?
<TheMuso> cfoch-always: I don't think any decisions have been made along those lines yet.
<mase_wk_> lo all. I have posted a message in #ubuntu-packaging but haven't had any reponse. Are packaging questions welcome in this channel ?
<sarnold> yes
<Unit193> sarnold: If I wanted to change /etc/dpkg/origins/default (a symlink, not in alternatives) to something else without doing something gross, what'd be the best way?
<sarnold> Unit193: it looks like this is the thing you've got ot play nicely with http://sources.debian.net/src/base-files/9.9/debian/postinst.in/?hl=47#L47
<sarnold> Unit193: .. in which case it feels a bit like you can just drop in your own file, re-set the link, and probably things will continue to work
<Unit193> Right, but if one didn't want to "fork" base-files?  One would have to take into account removing of course.
<Unit193> sarnold: FWIW, I'm partially messing with you due to your answer.  But, might be looking to do something like this.
<sarnold> I think the postinst script is prepared to live happily alongside your own deb dropping in your own file
<Unit193> Was thinking of moving the file, and in the pre/postrm move it back.
<sarnold> I think it looks set up to just accept a new file there, with a new symlink, without hassle
<mase_wk_> i am trying to package a PHP pecl extension for 16.04.  previously i have used dh-make-pecl (i think) but that doesn't seem to be in the repos. Does anyone know if the process has changed or if there is a new tool or something that has replaced it ?
<Unit193> Just have to handle the case of removing package-2.
<tjaalton> mapreri: why did freeipa need a rebuild against ldns2?
<xnox> cjwatson, infinity told me to not be a jerk and to scootch over.
<xnox> and make room for you
<ackk> cyphermox, hi, I'm having an issue with the zesty ubuntu-gnome installer. on my desktop it freezes at some point with the initial spinner
<ackk> cyphermox, how can I debug what's blocking?
<cyphermox> ackk: what do you mean by "the initial spinner"? the plymouth splash screen?
<ackk> cyphermox, yes
<ackk> cyphermox, I've tried both the beta2 iso and the daily one. the former hang at gnome startup, the latter at the splash screen
<cyphermox> ackk: ok, did you file a bug? what hardware is that on?
<ackk> cyphermox, I didn't because I don't have any info. I was wondering if there was a way to get some debug info
<cyphermox> the best is to file a bug in the first place; use "ubuntu-bug ubiquity" to make sure it includes hardware info we'd need.
<ackk> cyphermox, ok. is lshw output enough?
<cyphermox> just from there I'd guess shell doesn't like your video hardware, and maybe it's something I could reproduce on my own laptop.
<cyphermox> ackk: sure..., but ubuntu-bug does the right thing for you.
<ackk> cyphermox, so I run it on yakkety and just mention the issue is with zesty?
<cyphermox> yeah, that will do
<cyphermox> I'm most interested in the hardware, what make/model especially, just in the off chance I have that at home.
<mapreri> tjaalton: my fault.  I scheduled rebuilds on all packages mentioned by britney, I forgot to remove the arch:all ones (and I should have probably actually checked they build-dep on the relevant -devâ¦)
<mapreri> so I triggered at least 2 useless builds, including that.
<ackk> cyphermox, does it start X or wayland by default?
<cyphermox> probably X, I suppose
<cyphermox> jbicha: ^
<cyphermox> not that it would matter much, a bug is a bug
<jbicha> the installer does not use Wayland
<ackk> cyphermox, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1681846 FTR
<ubottu> Launchpad bug 1681846 in ubiquity (Ubuntu) "Zesty Ubuntu-GNOME Installer hangs at plymouth splash" [Undecided,New]
<cyphermox> thanks
<ackk> ty for the info
<tjaalton> mapreri: ok, no prob
<xnox> jamespage, i think https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1681470 is a cloudarchive backport bug. Is there a specific way to file cloudarchive bugs?
<ubottu> Error: Could not gather data from Launchpad for bug #1681470 (https://launchpad.net/bugs/1681470). The error has been logged
<xnox> https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1681470
<jamespage> xnox: https://bugs.launchpad.net/cloud-archive
<xnox> jamespage, tah.
<jamespage> yw
<infinity> slangasek, kees, stgraber: Vote we skip the TB meeting today because release week and other drama.
<stgraber> infinity: fine with me
<slangasek> infinity: ok
<rbasak> infinity: fancy doing my DMB->TB tasks then?
<slangasek> infinity, kees, stgraber: updated on the wiki
<rbasak> You (the TB) missed an outstanding one last week, so one person has been waiting a while.
<rbasak> bug 1674440
<ubottu> bug 1674440 in ubuntu-community "[TB/DMB] ACL for ~ubuntu-sru-developers" [Undecided,New] https://launchpad.net/bugs/1674440
<slangasek> rbasak: infinity is release managing in London today, so probably not him
<rbasak> Ah, I didn't realise there was a sprint.
<jdstrand> tyhicks: hey, are you planning any apparmor uploads for zesty?
<tyhicks> jdstrand: no, I don't believe so
<jdstrand> tyhicks: I was going to fix aa-notify and verify the wayland abstraction. is there anything else you'd like incorporated in that upload?
<tyhicks> jdstrand: I can't think of anything - thanks for asking!
<jdstrand> np
<iulian> rbasak: Thanks!
<rbasak> stgraber: would you be able to sort out bug 1674440 please?
<ubottu> bug 1674440 in ubuntu-community "[TB/DMB] ACL for ~ubuntu-sru-developers" [Undecided,New] https://launchpad.net/bugs/1674440
<rbasak> We've been waiting a while - it was missed at the last TB meeting.
<nacc> rbasak: triaging a mysql 5.7 upgrade failure in #ubuntu; why does the postinst not capture (at least) the output in run_init_sql and display it in case it fails?
<nacc> rbasak: as that's the failing step here
<nacc> or at least say "mysqld failed to start" ?
 * nacc thinks anytime a user ends up seeing only a dpkg returned 1 message and the log has nothing, there is something to improve :(
<rbasak> nacc: we usually get fairly descriptive things in bug reports now. So I'm not sure what's missing in that case.
<rbasak> Could it be a really old installation that doesn't write error logs at all?
<nacc> rbasak: i'm not sure, they said they were on 16.04 and the `apt-get upgrade` just ran recently
<rbasak> We fixed that an LTS or two ago, but users may not have picked up the conffile update.
<rbasak> /var/log/mysql/error.log should have the details
<rbasak> nacc: what was the dpkg output?
<nacc> http://paste.ubuntu.com/24362260/
<nacc> well taht was the first output
<nacc> we got to this: http://paste.ubuntu.com/24362788/
<nacc> and now we're asking them to hack the postinst a bit to not /dev/null that run
<nacc> rbasak: http://paste.ubuntu.com/24362893/
<nacc> it seems like mysqld is not starting properly
<rbasak> That's odd.
<rbasak> Skuggen: ^
<rbasak> nacc: anything in /var/log/mysql/error.log?
<rbasak> Is that file being touched?
<nacc> oh right, let me ask
<nacc> rbasak: "Fatal error: mysql.user table is damaged. Please run mysql_upgrade."
<rbasak> We should perhaps capture the log and print it on failure in this case.
<rbasak> I'd like Skuggen's input, but in the meantime, a bug report is welcome.
<nacc> rbasak: i'll ask them to file
<rbasak> Thanks!
<rbasak> A bug for the lack of useful error message of course.
<rbasak> I don't know that there is any other bug (yet).
<nacc> yeah
<tsimonq2> cyphermox: Hi :)
<cyphermox> hey
<tsimonq2> cyphermox: You around to do this debugging, or later?
<cyphermox> tsimonq2: so, could you file a new bug, add "systemd-resolve --status" and try 'sudo systemctl stop systemd-resolved' and finally running 'SYSTEMD_LOG_LEVEL=debug /usr/sbin/systemd-resolved > /tmp/resolved.log 2>&1' and trying to resolve something again?
<cyphermox> these command lines are approximate from memory, maybe there's not quite right
<cyphermox> wow, my grammar is bad today
<bdmurray> super bad
<tsimonq2> cyphermox: But at the moment I overwrote my /etc/resolv.conf to make this work.
<tsimonq2> cyphermox: Do I need a fresh file to do this on?
<bdmurray> nacc: I got a better stacktrace in bug 1667892. Should I flip it back to New?
<ubottu> bug 1667892 in apache2 (Ubuntu) "apache2 crashed with SIGSEGV in <signal handler called>()" [Medium,Invalid] https://launchpad.net/bugs/1667892
<nacc> bdmurray: yeah, sounds right
<tsimonq2> cyphermox: You saw my above ping, right? :)
<cyphermox> tsimonq2: yeah, I don't think you need to touch resolv.conf at all there
<tsimonq2> cyphermox: Ok, I'll continue now :)
<cyphermox> if you use the dig command to issue DNS requests you can point it right to 127.0.0.53
<cyphermox> ie.
<cyphermox> dig www.google.com @127.0.0.53
<tsimonq2> cyphermox: What should I title the bug?
<tsimonq2> Ok
<tsimonq2> Ok wat >__< -- this is weirdf
<tsimonq2> *weird
<tsimonq2> It works fine now...
<tsimonq2> O__o
<tsimonq2> Oh lol
<tsimonq2> cyphermox: bash: /usr/sbin/systemd-resolved: No such file or directory
<tsimonq2> Where is it really?
<cyphermox> oh, right
<sarnold> /lib/systemd/systemd-resolved ?
<Unit193> Yes.
<tsimonq2> sarnold: Trying.
<cyphermox> /lib/systemd/systemd-resolved
<cyphermox> silly place to put a binary.
<Unit193> > systemd
<cyphermox> Unit193: yeah, just need to retrain to not always /usr/sbin.
<tsimonq2> But... there's nothing in the log and I can dig everything fine?
<cyphermox> nothing in the log?
<tsimonq2> Plus, I'm talking to you now, soo
<tsimonq2> Nope, nada
<tsimonq2> $ cat /tmp/resolved.log
<tsimonq2> simon@semantic ~ $
<cyphermox> hold on, let me try this here.
<tsimonq2> Ok.
<tsimonq2> systemd is really "fun," at least this part of it is ^__^
<cyphermox> you're missing sudo
<tsimonq2> Gah, that would explain it...
<cyphermox> but not only that
<tsimonq2> Oh?
<cyphermox> arf
<cyphermox> sudo SYSTEMD_LOG_LEVEL=debug SYSTEMD_LOG_TARGET=console /lib/systemd/systemd-resolved 2>/tmp/resolved.log
<cyphermox> because just honoring redirects would be too easy.
#ubuntu-devel 2017-04-12
<tsimonq2> cyphermox: Whoops, got carried away doing something else, running that now.
<tsimonq2> THERE we go.
 * tsimonq2 digs
<tsimonq2> cyphermox: Want to see this log?
<tsimonq2> Because like I said, acting normally.
<cyphermox> tsimonq2: not especially
<cyphermox> tsimonq2: just kidding, yes please
<cyphermox> send it via email or put it in a bug
<cyphermox> there might be some gems there; probably something about DNSSEC not being happy
<tsimonq2> cyphermox: lol ok
<tsimonq2> cyphermox: You has mail.
<cyphermox> what did you dig for, just so I know where to look?
<tsimonq2> cyphermox: www.google.com
<cyphermox> tsimonq2: I can't see it here; could you please start again but this time query for 'www.perdu.com' ?
<tsimonq2> cyphermox: Ok.
<cyphermox> that's a test page that is easily recognizable in text; google turns up way too often on its own in normal use in logs like this
<cyphermox> sorry for the trouble
<tsimonq2> It's totally fine, I'm sorry that I'm putting you though log searching >__<
<tsimonq2> cyphermox: You want the full log or just the excerpt from digging?
<cyphermox> as little as possible is best, but it's easy to miss some important bits, so if you sent the entire thing I'll manage
<cyphermox> that's where knowing what to search for exactly helps a lot
<tsimonq2> Ok.
<tsimonq2> cyphermox: Get my email?
<cyphermox> yup
<tsimonq2> Yay ok
<cyphermox> and it successfully returned 208.97.177.124 ?
<tsimonq2> Yup
<cyphermox> so firefox should also be happy if resolv.conf was set to point to 127.0.0.53
<tsimonq2> ;; ANSWER SECTION:
<tsimonq2> www.perdu.com.          13909   IN      A       208.97.177.124
<cyphermox> (or libnss-resolved is installed and nsswitch points to the right place)
<cyphermox> tsimonq2: nothing looks out of place
<tsimonq2> cyphermox: That's super weird. If you give me a sec, I can repeat with a fresh reboot when it's an issue.
<cyphermox> tsimonq2: when you get the issue again, try 'systemd-resolve $url' with the same thing you tried to open (the hostname, anyway)
<cyphermox> if that succeeds, then try again with something else like www.verisign.com (which I expect should be DNSSEC capable, but you don't go hit every day)
<cyphermox> and put all of this in a bug... I don't see what's up right now
<tsimonq2> cyphermox: Ok.
 * tsimonq2 is on phone
<tsimonq2> cyphermox: Alright, reproducable now. Can't systemd-resolve either vps.tsimonq2.net or www.verisign.com
<tsimonq2> Wait, wrong wording there. It's a bug now...
<cyphermox> the exact answer to systemd-resolve is important
<cyphermox> but yeah, they should probably resolve, it's just that /how/ they don't tells us what's broken
<tsimonq2> Got it.
<cyphermox> and I'm sure it's still DNSSEC, it's the only thing that is consistently horrible
<tsimonq2> Going though the same steps to collect logs as you told me before.
<tsimonq2> cyphermox: Sent you one last set of logs. It would be wonderful if you could tell me what would be relevant to put in the bug report, but I totally understand if you don't have the time tonight.
<cyphermox> tsimonq2: that is a representative sample
<cyphermox> the key here is Timeout, and it's not something I've seen before
<tsimonq2> cyphermox: Oooooh ok
<tsimonq2> cyphermox: So what about my system could be Special?
<cyphermox> no idea
<cyphermox> timeouts are most often an environment issue, but it could also not be.
<tsimonq2> Ok.
<Belldandu> (Belldandu) So i would like to submit a dependency fix for postfixadmin but i'm not even able to branch of the code in order to propose a merge.  This problem hasn't been fixed for 3 years from trusty all the way to the latest ubuntu https://bugs.launchpad.net/ubuntu/+source/postfixadmin/+bug/1321955
<ubottu> Launchpad bug 1321955 in postfixadmin (Ubuntu) "postfixadmin dependencies not well defined (requires mysql-server or postgresql, removes MariaDB)" [Undecided,In progress]
<Belldandu> The fix is so miniscule its depressing that it hasnt been fixed
<Belldandu> Change debconf depency line mysql-client | pgsql-client to mysql-client | pgswl-client | mariadb-client
<Belldandu> pgsql-client*
<infinity> Belldandu: Looks already fixed in zesty
<Belldandu> in zesty and none of the other branches. Not everyone is going to use zesty
<Belldandu> Im using xenial for instance
<infinity> Belldandu: Sure.  So just attach the debian/control diff and subscribe ubuntu-sponsors.
<infinity> Belldandu: For xenial and yakkety.   And maybe backport the fix to trusty too, if you're feeling keen.
<Belldandu> Ok
<infinity> Looks like trusty also needs this fix to close the original bug:
<infinity>   * [76ef] change recommends of postgresql-server (not existing) to postgresql.
<infinity> While xenial and yakkety only need:
<infinity>   * update dependencies to allow mariadb as database (closes: #778794)
<infinity> Belldandu: As for "branching for an MP", UDD is long dead.  Just "pull-lp-source postfixadmin $release" and hack on the package that way.
<Belldandu> Yeah and ok
<onthewings> hey, I want to sign the contributor agreement. It asks me for a "Project contact (Please add the Canonical Project Manager or contact)". What can I put there?
<onthewings> I just want to send a PR to https://github.com/snapcore/snapcraft
<infinity> onthewings: https://www.canonical.com/projects/directory lists the contacts for each CLA-using project.
<sarnold> wow, I've never seen that before
<Unit193> infinity: A while ago we talked about 'automatic' backports of geoip-database, anything new on that?  Also was starting to wonder about publicsuffix too.
<infinity> Unit193: I doubt I used the word automatic. ;)
<Unit193> You did not, it's also in 'quotes'!  Not sure to call it a backport or SRU, it's rather neither.
<infinity> Unit193: Well, it's an SRU by definition.  It just might need different rules, like tzdata and a few others.
<Unit193> infinity: Right, and you had said something about it being discussed, considered, or thereabouts.
<infinity> Unit193: I suspect that we then failed to discuss it.  And for a long while, given I don't really remember the original. ;)
<infinity> Unit193: Step 1 would be to find someone (or a group of someones) willing to take responsiblity for said updates.  From there, working up a sane policy and making it happen shouldn't be too much effort.
<Unit193> Ah, alright.  I've been using backportpackage on it for a few releases now, so doesn't directly affect me.  But that's not really a solution.
<infinity> It's a solution, just not the most community-friendly one. :P
<infinity> (And we're all guilty of it... The joy of open source is being able to fix things locally, the burden/responsibility is that we shouldn't be fixing locally because that's selfish)
<Unit193> It's one for meeeee. ;D
<infinity> Which I totally do far too often.
<infinity> And tend to forget and discover 2 years later on an LTS upgrade when something breaks and I go "oh, huh, I never uploaded that?"
<tsimonq2> Like that sbuild thing. :P
<Unit193> 'virtualbox-ext-pack', 'youtube-dl', 'geoip-database' are a few, but then 'whois', 'publicsuffix' and a few others are starting to get the same treatment. :3
<tsimonq2> *I* am even guilty of *that* :P
<infinity> Unit193: whois is a bad example, unless someone breaks the data out from the code.
<infinity> Unit193: tzdata is in a good place there, as upstream tries very hard to decouple data and code, and we just update the data.
<Unit193> infinity: Perhaps yes, I haven't been backporting that.  And yeah, that's one db that does get updated, the mobile data does too IIRC.
<infinity> wireless-crda is on the list, yeah.
<infinity> The kernel team was meant to start loving that, but I think we fell down in the final steps of JFDIing that.
<infinity> Err, wireless-regdb, I mean.
<infinity> Whatever.  "the wireless thing".
<Unit193> usb-modeswitch-data?  mobile-broadband-provider-info?  I dunno, one of those.
<infinity> Unit193: If you have a certain passionate interest in this, I suggest that post-release (I'm only awake at 4am because release week, so clearly a bit too busy to multitask on this), you bring it up again, with a broad enough audience to also work on getting volunteers to own the various updates.
<infinity> Perhaps a nice bullet list of "* package : owner", and fill in the blanks until it looks less unpleasant.
<Unit193> I certainly have a vested interest in this, though not entirely sure I want to drive it as my current solution is much easier without outside help. :3
<infinity> The only ones I know we do reasonably well at are "tzdata: glibc maintainers" and "pciutils: kernel team"
<tsimonq2> infinity: Side note, I thought you were in Canada? Where are you that it's 4 AM?
<infinity> tsimonq2: London.
<tsimonq2> infinity: Fancy. You move there or just there for now?
<infinity> Just sprinting.
<tsimonq2> Ah, gotcha.
<infinity> I'd move here if I could afford it.
<tsimonq2> It *does* seem like a wonderful place.
<infinity> But my Calgary flat would cost about 3M pounds in a similar size and location here.
<infinity> Which is a bit out of my range.
<tsimonq2> Eeek. Yeah.
<Unit193> infinity: I could bring it up, but guessing it'd have to be on -discuss.
<infinity> Right, (hopefully actually final) rebuilds kicked off.  I need to get some sleep before morning attacks.
<tsimonq2> Sleep well infinity.
<Unit193> G'night.
<stgraber> infinity: anything that needs babysitting? I'll be up for another 2-3 hours I expect
<infinity> Unit193: Yeah.  I do a crap job of reading devel/devel-discuss, so if you do bring it up and want my input in the thread, please explicitly CC me.
<infinity> stgraber: I guess just make sure none of the builds go missing?  Should be 20170412 spitting out for $world over the next couple of hours.
<stgraber> infinity: ok, will check the tracker before I go to bed and track down anything that didn't update
<Unit193> infinity: It's email, so it may take me a few months to get to it, but I'll put it on the todo. :P
<infinity> Unit193: Heh.
<infinity> stgraber: Ta.
<Unit193> (I'm not kidding, sadly.)  infinity: Thanks!
<infinity> Unit193: I didn't assume you were.  My INBOX has unread messages older than some of our contributors.
<infinity> Unit193: And I don't mean "older than their contributions", I literally mean older than the people.
<Unit193> Haha! \o/
 * infinity -> bed.
<Unit193> So I've got time.
<sarnold> better get started on that email a dozen years ago if you want in on his todo list :)
<Unit193> I've actually got a message from 3 years ago I haven't responded to yet, and gotta do something about a message from 07/09/2016 >_>
<nacc> Belldandu: ping
<cyphermox> jbicha: looks like a fresh install works with shell here; so this smells like a packaging issue
<cyphermox> gdm3 starts fine at boot, so does shell, etc.
<cyphermox> I'm going to bed now but we could look at this some more when I'm back to debug it.
<sil2100> seb128: hey! Just in case - I poked around a bit and got the zesty language stats exported, also pushed a change to l-o-m to now look for them in the proper location
<sil2100> seb128: i.e. http://people.canonical.com/~people-l10n/data/ubuntu-l10n/
<sil2100> seb128: (for future langpack generation)
<seb128> sil2100, nice, thanks
<seb128> is that a new teamÂ¿
<seb128> ?
<sil2100> seb128: not new new, dpm requested its creation when he was leaving
<sil2100> So it was around for a bit but no one actually informed us I guess
<ginggs> Mirv, is there something that should ensure that appmenu-qt5 is removed?
<infinity> ginggs: It's very not removed here.  Should it be?
<infinity> Oh, I see, it's not in zesty anymore.
<ginggs> it seems to cause problems if it is not removed, see LP: #1680943
<ubottu> Launchpad bug 1680943 in telegram-desktop (Ubuntu) "telegram-desktop's window never shows up (differently from Debian's sid)" [Undecided,Confirmed] https://launchpad.net/bugs/1680943
<infinity> ginggs: Fun.
<infinity> ginggs: So, a do-release-upgrade will probably offer to remove it.  But all of us who have been tracking zesty will still have it installed.
<infinity> ginggs: Ideally, some other Qt component should Conflict/Replace it.
<infinity> (But not going to let that land between now and release either)
<Mirv> ginggs: it could be useful, yes, now that replacing functionality is in Qt 5.7
<Zta> How does one create a .deb out of, say, nothing? I do have some source code, but none of the tools I use work. All tools and tutorials require some weird structure beforehand.
<nacc> Zta: do you want a 'good' .deb or just something 'good enough' ?
<jtaylor> Zta: dh_make creates that structure
<nacc> Zta: like something you can submit for inclusion or put in a ppa?
<nacc> Zta: if you just need something locally, you can use checkinstall
<Zta> nacc: Let's start with something 'good enough'.
<Zta> Actually, I'm trying to make a package out of this: https://github.com/aseprite/aseprite/blob/master/INSTALL.md#platforms
<nacc> Zta: but for creating a true source package, you'll need to go down the path of what jtaylor suggested
<Zta> It uses ninja for build system.  This might be what's confusing the debhelpers?
<jtaylor> via cmake?
<nacc> Zta: have no idea what your d/rules says, etc
<cjwatson> At worst, that's just a matter of a couple of overrides.
<nacc> Zta: maybe just make a snap
<Zta> dh_make fails
<cjwatson> debhelper can work with anything.
<cjwatson> You'll probably do best if you pastebin terminal transcripts showing what's going wrong
<Zta> yes sir, hold on
<Zta> https://pastebin.com/zz4wmrjt
<Zta> oh wait, -p aseprite_123 does something good
<cjwatson> cd ..; mv aseprite aseprite-123; cd -; dh_make
<cjwatson> or similar
<cjwatson> that's what it's telling you
<cjwatson> but yes, -p aseprite_123 would work too
<cjwatson> (and is probably better, actually, so do that)
<nacc> (note the _ vs. - )
<Zta> nacc: exactly, I just noticed that now.  That's been bugging me for hours now =)
<nacc> Zta: yeah, it's a bit hard to detect that difference if you aren't looking for it :)
<Zta> Is there a tool to edit the debian/control file programmatically? (besides sed =)
<nacc> Zta: vi ?
<nacc> Zta: not sure what you mean, i guess :)
<nacc> Zta: it's just a text file, i mean
<Zta> I mean now dh_make generated a neat skeleton. Now I want to edit some of the fields like dh_editcontrol --homepage "http://aseprite.org" --section "universe/graphics"
<nacc> Zta: right, just use an editor
<Zta> I'm trying to script this, so vi isn't an option =).  Right, sed it is.
<nacc> Zta: i don't believe there is a helper command to edit d/control -- seems like overkill to me :)
<nacc> Zta: why are you scripting it?
<nacc> Zta: once you build a source package, you don't need to do it again
<nacc> Zta: alternatively, like i said, you coudl snap it and it might be a bit faster
<Zta> Yes I do, because it source code gets updated.
<nacc> Zta: uscan/uupdate handle tht
<nacc> Zta: the packaging is distinct from the upstream
<cjwatson> debian/control usually doesn't change on every upstream change
<cjwatson> there is cme if you want to automate though
<nacc> Zta: given a good d/watch file
<nacc> cjwatson: interesting, i hadn't seen that before, thanks!
<cjwatson> (though personally I find cme way too complex and don't bother)
<Zta> Ideally, I create a cronjob that pulls, builds, and reinstalls.  Or a docker image that serves a PPA?
<nacc> Zta: right, that's a recipe in launchpad (I think)
<nacc> Zta:  a git recipe, in this case
<nacc> Zta: and you'd keep your debian/ in another repo (aiui) which just has the packaging stuff
<cjwatson> https://help.launchpad.net/Packaging/SourceBuilds
<nacc> Zta: and the two get combined (magic!) and your package builds
<nacc> Zta: but the point is debian/control doesn't really change on every upstream change (necessarily  at least) -- only if deps change or whatever. d/changelog will update with the new version
<cjwatson> and debian/changelog updates are scriptable using dch
<Zta> It's not my code, so I can't put it into Launchpad.
<Zta> Hm, I was expecting dh_make to generate a better Depends list.
<Zta> Look at this: https://pastebin.com/HY4Nmkkr
<nacc> uh
<nacc> i think you're missing something in all of this
<cjwatson> dh_make just generates a skeleton
<nacc> Zta: do you undrestand the difference between a source and binary package?
<Zta> This is where I actually started.  Then I came to the conclusion that he manual dependency lookup was ... wrong.  So I started looking at dh_make.  But that doesn't really seem to generate a complete Depends list.
<cjwatson> it's not expected to write your Depends for you
<nacc> Zta: dh_make sets up the skeleton of a source package for you, nothing else
<nacc> Zta: and it doesn't build anything (which is what generates thea ctual depends in the binary package)
<cjwatson> you should regard debian/ as a chunk of code that you need to maintain on an ongoing basis
<cjwatson> it is not a thing you should be trying to generate for each upstream commit you want to build
<nacc> Zta: iirc, launchpad can import a github repository
<cjwatson> and writing anything under DEBIAN/ by hand is a red flag that you are doing something fundamentally wrong
<Zta> cjwatson: The DEBIAN/ thing was from a tutorial. It could be outdated, I don't know. Is it better to write stuff in debian/ by hand?
<nacc> Zta: DEBIAN and debian are different
<cjwatson> dh_make should generate a thing that uses dh to do the build; when you build the binary packages, that'll end up calling dh_shlibdeps somewhere, and dh_shlibdeps substitutes package dependencies corresponding to your ELF dependencies where you write ${shlibs:Depends} in debian/control
<cjwatson> yes, debian/* should be written by hand (perhaps starting from a skeleton generated by something like dh_make)
<Zta> nacc: I won't do that.  The auther of this code doesn't want anyone to distribute it. It's open source, but you have to buy it or compile it *yourself*. That's the deal.
<cjwatson> DEBIAN/* should only be touched by tools called (eventually) from debian/rules, which is the entry point of the source package
<Zta> cjwatson: Makes sense.
<cjwatson> if you find any tutorial that recommends writing files in DEBIAN/* directly, throw it in the bin and look for a better tutorial
<Zta> Right.
<dobey> i bet that is an interestingly worded license agreement
<nacc> Zta: except you are breaking that rule by building packages at all then
<nacc> Zta: so screw that and just do it the easier way :)
<Zta> Ok, so I have a skeleton for my source package now.
<Zta> nacc: I think I'm allow to distribute my own build it to myself =)
<nacc> right, that's all the recipe would do too (just in a ppa)
<nacc> you can make the ppa private
<Zta> hmm
<cjwatson> nacc: that's a paid feature
<nacc> cjwatson: ah :(
<nacc> Zta: so nm :)
<cjwatson> much though I'm a Launchpad developer, I think getting into recipes for this is too much of a rat-hole for now
<nacc> cjwatson: you might be right
<Zta> =)
<cjwatson> and you have to write the packaging anyway
<dobey> i'm curious what software this is
<Zta> sprite editor
<nacc> Zta: ok, so you've got the skeleton, so now you need to modify d/ files
<Zta> Think GIMP for kids 8)
<Zta> GIMP for 8bit gamers
<nacc> Zta: this has some rough guidelines iirc, for dh_make workflow: https://www.debian.org/doc/manuals/maint-guide/first.en.html
<nacc> Zta: but once you do it once,  you don't throw it away
<nacc> Zta: you keep that as your source package and then do updates to it as needed
<Zta> It's the Depends section that made me look into this whole mess.  The script I pasted before actually create a package that Works On My Machine.
<nacc> Zta: right, but as cjwatson said, that script is bunk :)
<nacc> Zta: it seems to be pretending that debhelper doesn't exist to do all this for you (e.g. dh-shlibdeps)
<nacc> err, dh_shlibdeps
<cjwatson> so just looking at my packages, here's one that's a compromise between being so simple that it doesn't help you learn much, and far too complex: https://anonscm.debian.org/cgit/pkg-man-db/man-db.git/tree/debian
<cjwatson> debian/control has ${shlibs:Depends}, ${misc:Depends}, which are filled in by various debhelper tools, and also some manually inserted dependencies
<cjwatson> debian/rules has override_* targets in cases where the defaults don't work
<cjwatson> or a simpler case, https://anonscm.debian.org/cgit/users/cjwatson/dumpet.git/tree/debian
<cjwatson> the simplest possible cases can have a three-line debian/rules
<cjwatson> anyway, must get a train
<Zta> Take the A train.
<Zta> That debian/rules looks complex =\
<nacc> Zta: so d/rules can generally be left alone, it will just end up calling make (presuming that works) -- so i'd change that last, on some level
<Zta> Should I use some debhelper tool to issue the actual compiling? Or is it okay to do that myself and install the binaries in a package dir that's then wrapped up?
<dobey> debuild
<nacc> Zta: i would recommend using one of debuild, dpkg-buildpackage and sbuild. I find it easiest personally to generate a source packge with dpkg-buildpackage and then sbuild that (so i don't mess with my host system)
<Zta> I'd prefer not to mess with my host system.
<dobey> sbuild for sure
<nacc> Zta: yeah, so get your code in good shape
<dobey> but you still need to debuild -S to generate the source package on host
<nacc> yep
<dobey> or you can try to build the source pkg inside sbuild too, but it's a bit of a pain
<nacc> which is just (aiui), dpkg-buildpackage -S
<Zta> This doesn't fit well with this weird ninja build system.
<nacc> with a few extra commands
<nacc> Zta: what do you mean?
<Zta> My build instructions say: mkdir BUILD ; cd BUILD ; cmake -G Ninja ..    This will generate build files in ./ (being BUILD).   Then I should issue the actual build: ninja asprite
<nacc> ok, then add a build-depends on ninja-build and run that command in an appropriate override
<Zta> sounds easy
<Zta> how? =)
<dobey> well you likely don't have to use ninja, and debhelper already supports cmake natively
<jtaylor> cmake works out of the box with make too, if you don't need the extra speed debhelper defaults should be fine
<nacc> yeah i can't tell if you need ninja or not
<jtaylor> the ninja speed is not important for package builds anyway
<jtaylor> its more useful for partial rebuilds
<jtaylor> aka development
<nacc> i undrestand their instructions say to use it, but i'd try it wihtout and see what works
<nacc> my guess is `make install` will dtrt and ninja is purely there for speed
<Zta> Well, it seems I have to do something, because running plain dpkg-buildpackage fails: https://pastebin.com/dssCzckH
<nacc> Zta: well, as we said
<nacc> Zta: you want to use -S
<nacc> Zta: build a source package and then build the binary using sbuild or so
<Zta> sorry, I'm downing in info =)
<nacc> Zta: yes, there's a lot to take in
<dobey> nacc: well it will still fail with the same error
<dobey> nacc: since that's trying to build the source package first
<nacc> dobey: yeah, i hadn't looked at the details yet :)
<nacc> Zta: ok, so it ooks like dpkg-buildpackage is seeing local changes relative to the orig tarball you used
<Zta> I didn't use a tarball; i checkout out from git.
<nacc> Zta: that is, it looking at the contents of aseprite_1.2-dev-master-fece0cf.orig.tar.xz
<nacc> Zta: yes, that's not how deb building works
<Zta> urgh..
<nacc> Zta: in that, as on the debian guide linked earlier
<nacc> Zta: there is an orig tarball and a debian tarball used to build
 * nacc also reiterates that a snap would probably be way faster for this
<Zta> My original question: (18:43:33) Zta: How does one create a .deb out of, say, nothing? I do have some source code, but none of the tools I use work. All tools and tutorials require some weird structure beforehand.
<Zta> =)
<nacc> Zta: yep, did you read the debian packaging guide i linked?
<nacc> Zta: that gives you a lot of inofrmation, but i think it's necessary so you understand how building works
<Zta> I saw it mentiond a tar.gz a couple of times and assumed it wasn't meant for me, since I'm not in that situation. I really hoped it would be able to build off a directory, say and extracted tarball.
<nacc> Zta: where did ./aseprite_1.2-dev-master-fece0cf.tar.xz come form?
<nacc> *from
<nacc> Zta: no, that's not how building works
<Zta> I have no idea. For what I know it doesn't exist. I did define that name and version when running dh_make, though.
<nacc> look in the current directory
<Zta> no such file.
<Zta> Oh, there's one in ..
<nacc> ~/asperite-workdir/aseprite I guess
<nacc> ah yeah it'll be in ../ sorry
<Zta> Ok, so that's what took so long.  dh_make wrapped up the entire dir?  Ok, so I have a tarball.
<nacc> Zta: yes, see 'ACTIONS PERFORMED' in `man dh_make`
<Zta> Right.
<nacc> because non-native package building needs an orig tarball and a debian tarball
<Zta> Wait... I have my workdir.  Here I have aseprite/ which is cloned.  Should I run dh_make (ie. have my debian dir) in the workdir or in the aseprite dir?
<nacc> Zta: i don't know what you mean by "have my debian dir"
<nacc> Zta: dh_make is used to generate a debian/ directory
<Zta> that's the directory I mean.
<nacc> you would run it from aseprite/, afaict
<Zta> should it be workdir/debian/   or workdir/aseprite/debian/ ?
<Zta> ok
<Zta> so the latter
<Zta> And the tarball magically ends up in workdir.
<nacc> yes, because all the tooling needs it to be in ../ relative to where you run the build from
<nacc> (even for source package builds)
<nacc> Zta: so basically, what dh_make did was it tarred up the current directory as it was (since no -f was given) and put it in ../orig.tar.xz
<nacc> Zta: so that it can track what you change relative to the 'pristine' upstream
<Zta> yes
<nacc> and every change to the upstream source must be stored as a patch in the debian/patches directory (for quilt-based packages)
<nacc> and then your packaging decisions go in debian/ which will be tarred up by dpkg-buildpackage into ../debian.tar.xz
<Zta> But the upstream is already outdated because it has the skeleton debian/control file.
<nacc> upstream does *not* have a d/control file
<nacc> https://github.com/aseprite/aseprite
<nacc> no debian/ directory
<Zta> dh_make just created one
<nacc> dh_make did the tarring *before* creating debian
<Zta> oh
<nacc> as i said earlier
<nacc> or it excludes debian/ i'm not sure (effect is the same)
<Zta> It first compresses, then it generates.
<nacc> ok
<nacc> well, you can see in the log from dpkg-buildpackage (there's a file referenced) what the changes it is detecting are
<Zta> dh_make also won't execute if a debian/ dir or the ../tarball exists is seems =)
<nacc> well if ../tarball exists,  you should use -f
<nacc> and yeah, dh_make is for making a new skeleton
<nacc> doesn't make sense torun it if you have a debian/
<Zta> I deleted both so I could retry.
<Zta> Ah, dpkg-buildpackage -S fails because if signing: No secret key
<nacc> Zta: try
<nacc> dpkg-buildpackage -S -nc -d -uc -us
<nacc> the last two say don't sign
<nacc> -nc says don't clean (can be handy while you iterate)
<nacc> and -d says don't worry about builddeps here
<nacc> since you are (hopefully) going to use sbuild to build, and the builddeps will get satisfied there
<Zta> no errors, exit code 0. That must mean success.
<nacc> right so go into the parent directory
<nacc> you should see an appropriately named .dsc file
<nacc> and a _changes file, iirc
<Zta> yes
<nacc> Zta: then you can pass those to sbuild (after having set up a sbuild environment locally (see mk-sbuild)
<Zta> Do I need both mk-sbuild and sbuild?
<Zta> mk-sbuild is from ubuntu-dev-tools
<sarnold> mk-sbuild is by far the easiest way to make the schroots that sbuild will use
<nacc> yeah, that's what i was just checking on
<nacc> Zta: i would use mk-sbuild, just to be sure you do it right :)
<sarnold> have you seen this yet/ https://wiki.ubuntu.com/SimpleSbuild
<nacc> sarnold: thanks, was just pulling that up
<Zta> sudo apt install ubuntu-dev-tools --no-install-recommends  it is
<Zta> How much of those instructions on SimpleSbuild should I go though?
<Zta> I feel it's building an entire ubuntu distriution right now =)
<nacc> Zta: it is
<nacc> Zta: in a schroot
<nacc> that's how you build in an environment that doens't affect your host
<sarnold> .. and so your host environment doesn't affect your build :)
<sarnold> (of course the running kernel affects the build, but these day's that's usually not a big deal)
<nacc> sarnold: good point! :)
<Zta> ...Docker seems less intrusive
<nacc> docker and lxd can also be used, but they aren't so directly integrated
<nacc> meaning you have to wrap commands in commands to build in them, afaict
<Zta> Done building zesty-amd64!
<Zta> I'm on xenial, though.  Is that a problem? =\
<nacc> Zta: not necessarily
<nacc> Zta: so you need to have an sbuild environemnt suitable for building your package for the release you want to target
<nacc> Zta: so in you case, you probably wanted to run `mk-sbuild xenial` if you want a .deb for xenial
<Zta> The tutorial learned me a nice command: sg sbuild  I've been missing that some times.
<Zta> So I'm here and I ran this: ~/aseprite-workdir/aseprite$ sbuild -A -d xenial-amd64 --host ../*.dsc
<Zta> and I get: E: Failed to open build log /home/stephan/.ubuntu-sbuild/logs/aseprite_1.2-dev-master-fece0cf-1_../aseprite_1.2-dev-master-fece0cf-1.dsc-20170412-2102.build: No such file or directory
<sarnold> try mkdir -p /home/stephan/.ubuntu-sbuild/logs and try again?
<nacc> Zta: yeah, i think you're missing some .sbuildrc values
<nacc> Zta: this is what i use locally: http://paste.ubuntu.com/24369306/
<Zta> The dirs are all there, and that paste doesn't help. But that path in the error message looks bad with those ".." in the middle.  Did I execute toe sbuild properly?
<nacc> Zta: oh wait
<sarnold> oh I missed that entirely
<sarnold> that does smell funny
<nacc> Zta: um, i don' think --host on its own does anything
<nacc> Zta: and then you really don't want to use *.dsc
<nacc> well, it might work right now
<nacc> but eventually taht will be multiple dsc files
<Zta> ok
<nacc> can you try with the actual file name?
<Zta> I know it's a hack for now; I was lazy.  It seems to evaluate properly, but I'll try full name.  And exclude host.
<Zta> wow!
<Zta> It builds something.
<nacc> Zta: when it finishes, it should put a .deb in .ubuntu-sbuild if you've not set upa  .sbuildrc
<nacc> iirc
<Zta> Btw this is was "mk-sbuild xenial" ended by saying: "To BUILD for : sbuild -A -d xenial-amd64 --host  PACKAGE*.dsc", so it seems like there's a $host missing somewhere =)
<nacc> the last lines should say explicitly the name of the .deb
<nacc> Zta: right, you *can* pass --host
<nacc> but it's only useful for cross-building
<nacc> which i assuemd you weren't doing :)
<Zta> Correct =)
<Zta> Build failed, though: https://pastebin.com/KMQ2CVPq
<nacc> Zta: did you add cmake as a build-dep in d/control?
<Zta> mmmno
<nacc> Zta: right, now you're at the point where you need to flesh out the skeleton
<nacc> with the build-deps, possible binary package deps, rules overrides, etc
<nacc> Zta: bbiab -- but i think you can iterate from here
<nacc> Zta: make some changes in debian/, run dpkg-buildpackage -S -nc -d -uc -us, run sbuild on the dsc and get it to build :)
<Zta> I'll call it day
<Zta> Thanks for the help so far.  I'll be back for some more dh_pain soon =)
<Zta> ..wait what? http://stackoverflow.com/questions/32012811/how-to-build-a-deb-file-for-cmake-from-source  ... I better leave that where I found it.
<Zta> Right, I managed to add cmake to dependency, and I commented out something cmake related in the the skeleton d/rules.  Now cmake is installed, and the build is executed, but it still fails.  I feel I'm close, but I'll come back and finish the job some other time.
<nacc> Zta: sure, just ping me if you need help, and paste the logs
<nacc> *pastebin
<Zta> Will do.  And again, thanks a lot of all the help everyone.
<acheronUK> Is there any way I can fool the update notifier etc into thinking Zesty is released?
<acheronUK> Just want a screenshot of the upgrade being offered
<nacc> acheronUK: i'm not sure if passing -d would do it?
<nacc> acheronUK: you can do that for update-manager, at least
<acheronUK> nacc: I want plasma-discover to think there is an upgrade, so I need to manually change a file somewhere I guess
<nacc> acheronUK: i would guess taht's specific to plasma-discover, but not sure
<nacc> maybe something in /etc/apt/apt.conf.d/60plasma-discover?
<acheronUK> nacc: I was thinking it's getting the info that a release upgrade is available from the same source as native ubuntu upgrade tools would
<acheronUK> nacc: no, definitely not that file.
<nacc> acheronUK: ok, i'm not sure
<acheronUK> anyway. I'm not overly fussed. I can quickly grab a screenshot when the release goes out for real and put that on the wiki. just would have been nice to get it all done now
<Laney> bdmurray: dkms> Is is that the get_newest_kernel_debian thing is broken? https://paste.ubuntu.com/24369911/
 * Laney doesn't know very much about dkms but it seems that this should return 4.10.0-19 not nothing ...
<Laney> maybe change the gt to ge?
<nacc> Laney: yeah that does seem off
<nacc> it doesn't seem like it would do any harm to be -ge, as it should be a no-op or, as in this case, a correct assignment of what is 'currently' consider the newest kernel when we haven't seen any kernels yet
<Laney> looks that way to me
<nacc> alternatively, rather than do the COMPARE_TO assignemnt, just do the same assignment in that section as later and continue the loop, as i think that's the intent
<nacc> the assignment in the if, that is
<nacc> Laney: nice catch
<Laney> didn't test it end to end yet ;)
<Laney> (actually not immediately sure how to do that)
<Laney> interrupt the upgrade and hack the file or something
<bdmurray> install dkms, hack it, then do the upgrade?
<Laney> apt install --reinstall bcmwl-kernel-source does give Building initial module for 4.10.0-19-generic though
<Laney> yeah I guess
<Laney> lemme try that
<Laney> k, it's running
<Laney> Building for 4.8.0-46-generic 4.10.0-19-generic
<Laney> looking ok so far
<bdmurray> there's also this new autoinstall_all_kernels option
<LocutusOfBorg> bdmurray, hello, wrt LP: #1681566, let me understand, you can install virtualbox-dkms without having corresponding kernel sources available?
<ubottu> Launchpad bug 1681566 in virtualbox (Ubuntu) "nvidia-375 DKMS module not recompiled on upgrade to 17.04" [Undecided,Confirmed] https://launchpad.net/bugs/1681566
 * LocutusOfBorg is going to sleep, sorry for the delay
<bdmurray> LocutusOfBorg: dkms isn't building modules for the new kernel during an upgrade. reinstalling the kernel or the dkms package then causes the modules to be built for the new kernel.
<bdmurray> LocutusOfBorg: Laney is testing a fix now.
<jackpot51> bdmurray: any ideas what was happening?
<nacc> maybe better asked here .. given just a .dsc, how do i dtermine which distribution the package targets? i'm not seeing anyting in the dsc object that provides that info
<nacc> or is that simply not deducible given just a .dsc -- it's fine if so, just wondering
<jackpot51> Try to dget the dsc file
<nacc> (assume i can also extract said source package)
<nacc> jackpot51: right, but dget works with ppas, say
<jackpot51> Look in the debian/changelog of the source package
<nacc> jackpot51: yep, that should work, was just wondering if there was seomething ... faster :)
<jackpot51> Don't know
<Laney> nacc: bdmurray: LocutusOfBorg: Attached. I need to go to bed now, so could one of you review / test / maybe upload? It might be worth asking tseliot and/or superm1 for advice if you can find them (maybe forwarding to upstream on github will get a response).
<nacc> Laney: nice work, have a restful evening!@
<Laney> thanks!
<Laney> oh, and feel free to try and understand the logic a bit better of course
<Laney> to determine if it was actually intended to behave like that and should be fixed elsewhere
<Laney> o/
<jackpot51> Hey Laney, Where can I see your work?
<bdmurray> jackpot51: in the ubg
<jackpot51> Launchpad was down for about 30 seconds. That was freakin scary
<jackpot51> Doing a release upgrade on the launchpad.net servers I hope?
<sarnold> I understand routers were having new rules pushed
<LocutusOfBorg> thanks lamont bdmurray
<LocutusOfBorg> s/lamont/laney
<LocutusOfBorg> I would like to upload but it is seeded almost everywhere :(
 * lamont did nothing :D
<LocutusOfBorg> SRU?
<jackpot51> bdmurray: LocutusOfBorg: Can we have the DKMS fixes in the repos before people get update-manager notifications?
<bdmurray> jackpot51: that's technically possible
<LocutusOfBorg> bdmurray, please upload then :)
 * LocutusOfBorg is going to sleep, 1am here and alarm is at 6
#ubuntu-devel 2017-04-13
<Laney> nacc: bdmurray: Got a new idea...
<Laney> attached
* Laney changed the topic of #ubuntu-devel to: Zesty Released | Archive: closed | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<nacc> Laney: nice catch, i think that's pretty reasonable
<Scars> So I was just reading on here: http://packaging.ubuntu.com/html/udd-intro.html
<Scars> Are you telling me this is dead?
<rbasak> Correct.
<ogra_> udd never really came to life actually
<rbasak> We're making good progress on a git-based replacement though
<Scars> Any alternative yet? Or any other way to learn how to contribute?
<ogra_> https://wiki.ubuntu.com/ContributeToUbuntu
<ogra_> perhaps ?
<rbasak> We can give you a usable git repo on request.
<rbasak> Or you can do it the non-VCS way.
<nacc> Scars: how comfortable are you with debian / ubuntu packaging?
<nacc> Scars: so it's not strictly required (although helpful) to fix issues
<nacc> there is some overview here: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow, but it needs some updating again
<Scars> Im completely new
<nacc> Scars: i'm on a call right now, but can help give you a guide in a few, if that's ok
<jackpot51> Laney: Do you need more testing on the DKMS patch?
<jackpot51> I could test the NVIDIA package
<lan3y> More is good.
<xnox_> sladen, cyphermox: in the latest debian upload pitti is disabling DNSSEC in resolved by default (include zesty)
<xnox_> because the support is not mature enough.....
<xnox_> sladen, unping
<xnox_> slangasek, ^
<xnox_> should I pick that up into zesty SRU?!
<cyphermox> xnox_: I'd tentatively say yes?
<cyphermox> it tends to break things
<slangasek> xnox_: there are certainly outstanding issues with dnssec, though I don't know if anyone ever filed a proper bug report; I'd say we need some sort of dnssec fix srued, yes
<xnox_> slangasek, the bit where it cannot validate things and internets not working is what concerns me
<xnox_> also pitti's commit in the debian's git doesn't mention a specific bug report/reports so it's a general statement.
<slangasek> xnox_: the last information I had on this is https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647031/comments/33
<ubottu> Launchpad bug 1647031 in systemd "systemd-resolvedâs 127.0.0.53 server does not follow CNAME records" [Unknown,New]
 * xnox_ feels like it should be cherrypicked into zesty.
<xnox_> but that one is fixed.
<xnox_> i thought
<xnox_> (the following bit)
<xnox_> things like https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1672235 ?
<ubottu> Launchpad bug 1672235 in systemd (Ubuntu) "zesty switch from dnsmasq caused lookup errors, DNSSEC validation failed: no-signature" [Undecided,Confirmed]
<slangasek> xnox_: bug #1647031 was fixed but that bug wasn't about dnssec, the dnssec was pile-on comments.  if there's a separate bug filed, ok good
<ubottu> bug 1647031 in systemd "systemd-resolvedâs 127.0.0.53 server does not follow CNAME records" [Unknown,New] https://launchpad.net/bugs/1647031
<xnox_> ah
<jbicha> I saw comments today from people upgrading to 17.04 and having network problems
<jbicha> is this something you're considering doing a 0-day SRU for?
<wxl> where's the bug number?
<jbicha> some comments on http://www.omgubuntu.co.uk/2017/04/ubuntu-17-04-review-new-features
<jbicha> https://ubuntuforums.org/showthread.php?t=2356828
<wxl> i'd encourage them to make a bug report
<wxl> i'm sure with enogh activity something would get done
<jbicha> wxl: I believe that's what's being talked about with systemd ^
<wxl> oh. harumph
<ilmaisin> xnox_: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966 did you notice this? the change in your patch wasn't enough for xenial, it probably is necessary to reload systemd configuration in the post-installl script also
<ubottu> Launchpad bug 1642966 in cups (Ubuntu Xenial) "package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1" [High,Triaged]
<ilmaisin> xnox_: however if it is the old package's preremoval script that fails it probably does not matter what there is in the new package's scripts
<infinity> Reloading systemd from packages should never be necessary.
<infinity> systemd has a dpkg trigger for this very prupose.
<infinity> purpose, too.
<ilmaisin> infinity: hmm
<ilmaisin> infinity: if you can tell what's wrong with the update i'll be grateful
<infinity> I'm having a hard time following the bug comments to see that anything's wrong with it at all. :P
<infinity> Ahh, found it.
<infinity> So, if old prerm is failing on a bad unit, then new prerm is attempted.  New prerm should be written in a way that it skips/ignores the failure.
<infinity> ilmaisin: Informed xnox of the above (he's right next to me)
<ilmaisin> infinity: thx
<ilmaisin> xnox_: the root cause of the problem seems to be that if there is a stuck job, "invoke-rc.de cups stop" fails
<ilmaisin> xnox_: this probably means that we can't have any updates to cups now, not even critical security updates
<DPK_> not sure if this is the right place to ask this, but i've been pulling my hair out lately trying to preseed/config a ubuntu install w/ a custom internal mirror of security.ubuntu.com -- the problem is our internal mirror is https
<DPK_> i'm trying to figure out how to override that in preseed config
<DPK_> initially i have just this:
<DPK_> d-i apt-setup/services-select multiselect security
<DPK_> d-i apt-setup/security_host string internal.mirror.net
<DPK_> d-i apt-setup/security_path string /current/security.ubuntu.com/ubuntu
<DPK_> but i can't figure out how to configure it such that it'll be https://internal.etc instead of http://internal.etc
<xnox_> DPK_, there is one more key for protocol i think
<xnox_> but i can't remember if we ask that for security too, let me check quickly
<xnox_> (cause we support http, ftp, https)
<xnox_> DPK_, ha, we do not it is hardcoded to http
<xnox_> for the security
<xnox_> DPK_, i think you may need to apply sed to either generators/91security during install; or in the install hook; or post install.
<xnox_> DPK_, could you please open a bug report against apt-setup requesting to support apt-setup/security_protocol key?
<xnox_> (cause e.g. for regular mirrors protocol question is a thing that is supported)
<DPK_> @xnox sure will do
<udevbot> Error: "xnox" is not a valid command.
<dobey> heh
<dobey> bots
<jbicha> I guess LP: #1681513 is another reason why some people are having network trouble after the update
<ubottu> Launchpad bug 1681513 in network-manager (Ubuntu) "Ubuntu GNOME 17.04 beta: wi-fi not working â mac address keeps changing?" [Undecided,New] https://launchpad.net/bugs/1681513
<wxl> jbicha: someone here in #kubuntu-devel has the problem and tested with the 4.10.x mainline kernel and problem is solved. not sure it's the same thing. there might be multiple issues.
#ubuntu-devel 2017-04-14
<cehwedrec> hi, i have a question for ubuntu's devs, i couldn't find an answer while searching, so here it goes:
<cehwedrec> when will ubuntu completely get rid off anything else than systemd's mechanisms for controlling services?
<cehwedrec> i've had some problems with the releases so far, systemctl wouldn't work properly for controlling some services
<cehwedrec> this doesn't happen on distro's that have only systemctl
<tsimonq2> Unit193, infinity: Interesting timing with this email... :P https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2017-April/017399.html
<Unit193> ...OK?
<tsimonq2> Unit193: (you remember the context for this right?)
<cehwedrec> hi, can anyone take a look at what i wrote earlier?
<ackk> cyphermox, hi, did you by any chance manage to reproduce https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1681846 ?
<ubottu> Launchpad bug 1681846 in ubiquity (Ubuntu) "Zesty Ubuntu-GNOME Installer hangs at plymouth splash" [Undecided,New]
<ilmaisin> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966
<ubottu> Launchpad bug 1642966 in cups (Ubuntu Xenial) "package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1" [High,Triaged]
<ilmaisin> so this problem seems to be because cups will not shut down cleanly if there are jobs in queue
<ilmaisin> and thus it is impossible to safely do updates of any kind
<cyphermox> ackk: no
<smoser> slangasek, would you try to verify https://bugs.launchpad.net/cloud-init/+bug/1677376 sometime today ?
<ubottu> Launchpad bug 1677376 in cloud-init (Ubuntu Yakkety) "growing partitions does not work when booted without initramfs" [Medium,Fix committed]
<smoser> i expect to have all the other cloud-init sru verified.
<cehwedrec> hi, i have a question for ubuntu's devs, i couldn't find an answer while searching, so here it goes:
<cehwedrec> when will ubuntu completely get rid off anything else than systemd's mechanisms for controlling services?
<cehwedrec> i've had some problems with the releases so far, systemctl wouldn't work properly for controlling some services
<cehwedrec> this doesn't happen on distro's that have only systemctl
<jbicha> cehwedrec: upstart will be completely dropped in 17.10, but if you have a specific issue please file a bug
<ogra_> well, if it is about system services, thats fully systemd only since 16.04
<jbicha> upstart is only used for unity8 in 17.04 so that shouldn't really affect anything else at all
<ogra_> the only bit upstart is used for still is user sessions
<ogra_> (yeah, and even that was dropped in 17.04 for the mainstream stuff)
<cehwedrec> i'll try 17.04 and see if i have the same probs, thanks!
<slangasek> smoser: I'm off today, so probably not, but I can do it Monday
<nacc> cehwedrec: i can imagine some upgrade paths may not be well-tested or could have corner cases, so bugs are probably the right way if you do reproduce it
<Unit193> Tip, don't have cracklib-runtime installed, it bails and the upgrader has bad error recovery.
<bdmurray> Unit193: isn't that package seeded?
<Unit193> bdmurray: Hrm, OK.  So not specifically that package but involving that package.  I'm sorry I misspoke. :3
<Unit193> bdmurray: Looked like this https://bugs.launchpad.net/ubuntu/+source/cracklib2/+bug/1681231 anywho.
<ubottu> Launchpad bug 1681231 in cracklib2 (Ubuntu) "package cracklib-runtime 2.9.2-3 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [Undecided,New]
<Unit193> Which you just looked at. :)
<nacc> sarnold: got pinged in #ubuntu about a security bug in 1678349 which has not been triaged yet (universe package i'm told) -- is the right answer "package is in universe, may not get triaged for security bugs"? or is this an oversight?
#ubuntu-devel 2017-04-16
<kees> doko: is there any way to tell a debian/ubuntu gcc build from a stock gcc build using only preprocessor magic? it looks like there's nothing different but a date in the __VERSION__ define.
<kees> (specifically I'd like to tell stock 4.6 from ubuntu 4.6 since ubuntu moved the plugin headers around slightly)
<Prutheus> Hello! I am working with GTK and libappindicator ... however, I want to change the icon of the indicator in my program dynamically ... like this: https://ghostbin.com/paste/jt9wd  but this is not working, how to solve my problem?
<infinity> kees: By "plugin headers", you mean /usr/lib/gcc/x86_64-linux-gnu/6/ and the like?
<infinity> kees: That sort of thing should be tested outside the compiler, not within (as in, cpp macros don't make sense for that)
<infinity> kees: See, for example: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6706074627da7734d21f0024b6f7fb58b5629d6b;hp=800938a1268309932c20dc523bb226bcab4bfe18
<infinity> kees: (assuming you're doing the same silly thing we are, which is dropping stdinc, and then turning around and trying to recontruct it because we think we know better :P)
<kees> infinity: I mean the headers in gcc-N-plugin-dev. the "c-common.h" file moved to c-family/ in gcc 4.7, but ubuntu's 4.6 moved it there early with https://sources.debian.net/src/gcc-4.6/4.6.3-14/debian/patches/pr45078.diff/
<kees> infinity: which means that if I do a gcc version test in headers to find the right place to include c-common.h from, I can't use only a version test, since 4.6 stock and ubuntu builds have it in different places.
<infinity> kees: Ahh.
<infinity> kees: That similarly seems like a job for autoconf-style search tests, especially given upstream's joy of backporting to stable branches.
<kees> infinity: yeah, kernel Kconfig is ... not friendly ... about such tests.
<kees> but that's okay. near as I can tell, the only gcc 4.6 left on the planet not built from source are the Debian and Ubuntu packages. :) so I'll just continue to pretend that's the "real" 4.6
<infinity> Heh.
<infinity> kees: While I have you here, care to have a public opinion about armhf and PIE?  I recall the last time you and I spoke about it, you said ChromeOS does PIE on armhf and we should JFDI ourselves.  doko, on the other hand, says you expressed the opposite opinion to him. :P
<infinity> (Bonus points if you had any numbers, even fuzzy ones)
<Zta> nacc: Hi again =) I decided to go a somewhat different route: I created a docker image with all tools and dependencies and clone the sources. Then I added scripts to do all what we discussed earlier, with the exception of schroot; I build the package directly on the host (=dockered!) system. And I actually got something working (with the same procedure that did not work in schroot, strangely).
<Zta> nacc: So all is good. Except when I decide update my sources and rebuild the package.  Then I get: dpkg-source: error: unwanted binary file: debian/aseprite/usr/bin/aseprite[...]  Should I just delete this directory manually?
<kees> infinity: I think what doko remembers was me agreeing that I wasn't opposed to armhf staying non-PIE. That said, I think there's no good reason to stay non-PIE since there are more general registers on arm than i386, and the compiler can already float the PIE register around, so there's even less loss of performane.
<kees> infinity: I think everyone should configure gcc with --enable-default-ssp and --enable-default-pie :)
#ubuntu-devel 2018-04-09
<tsimonq2> jbicha: I had a backport of spectre-meltdown-checker started but not finished in bug 1743334. If you would like to finish it up (since you synced to Bionic today), you're welcome to, just assign the bug to yourself. Otherwise I'll assign the bug to myself tomorrow.
<ubottu> bug 1743334 in Artful Backports "Please backport spectre-meltdown-checker 0.29-1 (universe) from bionic" [Undecided,Confirmed] https://launchpad.net/bugs/1743334
<LargePrime> how can i get this package updated https://launchpad.net/ubuntu/+source/xflr5
<LargePrime> please ping if you reply, i sleep now
<LargePrime> a link to a how to help ubuntu keep packages up to date would be great
<tsimonq2> LargePrime: Ask Debian.
<tsimonq2> LargePrime: https://bugs.debian.org/864588
<ubottu> Debian bug 864588 in wnpp "O: xflr5 -- analysis tool for airfoils" [Normal,Open]
<slangasek> nacc: non-standard xz flag> hmph, who do we blame for that?
<lathiat> FYI seems there is a bug in bind9-host on bionic that causes it to hang forever sometimes, which causes avahi-daemon-check-dns.sh to hang forever and cause network connections to hang indefinitely.. https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1752411
<ubottu> Launchpad bug 1752411 in bind9 (Ubuntu) "Can not ping IP addresses on remote network after connect" [High,Confirmed]
<zyga> re
<mvo> sil2100: hey! I was told by zyga that there might be an issue with the ubuntu-image snap (zyga knows the details). are you aware of this?
<zyga> mvo, sil2100: the ubuntu-image snap is published to edge and beta and doesn't function (GLIBC things explode)
<zyga> if the snap should be used it should be fixed and published to stable
<zyga> otherwise I think the channels should be closed
<zyga> it's a high-profile item in device maker circles
<sil2100> zyga: I think we didn't use stable before, but maybe it's finally time - anyway, I wasn't aware that the current snap is exploding, thanks for letting me know
<sil2100> I'll take a look at it
<slangasek> sil2100: hum, it's long overdue for it to be on stable IMHO
<sil2100> slangasek: yeah
<slangasek> sil2100: OTOH we should only push it there if it's actually stable ;)
<sil2100> slangasek: well, I think the idea was to publish it to stable once we have 1.0 - and we did, but I guess we forgot ;p
 * zyga feels this issue is now in very good and capable hands :)
<slangasek> is the glibc issue one that's currently fixable with current snapcraft and classic snaps?
<slangasek> I'm not sure if we've gotten the all-clear on that
<snikker> hello, i'm compiling kernel usung "make deb-pkg", there is a way to use custom "changelog" and "control" files instead of auto generated?
<doko> oSoMoN: re LP: #1034558 why remove, they are synced from Debian. why did you remove the external deps?
<ubottu> Launchpad bug 1034558 in pentaho-reporting-flow-engine (Ubuntu) "[MIR] libbase-java, libsac-java, libxml-java, libflute-java, libpentaho-reporting-flow-engine-java" [Undecided,Won't fix] https://launchpad.net/bugs/1034558
<oSoMoN> doko, I didn't remove anything, I'm merely suggesting that they could be if we wanted to, there's nothing actually using those
<sil2100> mvo, zyga: are the issues with the ubuntu-image snap reported anywhere?
<zyga> sil2100: not that I know of
<ginggs> tseliot: you have a new PR
<sil2100> zyga: I see some issues indeed, e.g. it's busted on artful - but it's been like that since a while, I guess might be good to see if it can get fixed now
<sil2100> For xenial it works as expected
<sil2100> I was wondering if this was some other issue, or is this it
 * sil2100 needs to check on bionic
<zyga> sil2100: what was the issue on artful?
<zyga> I think you _maybe_ just need a rebuild with new snapcraft
<sil2100> zyga: yeah, I guess that's it, it's the glibc issue caused by the old snapcraft IIRC
<zyga> sil2100: it looks like the snap was built on bionic
<zyga> but I don't understand why it would work on xenial then
<sil2100> I'll investigate some more
<tseliot> ginggs: yes, I'll have a look at it later, thanks
<ginggs> tseliot: thanks - i checked and it wasn't in the 384 packaging, so must have crept in during the switch to the new packaging in 390
<doko> please pickup your ftbfs here ... http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20180408-bionic.html
<LargePrime> tsimonq2, how hard is it to maintain a package?
<LtWorf_> LargePrime: maintaining chromium is slightly harder than maintaining nyancat
<LtWorf_> (i mean that it all depends on how hards is the content of the package itself)
<LargePrime> LtWorf_, it would be this https://bugs.debian.org/864588
<ubottu> Debian bug 864588 in wnpp "O: xflr5 -- analysis tool for airfoils" [Normal,Open]
<LargePrime> not hard i think.  but no experience in the domain
<LargePrime> have you any advice for me?
<LtWorf_> LargePrime: i think #debian-mentors on oftc is a better channel to ask this stuff
<sil2100> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
<tsimonq2> LargePrime: Not *terribly* hard if you RTFM. :P
<nacc_> slangasek: not sure, i need to verify it's true, and then see .. i've filed a few bugs in debian re: non-reproducible tarballs before
<nacc_> slangasek: none of them have received any response, which makes me feel like pristine-tar is not maintained (i mentioned this to you before, i think)
<nacc_> slangasek: and it's also something i struggled to debug effectively, but I believe I should be able to without git-ubuntu ... i'll do that today
<seb128> cyphermox, hey, was bug 1754422 good to go after security +1?
<ubottu> bug 1754422 in volume-key (Ubuntu) "[MIR] volume-key" [Undecided,Incomplete] https://launchpad.net/bugs/1754422
<nacc> slangasek: i'm still wading into this, but it does appear to be reproducible with just pristine-tar in a Git repo. Also this article https://www.nongnu.org/lzip/xz_inadequate.html
<slangasek> heh
<nacc> slangasek: i believe (and this might be true for other formats, just no flags are used there), it's not always possible to know what xz was used to compress something
<nacc> slangasek: and what flags, maybe, more particularly
<slangasek> nacc: sure; it just seems so unlikely that an Ubuntu dev would be using arbitrary xz flags when building this orig.tar.xz?
<slangasek> it appears juliank did the cryptsetup upload in question
<slangasek> juliank: ^^ how did you acquire the orig.tar.xz for that upload? did it come from upstream or did you create it?
<nacc> slangasek: oh no i meant the upstream did
<nacc> slangasek: it's what is published upstream (i've verified that now )
<slangasek> ah
<nacc> slangasek: but i believe pristine-tar has to be able to call xz in the same way upstream does in order to verify it did the right thing
<nacc> slangasek: and it's not always going to be able to (again, this is still just my rough understanding)
 * slangasek nods
<nacc> we obviously could decompress and recompress xz as something else in order to reproduce it, but it's really not a big deal (imo) yet
<nacc> pristine-tar support in git-ubuntu is best effort on import
<nacc> we can always fallback to Launchpad (and I think I have an algorithm for your merge case now)
<nacc> slangasek: i've asked upstream how they generate the tarball, as even the manual try-all-known options path in pristine-xz fails: https://gitlab.com/cryptsetup/cryptsetup/issues/374
<coreycb> RAOF: hi, if you have a chance during your Tues SRU rotation, would you be able to take a look at promoting neutron to artful-proposed and possibly reviewing the neutron versions in the xenial and artful queues?
<slangasek> coreycb: none of the Monday rotaters available?  (infinity)
<coreycb> slangasek: possibly. i like to add a little buffer time to my asks to account for timezones, shock, etc. :)
<andyrock> slangasek: hey hey
<andyrock> slangasek: I didn't see your ping earlier this morning
<andyrock> slangasek: I guess the only problem would be if you've software-properties-dbus installed and not snapd-glib
<andyrock> slangasek: maybe we can move that dependency there
<andyrock> for the others I'm pretty sure there will be no problem
<slangasek> andyrock: ok great, thanks - I'll sponsor the upload now
<andyrock> slangasek: I moved snapd back to common
<andyrock> how can I check if it is going to create problems in the server image?
<slangasek> andyrock: launch a default lxd instance; install updated versions of software-properties-common + python3-software-properties; confirm that add-apt-repository doesn't bail
<slangasek> andyrock: so if we have to still depend on gir1.2-snapd-1, that's very specifically the one that is causing the image bloat
<slangasek> andyrock: because glib1.2-snapd-1 -> libsnapd-glib1 > libsoup2.4-1 > glib-networking
<slangasek> since we don't use it in the "common" case, it would be good to figure out how to avoid that dependency
<andyrock> mmm one thing that we can do is to not make it a depedency
<andyrock> than we can move the "from gi.repository import snapd" inside a try
<andyrock> the rest of the code is not going to be called
<slangasek> yes, that would also be fine from my POV
<andyrock> so it should not create any problems
<nacc> slangasek: ah, pristine-tar 1.42 has added a -r flag
<slangasek> nacc: short for --really-pristine?
<nacc> slangasek: --recompress
<slangasek> ok
<nacc> slangasek: which allows for recompressing a reproducible tarball
<slangasek> --right-this-time-we-mean-it
<nacc> yeah :)
<nacc> i think it will guarnatee the .tar is the same, even if hte .tar.xz is not ... which is still not ideal
<nacc> i'm not sure we want git-ubuntu to do that, as it will lead to weird issues
<andyrock> slangasek: https://code.launchpad.net/~azzar1/software-properties/fix-1762082/+merge/342854
<jbicha> slangasek: can you let my DMB email through the u-devel-announce moderation queue? LP: #1762516
<ubottu> Launchpad bug 1762516 in ubuntu-community "[TB/DMB] Please extend expiring members term by 1 month" [Undecided,New] https://launchpad.net/bugs/1762516
<slangasek> jbicha: done
<slangasek> andyrock: thanks, uploading
<joelkraehemann> hi all
<joelkraehemann> how is the freeze?
<joelkraehemann> Since I just discovered a flaw in GSequencer
<joelkraehemann> http://git.savannah.nongnu.org/cgit/gsequencer.git/commit/?h=1.4.x&id=07f18a82b7df829a6969e88f86848e676d888fd4
<joelkraehemann> I just build the new tarball
<nacc> joelkraehemann: bugfixes are allowed
<joelkraehemann> it is a bugfix
<nacc> joelkraehemann: ok, file a bug?
<joelkraehemann> I am upstream
<joelkraehemann> should I do it anyway?
<nacc> joelkraehemann: an ubuntu bug, i mean
<joelkraehemann> great
<nacc> joelkraehemann: file a bug, provide a debdiff, ifyou can
<nacc> joelkraehemann: it'll go into the sponsorship queue -- i can probably take a look if you ping me :)
<joelkraehemann> thank you
<joelkraehemann> https://bugs.launchpad.net/ubuntu/+source/gsequencer/+bug/1762564
<ubottu> Launchpad bug 1762564 in gsequencer (Ubuntu) "GSequencer wrong interface init function of AgsRecallAudioRun" [Undecided,New]
<joelkraehemann> nacc: the debdiff takes some time because I just run the test-suite
<nacc> joelkraehemann: sure
<joelkraehemann> nacc: ping
<joelkraehemann> FYI, there is a new upstream tarball available
<joelkraehemann> it contains 2 other fixes but are less important
<sarnold> nacc will probably want all the changes in a new tarball documented in the bug
<joelkraehemann> sarnold: Ok, I do so
<sarnold> joelkraehemann: thanks :)
<joelkraehemann> sarnold, well there was 1 symbol not exported
<joelkraehemann> https://bugs.launchpad.net/ubuntu/+source/gsequencer/+bug/1762576
<ubottu> Launchpad bug 1762576 in gsequencer (Ubuntu) "ags_widget_cclosure_marshal_VOID__STRING_INT() symbol not exportet" [Undecided,New]
<joelkraehemann> https://bugs.launchpad.net/ubuntu/+source/gsequencer/+bug/1762578
<ubottu> Launchpad bug 1762578 in gsequencer (Ubuntu) "ags_recall_stop_persistent() event not properly done" [Undecided,New]
<joelkraehemann> nacc: all patches provided
#ubuntu-devel 2018-04-10
<nacc> joelkraehemann: thank you, i'll look again tmrw
<seb128> rbasak, tjaalton, what happened to the upload from bug #1750947? it looks like it is in the rejected queue but the bug doesn't state why/what's the issue
<ubottu> bug 1750947 in pulseaudio (Ubuntu Xenial) "pulseaudio print lots of error when selecting unavailable profile" [Undecided,Confirmed] https://launchpad.net/bugs/1750947
<mvo> doko: how do you feel about http://paste.ubuntu.com/p/hK9xtcCrM9/ ?
<doko> mvo: yes, that looks much better
<tjaalton> seb128: Rejected by Robie Basak: Missing SRU information. See bug for details.
<seb128> tjaalton, since when missing info is a reason for reject? usually they ask to fix the bug and keep unaccepted meanwhile...
<mvo> doko: for this to fully work we need the trivial python upload with the cnf- hints, I will do the change in c-n-f now to actually have a special case for python when python3 is already installed
<seb128> tjaalton, thx
<seb128> rbasak, ^
<tjaalton> seb128: yeah my thoughts exactly..
<LtWorf> anyone can tell me how do i figure out why a package was removed from ubuntu bionic? (python3-motor)
<LtWorf> it's in artful, and it's in debian testing
<seb128> LtWorf, https://launchpad.net/ubuntu/+source/python-motor/+publishinghistory
<mvo> Laney: we see failures in autopkgtest on bionic-i386 currently with snapd. the error is a bit puzzling, the autopkgtest system seems to hang for more than 15min in "journalctl --sync": https://paste.ubuntu.com/p/r4nJxhXMQg/ (it starts to warn at 07:37 and gets eventually killed at 07:52. is there anything unusual about the i386 autopkgtest systems or the configuration that might explain this?
<Laney> mvo: hi, not really and nothing that would be different from amd64, is it OOMing or running out of disk space or something?
<LtWorf> i don't know much about the package, i just use it :D
<Laney> did you try running it locally to see if it happens for you?
<LtWorf> i use debian testing, works fine for me
<LtWorf> it did have a bug because it had a broken dependency on pymongo, while in truth it required a newer one
<LtWorf> for a bit, but that was fixed when they upgraded pymongo as well
<mvo> Laney: it seems to be fine on amd64 (and the other arches) and never got this behaviour on linode or GCE where we run dozens of the same run each day. sadly our logs do not include disk-free data, but let me dig a bit if I can find something
<mvo> Laney: its not OOMing (we do have the dmesg output in our debug log)
<LtWorf> so on debian, i opened and closed the RC bug (and still think the maintainer is a bit clueless)
<seb128> LtWorf, talk to doko he's the one who deleted it
<LtWorf> well we use it for some internal thing at work, guess we just switch the vm to debian
<mvo> Laney: and funny enough all the other tests that use exactly the same code path work. and the previous failures are also happening in different tests but it is also hanging in journalctl --sync.
<LtWorf> i'm a user of the package, not the dm
<mvo> Laney: I assume all the autopkgtest images use the same systemd version in bionic?
<Laney> mvo: Yeah, and you can probably see that if you download the artifacts and look at testbed-packages
<mvo> Laney: cool, let me try that
<LtWorf> doko: i was kinda using python3-motor :P
<xnox> mvo, there are some fixes to journalctl wrt. syncing / flushing / keeping track of FDs. I do not know if you are hitting those bugs. I did not see such bugs yet, but I'm thinking to cherrypick those fixes anyway, because they look sane.
<doko> LtWorf: is there a fix for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894683 ?
<ubottu> Debian bug 894683 in src:python-motor "python-motor's autopkg test fail" [Important,Open]
<LtWorf> that would be a ftbfs no?
<doko> it keeps the package out of the release pocket
<LtWorf> i see. Would you be able to do a nmu if i were to make a patch?
<LtWorf> i am under the impression that the maintainer is basically MIA
<LtWorf> but it's team maintained so it's fine
<Laney> mvo: I'll run it on the server and then we can look at the console-log and stuff
<rbasak> seb128: I don't remember if I rejected because of it, but comment 14 is a reason for rejection. It even says so in the SRU docs.
<doko> LtWorf: at this point, I would consider doing a Ubuntu upload, if the bug in Debian has a patch
<LtWorf> okay
<rbasak> seb128, tjaalton: leaving it in the queue means that every day an SRU team member wastes time looking again.
<rbasak> seb128, tjaalton: you should not be uploading or sponsoring until the SRU information is complete.
<tjaalton> fine
<seb128> rbasak, it seems a bit harsh to require another upload dance when the source doesn't need any change
<rbasak> seb128: it gets ridiculous when there are four or five uploads languishing in the queue in a row that cannot be accepted because the SRU procedure has been ignored.
<seb128> rbasak, right, I can understand that being frustrating ... well in that case the bug has been updated now, can the upload be rescued from the rejection queue or does it need reuploading?
<rbasak> Rescuing from the rejection queue _is_ reuploading.
<seb128> k
<rbasak> seb128: if it's just an odd one that needs fixing up then I usually leave it in the queue, FWIW.
<seb128> tjaalton, well, I guess you need to reupload then
<tjaalton> I don't have the source anymore
<rbasak> And I also try to be more patient with newbies
<seb128> tjaalton, https://launchpad.net/ubuntu/xenial/+queue?queue_state=4&queue_text=pulseaudio has it
<rbasak> But when there's a wall of queue items that objectively can't be accepted, then I think it's OK to reject because I'm saving the next SRU person (and possibly myself next week) wasting time reviewing the same wall.
<tjaalton> done
<doko> ricotz: we are currently running an archive test rebuild. please could you stop your mozillateam builds for a week or so, or move to one or two builds per week?
<LocutusOfBorg> LtWorf, I can upload in Debian if you have a patch
<seb128> rbasak, fair enough, it's just the first time I see that, but usually I do have my SRU bugs SRU compliant before upload, I just had cases where some tweaks/extra info was requested for
<doko> oSoMoN: ^^^ same for LO test builds
<seb128> tjaalton, rbasak, thanks
<LtWorf> LocutusOfBorg: i don't have a patch, was evaluating if it was a good idea to work on one :D
<LtWorf> (If i had done it, i would have just attached it)
<oSoMoN> doko, ack, I don't have any test builds running, and I'll refrain from doing them
<ricotz> doko, hi, there are two firefox beta releases per week which are mandatory to be done
<Saya> it looks like debian testing has the latest version of python3-motor from pypi (1.2.1) whereas bionic was still on 1.1 https://launchpad.net/ubuntu/bionic/+package/python3-motor
<ricotz> doko, regarding a recent libreoffice packaging change there is a need for a new build of its backports later this week
<doko> ricotz: mandatory?
<ricotz> doko, yes
<LtWorf> dok
<LtWorf> *typo
<LocutusOfBorg> doko, what happens if the reason for the test failures are a "merge mongodb" issue?
<rbasak> LocutusOfBorg: mongodb? Context please?
<rbasak> Because I'm working on bug 1761807
<ubottu> bug 1761807 in mongodb (Ubuntu) "[FFe] Bump mongodb to 3.6.X" [High,Triaged] https://launchpad.net/bugs/1761807
<ricotz> doko, btw is this archive rebuild done regarding retpoline?
<LocutusOfBorg> rbasak, can't we just sync mongodb from debian?
<LocutusOfBorg> this should fix python-motor
<LocutusOfBorg> I see the bug, so please try to make python-motor back in the archive after uploading mongodb
<rbasak> LocutusOfBorg: we may be able to sync 2.4 from Debian. I'd just want to check that the Breaks/Replaces remain correct for Ubuntu.
<LocutusOfBorg> the changes from Debian can be taken as-is, except for the Breaks+Replaces that needs a lower version
<LocutusOfBorg> rbasak, we wrote the same, yes they need to probably have a lower version until bionic is out
<rbasak> Yeah :)
<LocutusOfBorg> the new server package is bionic only
<rbasak> But I hope to supersede with 2.6 anyway.
<LocutusOfBorg> just please make sure that python-motor runs the testsuite again and upload in case
<LocutusOfBorg> do you have an ETA?
<LocutusOfBorg> maybe in the meanwhile we can sync/merge 2.4 and then leave the jump
<LocutusOfBorg> to you :)
<rbasak> I'm hoping this week. I'm still examining other reverse depends against 2.6 to minimise regression risk.
<rbasak> (and considering upgrade paths etc)
<LocutusOfBorg> what about merging mongodb right now?
<LocutusOfBorg> if that doesn't break your workflow, it should make even easier to upgrade after :)
<doko> ricotz: we are doing archive test rebuilds twice per release, that shouldn't be news. I'm a bit sad that these mozilla "requirements" monopolize the buildds
<rbasak> I have no objection to that, though I'd prefer to focus on 3.6.
<rbasak> LocutusOfBorg: if you'd like to merge 2.4 this week, please go ahead.
<rbasak> Uh, 3.4.
<rbasak> LocutusOfBorg: please make sure the breaks/replaces is correct for Ubuntu.
<rbasak> LocutusOfBorg: I'm happy for the ppc64el altivec code to be re-enabled the way Debian did it now that IBM have confirmed for us that the upstream workaround is correct.
<rbasak> LocutusOfBorg: and we need to keep the mongodb-server-core package please.
<rbasak> LocutusOfBorg: that's all I can think of in relation to the merge.
<rbasak> If it gets stuck in proposed, well my 3.6 will need to migrate anyway, so it won't affect me.
<LocutusOfBorg> rbasak, agree wrt ppc64el
<LocutusOfBorg> and the server-core is now in Debian
<LocutusOfBorg> and we already talked about the breaks+replaces, we are aligned then! doing
<rbasak> Yeah it all sounds good. I just wanted to make sure you knew about my "things I care about" list :)
<Nafallo> hmm. I just tried running nvidia-detector in bionic. it tracebacks. who should I be talking to? :-)
<LocutusOfBorg> we should *all* have the same list :)
<ricotz> doko, I see -- this is a bit unfair, those usually take like 1,5-2,5h on x86 which is nothing compared to e.g. chromium and other ppa-copy-happy people
<LocutusOfBorg> oh got the merge failure, fixing and uploading
<doko> ricotz: I ping those people as well. but it takes much more on armhf and arm64
<Nafallo> tseliot: hi :-)
<LocutusOfBorg> rbasak, just take the deb packaging from proposed in case it doesn't migrate
<LtWorf> is this applicable in debian? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894683 for version 1.2.1?
<ubottu> Debian bug 894683 in src:python-motor "python-motor's autopkg test fail" [Important,Open]
<tseliot> Nafallo: hi
<Nafallo> tseliot: bug 1054458, fixed in 2013 popped up again in bionic for me :-)
<ubottu> bug 1054458 in ubuntu-drivers-common (Ubuntu Quantal) "nvidia-detector crashed with ValueError in __get_value_from_name(): invalid literal for int() with base 10: 'experimental-304'" [High,Fix released] https://launchpad.net/bugs/1054458
<LocutusOfBorg> LtWorf, I don't know...
<LocutusOfBorg> I'm uploading a new mongodb to see if failures still happen
<LtWorf> thanks
<Nafallo> tseliot: are you able to verify?
<tseliot> Nafallo: I sure didn't expect that. I'll have a look at it
<Nafallo> cheers :-)
<Laney> mvo: would you believe that my test run passed ð
<mvo> Laney: meh, so sad. I hate heisenbugs. all failures in http://autopkgtest.ubuntu.com//packages/s/snapd/bionic/i386 since the last success happend on --sync. I also looked at the journalctl source, there is some interessting stuff going on there. it sends a signal and then waits for an inotify change on a watch file. makes me wonder if there is a bug there somewhere in bionic
<Riddell> mvo: would you know how geoip.ubuntu.com works? is the source code available at all?
<mvo> Riddell: hey! unfortunately I don't know much about it, I think the source is available but I'm not sure where
<Riddell> mvo: any idea who would know about it?
<mvo> Riddell: maybe ev knows about geoip.u.c but I'm not sure if it was added for ubiquity or was there before and just used by it
<Riddell> thanks i'll ask him
<TJ-> Riddell: I *think* it's libapache2-mod-geoip
<Riddell> thanks TJ-
<cjwatson> I believe that's wrong
<cjwatson> I have an old copy of the internal puppet tree which has (shortish) custom Python handlers which I think implement geoip.ubuntu.com
<cjwatson> But that puppet has been decommissioned so I don't know where their canonical source is now
<TJ-> I recall seeing some discussion about it many years ago and playing about with something similar, so I may be wrong
<cjwatson> Best bet is probably to ask rt@ubuntu.com for it to be released
<Riddell> thanks also cjwatson
<cjwatson> I can probably answer questions based on what I have but don't have authorisation to just paste it or whatever :)
<LocutusOfBorg> LtWorf, tests passes now, python-motor is back to 18.04, thanks for your contribution to Ubuntu!
<LtWorf> LocutusOfBorg: ah well thanks to you for doing the work, I just complained :P
<LtWorf> Saya: â
<ogra_> you complaintributed ;)
<Saya> Nice :) thanks a bunch
<Saya> that was fast
<LtWorf> by the way, i guess the debian bug can be closed too?
<LocutusOfBorg> :)
<LocutusOfBorg> already closed!
<LtWorf> ah good
<Laney> mvo: I got it to happen, and there was stuff about OOM in the logs including journald!
<Laney> maybe you need a bigger system? or do you want to be able to run in this kind of system (1536M ram)?
<mvo> Laney: ohhh, are you in the system currently?
<Laney> also, after I ran journalctl --sync myself out of band the test continued and dmesg was cleared :(
<Laney> mvo: yeah, I can paste you dmesg but now it's carrying on
<mvo> Laney: so first this amount of ram should be fine. however we had seen (in the past) issues with lowmem which are i386 specific, something that looked like a kernel memory leak that we trigger. let me search for the relevant link
<Laney> https://paste.ubuntu.com/p/TRMqVK7vJQ/
<mvo> Laney: I can add code to our tests that errors when we oom
<mvo> Laney: so that at least the error is clear
<mvo> Laney: s/we/the system/
<mvo> Laney: I suspect this is a variation of https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101 - I will add checks in our code for OOM and make the tests fail in a clean way in such a situation
<mvo> Laney: thank you so much! this was super helpful
<mvo> Laney: I wonder if the adt artifacts should include a dmesg dump - but this information would have been drowned in the sea of DENIALs probably anyway
<Laney> mvo: We had thought about including the console-log, maybe dmesg too
<Laney> but in this case dmesg has been truncated by something :(
<mvo> Laney: *cough* it is our code doing nasty things. sorry for that
<Laney> ah but kern.log has it all
<Laney> in your face snapd!
<mvo> Laney: heh :)
 * mvo hugs Laney 
<Laney> *hugs*
<sergiusens> slangasek: hi there, considering I am +1 for removal of LP: #1762334 is there anything else I need to do (like take care of the removal? But I'd need to know how)
<ubottu> Launchpad bug 1762334 in golang-udm (Ubuntu) "golang-udm build-depends on golang-gocheck-dev, removed from Debian" [High,Triaged] https://launchpad.net/bugs/1762334
<rbasak> jamespage, coreycb: any openstack implications in landing bug 1761807?
<ubottu> bug 1761807 in mongodb (Ubuntu) "[FFe] Bump mongodb to 3.6.X" [High,Triaged] https://launchpad.net/bugs/1761807
<jamespage> rbasak: not from an openstack perspective - ceilometer no longer uses mongodb
<rbasak> OK thanks
<slangasek> sergiusens: removal needs to be done by an archive admin - done now, thanks :)
<rbasak> slangasek: please could you also extend the mongodb FFe approval to cover mongo-tools? I think it makes sense to keep the version of mongo-tools in line with the mongodb package. Bug 1761807 - I've added the task.
<ubottu> bug 1761807 in mongodb (Ubuntu) "[FFe] Bump mongodb to 3.6.X" [High,Triaged] https://launchpad.net/bugs/1761807
<slangasek> rbasak: done
<nacc> joelkraehemann: in the future, you can put all the debdiffs in one bug
<nacc> joelkraehemann: so there are three patches total?
<Wimpress> jbicha: Is this something you could quickly ninja for me?
<Wimpress> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1762807
<ubottu> Launchpad bug 1762807 in software-properties (Ubuntu) "gnome-session-bin installed on Ubuntu MATE" [Undecided,New]
<jbicha> Wimpress: why the urgency? (I'm asking because I was planning to do a software-properties upload sometime this week to add AppStream metadata)
<Wimpress> jbicha: If you can add that change when you do that, it would be great.
<jbicha> ok
<Wimpress> I asked because I'm happy to go through biletto.
<jbicha> it doesn't use bileto just regular bzr merge requests
<Wimpress> But wasn't sure what other changes might be pedning.
<Wimpress> I'll make a merge proposal and sub you.
<jbicha> ok
<jbicha> bileto gets you those long version numbers :)
<Pici> ;25
<slangasek> kees, stgraber, mdeslaur, infinity: TB meeting?
<mdeslaur> ack
<slangasek> infinity: ^^
<Wimpress> jbicha: merge proposal submitted and linked to the bug. Thanks.
<Wimpress> infinity: Can you take another look at this please?
<Wimpress> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-release-upgrader/ubuntu-mate-bionic-update/+merge/342372
<doko> LocutusOfBorg: is that you? ~costamagnagianfranco
<doko> yes, it is you. please could you stop these long rebuilds like firefox while the archive rebuild is running?
<jbicha> stop hogging the builders while I'm hogging the builders!
<jbicha> (it doesn't look like it's actually a firefox build, it's just a ppa named firefox)
<cjwatson> Right, it was boinc, 33 minutes on armhf.  Probably not worth getting too cross about.
#ubuntu-devel 2018-04-11
<LocutusOfBorg> doko, firefox?
<LocutusOfBorg> let me see, I'm not aware!
<LocutusOfBorg> if you mean "firefox" ppa, it is building boinc-daily https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/firefox
<LocutusOfBorg> it takes some minutes, it is an automatic nightly build, not something I trigger
<LocutusOfBorg> please point me to a build, and I'll stop it in the automatic ppa builds
<joelkraehemann> nacc: yes, there are 3 patches total
<LocutusOfBorg> oh, I read it only now, yes it was boinc, but it takes not that much, and only when new code is pushed upstream (and the project is not so highly developed right now...)
<LocutusOfBorg> damn, I now read "bionic" each time somebody writes "boinc"
<LocutusOfBorg> stop calling releases with similar names of packages under my ddpo! :p
<seb128> doko, some of the ftbfses in the rebuild are "dh: unable to load addon python3: Can't locate Debian/Debhelper/Sequence/python3.pm in @INC ", do you know if something was pulling in dh-python before and stopped doing so?
<fbo> Hi everyone
<fbo> I'm trying to install Bionic via netinst/preseed/... and it fails (I've got more details here). Is it already supposed to be working or should I wait until the official release?
<doko> seb128: yes, please point me to those. I'll fix them
<rbasak> LocutusOfBorg: please could you take a look at bug 1762915?
<ubottu> bug 1762915 in mongodb (Ubuntu) "package mongodb-server-core 1:3.4.7-1ubuntu4 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/mongod.1.gz', which is also in package mongodb-server 1:3.4.7-1ubuntu4" [Undecided,New] https://launchpad.net/bugs/1762915
<rbasak> Sounds like the Breaks/Replaces is wrong.
<rbasak> cpaelzer: may I have some help with bileto please? I've never used it before, and it isn't obvious to me how to supply an upload to it.
<cpaelzer> rbasak: sure, HO so I can show you tihngs?
<cpaelzer> standup HO link?
<rbasak> ack, omw thanks
<cpaelzer> just clsoing a few things ...
<LocutusOfBorg> sure rbalint
<LocutusOfBorg> s/ rbalint / rbasak
<rbasak> LocutusOfBorg: do you have an ETA for that please? I need to rebase my nearly-ready 3.6 branch on it.
<nacc> joelkraehemann: ok, i'll review them today
<LocutusOfBorg> doko, I see your test rebuilds results... can you please look at keyutils? it seems terribly java rework related
<LocutusOfBorg> yes rbasak sorry was afk
<LocutusOfBorg> doing it now
<nacc> doko: along the same vein, i'm told that since 17.10, possibly, netbeans hasn't worked?
<nacc> doko: we might need the newere netbeans (8.2) to be java9 comaptibile
<LocutusOfBorg> uploading in some seconds
<LocutusOfBorg> sorry rbasak this seems a stupid mistake, just change ubuntu2 to ubuntu4 should fix it
<LocutusOfBorg> in case, let me know if somebody complains :)
 * LocutusOfBorg is not aware of an easy way to check once stuff has migrated
<LocutusOfBorg> uploaded rbasak
<rbasak> LocutusOfBorg: a breaks/replaces problem usually leads to a bug report like in this case. Thank you for fixing promptly :)
<tseliot> Wimpress: hi, I think I need your help debugging LP: #1756226
<ubottu> Launchpad bug 1756226 in ubuntu-drivers-common (Ubuntu) "nvidia-driver-390 fails to start GUI" [High,In progress] https://launchpad.net/bugs/1756226
<Wimpress> tseliot: Sure, in a meeting now. But let me know what you need and I'll help in a bit.
<tseliot> Wimpress: thanks. Please have a look at my comment in the bug report
<doko> nacc: feel free to update netbeans
<nacc> doko: :)
<nacc> doko: i'll take a look if i can
<doko> or use 8 explicitly
<nacc> doko: yeah, that might be the simplest choice, i'll check it out
<seb128> doko, https://launchpadlibrarian.net/363906839/buildlog_ubuntu-bionic-i386.libunity_7.1.4+18.04.20180209.1-0ubuntu1_BUILDING.txt.gz , update-notifier was one but that got fixed it seems, adding the build-depends on dh-python is easy but it doesn't tell us what changed in a incompatible way that force us to fix other packages now and that late in the cycle
<LocutusOfBorg> rbasak, can you please grab it from there? http://launchpadlibrarian.net/364563021/mongodb_1%3A3.4.14-3ubuntu1_1%3A3.4.14-3ubuntu2.diff.gz
<rbasak> LocutusOfBorg: yeah I'll grab from unapproved to unblock me for now, thanks
<LocutusOfBorg> oh, I got the problem
<LocutusOfBorg> it was not a wrong  version
<LocutusOfBorg> it was that debian moved also manpages
<LocutusOfBorg> so I had to bump it
<rbasak> Oh.
<rbasak> Yeah, I should have probably moved the manpages.
<LocutusOfBorg> maybe this 1:3.4.14-3ubuntu1 would have been more correct?
<LocutusOfBorg> let me reupload
<LocutusOfBorg> http://launchpadlibrarian.net/364567650/mongodb_1%3A3.4.14-3ubuntu1_1%3A3.4.14-3ubuntu2.diff.gz
<LocutusOfBorg> this one looks better to me
<LocutusOfBorg> rbasak, ^^
<Wimpress> tseliot: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/1756226/comments/27
<ubottu> Launchpad bug 1756226 in ubuntu-drivers-common (Ubuntu) "nvidia-driver-390 fails to start GUI" [High,In progress]
<rbasak> LocutusOfBorg: you forgot to run update-maintainer. Please leave it as-is though to save me rebasing again.
<LocutusOfBorg> thanks sure
<LocutusOfBorg> I don't like to run update-maintainer TBH, it makes merges difficult with the usual std-version bumps
<rbasak> AIUI, it's basically a policy requirement to run it for us.
<rbasak> (since that's what Debian concluded they wanted)
<LocutusOfBorg> but what is the effect of this?
<LocutusOfBorg> it is really annoying :/
<nacc> we really don't want bug reports going to debian for ubuntu delta
<nacc> (imo)
<LocutusOfBorg> how can ubuntu-bug report to BTS?
<LocutusOfBorg> I admit I don't report a bug since a lot of times
<rbasak> Some users email the listed maintainer.
<Wimpress> tseliot: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/1756226/comments/28
<ubottu> Launchpad bug 1756226 in ubuntu-drivers-common (Ubuntu) "nvidia-driver-390 fails to start GUI" [High,In progress]
<nacc> LocutusOfBorg: people (regularly) use the listed maintainer
<LocutusOfBorg> seriously? :( this is ankward
<rbasak> LocutusOfBorg: this discussion happened (and was resolved) years ago: https://wiki.ubuntu.com/DebianMaintainerField
<nacc> LocutusOfBorg: we get emails to ubuntu-devel-discuss periodically, for sure
<nacc> (which is what update-maintainer inserts)
<TJ-> there's a script for that!!? I always change it manually :)
<nacc> TJ-: yes :)
<TJ-> ahh, not so relevant to my own private builds though.
<tseliot> Wimpress: ok, so, you seem to have a different problem, which the option certainly doesn't help: (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)
<Wimpress> tseliot: Ah, OK.
<tseliot> Wimpress: so, the nvidia driver is not really working, maybe because your kernel module failed to build (?), and telling X to use nvidia as the main GPU is not going to help
<tseliot> Wimpress: "dkms status" should tell
<Wimpress> tseliot: nvidia, 390.48, 4.15.0-13-generic, x86_64: installed
<Wimpress> virtualbox, 5.2.8, 4.15.0-13-generic, x86_64: installed
<nacc> doko: sigh, ftbfs :/
<tumbleweed> win 32
<tumbleweed> grr
<jbicha> I get emails from people that see my email in the debian/changelogâ¦
<slangasek> jbicha: I get emails from people who see my launchpad ID attached to package removals that I've mirrored from Debian... so... ;)
<jbicha> "thank you" emails I'm sure :)
<tjaalton> ahasenack: hi, is bind9 9.11.3 planned for bionic? I'm seeing a crash on startup when configured for freeipa
<tjaalton> was wondering if it might help
<ahasenack> no, wasn't planning on that
<ahasenack> what kind of crash?
<tjaalton> ../../../lib/dns-pkcs11/view.c:960: REQUIRE(view->zonetable != ((void *)0)) failed
<jbicha> I should start signing my changelogs as "Debian's Automated Developer" https://launchpad.net/ubuntu/+source/libnfs/2.0.0-1~exp1
<tjaalton> I'll check if it's just misconfiguration
<ahasenack> tjaalton: are you in a chroot?
<tjaalton> no, vm
<ahasenack> I mean, is named configured to run in a chroot?
<tjaalton> ah
<tjaalton> don't think so
<ahasenack> check /etc/default/bind9 for the "-t" parameter iirc
<ahasenack> it's not a default
<tjaalton> nope
<teward> bdmurray: i've got a user who wants to test an upgrade from 16.04 to 18.04, and is trying to use `do-release-upgrade -d` to do that, but gets the error "Upgrades to the development release are only available from the latest supported release."  I'm assuming that this is by-design and that a 16.04 -> 18.04 upgrade path won't exist until release?
<teward> nacc suggested I prod you with the question
<bdmurray> teward: it works for me. whats in /etc/update-manager/release-upgrades?
 * nacc considers that a successful referral
<teward> bdmurray: good question, I'll have to get the information.  https://askubuntu.com/questions/1024147/cant-do-release-upgrade-d-from-16-04-to-18-04 is where I'm asking, since it's on my radar as well
 * teward isn't testing the upgrade path yet, himself.
<bdmurray> teward: what I'd say is the answer there
<teward> OP must have a broken system or a broken do-release-upgrade because they said they did that already in response to the answer.
<teward> but i'll keep an eye on it, if there's nothing more they should be doing beyond that answer
<teward> god-forbid something in 16.04 exploded horribly and prohibits the upgrade path
<teward> (does do-release-upgrade work on server as well?  If so I can test a direct upgrade with a 16.04 VM... wouldn't dare do that in a container but... :P)
<bdmurray> then they should maybe remove the cache met-release file
<bdmurray> then they should maybe remove the cached meta-release file
<nacc> teward: yeah it does
<tsimonq2> I did try this myself in a Lubuntu VM the other day; a fresh Lubuntu 16.04 install, fully updated, throws that exact message at me.
<teward> bdmurray: given tsimonq2's statement, maybe this is a larger bug?
<teward> tsimonq2: unless you don't have the latest release upgrader software?
<tsimonq2> teward: Possibly. I'll give it another try.
<teward> because it *looks* like this works, at least in a container.  Will test a dedicated VM later, once I'm at home/
<bdmurray> tsimonq2: clear out your cache in ~/.cache/update-manager-core/ if you get an error
<tsimonq2> bdmurray: ack
<tsimonq2> bdmurray, teward: Ah, it's working now.
<tsimonq2> Specifically, `sudo do-release-upgrade -d` from LXTerminal on a fresh Lubuntu 16.04 install, fully updated.
#ubuntu-devel 2018-04-12
<sarnold> doko: re gcc-8 build failures, https://github.com/mobile-shell/mosh/issues/971
<tjaalton> ahasenack: 9.11.3 fixes the crash, I'll upload the merge
<boichev> anyone having experience with checkinstall ? I am trying to add a php.ini file inside a build from source but at the end it never gets included .... i use --include=/usr/local/php/php.ini or a text file containing this path ...... no success
<ahasenack> tjaalton: oh, cool find
<nacc> LocutusOfBorg: ping
<nacc> LocutusOfBorg: s3cmd does not run, and you appear to TIL (LP: #1763398)
<ubottu> Launchpad bug 1763398 in s3cmd (Ubuntu) "s3cmd package requires python distutils package" [Undecided,Confirmed] https://launchpad.net/bugs/1763398
<nacc> LocutusOfBorg: it appears to have a build- and run-time dependency on python3-distutils that is either not expressed explicitly or is not being parsed
<nacc> LocutusOfBorg: it's also broken in Debian
<ginggs> doko: more distutils fun ^
<nacc> ginggs: ref to the relevant change? was this a python3 change?
<ginggs> nacc: I think it was here: https://packages.qa.debian.org/p/python3.6/news/20180320T071954Z.html
<nacc> ginggs: ah thanks
<nacc> ginggs: and yeah, definitely direct fallout
<LocutusOfBorg> nacc, what I can do?
<nacc> LocutusOfBorg: i guess take my patch in debian so we can sync it later :)
<nacc> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895560
<ubottu> Debian bug 895560 in s3cmd "s3cmd has a runtime dependency on python3-distutils" [Important,Open]
<LocutusOfBorg> ok but why!
<nacc> LocutusOfBorg: if you had been around, i was going to ask you to help me understand the problem :)
<nacc> LocutusOfBorg: python3-distutils is no longer pulled in by python3
<nacc> LocutusOfBorg: https://packages.qa.debian.org/p/python3.6/news/20180320T071954Z.html
<nacc> LocutusOfBorg: you were the uploader to debian, which is why i pinged :)
<LocutusOfBorg> hurray more python fine
<nacc> maintainer, rather
<LocutusOfBorg> sure, I'll upload now
<nacc> LocutusOfBorg: thanks!
<nacc> LocutusOfBorg: i've already uploaded to bionic
<ginggs> nacc: LocutusOfBorg: apparently adding a runtime dependency on distutils is *not* the desired solution
<nacc> ginggs: what is?
<ginggs> nacc: :) this is why I pinged doko, hoping he would explain
<ginggs> nacc: here is an example https://launchpad.net/ubuntu/+source/gpaw/1.3.0-2ubuntu1
<nacc> ginggs: i mean, yeah, sure, if i knew how to fix an upstream, i would have done that :-P
<bdmurray> tsimonq2: how many bugs are you setting to Incomplete? Are you doing it strategically at all?
<tsimonq2> bdmurray: Sorry, what are you referring to?
<bdmurray> tsimonq2: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1152399/comments/3
<ubottu> Launchpad bug 1152399 in ubiquity (Ubuntu) "ubiquity upgrade option failed due to being unable to resolve the upgrade" [Undecided,Confirmed]
<tsimonq2> bdmurray: Ah. I inspected a decent chunk of bugs and put them in a script to set the statuses and leave the comments so I wouldn't have to click over and over and over again. I am finding out that while the majority of the bugs I set were fine, there were a few false ones, which have now been corrected, I believe.
<tsimonq2> Sorry.
<bdmurray> tsimonq2: So you are done then?
<tsimonq2> bdmurray: I was done a week or so ago, yes.
<Wimpress> bdmurray: Any chance this could be merged please?
<Wimpress> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-release-upgrader/ubuntu-mate-bionic-update/+merge/342372
<bdmurray> Wimpress: Does anything need to change for DistUpgrade.cfg.xenial for upgrades from 16.04? (I don't think so but would like a 2nd opinion.)
<Wimpress> bdmurray: No, these changes are good for upgrades from 16.04 or 17.10.
<bdmurray> Wimpress: To be clear the DistUpgrade.cfg file is read when the upgrade is being calculated and the section you are modifying is relevant for packages currently installed on the system so ubuntu-mate-cloudtop should still be in DistUpgrade.cfg.xenial because it is a valid meta package on 16.04.
<Wimpress> bdmurray: OK, I'll add DistUpgrade.cfg.xenial so that ubuntu-mate-cloudtop is accounted for.
<Wimpress> Thanks.
<bdmurray> Wimpress: My point is I don't think you want to add it because it is a valid metapackage for that release.
<bdmurray> s/add/remove it/
<nacc> doko: fyi, netbeans is basically fundamentally broken and ftbfs now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894715
<ubottu> Debian bug 894715 in netbeans "netbeans doesn't start (and exits with error code 2)" [Important,Open]
<nacc> i'm going to check if it ftbfs in debian too, and if not, why not
<jbicha> doko: I reported Debian bug 895574 I assume you understand the issue better than I do
<ubottu> Debian bug 895574 in src:lintian "lintian: binary-compiled-with-profiling-enabled test fails on Ubuntu's armhf" [Normal,Open] http://bugs.debian.org/895574
#ubuntu-devel 2018-04-13
<ehashman> hi I'm a DD and someone randomly RM'd my package from bionic without telling me, can someone help me get it back in
<sarnold> ehashman: which package?
<ehashman> sarnold: leiningen
<ehashman> all the deps need to get synced too I think
<ehashman> source package name is "leiningen-clojure"
<ehashman> it's all stuff in universe
<sarnold> ahh I wondered ... leiningen looks like it was removed in 2014, hehe
<ehashman> yeah
<ehashman> I revived it
<tsimonq2> "(From Debian) RoM; obsolete; request from upstream; Debian bug #761305"
<ubottu> Debian bug 761305 in ftp.debian.org "RM: leiningen: RoM; obsolete; request from upstream" [Normal,Open] http://bugs.debian.org/761305
<tsimonq2> Oh
<tsimonq2> ehashman: From doko: "see Debian #889533, leiningen-clojure not ready for release. remove it + rdeps (cider)"
<sarnold> https://launchpad.net/ubuntu/+source/leiningen-clojure/+publishinghistory
<ubottu> Debian bug 889533 in src:leiningen-clojure "leiningen-clojure FTBFS with libclojure-java 1.9.0~alpha15-1" [Serious,Open] http://bugs.debian.org/889533
<dpb1> heh
<ehashman> tsimonq2: yes, I'm working on that
<sarnold> ehashman: strictly speaking, at this point in the bionic cycle, it might be a fair amount of effort to get it back in. :/ we're well past feature freeze date, so a featurefreeze exception bug would probably need to be prepared
<ehashman> so the issue is that it got RM'd >2 weeks ago but I only found out today
<ehashman> I got everything rebuilding (needed a new clojure because the 1.9 upgrade broke it) but Java 9 seemed to introduce some perf regressions so I was holding off on upload
<sarnold> but like you said, it's a universe package, hopefully it wouldn't be too onerous..
<tsimonq2> sarnold: Feature Freeze doesn't apply to Source NEW unless it's already in the distro
<tsimonq2> Although that's iffy.
<sarnold> tsimonq2: *whooooosh*  :D
<ehashman> I would have gotten to this a lot sooner had I known
<tsimonq2> ehashman: I can sync it as soon as you have a solution uploaded.
<sarnold> slangasek: around? ^^
<ehashman> tsimonq2: thank you muchly, I will send you the list of everything once I get it uploaded and that bug closed, I've prioritized it for tonight
<tsimonq2> ehashman: OK; if I don't respond on IRC, tsimonq2@ubuntu.com
<ehashman> thanks!!
<tsimonq2> Thanks for fixing the package!
<xnox> tjaalton, why has freeipa bump bind9 dep? ubuntu doesn't have that point release bind merged yet.... or maybe ahasenack could quickly merge the new bind9 point release from debian?
<xnox> currently freeipa is not installable in bionic-proposed.
<sarnold> that's one way to cut down on bug reports.. :)
<tjaalton> xnox: because the current version would crash on start if confured via ipa-dns-install
<tjaalton> uh
<tjaalton> configured
<tjaalton> and i merged and pushed the update but it was dirty and got rejected :)
<tjaalton> i'll file a ffe
<tjaalton> slangasek: ^
<slangasek> ok
<slangasek> sarnold: not sure what the tag is for; if it's synced, it goes in the new queue and can be reviewed, but not before then?
<sarnold> slangasek: thanks :)
<baltix-linux> Hi
<baltix-linux> cyphermox: hi, I'm finishing ubiquity and ubiquity-slideshow translations, when you will update tranlations from launchpad for final 18.04 release?
<Mirv> deadline was 9.5h ago theoretically, so it depends on whether there was some scheduled export or if cyphermox will be doing that manually later
<Mirv> s/9.5/12.5/
<Mirv> juliank: if you can help/advise gunnarhj on cryptsetup at https://bugs.debian.org/688735 , please do. it's quite visible i18n problem and if the eventual patch is clean enough I'd think we could consider backporting it to 18.04 eventually too.
<ubottu> Debian bug 688735 in cryptsetup "Some strings need to be set up for i18n" [Wishlist,Open]
<baltix-linux> Mirv: thanks, I found info about dead just today, so, it would be nice if my work was included, because now several strings in ubiquity translations are in english  :)
<baltix-linux> Mirv: in Lithuanian ubiquity translations :)
<baltix-linux> cyphermox: so, will you do manual ubiquity translation export from launchpad today?
<Mirv> baltix-linux: he'll wake up within 5 hours or so, so we'll find out then
<juliank> Mirv: I don't know, not this week certainly
<rbasak> xnox: do you have an opinion on bug 1712817 please?
<ubottu> bug 1712817 in freeradius (Ubuntu) "postinst fails if the service is disabled via systemd" [Low,Invalid] https://launchpad.net/bugs/1712817
<rbasak> Following my comment, on second thoughts, perhaps Debian should arrange invoke-rc.d not to fail if a service is disabled by the user, effectively providing the same behaviour as a policy-rc.d based disablement?
<xnox> rbasak, the description sounds valid. i believe i have hit something similar before, thus yeah a fix to debhelper for this class of issues would be most welcomed.
<rbasak> xnox: thanks. debhelper, or invoke-rc.d?
<rbasak> xnox: and may I quote that message in the bug? :)
<xnox> rbasak, my understanding was that maintainer scripts that are generated, do attempt to check if a thing was "enabled and active" before the upgrade; and post upgrade. But maybe they only do so for systemd native units, and not for init.d->systemd units.
<xnox> rbasak, specifically for ubuntu, i think we need not any init.d / invoke-rc.d stuff, as we can be simply using policy + deb_systemd_helper only.....
<xnox> rbasak, sure, about quotes.
<xnox> ð
<rbasak> Thanks
<rbasak> I've updated the bug and added a debhelper task.
<LocutusOfBorg> tjaalton, are you trying bind9 rebuilds / transition=
<LocutusOfBorg> ?
<tjaalton> LocutusOfBorg: what transition?
<tjaalton> isc-dhcp would need to be rebuilt, that's all
<tjaalton> bind9-dyndb-ldap too of course
<LocutusOfBorg> so tjaalton you will take care of freeipa migration? thanks!
<tjaalton> sure, if it's accepted
<tjaalton> bind 9.12 will bundle all libs in bind-libs, so no more shlib bump rebuilds..
 * mvo hugs rbalint for the latest u-u fixes
<didrocks> mvo: hey! I have a small question about do-release-upgrade. If I get some fixes in do-release-upgrade in bionic, that will end up automatically in the tarball when d-r-u new version is updated for 16.04 users?
<mvo> didrocks: correct, its a custom upload type
<mvo> didrocks: you speak aobut do-release-upgrade itself, not some dependencies of it, right?
<didrocks> mvo: yeah, do-release-upgrade itself :) So, basically, I can just MP at some point, get that into bionic, and then, don't worry, correct?
<mvo> didrocks: yes, the build includes a custom LP upload that makes it end up in the right place
<mvo> jbicha: thanks for your c-n-f upload! would you mind doing a MP with your fix to lp:command-not-found as well? that would be great so that the lp code branch and the archive are in sync
<didrocks> mvo: excellent! Thanks :)
<jbicha> mvo: I just pushed directly now
<mvo> jbicha: thank you!
<rbasak> Is there a place to find the URL to the latest test rebuild?
<rbasak> I find myself always searching for doko's email. I wonder if there's a better wayl
<rbasak> way.
<rbasak> Oh
<rbasak> http://qa.ubuntuwire.org/ftbfs/rebuilds/ maybe
<rbasak> balloons: around? Can you help with golang-github-juju-testing please?
<balloons> rbasak, yea, I've been watching mongodb
<balloons> rbasak, what do you need?
<rbasak> Error parsing command line: unrecognised option '--nohttpinterface'
<rbasak> I suspect that's been dropped in 3.6.
<rbasak> balloons: is golang-github-juju-testing still needed?
<rbasak> I don't see any rdepends.
<rbasak> Was it for the former archive juju package for example?
<rbasak> Hmm.
<rbasak> It's not Ubuntu-only. It was synced from Debian.
<balloons> rbasak, ahh, it was added as build-depends for juju I assume
<balloons> rbasak, yes, we synced golang libs to debian
<rbasak> balloons: so it can be removed now?
<balloons> rbasak, if no one else is depending on it and it ftbfs we could update it, but it makes just as much sense to drop it
<balloons> rbasak, so yes, +1
<rbasak> Unfortunately if it's synced from Debian I'm not sure the AAs will want to just remove it.
<rbasak> I'm not sure to what extent it should be removed from Debian.
<balloons> rbasak, interesting.. it's only in bionic
<cjwatson> It was only added there very recently.
<rbasak> Depends on the Debian Go packaging team's policies I guess.
<rbasak> Maybe a force-badtest would be acceptable though?
<balloons> there's several new juju libs in bionic
<rbasak> I suppose the summary is that the package needs its dep8 test updating to work against mongodb 3.6.
<balloons> That's why I didn't recognize it. I'm not sure who did those uploads
<cjwatson> You can see it in https://tracker.debian.org/pkg/golang-github-juju-testing
<cjwatson> The sync to Ubuntu was automatic
<balloons> right. So mwhudson and I were working through juju's golang needs and getting them into debian
<balloons> But that was some time ago, and I set it aside to pursue the snap
<rbasak> I think I can just drop the --nohttpinterface
<rbasak> AFAICT, the (deprecated) HTTP interface was removed in 3.6.
<rbasak> So presumably not specifying that will result in the same behaviour in 3.6.
<rbasak> Aha: https://github.com/juju/testing/commit/1f2396685494ccf2c5079936561a70652ef78111
<balloons> rbasak, yes, pulling in the newer version makes more sense if you want it to work with 3.6
<rbasak> balloons: I'm looking at just cherry-picking that fix.
<balloons> ahh right..
<balloons> it's actually tiny
<rbasak> I don't see the point in pulling in the newer version if nobody actually needs it.
<rbasak> The package might be a candidate for orphaning in Debian.
<balloons> rbasak, there's many new github-juju*-dev packages in bionic
<balloons> 15 looks like?
<rbasak> I got a pass with this: http://paste.ubuntu.com/p/kVK4Fdn3Ry/
<cjwatson> orphaning> seems like a bizarre response in the case of something that was first uploaded a couple of months ago
<cjwatson> orphaning is a response to not being maintained, which normally requires longer than that
<rbasak> cjwatson: yeah, though AIUI balloons and mwhudson are no longer interested in maintaining the package in Debian (or Ubuntu) because they've switched to snaps instead?
<cjwatson> if it shouldn't be in Debian then the correct response would be to ask the maintainer about having it removed
<rbasak> And it's a Juju-specific package.
<cjwatson> rbasak: they're not the Debian maintainer, so that's not terribly relevant
<cjwatson> they weren't maintaining it in Debian to begin with :)
<rbasak> I'm under the impression that mwhudson is a member of the Go packaging team in Debian.
<balloons> yes, indeed. That's why I was surprised to see it
<bdmurray> andyrock: What release of Ubuntu would you want a version of plymouth to test with?
<cjwatson> perhaps, but he has no involvement in the changelog of that package.
<rbasak> Oh
<rbasak> I missed that.
<andyrock> bionic is fine
<rbasak> I assumed it was uploaded via balloons and mwhudson.
<cjwatson> I certainly would not assume that e.g. everything in the Python modules packaging team was maintained by me, even though I could work on if if I wanted
<cjwatson> *on it if
<balloons> right. To be clear, I have no knowledge of those packages, and as cjwatson pointed out, mwhudson didn't push it either
<andyrock> bdmurray: I can test it in few hours
<rbasak> Can I get a peer review from someone for http://paste.ubuntu.com/p/kVK4Fdn3Ry/ please?
<rbasak> It builds and passes autopkgtest for me locally. And I locally reproduced the current failure, too.
<cjwatson> rbasak: LGTM
<rbasak> Thanks. I'll upload.
<rbasak> And submittodebian.
<rbasak> That should unstick mongodb 3.6 hopefully.
<balloons> thanks rbasak
<rbasak> balloons: np. It has built. Now we wait a couple of publisher runs I think.
<rbasak> balloons: I'm nearing EOD now, so I'll have to resume on Monday to get this landed if necessary.
<balloons> rbasak, no worries. I very much appreciate you getting this landed, and doing so quickly
<balloons> rbasak, we'll plan to get juju 2.4-beta1 first thing next week as weel
<jbicha> slangasek: for an especially serious example of the GNOME Software issue, see bug 1756788
<ubottu> bug 1756788 in gnome-session (Ubuntu) "Removing "Startup Applications" in "Ubuntu Software" makes the system unable to launch GDM" [High,Fix released] https://launchpad.net/bugs/1756788
<jbicha> there is a shiny "Remove" button in the Installed list in GNOME Software and eventually some users are going to click that button
<slangasek> heh
<jbicha> when it's clicked, GNOME Software happily removes the package using PackageKit
<jbicha> it the package is say, update-manager, then PackageKit will remove ubuntu-desktop because ubuntu-desktop has depends: update-manager set
<jbicha> GNOME Software does not tell the user that things like this are happening
<slangasek> right; I share bdmurray's unease with the shape of the solution, however
<jbicha> but if we add the compulsory_for_desktop field to AppStream metadta, then the app is marked as a System Application and we avoid this issue
<slangasek> i.e. we work around a bug in GNOME Software by having to touch every package to manually tell it to not be dumb
<jbicha> the design of GNOME Software is a much larger and older issue than we can hope to change much before bionic's release :(
<slangasek> why ship these appstream files in the individual packages instead of in gnome-software itself?
<jbicha> because gnome-software isn't the source of packages
<slangasek> no, it's the source of the damage
<jbicha> I mean sure it could ship its own whitelists for this issue
<jbicha> but appstream metadata in general should be shipped with the individual app
<jbicha> the compulsory field is controversial; some users really want to remove system apps
<slangasek> if there's a reason to ship that metadata in the first place, which it's unclear to me that there is other than this bug
<slangasek> and the "compulsory"ness is a function of the flavor metapackage, not of the application
<jbicha> yes
<jbicha> you should probably talk to ximion if you have concerns about appstream ;)
<slangasek> which means that if the seeds change to drop a package, and the package's appstream is not updated, it becomes buggy again
<slangasek> I don't think the concern I'm expressing is about appstream; it's about relying on appstream to work around gnome software not dtrt with distro policy
<jbicha> ok, then talk to hughsie or Laney or robert_ancell ;)
<slangasek> Laney: hi I talk to you
<slangasek> :)
<jbicha> lol, he's probably trying to enjoy his weekend
<slangasek> he's probably used to me spoiling that
<jbicha> yeah, I guess this is really bad for Lubuntu if Lubuntu users want to try to use GNOME Software
<jbicha> yet more fun from Lubuntu not wanting to use Recommends yet :)
<jbicha> we've had this issue since 2016 though
<jbicha> ximion: the context is https://lists.ubuntu.com/archives/ubuntu-devel/2018-April/040278.html
<bdmurray> Isn't it bad for any flavor that uses GNOME software though?
<ximion> jbicha: I have seen that mail :-)
<ximion> slangasek: what is compulsory or not is set by the upstream project, usually
<slangasek> ximion: that's nonsense
<slangasek> we as a distribution define what is compulsory for our desktop flavors
<ximion> GNOME Software intentionally has no idea about what the distribution does, and I am pretty sure that hughsie wouldn't be happy to implement anything that involves parsing a lot of package dependencies
<slangasek> and that definition lives in the metapackages, not in the individual components
<jbicha> bdmurray: it's not too bad for Budgie or Unity which have pretty similar Depends to Ubuntu
<ximion> that was my argument - sort of - when we added the feature a while back, but certain things like the GNOME Shell etc. are always compulsory, and that is what compulsory_for_desktop should primarily be used for
<jbicha> but   apt show lubuntu-desktop  is a bit horrifying when considering this issue
<ximion> i.e. stuff that you would only display in the software center to e.g. display addons, but which you would otherwise not even display there because it essentially is a system component
<jbicha> ximion: off-topic, but do you know why there is an LXDE warning here? http://appstream.ubuntu.com/bionic/main/issues/update-manager.html
<slangasek> ximion: I think juliank's proposal is that something could instead synthesize the 'compulsory' bits from apt metadata and inject that information into gnome-software, perhaps via appstream; but that would require us to be able to provide appstream "overrides" for apps that do ship their own appstream data for other reasons
<slangasek> I'm not sure if that's supported?
<ximion> jbicha: apparently LXDE wasn't registered as a DE when the list of environments was last updated... I fixed this upstream now, thanks for noticing!
<jbicha> ximion: which upstream? asgen?
<jbicha> (update-manager and software-properties are the first and only things to use compulsory for LXDE that I can see)
<ximion> jbicha: AppStream itself - you can use LXDE as value though, this is just a validation warning (so it won't filter LXDE out)
<ximion> slangasek: we support something like that (overriding and extending metadata) - this would require APT to have detailed knowledge on which packages are important (essentially treating metapackages like ubuntu-desktop specially) and it would also need to know how to write AppStream metadata
<ximion> we could in theory also have the appstream-generator read the Germinate seed files, and have it synthesize compuksory tags for packages with components that are explicitly mentioned in there
 * ximion can't reply to stuff on ubuntu-devel or ubuntu-desktop though with proposals like that
<juliank> oh, missed the discussion here
<jbicha> (sorry I forked the conversation)
<slangasek> ximion: we have lots of knowledge in apt already about which packages are special; it's kind of meant to be authoritative about this ;)
<ximion> slangasek: the regular standard/essential/etc. priorities for packages don't usually apply to desktop metapackages though, like ubuntu-desktop, because you sometimes want a different DE
<ximion> or do you really have rules like "if that package is installed, it should stay installed" somewhere?
<juliank> ximion: But we can special case <foo>-desktop
<juliank> And yes, we do, but we use it for more important stuff
<ximion> I remember that in the past apt would let mre remove any Ubuntu metapackage without any problems
<slangasek> ximion: we do have such rules in the release upgrader.  I don't think a high-level frontend like gnome software should touch any desktop metapackages, and if you really want to do that you can use apt from the commandline
<ximion> I agree it shouldn't remove them, but as of now, GNOME Software has no way of knowing that ubuntu-desktop is special
<ximion> PackageKit is essentially as smart as apt on the command-line here
<juliank> is it?
<ximion> jup - "smart"
<jbicha> apt at least tells you what it's doing (although lots of users don't understand the significance of 'ubuntu-desktop' in its output)
<jbicha> bdmurray: did you see https://code.launchpad.net/~jbicha/apport/drop-py2/+merge/343218 or did you want to wait for Chaotic for that?
<ginggs> tsimonq2: nodejs  8.11.1~dfsg-2 was uploaded to unstable
<tsimonq2> ginggs: You can follow through with the transition yourself? ;)
<ginggs> tsimonq2: sync it
<tsimonq2> ginggs: No you. :P
<ximion> jbicha: PK would tell you that, but this information not showing up is a GNOME design decision
<ximion> (AFAIK KDE Discover started to display that information for updates, at least)
<slangasek> ginggs, tsimonq2: don't worry, nodejs is seeded on kubuntu, I'll reject with prejudice :P
<ximion> some smart mechanism to prevent desktop metapackage removals would be nice
<ginggs> tsimonq2: it's probably a good idea for us to not have a version from experimental - there's probably very little that's changed since the last version - and it's weekend and the autopkgtest queues are empty
<ginggs> i'll help with the migration if slangasek let's it in
<ginggs> *lets - aargh
<slangasek> ginggs: final freeze and it's seeded, you're going to have to have a specific rationale in terms of source changes for me to let it in rather than just the upload target listed in debian/changelog
<ginggs> tsimonq2: will you take care of that?
<jbicha> ginggs: it won't even build on bionic unless you also sync http-parser. you probably do not want the new version of nodejs
<tsimonq2> slangasek: hahahaha
<tsimonq2> ginggs: No. :P
<tsimonq2> I won't touch it with a ten foot pole.
<ginggs> jbicha: I do not want any version of nodejs :p
<jbicha> ginggs: how about haskell?
<ginggs> jbicha: not my thing either
<tsimonq2> Funny we talk about new transitions... *nudges acheronuk*
<tsimonq2> I totally don't plan on doing a Qt transition last minute... :P
<tsimonq2> (/s)
#ubuntu-devel 2018-04-14
<Whoopie> Hi, I see an issue with ldconfig that it can't follow symlinks in /etc/ld.so.conf.d, e.g. the virtualbox-guest-x11 package adds an alternatives link into this folder and ldconfig shows:
<Whoopie> http://paste.debian.net/1020221/
<Whoopie> http://paste.debian.net/1020222/
<Whoopie> this is under ubuntu 18.04, it works under 16.04
<joelkraehemann> hi all
<joelkraehemann> https://launchpad.net/ubuntu/+source/gsequencer/1.4.24-1ubuntu1
<joelkraehemann> ^^ you can't run the functional tests parallel
<joelkraehemann> There is a good reason why they were excluded from build
<joelkraehemann> xvfb-run --server-args="-screen 0 1920x1080x24" -a dh_auto_test
<joelkraehemann> 	make -j4 -O check VERBOSE=1
<joelkraehemann> ^^ this won't work
<joelkraehemann> https://launchpadlibrarian.net/365175407/buildlog_ubuntu-bionic-s390x.gsequencer_1.4.24-1ubuntu1_BUILDING.txt.gz
<tsimonq2> joelkraehemann: If you have a debdiff fixing this, I will happily sponsor it.
<joelkraehemann> tsimonq2: It is here https://salsa.debian.org/multimedia-team/gsequencer/blob/master/debian/patches/disable-functional-tests.patch
<joelkraehemann> the person running the build disabled the patch by intention
 * tsimonq2 grabs the Ubuntu source
<tsimonq2> joelkraehemann: It's in the series file here...
<tsimonq2> Hmm.
<joelkraehemann> sorry my mistake
<joelkraehemann> https://launchpadlibrarian.net/364133581/fix-missing-symbol.patch
<tsimonq2> That's also in the series file. :P
<joelkraehemann> the tests are enabled, again
<tsimonq2> ohhhh
<joelkraehemann> I provide a fixed patch, soon
<tsimonq2> OK.
<tsimonq2> Ping me and I'll be happy to upload it.
<joelkraehemann> https://launchpadlibrarian.net/365263160/fix-missing-symbol.patch
<joelkraehemann> tsimonq2: I just removed the wrong part of the diff
<tsimonq2> joelkraehemann: Uploaded.
<joelkraehemann> tsimonq2: thank you
<joelkraehemann> everything is fine, now
<joelkraehemann> https://launchpad.net/ubuntu/+source/gsequencer/1.4.24-1ubuntu2
<tsimonq2> \o/
<mwhudson> rbasak, balloons: yeah i have no idea who uploaded to debian or why, it certainly wasn't me!
<mwhudson> i am in the debian go team though so i *can* upload it if required...
<jbicha> mwhudson: sorry to bother you on the weekend, but could you look into bug 1759540 when you can? I guess that's waiting on you now?
<ubottu> bug 1759540 in ubuntu-report (Ubuntu) "[MIR] ubuntu-report: send telemetry data to ubuntu server" [Undecided,New] https://launchpad.net/bugs/1759540
<mwhudson> jbicha: ok, tomorrow :)
<jbicha> juliank: could you look into the apport autopkgtest failures? test_install_package_from_a_ppa
<jbicha> maybe the problem is "WARNING: cannot connect to: https://api.launchpad.net/devel/~fooser/+archive/ubuntu/bar-ppa"
#ubuntu-devel 2018-04-15
<ehashman> tsimonq2: just emailed you. leiningen is still incoming into the archive, but it's uploaded/built/accepted
<tsimonq2> ehashman: ack
<tsimonq2> ehashman: I can't sync it to Ubuntu (unless I do it manually, which I'd prefer not to do unless it needs to go in *now*) until dinstall + ~ 2 hours.
<ehashman> cool
<tsimonq2> But yeah, I'll get it done. :)
<tsimonq2> Thank you!
<tsimonq2> ehashman: To save me some time, what's your LP ID?
<ehashman> should also be ehashman
<tsimonq2> OK
<tsimonq2> dinstall *seems* to be running now, so let's see if it was picked up or if we'll have to wait.
<tsimonq2> ehashman: I'll sync these in your name when the time comes, if that's OK?
<tsimonq2> (It helps should you ever want upload permissions to these in Ubuntu in the future (let me know if you do, I can give you a hand if you want).)
<ehashman> sounds good!
<tsimonq2> Cool :)
<tsimonq2> ehashman: Took care of your syncs.
<ehashman> tsimonq2: just saw! looks like it didn't grab the most recent leiningen (2.8.1-6); if you could syncthat one I'd appreciate it, as 2.8.1-5 only works on amd64
<ehashman> finally got installed in the archive
<ehashman> *11
<krytarik> ehashman: You might want to have a look at the build failure of that in the meantime though: https://launchpad.net/ubuntu/+source/leiningen-clojure/2.8.1-5/+build/14761232
 * ehashman looks
<ehashman> looks like a dep is missing
<ehashman> if only I knew which one :(
<ehashman> are there docs for creating a bionic-proposed schroot?
<ehashman> oh maybe I'll just make a bionic one and then edit it to point at bionic-proposed
<jbicha> ehashman: leiningen-clojure builds now. I guess clojure1.8 just needed to be rebuilt
<ehashman> ah perfect
<ehashman> I was tearing my hair out trying to figure it out, lol
<ehashman> mostly because I could not get a bionic-proposed sbuild working :)
<jbicha> Java packages are more broken than usual for this point of the release cycle because of the late Java 10 transition
<jbicha> you might find sbuild-launchpad-chroot helpful
<ehashman> as I said on twitter: java 9? more like java NEIN
<ehashman> I had to pin this package to java 8 because upstream doesn't support anything newer
<ehashman> the java transition was causing all kinds of weirdness :|
<ehashman> does ubuntu also run autopkgtests?
<jbicha> yes and autopkgtest regressions on any arch will block promotion out of -proposed
<jbicha> https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html
<jbicha> Ubuntu doesn't do a 5 day wait during the dev cycle but it does do autopkgtests :)
<jbicha> leiningen-closure will need to be manually approved by Archive Admins since it is a new binary package
<jbicha> https://launchpad.net/ubuntu/bionic/+queue?queue_state=0
<ehashman> jbicha: hrm
<ehashman> it's technically not "new", it was in bionic after the freeze
<ehashman> someone removed it without telling me
<ehashman> hopefully won't cause any issues
<jbicha> https://launchpad.net/ubuntu/+source/leiningen-clojure/+publishinghistory
<ehashman> yeah, I found out about the thing from March 25th last Thursday
<jbicha> I don't think it will be a problem. I was just letting you know why it will appear stuck for a bit
<ehashman> I appreciate it :)
<jbicha> I don't know what tools-nrepl-clojure's problem is though
<jbicha> https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_output.txt
<ehashman> O
<ehashman> I'll also let spwhitton know about cider
<ehashman> jbicha: I know what tools-nrepl-clojure's problem is
<ehashman> I screwed up a breaks/replaces in clojure1.8 and switched the dep from clojure to clojure1.8
<ehashman> so the upgrade fails
<ehashman> but I need to test the fix
<ehashman> afk
<jbicha> ehashman: I suspect that leiningen-clojure 2.8.1-6 is still wrong. It's an arch: all package that tries to use the amd64 java
<jbicha> see for instance http://autopkgtest.ubuntu.com/packages/l/leiningen-clojure/bionic/i386
<jbicha> never mind, I guess it workedd
<ehashman> jbicha: that build appears to be passing, I think you might have seen the 2.8.1-5 build
<ehashman> 2.8.1-5 I stupidly pinned to amd64, fixed it in 2.8.1-6
<ehashman> http://autopkgtest.ubuntu.com/packages/leiningen-clojure suggests it's passing on all arches now
<zerorax> hey, how do I go about making my own ubuntu variant?
<zerorax> I mean, I know how to make it
<zerorax> but I want it to be recognized like Lubuntu Xubuntu Kubuntu
<zerorax> I want to go through the proper channels and make it official
<jbicha> zerorax: https://wiki.ubuntu.com/RecognizedFlavors#Guidelines_to_become_and_remain_a_recognized_flavor:
<zerorax> thanks jibel
<zerorax> I want to make an enlightenment based flavour
<zerorax> I know there is bodhi linux, but I don't think they did a good job
<zerorax> and e17 is really old, it's in the repos but I want a newer release
#ubuntu-devel 2019-04-08
<cpaelzer> cjwatson: seeing you reminded me to ask for bug 1822370
<ubottu> bug 1822370 in openssh (Ubuntu Disco) "19.04 beta openssh-client broken pipe" [Critical,Triaged] https://launchpad.net/bugs/1822370
<cpaelzer> there was no further debian response that I'd have seen
<cpaelzer> but since we final freeze in 3 days I was wondering if you considered uploading that to Buster now (or not)
<cjwatson> cpaelzer: Yes I am considering it and was already looking at it before you pinged
<cjwatson> Please stop asking for a while :)
<cpaelzer> :_/ ok
<cpaelzer> even my nose seems to slip out of my smiley face in shame
<doko> https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.tag=cc-tc-updates
<doko> cpaelzer, jamespage, coreycb: while this is cosmic, these are the python 3.6.8, 3.7.3 and 2.7.16 updates also planned for bionic. Any comment which ones should be fixed, and which ones could be ignored would be welcome
<jamespage> doko: glance will need fixing - the errors look familiar
<jamespage> that ceph failure is odd
 * jamespage digs further
<rbasak> cpaelzer: were you involved in libapache2-mod-shib2 libcurl3/4 thing? Or was that ahasenack? Bug https://bugs.launchpad.net/ubuntu/+source/shibboleth-sp/+bug/1822069.
<ubottu> Launchpad bug 1822069 in xmltooling (Ubuntu) "SRU: Shibboleth SPv3 for bionic" [Undecided,New]
<doko> jamespage: this is using ppa:ubuntu-toolchain-r/ppa
<jamespage> ack
<jamespage> doko: the ceph failure is from the version in the release pocket rather than the -updates pocket - was that intentional?
<doko> jamespage: ahh crap, wrong name for the updates archive. my script didn't error out on a missing archive :-/
<jamespage> doko: I think the one in the release pockets probably already FTBFS - ceph got stuck in proposed for most of that cycle
<jamespage> the glance failures look familiar as well
<jamespage> bug 1800601
<ubottu> bug 1800601 in glance (Ubuntu Disco) "[SRU] Infinite recursion in Python 3" [Critical,Fix released] https://launchpad.net/bugs/1800601
<jamespage> yeah that was done as an SRU post cosmic release
<doko> now regenerated http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190404-gcc8-cosmic.html
<doko> there are no regressions with the planned toolchain updates :-)
<doko> sorry for the noise
<cpaelzer> rbasak: I had nothing to do with the bug that you listed
<cpaelzer> was it the right bug number?
<cpaelzer> rbasak: do you know https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1823665 which doko was asking about above?
<ubottu> Launchpad bug 1823665 in mysql-5.7 (Ubuntu) "mysql-5.7 ftbfs with cosmic toolchain updates (amd64, i386 only)" [High,New]
<rbasak> cpaelzer: no I know that's a new bug - but it's connected to the previous work on libapache2-mod-shib2 and libcurl3/4 which I think someone was dealing with - hence my question.
<rbasak> Skuggen: could you take a look at bug 1823665 please?
<ubottu> bug 1823665 in mysql-5.7 (Ubuntu) "mysql-5.7 ftbfs with cosmic toolchain updates (amd64, i386 only)" [High,New] https://launchpad.net/bugs/1823665
<doko> cpaelzer, rbasak: that's fixed in -updates. my bad
<rbasak> Ah, no worries.
<rbasak> Skuggen: cancel the above please :)
<doko> so just one symbols file regression with the proposed updates. better than expected
<Skuggen> Best kind of issue; The kind that's fixed before I become aware of their existence
<tsimonq2> cyphermox, xnox: Currently GRUB2 doesn't support LUKS2, as enabled by default in the recent cryptsetup release. I understand investigations are still being done into true FDE with Ubiquity, but in Lubuntu and very likely most custom installations, this simply won't work. Would either of you object to me building cryptsetup with LUKS1 as default until GRUB2 gets support?
<cjwatson> Oh is that what that is
<cjwatson> tsimonq2: If you're doing that could you also chase it with Debian?
<cjwatson> Assuming LUKS2 being the default explains the various reports I've seen about buster
<cjwatson> Or maybe it should be done in partman-crypto instead?
<cjwatson> Though https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919725 has a comment about wanting d-i's default to match cryptsetup's, which makes sense
<ubottu> Debian bug 919725 in cryptsetup "cryptsetup: switch to LUKS2 by default for new installs" [Wishlist,Fixed]
<cjwatson> I think Debian must have the same problem and it's surely release-critical
<cjwatson> https://savannah.gnu.org/bugs/?55093 too
<tsimonq2> cjwatson: ack, Ubuntu's release is sooner though :)
<tsimonq2> I'll happily file a bug there too
<infinity> Disturbingly soon for this to be "just" coming up as a thing.
<tsimonq2> Better than release week.
<cjwatson> it became the default last month or so I think?
<cjwatson> the spec (https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/on-disk-format-luks2.pdf) looks vaguely tractable but I won't have time to even think about it for a week or two at least
<infinity> Is there a bug filed detailing the interactions here between cryptsetup, installers, grub, what needs changing, how to make sure they all agree?
<tsimonq2> No, just a feature request in GRUB upstream.
<infinity> Will flipping cryptsetup back make everything just go back to how it was in cosmic?
<cjwatson> Pretty sure what needs changing is "configure cryptsetup with --with-default-luks-format=LUKS1"
<infinity> Cause +1 on that, if so.
<cjwatson> But obviously wants testing
<tsimonq2> cjwatson: Exactly.
<cjwatson> I think the cryptsetup people in Debian just forgot that GRUB parsing LUKS is a thing
<tsimonq2> I'll be happy to look this afternoon and file a block-proposed bug, unless either of you volunteer.
<infinity> tsimonq2: Please make it so.
<tsimonq2> Alright.
<infinity> "LUKS1 can be in-place-converted to LUKS2 in most cases."
<infinity> So, users are going to do this to themselves?
<infinity> Excellent.
<LeoB> cpaelzer, hello! I need to build libvirt packages for a ppc64el machine, in order to test it, but it fails when I try building on ppc64le. Error message https://paste.ubuntu.com/p/M5dwXvjbFF/
<cjwatson> Yeah, now that I've realised this is a problem I may see if I can manage an implementation in GRUB
<cjwatson> The LUKS1 code is only 485 lines
<LeoB> cpaelzer, *test a patch
<TJ-> infinity: cjwatson There's a related initramfs-tools issue too, for LUKS2: Bug #1813295
<ubottu> bug 1813295 in cryptsetup (Ubuntu) "initramfs-tools MODULES=dep causes LUKSv2 unlock to fail" [Undecided,Confirmed] https://launchpad.net/bugs/1813295
<cjwatson> OK, at least that's different in kind because that doesn't involve another LUKS parser :)
<TJ-> :) I like to make life easy for you
<TJ-> FYI, I'm managing LUKS systems with separate /boot/ and LVM, and learned (last August) the hard way that /boot/ has to be LUKS1 whilst LVM can be LUKS2 ! I thought I reported a bug on it but cannot find it now.
<cyphermox> I thought we'd already changed that to MODULES=most
<cyphermox> ah maybe not
<jamespage> roaksoax: https://bugs.launchpad.net/ubuntu/+source/python-libmaas/+bug/1823718 ;)
<ubottu> Launchpad bug 1823718 in python-libmaas (Ubuntu) "Installation fails with Python3.7 SyntaxError on Ubuntu Disco" [Undecided,New]
<sil2100> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<TJ-> cyphermox: re: MODULES=most, yes that is the default, but I prefer to use 'dep' since the initrd.img does not need almost every module and supporting firmware image (combined with my own pruning code it reduces initrd.img from ~60MB to ~15MB - a nice saving in both build and boot-time
<xnox> tsimonq2, cjwatson, cyphermox - no, we should default to luks2.
<xnox> tsimonq2, cjwatson, cyphermox - grub has luks1 support, but we don't build that module into grub-signed, therefore on secureboot systems currently on Ubuntu one cannot have encrypted /boot.
<xnox> tsimonq2, cjwatson, cyphermox - thus in ubuntu, there is no regression w.r.t. luks1->luks2 switch. Luks2 is better, and has better defaults for key derivation functions. it is more logical to request/implement luks2 in grub.
<tsimonq2> xnox: When's the last time you checked that?
<tsimonq2> Also, that doesn't apply on BIOS.
<xnox> tsimonq2, cjwatson, cyphermox - also we will be requiring and using luks2 in core20.
<wxl> hopefully grub will be compatible by then :/
<TJ-> tsimonq2: what xnox says affects all my systems (signed GRUB not including the luks/cryptodisk/gcry_* modules)
<xnox> tsimonq2, cjwatson, cyphermox - also there are trivial options you can pass to force luks1 if you want to downgrade security/crackability of the default fde setup.
<tsimonq2> TJ-: Have you checked with Disco?
<xnox> tsimonq2, disco uses luks2 by default, and there is no luks2 support in grub yet. end of story =)
<tsimonq2> No, not end of story. :)
<tsimonq2> That's called a regression.
<xnox> tsimonq2, are you telling that we should downgrade default security of all Ubuntu installations because of Lubuntu on bios?
<tsimonq2> LUKS as implemented by default in Ubuntu worked with GRUB in Cosmicm
<tsimonq2> *Cosmic.
<tsimonq2> No, I'm not saying that.
<xnox> tsimonq2, and still does. for /, and we do require separate unencrypted /boot.
<xnox> as we did before, and still do.
<xnox> unless i am missing something, and we started to encrypt /boot somewhere.
<tsimonq2> Are you suggesting Lubuntu downgrades security because Ubuntu is too fast in switching to LUKS2?
<xnox> i don't believe neither partman, ubiquity, or subiquity do that.
<tsimonq2> Nope.
<cyphermox> there's a simpler story to this right now, i think
<xnox> tsimonq2, luks2 support was added in bionic, and make default in disco. Sounds the right speed, as any bionic system can luks2-unlock.
<wxl> what *requirement* is there for luks2 at this point? besides "it's nicer"
<xnox> s/make/was made/
<tsimonq2> wxl: +1
<tsimonq2> I'm not saying we carve out support.
<wxl> making luks1 the default does not remove the ability to use luks2
<xnox> wxl, it's harder to crack open; and it stores more info/parameters about the volume in the header (with bigger header), thus it's easier to unlock it correctly without destroying data without having a matching crypttab.
<TJ-> tsimonq2: No, not tested with Disco - It looks like disco-devel does include the modules from the debian/build-efi-images script
<tsimonq2> infinity: You were involved in this discussion as well. ^
<wxl> xnox: that all falls under "it's nicer"
<cyphermox> xnox: tsimonq2: TJ-: the partitioning schemes we currently support on everything but calamares are such that grub doesn't need to read luks
<cyphermox> ie. "supported installs with disk encryption" are where there's a separate /boot that is unencrypted, for better or for worse, at the moment
<cyphermox> the way I see this, calamares doing this differently is not sufficient rationale for changing the default to luks1 everywhere, especially this late in the cycle
<cyphermox> the way I see this, it's more like rationale to patch calamares to specify it wants luks1, somehow
<cyphermox> (this may or may not require some work in luks to let you set that, I don't know)
<xnox> tsimonq2, i kind of fail to see the poing of encrypting /boot, when ESP is not encrypted. and if calamares really only wants to manage a single encrypted volume, put the grub.cfg vmlinuz and initrd on the ESP.
<tsimonq2> Upstream has rejected that, Manjaro and Fedora are facing the same issue.
<wxl> of course an unencrypted /boot can lead to exposed keys, no?
<xnox> wxl, how?
<cyphermox> xnox: you could potentially have a compromised initrd.
<xnox> wxl, in bios you have compromised grub
<cyphermox> tsimonq2: upstream has rejected what?
<xnox> cyphermox, yeah, but i don't see how it could be protected. cause grub is still unencrypted.
<tsimonq2> cyphermox: Explicitly defining LUKS1.
<cyphermox> tsimonq2: sure, but we can distro patch that
<wxl> distro patching for something that's not entirely necessary is a bit of a pain
<cyphermox> tsimonq2: what I'm advocating for is "reducing the security" where it potentially makes the least damage
<cyphermox> wxl: I'd like to hear the security team on this, but I don't believe moving back to luks1 everywhere is necessarily better
<cyphermox> I understand it's a recent change, so YMMV
<wxl> yeah i would, too
<xnox> luks1 doesn't support persistent encryption / paes / zkey on s390x.
<tsimonq2> +1
<wxl> perhaps that's the next step
<wxl> i won't argue that luks2 has advantages
<wxl> i mean it does
<cyphermox> what I'm saying is: right now it kinda looks like it's easier/safer to patch calamares and only affect calamares, than change a default and affect every install of 19.04.
<xnox> tsimonq2, wxl - to me it seems like an oversight, that calamares was using/relying on partitioning setups that no ubuntu flavours ever did, or were supported by ubuntu/foundations.
<cyphermox> wxl: tsimonq2: TJ-: then once grub has support for dealing with LUKS2 in E; we can remove that patch
<xnox> and if lubuntu defaults luks1, when ubuntu enables tpm2 / secureboot / measured boot -> it wouldn't work on lubuntu installs.
<xnox> to counter cyphermox's proposal, i'd rather have calamares create unencrypted /boot, until grub2 gains luks2 support.
<wxl> wait a minute.. since building the luks1 as default means luks2 is available, couldn't we rework ubiquity et al to call cryptsetup to use luks2 explicityly and all would be fine?
<xnox> wxl, no. as it's not just ubiquity.
<wxl> thus "et al"
<cyphermox> wxl: we could, but that's still changing "every install" rather than limiting the change to lubuntu
<TJ->  mad idea but... could GRUB be side-stepped for the specific LUKSv1 scenario in favour of a direct SecureBoot of vmlinuz ?
<xnox> wxl, it's udisks2, gnome-disks, partman-crypto, ubiquity, s390-tools zkey, and many 3rd party disk encrptyion and key escort tools (floss and proprietary).
<cyphermox> TJ-: only if you want to keep all three pieces
<wxl> cyphermox: but that would be a minor change and one that even with luks2 as the default would not likely make any difference
<cyphermox> TJ-: it's "possible", but it imposes a lot of work on your users
<TJ-> cyphermox: yeah, I did say it was mad :D
<cyphermox> wxl: I'm not sure I follow
<xnox> TJ-, our vllinuz is signed with canonical key, so you'd need to mess with MOK to enroll canonical's keys into secureboot.... which at the mometn has ugly ux, but doable.
<tsimonq2> Lubuntu is between a rock and  a hard place here. Upstream won't default to LUKS1 as default, and says "build cryptsetup differently downstream." Both of you are NACKing it, even though it shipped this way in every supported stable Ubuntu release. If there's a security problem here, it should be in all releases of Ubuntu, not just Disco. Lubuntu has had repeated conversations with the release team
<TJ-> xnox: true too :)
<tsimonq2> in which it was understood that Foundations couldn't support Calamares, but we're welcome to fix our own stuff. This isn't even a Calamares issue as much as it's a GRUB issue; if someone does custom partitioning, they'll likely face this as well.
<wxl> cyphermox: there's two ways to essentially toggle between luks1/2.. compile cryptsetup with the default you want.. or call cryptsetup with the explicit version
<xnox> TJ-, also one would loose grub benefits of fallbacks / recordfail which are standard on *buntu.
<tsimonq2> It's too late in the game for Lubuntu to switch back to Ubiquity.
<TJ-> xnox: yes, I was just trying to come up with a novel sneaky way past the issue
<cyphermox> wxl: yes
<cyphermox> wxl: changing one installer or another is relatively equivalent
<xnox> tsimonq2, i do not believe for a second, that changing a cryptsetup command in calamares to '--format=luks" or changeing the default recipy to have '/boot' in calamares, as a distro patch, is somehow "non-trivial"
<xnox> *luks1 that is.
<wxl> cyphermox: so the installers could simply call cryptsetup with the explicit version call, regardless of what the default version is
<xnox> wxl, sure, but sensible defaults should always be there. Otherwise systems become unusable.
<wxl> moreover, if luks2 became the default, the explicit call wouldn't need to be fixed.. it would still work
<xnox> wxl, and relying on luks1 in grub, is well, not a sensible thing. plus what did calamares do before? because surely luks1 was not in grub in like bionic? was it?
<cyphermox> personally, I'm naking the change based on 'it's better to affect a single flavour with a change than all of them'
<cyphermox> wxl: again, I got lost. isn't the default luks2 now?
<tsimonq2> xnox: Yes, it was.
<cyphermox> and installers all DTRT with default calls?
<xnox> tsimonq2, ack.
<TJ-> wxl: yes; that's how I recovered the two times this bit me last year before I had it in my mind to always force LUKSv1 for /boot/
<tsimonq2> GRUB2 supports LUKS1.
<wxl> cyphermox: right. and we're asking for luks1 to be the default.
<cyphermox> except calamares, because it partitions things differently than all the other installers
<xnox> wxl, what you are really asking is for /boot to be luks1
<xnox> wxl, imho, the best thing for calamares to do is unencrypted bios or ESP, then luks1 /boot, then luks2 for the rest.
<cyphermox> xnox: /boot is no different than / in their setup I think.
<cyphermox> and moving things around is even more work.
<cyphermox> (and even more uncertainty)
<xnox> sure sure, but well quickly write luks2 support partch into grub, is not gonna happen before release.
<wxl> exactly
<tsimonq2> xnox: https://cgit.kde.org/kpmcore.git/tree/ is the backend Calamares uses for partitioning.
<tsimonq2> I'd be curious to see where that flag is.
<cyphermox> xnox: I don't think splitting up a disk encryption scheme and moving files around is much more realistic
<xnox> heh
<cyphermox> xnox: that's why I think changing one cryptsetup call is simple.
<xnox> tsimonq2, i see clearly there luks2 and luks1.... and i clearly see it passing --type luks1
<xnox> tsimonq2, i see clearly there --type luks2 in luks2 "formatting method"
<tsimonq2> Calamares certainly hasn't changed, cryptsetup did.
<tsimonq2> What would cause the explicit calls for each type to be ignored?
<cyphermox> tsimonq2: wha?
<cyphermox> tsimonq2: I don't think there is anything ignored?
<wxl> wait, we have to modify kpmcore here?
<cyphermox> no
<cyphermox> at least, it doesn't look so, the code is just a bit confusing.
<wxl> because if we do that could be problematic
<cyphermox> yup
<tsimonq2> Alright, so here is the partition module of Calamares: https://github.com/calamares/calamares/tree/master/src/modules/partition
<xnox> tsimonq2, wxl - i was pointed to kpmcore code, i opened it, and it has explicit types for luks1 and luks2.
<xnox> tsimonq2, wxl - so at least kpmcore does what you want. very explicit about which luks* to use, and forcing cryptsetup to use the one that is asked.
<xnox> that's all.
<wxl> but kpmcore has the potential more far reaching effects/conflicts
<cyphermox> wxl: tsimonq2: do you know where the automated partitioning is defined?
<wxl> nope
<xnox> wxl, tsimonq2 - so looking at https://github.com/calamares/calamares/blob/master/src/modules/partition/core/KPMHelpers.cpp#L140 it seems like you do want PartitionRole Luks1 Luks2, instead of just Luks => to match kpm.
<xnox> wxl, tsimonq2 - or simply forse to use FileSystem::Luks1 in the FileSystemFactory::create( call
<xnox> wxl, tsimonq2 and check if the luks1/luks2 kpmcore is in disco.....
<xnox> wxl, tsimonq2 - also my teeth are in pain now, and i shouldn't be looking into that.... and it looks like your upstream are working well to support luks1 and luks2, at least in kpmcore.
<xnox> (irrespective of availability / what is the default in cryptsetup)
<tsimonq2> ok
<LeoB> Hello, doing 'fakeroot debian/rules binary' on any source package is enough to build it ?
<xnox> LeoB, not always, sometimes you may need to call 'fakeroot debian/rules clean binary' to be sure.
<xnox> as sometimes clean target generates things.
<xnox> and well install build-dependencies: sudo apt build-dep ./
<xnox> and well be on a matching distro/chroot
<LeoB> i am on the same distro (bionic ppc64el), did the build-dep and 'fakeroot debian/rules clean binary' . It fails on building libvirt packages
<xnox> LeoB, well, use paste.ubuntu.com to show your log.
<xnox> LeoB, where did you get the source from? Ubuntu? with like $ pull-lp-source libvirt bionic ?
<xnox> LeoB, cause $ pull-lp-source libvirt bionic -> is the one that should build packages correctly. Not sure if it would be able to build all of arch:all packages or not though, it might only be able to build arch:ppc64el
<rbasak> LeoB: I mentioned this before: after the clean, try the build target _without_ fakeroot. That is more accurate to how packages are really built.
<rbasak> LeoB: and sbuild will get you closer.
<xnox> LeoB, you can try ./debian/rules binary-arch -> that one will not build arch:all things
<LeoB> i tried  pull-lp-source, apt-get source, and this git repository: https://git.launchpad.net/ubuntu/+source/libvirt
<LeoB> all of them failed. I also tried without fakeroot. Now I will try './debian/rules binary-arch' as you suggested
<xnox> LeoB, can you please givve us the paste showing as to why it failed and how?
<xnox> LeoB, it's hard to guess...
<xnox> LeoB, using paste.ubuntu.com or somewhere similar?
<LeoB> yes, sure, I am just rebuilding to get the error message
<xnox> LeoB, ideally the full log &> log.txt is nice.
<LeoB> Is it better if I open a bug on that issue?
<xnox> from start to finish.
<xnox> LeoB, not really. cause you don't sound like you are doing a clean build with sbuild, in a pristine environment.
<LeoB> ok then
<xnox> LeoB, i'm gonna go away for a while, but will be back tomorrow. if you don't idle on irc with a bouncer, feel free to $ report-bug libvirt -> and then at least i'll be able to look it up and respond. Might be easier for you to attach build logs there.
<xnox> LeoB, or just ask somebody else, there are plenty of people around to help out, once you can show a build log.
<LeoB> ok, thanks xnox
<infinity> LeoB: For the record, "dpkg-buildpackage -b" is what the buildds (and sbuild) call, which takes care of getting the right rootness for debian/rules targets, and makes sure you have build-deps satisfied, etc.
<infinity> LeoB: Randomly calling debian/rules target is, indeed, the internal interface that gets the job done, but higher level tools are much less error-prone.
<LeoB> thanks infinity
<LeoB> infinity, "dpkg-buildpackage -b" also fails on https://git.launchpad.net/ubuntu/+source/libvirt
<infinity> LeoB: I can't speak to that git repository, or its buildability.  The canonical source packages are the ones you get from the archive mirrors.
<infinity> (Ubuntu isn't built from git, random git imports are built from Ubuntu)
<infinity> LeoB: But also, pointing at a git repository doesn't really say which tag you tried to build, on which release you're building, how it failed, etc.
<LeoB> origin/ubuntu/bionic-devel, https://paste.ubuntu.com/p/gWJ4Fh6zmj/
<infinity> And you didn't alter virt-aa-helper.c in any way?
<tsimonq2> xnox, wxl: So, I originally thought both of you were correct about it being in Calamares itself, but it's actually a kpmcore thing. The URL I linked earlier is master, and the version currently in the archive doesn't have `--type luks1` in the arguments for LUKS. Testing that, and if it works, I'll upload.
<infinity> And you're building on bionic?
<LeoB> yes, and yes
<infinity> gcc --version
<LeoB> gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
<infinity> Cause that source built fine on bionic on ppc64el just a few weeks ago.
<LeoB> Now I could build with pull-lp-source and sbuind, but not with dkpg-buildpackage
<LeoB> on the git repo
<infinity> Ahh, well, if the git repo is broken, that's less interesting to me. :P
<infinity> Like I said, that's not the source.  The source packages from the archive are the source.
<LeoB> Ok, when people try to backport patches, what do they use, that is synced with the source packages?
<infinity> That said, looking at the official build, that same error is there, it's just emitted as a warning, not an error.
<infinity> Do you have explicity -Wall CFLAGS in your environment or anything similarly silly?
<infinity> Or -Werror, I should say.
<infinity> This doesn't look like a bug with the source, but a bug with how you're building it.
<infinity> sbuild gives you a clean enviornment and warns on that enum issue, your more manual build is upgrading that warning to an error.
<cjwatson> xnox: I think I missed most of this discussion, but it's news to me that we don't build luks into grub2-signed.  I fixed that in Debian in -10, and AFAIK that was merged in disco.
<tsimonq2> cjwatson: Correct.
<infinity> cjwatson: Yeah, I believe we all decided he was mistaken.  On the other hand, "merged in disco" makes it pretty hard to argue that disco has a regression in grub-vs-luks handling. :P
<cjwatson> For the SB case, sure.
 * infinity nods.
<cjwatson> It's a problem in Debian buster because people are being upgraded from non-SB to SB.
<LeoB> infinity, running sbuild over the git repo doesn't seem to work also
<mwhudson> infinity: comments on https://github.com/CanonicalLtd/subiquity/pull/445 welcome
<cjwatson> (I think)
<infinity> LeoB: Okay?  I mean, I geniunely don't know what you're doing, and you've proven yourself that the source from the archive build, so you have your way forward.
<infinity> LeoB: Ubuntu packages aren't developed in git.  Some people prefer to muck about in that direction as its familiar tooling, but if you're going to submit fixes, it'll be patches against a source package, not git MPs against a non-authoritative branch.
<LeoB> ok then
<cjwatson> (aren't universally developed in git; many are of course)
<LeoB> I redo my patch over this source package. Thanks
<LeoB> infinity, ^
<infinity> cjwatson: I should have said s/developed in/built from/ :P
<infinity> Ultimately, all Ubuntu binary builds come from a source package upload.
<infinity> What happens before that upload is irrelevant and, quite often, doesn't match.
<infinity> Because reasons.
<infinity> cjwatson: Hrm, do I take your openssh sync from 9m ago, or the one LocutusOfBorg beat you to by 50m?
<cjwatson> Oh, I'm not precious about it
<cjwatson> Flip a coin
<LeoB> infinity, according to <cpaelzer> https://code.launchpad.net/~usd-import-team/ubuntu/+source/libvirt/+git/libvirt/+ref/ubuntu/bionic-devel should match what "pull-lp-source libvirt bionic" gives you right now
<infinity> LeoB: Right, so we're back to the "it's how you're building it" argument.
<infinity> LeoB: If you can make one work and not the other, you're driving one wrong.
<infinity> LeoB: And it's pretty clear that one of those builds has -Werror and the other doesn't.
 * infinity shrugs.
<infinity> I can't really say more without driving your computer for you.
<infinity> Well, "has -Werror" or "is using a different gcc that upgraded that warning to an error" or whatever.
<LeoB> I have a clean checkout of the repository, no change at all, and I just do the same sbuild command from pull_lp_source
<infinity> I mean, it can't be "the same sbuild command", unless you're skipping some steps.
<infinity> Do you build the source package from the git repo with "dpkg-buildpackage -S"?
<infinity> And then feed the .dsc to sbuild?
<infinity> Either way, looking at the build log on the buildd and your pasted on, it's clear:
<infinity> buildd:
<infinity> configure:        Use -Werror: no
<infinity> yours:
<infinity> configure:        Use -Werror: yes
<LeoB> it seems the git repo is different from the build packageq
<LeoB> source package
<cjwatson> That's easy enough to check - unpack the package and diff it against the git tree you have
<LeoB> that's what i did
<cjwatson> As a bonus that will tell you what the differences actually are and then you can iterate from there
<LeoB> in order to say it is different
<cjwatson> OK, so now you have the information needed to narrow it down
<cjwatson> That said, I wonder if you actually need applied/ubuntu/bionic-devel rather than just ubuntu/bionic-devel
<infinity> Probably.
<cjwatson> Since unpacking the source package gives you the version with patches applied, so that's what you'd need if you're diffing
<cjwatson> And sbuild would usually be run on a patches-applied tree
<cjwatson> (Shouldn't matter actually, but I guess could)
<infinity> Shouldn't?
<infinity> Will dpkg-buildpackage apply series if it's unapplied?
<cjwatson> Because sbuild would build a source package first and dpkg-source should DTRT
<infinity> Oh.
<cjwatson> dpkg-buildpackage won't, I think
<infinity> Right, that.
<infinity> Unless sbuild grew support for directly abusing source trees without the middle step.
<cjwatson> (Anyway this is an overcomplicated digression)
<infinity> But I haven't noticed such a feature.
<infinity> Not that I'd be looking for it.
<LeoB> with this 'applied' branch, it could build from git. Thanks for explaining what it means
<LeoB> thanks cjwatson infinity ^
<LeoB> ls
<cjwatson> np
#ubuntu-devel 2019-04-09
<tsimonq2> I don't really know where to start in solving this s390x FTBFS: https://launchpad.net/ubuntu/+source/kpmcore/3.3.0-5
<tsimonq2> Tests are failing with Invalid CBOR stream: unexpected 'break' byte
<tsimonq2> It's Ubuntu-s390x-specific.
<sarnold> step one, get an s390x...
<tsimonq2> I'd try to repro it in a porterbox if Debian was having the issue too...
<doko> tsimonq2: reproducible on a big endian 64bit system?
<tsimonq2> I'll see.
<sarnold> which endianness is our arm64?
<tsimonq2> doko: I can't repro on zelenka with a fresh sid schroot.
<mwhudson> sarnold: little, we're not crazy
<sarnold> mwhudson: hehe
<jamespage> cpaelzer, doko: can we get python-os-ken, python-os-resources and python-websockify promoted to main pls - I think the MIR's are all approved and mismatched nova/neutron is currently blocking testing
<cpaelzer> jamespage: I have no powers to do so
<cpaelzer> jamespage: resolving acked MIRs by promoting is an AA task
<cpaelzer> but doko can and so does (considering the time and timezones) maybe apw ?
<jamespage> cpaelzer: yep - hence my inclusion of doko in my request :)
<cpaelzer> jamespage: well I was mostly commenting on my inclusion being useless on this task :-)
<jamespage> cpaelzer: I was a bit unclear on the bug task status's - what's the normal status for 'Reviewed, ready for promotion'
<jamespage> ?
<cpaelzer> jamespage: "in progress" means ready, the next is "Fix committed" if you have put the stuff in proposed that makes the dependency appear
<cpaelzer> jamespage: so in your case I think all of them are fix committed then right?
<cpaelzer> jamespage: since I never understood the states I wrote this some time ago https://wiki.ubuntu.com/MIRTeam#Process_states
<jamespage> cpaelzer: yes I think so
<jamespage> cpaelzer: so do I do that?
<jamespage> done
<jamespage> jdstrand_: hey - just tripped on https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1823862 - something you where aware of?
<ubottu> Launchpad bug 1823862 in ufw (Ubuntu) "disco: unable to enable ufw" [Undecided,New]
<seb128> xnox, vorlon, what is happening to bug #1816812? it's 1 liner fix and important to have in disco, you agreed when we discussed it during the foundation team meeting some weeks ago ... is it still on track to land before the freeze this week?
<ubottu> bug 1816812 in systemd (Ubuntu Disco) "desktop logout delays due to missing PropertiesChanged signal" [Undecided,New] https://launchpad.net/bugs/1816812
<cpaelzer> rbalint: you are saving my day on 1823872 thanks a lot
<cpaelzer> saw your update
<cpaelzer> if I can help anything let me know
<cpaelzer> let me check on steps to reproduce and prep an SRU Teamplate for you at least
<doko> jamespage: python-os-* promoted
<jamespage> doko: ta
<doko> jamespage: looks like websockify isn't yet ready
<jamespage> websockify is, spice-html5 is not
<jamespage> at least I think that's what cpaelzer indicated
<cpaelzer> yes
<cpaelzer> jamespage: yes you said you want to punt spice-html5 after my feedback
<cpaelzer> doko: what else seems missing on websockify - IIRC it had no hard dependency on spice-html5
<doko> ahh, ok
<doko> websockify promoted
<coreycb> cyphermox: jamespage: new heat-dashboard version uploaded to disco with tests running successfully
<cpaelzer> rbalint: FYI I added you test steps and an SRU template as promised
<cpaelzer> rbalint: if you have a PPA that I should test let me know
<cpach> hi folks. today i noticed a strange behaviour in apt, that might be a bug in ubuntu or upstream. what place is best to report bugs? launchpad? ubuntuforums.org? some other place? please advice.
<cjwatson> Not the forums!  "ubuntu-bug apt" is normally best
<cpach> cjwatson: looks neat. thank you!
<cjwatson> np
<cyphermox> coreycb: hurray :)
<cyphermox> coreycb: mir approved
<coreycb> cyphermox: thanks!
<rbalint> cpaelzer, thanks, i'm adding build time tests as well because i'm fixing conffile moves in general (wip: https://github.com/rbalint/unattended-upgrades/tree/conffile-moves )
<cpaelzer> ok great
<tjaalton> kyrofa: hey, the darktable snap doesn't support opencl?
<kyrofa> tjaalton, it seems not, but I haven't had time to dig into why
<tjaalton> it tries to search for libOpenCL.so.1
<tjaalton> can't find it if it's installed on the system
<tjaalton> probably the same for the drivers
<kyrofa> tjaalton, looks like we'd need to bundle opencl: https://forum.snapcraft.io/t/snaps-and-opencl/8509/10
<tjaalton> yeah, fun
<tjaalton> I've now packaged the intel neo driver
<tjaalton> and tested it using darktable. deb works, snap doesn't
<kyrofa> tjaalton, if you have ideas, pull requests are always welcome
<tjaalton> there would have to be a platform snap for it
<tjaalton> or if there is, opencl support added to it
<tjaalton> otherwise it's just madness adding all drivers to each snap that might use opencl
<tjaalton> though it might be an unavoidable madness :)
<jdstrand> jamespage: yikes, no, thanks :)
<jamespage> jdstrand: I tripped over it this morning - we use ufw to secure firewall comms between swift storage nodes for openstack
<jdstrand> jamespage: I asked for more information
<dviola> hi
<dviola> I've been trying to deal with this bug for days now: https://bugs.freedesktop.org/show_bug.cgi?id=110214
<ubottu> Freedesktop bug 110214 in Drivers/Gallium/radeonsi "radeonsi: xterm scrollback buffer disappears while Shift+PgUp and Shift+PgDn" [Normal,New]
<dviola> basically, xterm does not behave properly (the fonts become invisible when I shift+pageup)
<dviola> however, on ubuntu this works fine... on other distros, I get the bug
<dviola> I was wondering if ubuntu devs can shed me some light into why it works on ubuntu and doesn't on other distros
<dviola> we tried a lot of things...
<sarnold> none of the patches in xterm's debian/patches/ directory feel like they'd be involved
<JanC> is it the same version on all those distros?
<JanC> it might be a gallium/radeonsi patch thing too
<JanC> or a default setting difference
<infinity> Most likely to be a kernel/mesa/xorg difference than an xterm thing.
<JanC> might be freetype too
<infinity> xterm's font rendering is from 1975, I don't suspect much trickery there.
<infinity> If it was gnome-terminal, I'd go looking for differences in pango.
<dviola> JanC: no, but we compiled different versions of Xephyr, mesa, xterm, etc. yet it only works on ubuntu for some reason
<JanC> it might be as simple as a different default setting in Ubuntu?
<dviola> on arch it works if I disable GL_NV_texture_barrier or if I export R600_DEBUG=nodpbb, which seems strange, I wonder what ubuntu is doing different
<dviola> I tried looking at the patches ubuntu applies on top of mesa and there doesn't seem to be anything related
<wxl> bdmurray: since you are so closely aligned with apport, can you explain to me why python3-launchpadlib is a suggest for python-apport rather than a depend as it once was?
<bdmurray> wxl: Are you sure it was a depend?
<dviola> not sure if I'm looking at the right thing...
<wxl> bdmurray: yeah, like back in saucy or something XD
<wxl> bdmurray: since it is required for apport-collect, i can at minimum see it being a recommend. suggest seems way too weak
<bdmurray> wxl: the rationale is in the bzr log and bug 1192330 although it may not apply anymore since there is python3-launchpadlib
<ubottu> bug 1192330 in apport (Ubuntu) "missing dependencies on Ubuntu Server" [Medium,Fix released] https://launchpad.net/bugs/1192330
<wxl> bdmurray: yeah, i saw that. i guess the question is why we haven't returned it back to the way it was given that that's not entirely relevant anymore.
<bdmurray> wxl: because its not a huge priority
<wxl> bdmurray: ok good enough for me :) if i submitted a fix i presume there would be no other reason to think it wouldn't be accepted?
<bdmurray> wxl: well another reason it wouldn't be accepted might be the release coming up
<wxl> bdmurray: yeah i didn't mean NOW. :) good enough, thanks
<jdstrand> jamespage: thanks for the added info. please see comments (still can't reproduce)
<vorlon> mdeslaur, stgraber: meeting?
<dviola> where can I see how a package was compiled with? configure switches, etc
<dviola> or rather, how
<sarnold> build logs are available on launchpad
<dviola> thanks
<sarnold> from eg https://launchpad.net/ubuntu/+source/xterm you can click the 330-1ubuntu2 under bionic beaver, then amd64 under builds, then buildlog on the left
<dviola> got it, thanks
<dviola> for mesa, I see it applies a few patches
<dviola> https://launchpadlibrarian.net/417491370/buildlog_ubuntu-disco-amd64.mesa_19.0.1-1ubuntu2_BUILDING.txt.gz
<dviola> e.g. Applying patch revert-set-full-thread-affinity.diff
<dviola> do you know where can I see those patches?
<sarnold> the easiest way is to have deb-src lines configured in your apt sources, then you can use apt-get source mesa and then it'll probably be in mesa*/debian/patches/
<dviola> thanks
<sarnold> if you just want the patches you can find the deltas from debian on https://patches.ubuntu.com/
<dviola> thanks
<dviola> I guess I'll compile mesa and revert that commit
<dviola> https://gitlab.freedesktop.org/mesa/mesa/commit/d877451b48a59ab0f9a4210fc736f51da5851c9a
<dviola> I can't see other patches that relates to radeonsi
<sarnold> dviola: wow. if *that*s the fix I'm going to be very dissapointed
<dviola> hrm, I have no idea :)
<dviola> we've spent crazy amount of time with this bug already... hopefully it's this one
<dviola> everything we tried, it failed basically
<dviola> except this: export R600_DEBUG=nodpbb
<dviola> and the other extension
<dviola> fedora is affected, arch is affected
<dviola> ubuntu doesn't have the bug
<dviola> at least it reverted cleanly
<dviola> ok mesa is compiling
<dviola> nope, that wasn't it
<coreycb> bdmurray: hi, would you happen to have cycles to take a look at tye python-oslo.cache fix in the cosmic unapproved queue? i just uploaded it today. it's currently tagged as a release blocker for the openstack charms release.
<bdmurray> coreycb: sure
<dviola> found another potential culprit
<dviola> a patch
<dviola> https://patches.ubuntu.com/x/xorg-server/xorg-server_2:1.20.4-1ubuntu3.patch
<dviola> glamor-disable-logic-ops-when-doing-compositing.diff: Fix libreoffice with glamor. (LP: #1575000)
<ubottu> Launchpad bug 1575000 in xorg-server (Ubuntu Xenial) " font glyph corruption on dialog box" [High,Fix released] https://launchpad.net/bugs/1575000
<dviola> that patch is already merged upstream, so it can't be that
<coreycb> thanks bdmurray
#ubuntu-devel 2019-04-10
<Unit193> Heh, awesome rejection reason: [lplibrarian-public-upload.internal:10004]: [Errno 113] No route to host
<plongshot> I'm wanting information about the development environment with ubutu. I'm wondering how ubuntu manages upstream dependencies in a project? I don't know where else to ask so maybe someone can give a real life example?
<plongshot> I b using git
<plongshot> :p
<plongshot> but that doesn't matter
<sarnold> what do you mean?
<CarlFK> plongshot: do you mean how are ubuntu releases managed. or how does someone develop a project that depends on packaged libs?
<plongshot> sarnold: I may have a tough time answering succincly bc I'm so newb. I decided to fork a project privately so I can base a new work off an old one (github / local git). I don't understand how to handel (workflow, strategy, skills) a project that has an upstream dependency. In my case the upstream dep is the project I forked off of. There will be changes coming from that upstream src that I'll have to deal with as my project
<plongshot> progresses.
<plongshot> I'll have two remotes in my local repo
<plongshot> aack!
<plongshot> I been asking all over irc all day
<plongshot> Someone have mercy on my soul!
<plongshot> I was hoping that since I love ubuntu so much I would be welcome  :)
<sarnold> plongshot: it might be easier with specifics
<plongshot> can I pm you?
<plongshot> sarnold: ^
<sarnold> plongshot: I'm about to go cook dinner
<sarnold> besides, irc is best in the open, because you can get a variety of opinions that way
<plongshot> np
<plongshot> it ok
<plongshot> I too newb to know better ok then
<plongshot> ty
<sarnold> plongshot: if you're asking about how to manage upstreams with git, maybe one of the github or gitlab tutorials would work out well; I've heard mixed things about the git book on git-scm.com, some said it's not focused enough on just getting work done
<plongshot> I forked gimp by making cloiing the gimp repo locally. Then I create a repo on github (a private one wiht a unique name). I push the cloned gimp repo from local to my new private repo, delete the original gimp repo and then clone my private repo (with gimp in it). Now I add a remote to my private repo that points to the original gimp repo (that becomes the upstream dependency in my project). Mow I barely know how to use all
<plongshot> this crap so far as workflow and toos are concerned. Now I have two remotes. One I depend on once I get going with my project because the changes made in gimp will affect my new program as time goes on.  Where to find in depth information how to handle this situations (situation where you have 3 repos and 2 remotes in play one is a dependency and one is what you're doing).
<plongshot> Sorry so long but like I said I'm too newb to know how to phrase the question even. I just want to find information relevant to my situation.
<plongshot> And I'm sorry if I ask in wrong place. I love ubuntu and I though ubuntu propably deal with this too
<sarnold> plongshot: I found these instructions very helpful when I was working with this repo: https://github.com/CVEProject/cvelist/blob/master/CONTRIBUTING.md#sending-data-about-cve-entries-to-mitre
<plongshot> I will look
<sarnold> plongshot: hopefully you'll be able to figure out what the equivalent commands are for your gimp repos :)
<plongshot> sarnold: enjoy you dinner sir
<plongshot> ok
<plongshot> I appreciate you sarnold
<sarnold> thanks! have fun plongshot
<plongshot> you know it  :)
<sarnold> :D
<Kolargol00> rbasak: I've updated LP#1822069. Is that the analysis you were looking for?
<Unit193> LP 1822069.
<ubottu> Launchpad bug 1822069 in xmltooling (Ubuntu) "SRU: Shibboleth SPv3 for bionic" [Undecided,New] https://launchpad.net/bugs/1822069
<rbasak> Kolargol00: that's very useful, thanks!
<rbasak> Kolargol00: note though that "Usage of the libraries for other purposes is generally not supported" is not applicable to Ubuntu.
<rbasak> Ubuntu released it with a stable release promise; breaking particular use cases because upstream don't consider them "supported" is still not acceptable.
<jamespage> jdstrand: its -virtual vs -generic
<rbasak> Kolargol00: we still need to weigh them up whether upstream support them or not
<rbasak> Kolargol00: does that change your analysis? Please could you update the bug to cover all possible use cases, including upstream non-supported ones?
<jamespage> apw: around? bug 1823862 is worrying me
<ubottu> bug 1823862 in ufw (Ubuntu) "disco: unable to enable ufw under -virtual kernel" [Undecided,New] https://launchpad.net/bugs/1823862
<cpaelzer> thanks seb128 for the explanation on usbguard
<seb128> cpaelzer, np, thx for the review and all the details!
<cpaelzer> and take no offense in the reivew please, this was one of the first times I could not just say ack after a while
 * cpaelzer is afraid of backfire :-)
<seb128> haha
<seb128> no worry, I do agree with the things you wrote there and it makes sense to fix/improve those
<cpaelzer> seb128: yeah given that I now struggle to use my keyboard here I really think it might need some work
<cpaelzer> purging it makes it still blocking things on replug
<cpaelzer> I assume it has swicthed something deep in sysfs that controls the defaults
<cpaelzer> but I don't want to reboot to hopefully clear it
<seb128> cpaelzer, reinstall, desactivate with the tools and re-uninstall? ;)
<seb128> but yeah, agreed, would be nice to fix
<seb128> though "I uninstalled that service which is installed by default and I don't want to reboot" isn't probably a common/important usecase
<seb128> still would be better if it worked though
<cpaelzer> seb128: I have done "reinstall, desactivate with the tools and re-uninstall" already - does not help
<cpaelzer> you need it active to apply the "allow" rule
<seb128> :(
<cpaelzer> as I said it seems to have swicthed there kernel/controllers default
<cpaelzer> and if the daemon does not say "yes" then you are blocked
<cpaelzer> anyway, not an issue for now
<cpaelzer> It is some sort of anti-theft protection on my laptop for now
<seb128> :)
<seb128> xnox, thx for the system upload!
<Kolargol00> rbasak: I know nothing about usage of these libraries outside of the context of running a Shibboleth SP. Is there a way to discover such use cases? for example with reverse dependencies?
<rbasak> Kolargol00: yes - explore the distribution release's dependency tree, and for each package found, consider how users might use the package directly.
<rbasak> Kolargol00: an exhaustive search is obviously impossible, but we do need to make a reasonable effort. For me to read "other use cases are not supported" is worrying because it sounds like the opposite is being done.
<Kolargol00> rbasak: Well "other use cases are not supported" is upstream's [Shibboleth project] position, not really mine. I was repeating it here since I'm not aware of other uses. I've been backporting this set of packages for Debian and Ubuntu for 3-4 years now and I don't remember someone complaining that their program broke because I updated a library. However, this is no excuse not to dutifully assess the impact of this SRU. :)
<Kolargol00> rbasak: `reverse-depends` already brought up shibboleth-resolver and moonshot-gss-eap, is there any other tool you'd recommend to explore dependencies?
<rbasak> Kolargol00: that should be fine, but make sure you use -r to specify the release in question. Otherwise it'll do the development release which may miss stuff if packages have been removed.
<rbasak> (I've never used -r - I use chdist and apt-cache rdepends)
<Kolargol00> rbasak: yeah reverse-depends -r bionic src:<package> is what I've used to write comment #10
<Kolargol00> rbasak: Running `apt-cache rdepends` with all binary packages yields the same set as reverse-depends (shibboleth-resolver, moonshot-gss-eap, wordpress-shibboleth) so I think what I wrote for these packages in #10 still stands. Is there something else missing from this analysis?
<rbasak> Kolargol00: as long as you haven't discounted anything on the basis of "not supported by upstream", it looks good to me from a quick glance. I need to go over it in detail. It's rather complex :-/
<Kolargol00> rbasak: I've looked at the changes (git log) in opensaml2-tools and xml-security-c-utils to find out whether the programs they provide had changed, but apparently there are only internal changes, nothing changing the CLI. The man pages didn't change either.
<rbasak> Kolargol00: that sounds good. Please keep updating the bug :)
<rbasak> tsimonq2: in your mixxx upload, the changelog says "New upstream release" but the upstream version number isn't bumped. What am I missing?
<Kolargol00> rbasak: ok, I'll add that comment :)
<tsimonq2> rbasak: ...what? :)
<tsimonq2> It's for Cosmic but it's a direct backport of Bionic.
<tsimonq2> er
<rbasak> Kolargol00: thank you for working on Shibboleth for Ubuntu users, BTW. Please note that I might not get to it today though - it's rather large to review
<tsimonq2> s/Bionic/Disco/
<rbasak> tsimonq2: ah, right.
<rbasak> I'd have mentioned that it was a backport, but never mind.
<Kolargol00> rbasak: I understand it's not an easy thing to review. You're welcome :) I'm now trying to have all my packaging/backporting work included in the official Ubuntu repositories so that people don't have to use third-party repos and it benefits a much wider community.
<rbasak> Kolargol00: great! Once you're familiar with Ubuntu development process, we'd love for you to become an Ubuntu developer - then you won't need sponsorship any more.
<Kolargol00> rbasak: That would be nice! I do appreciate the review that the sponsorship process provides though.
<jdstrand> jamespage: thanks
<jdstrand> sforshee (cc tyhicks, jamespage): I'm not sure who to ping about this, but it seems there is a regression surrounding the virtual kernel or where netfilter modules are being shipped (or perhaps a seedingg issue): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823862
<ubottu> Launchpad bug 1823862 in linux (Ubuntu) "disco: unable to use iptables/enable ufw under -virtual kernel" [Undecided,Confirmed]
<sforshee> jdstrand: looking
<jdstrand> sforshee (cc tyhicks): I would argue that iptables should be workable without extra modules (and ufw's check-requirements), but perhaps there are other reasons against that
<jdstrand> Odd_Bloke: fyi, I wonder if this was your "iptables v1.6.1: can't initialize iptables table `filter': Memory allocation problem". cause with a virtual kernel, I see that locally when extra modules aren't installed
<Odd_Bloke> jdstrand: Ah, it certainly looks like it could be adjacent at least!
<jdstrand> Odd_Bloke: I added a comment to https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1820114
<ubottu> Launchpad bug 1820114 in linux (Ubuntu) "iptables v1.6.1: can't initialize iptables table `filter': Memory allocation problem" [Undecided,Confirmed]
<jdstrand> sforshee: an easy fix would be to have linux-image-virtual pull in linux-modules-extra-... like linux-image-generic does
<jdstrand> sforshee: but perhaps something got shuffled around and the netfilter modules are in linux-modules-extra-... when they shouldn't be
<sforshee> jdstrand: then there would be no difference between linux-virtual and linux-generic. What we want to do is figure out exactly which module(s) are missing from linux-modules and move them from -extras to there
<jdstrand> sforshee: or, maybe things *should* be shuffled around so you keep cloud images small but still have iptables support
<jdstrand> sforshee: if you go that route (the last thing I suggested), please at a minimum use /usr/share/ufw/check-requirements to make sure it at least works (I suggest starting with all netfilter)
<jdstrand> sforshee: thank you for looking at it
<sforshee> jdstrand: I put a test build on the bug that passes check-requirements for me. All that was missing is bpfilter
<jamespage> sforshee: testing now
<tyhicks> jdstrand: hey - I'm confused how test_python from QRT's test-apparmor.py has been passing for your apparmor 2.13.2 testing
<tyhicks> (in disco)
<tyhicks> jdstrand: it uses python and python3 to test the libapparmor bindings but python-libapparmor no longer exists in Disco
<tyhicks> jdstrand: I've got a fix for QRT to only test python3 in Disco (I'm running the test script now) but I'm thinking that maybe I'm missing something because I know you use test-apparmor.py as part of your testing
<jamespage> sforshee: tested ok added comment to bug
<sforshee> jamespage: thanks!
<jdstrand> sforshee: woohoo! :)
<jdstrand> tyhicks: I think what may have happened is I had 2.12 installed, then upgraded to 2.13 and ran qrt
<jdstrand> tyhicks: which didn't remove the py2 bindings
<jdstrand> sf
<jdstrand> err
<tyhicks> jdstrand: ah, that makes sense
<tyhicks> jdstrand: I found one other problem with that test and am rerunning all of test-apparmor.py one last time and then I'll push
<jdstrand> sforshee: does it make sense to add to your smoke tests running check-requirements? I ask cause next cycle we are likely going to have iptables 1.8.3, and I suspect (but don't know) there might be a module or two that will need to move over
<sforshee> jdstrand: I was already thinking about adding a test, problem is that I'm not sure if we're testing with only linux-virtual anywhwere currently
<sforshee> but yeah, I'll look into it
<jdstrand> tyhicks: ack thanks. I can definitely say for the first upload to disco, it passed :) subsequent uploads I didn't do all that cause they were just some small packaging fixes, so it hasn't been run for a number of weeks
<jdstrand> sforshee: cool, thanks
<tyhicks> jdstrand: what you suspect regarding the upgrades would explain why the failures are just now showing up
 * jdstrand nods
<tyhicks> jdstrand: and it gives me confidence that skipping the py2 tests is the right thing to do :)
<jdstrand> heh. well, we did drop them so it seems fairly reasonable :)
<jdstrand> I should've noticed that. thanks for taking care of it
<jdstrand> tyhicks: ^
<tyhicks> np
<LeviM> I'm trying to build openmpi from sources. Using `apt source --compile openmpi` seems to fail (with what I think is the relevant snippet). https://www.irccloud.com/pastebin/z6GqV7nv/
<LeviM> As far as I can tell, bionic is using Java 10, and so javah doesn't exist.
<LeviM> Is there some other command I should be using?
<LeviM> My eventual goal is to build OpenMPI with Slurm's PMI2 support, but I can't even get it built without modifications yet.
<LeviM> I assume someone got it built since I can install it.
<sarnold> LeviM: did you apt-get build-dep beforehand?
<LeviM> Looking through command history, I ran exactly `sudo apt build-dep -y openmpi`
<Faux> I'd wildly guess it only builds with a Java which is different to the version you have installed.
<LeviM> Assuming that is true, does that mean it's probably broken? lol
<LeviM> Is there a way I can see how the official packages get built?
<LeviM> This is my first foray into source packages.
<LeviM> I installed openjdk-8-jdk. Got past that step, so it probably does only build with an older version.
<LeviM> > Error: Could not find class file for 'mpi.CartParms'
<LeviM> ^ Need to investigate this, now.
<sarnold> LeviM: you can scrape the build logs on https://launchpad.net/ubuntu/+source/openmpi -- click whatever version you've got, then the arch you care about, then buildlogs
<LeviM> sarnold: thanks. I can see it does used jdk-8.
<LeviM> Is there a way to see what script it is running?
<sarnold> apt-get source openmpi  then look in openmpi*/debian/rules
<LeviM> Hmm.
<LeviM> Nothing in there installs jdk8, unless I ran the wrong command.
<LeviM> Which indicates to me the build bot is using more than the source package, unless I'm mistaken on something.
<nacc> LeviM: what version and arch?
<nacc> LeviM: more than likely the version is via a metapacakge (e.g. default-jdk)
<nacc> LeviM: fwiw i think this is 'documented' as http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html (test rebuild of bionic)
<nacc> specifically you're hitting the move from openjdk8 to jdk11 as the default in bionic
<LeviM> Ubuntu 18.04, amd64
<LeviM> Just got out of a meeting, will poke around. Thanks.
<LeviM> nacc: looks to be the same issue, yes. Given that I'm a newbie, how can I help here?
<LeviM> My (limited) understanding is partly that it (OpenMPI) tries to find `javah`, which fails. `javah` is roughly `javac` with some arguments, right?
<LeviM> What is the best angle of attack?
<Faux> Use the version of java it wants (8, which is in bionic), and tell apt to ignore the problem.
<LeviM> Faux: in this case the project has a later commit that fixes it -- can we backport the commit? I'm testing to see if it will work, but I was wondering about getting it fixed properly.
<LeviM> Hmm, the build is still failing for me even with older JDK.
<LeviM> Is there a command like `apt-cache depends` for source packages?
<LeviM> The built packages do not need openjdk, apparently (not by any listed deps, anyway), but clearly the source package needs it.
<LeviM> How does the buildbot know to install JDK one way or another?
<sarnold> the build-depends field; apt-get build-dep can install them
<LeviM> Can I list them without installing them?
<vorlon> apt showsrc $pkg
<LeviM> Thanks.
#ubuntu-devel 2019-04-11
<sarnold> ddstreet: thanks for working on ureadahead :)
<LocutusOfBorg> tjaalton, did you find the intel-media-driver issue?
<tjaalton> LocutusOfBorg: yes, uploaded a new rebase plus fix from git
<LocutusOfBorg> nice! I admit, I'm really curious
<LocutusOfBorg> oh.... so the wrong substvar was preventing shlibs from being picked up?
<LocutusOfBorg> that makes sense
<danyspin97> Hey there. I'd like to ask about bcron-run; the package description says it replaces cron, but it only provides runit services which, by my understanding, are not run without runit-systemd. Why isn't runit-systemd a dependency of bcron-run?
<vorlon> why is ca-certificates prompting me on upgrade about whether or not to activate non-default certificates?
<sarnold> o_O
<sarnold> that sounds vaguely like cacert from before LE days..
<vorlon> "before LE"?
<vorlon> the config script does 'db_input critical ca-certificates/new_crts || true' so any bug here is in ca-certificates
<sarnold> letsencrypt
<vorlon> k
<vorlon> sarnold: turns out I may have at some point in the past opted in to this pain <shrug>
<sarnold> vorlon: just so long as it's not bugging our users :)
#ubuntu-devel 2019-04-12
<Unit193> vorlon: Hi!  You have a longstanding patch in irssi, did you ever file an issue upstream for that or talk to someone in #irssi?  I'm presuming it has something to do with connecting to Canonical's IRC network, or getting out from there.
<vorlon> Unit193: it was filed upstream; upstream rejected it; the patch in question is mandatory if you want proxies to work properly w/ ssl
<vorlon> unless upstream has since fixed things differently
<Unit193> Unfortunate..
<seb128> rbalint, hey, is unattended-upgrades supposed to be installing standard updates in disco? or is that a bug?
<seb128> vorlon, ^ maybe you know?
<rbalint> seb128, not at all! u-u starts upgrades 21 days before the release https://github.com/mvo5/unattended-upgrades/pull/149
<didrocks> rbalint: vorlon: associated bug: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1824470
<ubottu> Launchpad bug 1824470 in unattended-upgrades (Ubuntu) "unattended-upgrade is running on the dev version, updating regular packages" [Undecided,New]
<seb128> rbalint, well, we are in that timeframe, but it seems to apply any disco update
<didrocks> but isn't it supposed to only install security updates?
<seb128> (we don't have anything in security at this point)
<rbalint> seb128, didrocks: u-u runs in Debian unstable and testing all the time to catch bugs in u-u and in every other package
<seb128> rbalint, I noticed because in the mornings my apt is being locked/not usable for long times
<didrocks> rbalint: this is annoying on the development version, where you want people to have control over their updates though
<didrocks> like this morning, there was a known mutter issue
<didrocks> I wanted to check
<didrocks> updates
<didrocks> and check the fix
<rbalint> didrocks, it is possible to disable it
<didrocks> here, I was puzzled because suddenly things are updated under my feet
<didrocks> right, I can disable the systemd service
<didrocks> but maybe won't reenable it after release
<didrocks> sounds weird, the GUI options tells this service only apply security updates
<rbalint> didrocks, i'd suggest using the config file instead
<seb128> rbalint, sorry your answer are not clear to me. So what you say is that it doesn apply every updates by design on unstable series (= disco)?
<didrocks> which it doesn't
<seb128> rbalint, is it going to stop doing that when disco turns stable? (do we need an upload for changing the behaviour or does it has a notion of what are unstable/stable series?)
<rbalint> seb128, didrocks: the release pocket and -security are enabled
<rbalint> relese pocket freezes after the release, thus packages from -security will continue flowing in
<seb128> ah, I guess it means once disco it's stable release is not changing and it's not handing -updates
<seb128> *only handling updates
<rbalint> seb128, yes
<seb128> sorry -*not*
<seb128> rbalint, k, makes sense
 * didrocks finds this new behavior a little bit puzzling though
<seb128> rbalint, the user experience is not really nice, we should do integration work in the desktop to tell the user what's going on
<seb128> e.g indicator or something
<seb128> would be nice if apt was also hinting that "unattended upgrades are being applied" rather than just telling that there is a lock set
<seb128> I often end up with a system which I can't use to do work in the morning wondering how long it's going to take before I've my apt back
<seb128> I killed unattended-upgrades after 10 min the other day
<didrocks> especially as it treats one package after another
<didrocks> as also, you don't know if you are testing the updated version or the one for the day before, like in the mutter case
<didrocks> because apt policy will tell you are you on the latest, but you didn't restart the software
<didrocks> (which is actually what happened this morning)
<didrocks> which is OK in the released version, a little bit less on a dev one IMHO
<seb128> (that point is probably a "need to learn about how things changed/are done now" more than a long term issue, once you know it's doing update in bg when you start the machine you can teach yourself to check the update timestamp)
<didrocks> if you have something that reminds you "we are in those 21 days period before releaseâ¦"
<seb128> yeah, I think the real issue is that we don't surface what's going on in the UI
<didrocks> yep
<seb128> which is also true for security on stable
<didrocks> right
<seb128> we have a class of bugs about that
<seb128> like "system hang on shutdown"
<seb128> (which is "waits for that service finishes working")
<seb128> rbalint, do you have any opinion on the right venue to discuss properly surfacing to the user/in the desktop that u-u is doing its thing in the background (so you know that your updates are being handled, what is making your internet/disk busy, what is locking your packaging tools)
<seb128> rbalint, also we should fix software-properties to not tell that "only security updates are being applied" where it's obviously not true
<rbalint> seb128, probably it would be #ubuntu-desktop
<rbalint> seb128, terminal users don't really need that
<rbalint> seb128, ther can be a desktop applet showing when the apt lock is taken
<rbalint> seb128, it is not only u-u doing things in the background, it can be landscape or other management tool
<rbalint> seb128, but in a stable release the upgrade should not be noticable
<seb128> rbalint, I'm not sure I agree with that, as I said I needed apt to do work the other day and I couldn't use it for 10 min+, I had to lsof on the lock to figure out what was going on, so it's not only desktop
<seb128> apt way of telling you that "the lock is taken" without details is an issue for command line users imho
<rbalint> seb128, i'd just run top or pstree
<seb128> because you know what to look for
<seb128> I did ps and looked for dpkg processes
<seb128> didn't find any
<rbalint> well, pstree is really nice
<seb128> but maybe that was looking for the wrong thing, u-u is not using dpkg?
<rbalint> seb128, well, it uses mostly libapt, but keeps the lock for the whole session
<seb128> right, so I was looking for the wrong thing
<seb128> I though it would use dpkg if it was installing packages
<seb128> and looked for that
<seb128> bottom line is that apt could tell you who owns the lock
<seb128> and what's going on
<seb128> imho
<rbalint> seb128, this sounds like an apt wishlist bug
<seb128> rbalint, also "it's not an issue on stable" is probably true for a machine which is modern and that you use daily, the other day I turned one a computer I didn't use for a month which has a non-ssd drive
<seb128> u-u took like half an hour
<rbalint> seb128, this is challenging but not unexpected at all
<seb128> k
<seb128> well, seems we disagree on what makes a good user experience and what can confuse users
<seb128> which I guess is the way it is, no point arguing for hours over it
<seb128> rbalint, thx for listening and for the replies!
<rbalint> seb128, no, i agree that showing that apt working in the background could be useful on desktop
<rbalint> seb128, i have hight expectation of users using dev release on their main machine
<seb128> I see that :)
<rbalint> and i believe we should optimize for high quality stable relases instead of not putting pressure on dev users
<rbalint> the extra pressure is little imo, i got few complaints from Debian devs for running u-u all the time in testing and sid
<didrocks> I think thus such changes should have been announced, it impacts everybody using the dev release and announcing those is high development standard IMHO
<rbalint> didrocks, i agree, i had the plans to write a blog post about it on planet ubuntu, but this got lost in the priorities. I'm sorry.
<didrocks> rbalint: no worry, but it's not too late! It can help others
<seb128> rbalint, right, I agree with that, as Didier said it just probably missed at least an email to ubuntu-devel@ with a FYI
<seb128> rbalint, oh, last question for today and then I stop bothering you ... does u-u provide a "client API" (dbus or other) that a potential desktop indicator could use to reflect the current status?
<rbalint> seb128, no, just the log files, but since not u-u is the only background apt frontend imo it would be better to query the lock file
<seb128> rbalint, ideally we would probably like to display the number of pending updates to apply (and a time estimate? but I guess that would be more difficult)
<seb128> (or % done estimate)
<seb128> a "btw something has a lock" is useful but not that useful
<seb128> software management tools do tell you that they fail working because there is a lock
<seb128> by itself it's confusing unless you know what has the lock/why/how long it's still going to do things
<seb128> otherwise you can't tell appart a "something crashed and left a stalled lock" from "u-u is applying update, it's done with 27 of the 30 pending ones, it should be done soon"
<rbalint> didrocks, seb128 just sent the email, thanks for the reminder
<seb128> rbalint, thx!
<seb128> rbalint, so, who is the person to talk to about maybe scheduling work to add a proper status reporting API to u-u? ;)
<seb128> I've a feeling it's going to end up being too low priority to make it on the roadmap for next cycle, but I think it's worth having a discussion about it at least
<rbalint> seb128, it would be me :-)
<seb128> rbalint, :-)
<seb128> I need to check with willcooke also if he believes that's important enough from a desktop side to commit to work on it
<seb128> or if that's in a land of wishlists we are not likely going to be able to work on
<rbalint> seb128, in general i agree we should let users know that something is going on when the system is working hard, i see devel as a special case
<seb128> right, I don't care so much about devel
<seb128> but that problem exists in stable series as well
<rbalint> seb128, and package upgrades should take a few seconds tops
<rbalint> seb128, i have a few work items around that
<seb128> on my inspiron test machine regenerating the locales when there is a libc update takes like 3 minutes by itself
<rbalint> seb128, imo this is the problem, not the indicator
<seb128> I think the "few seconds" depends a lot of what is in the upgrade and your hardware/disk
<didrocks> the issue is that packages are installed grouped by grouped
<didrocks> not in one apt transaction
<seb128> kernel updates and regenerating the initrd also take a while
<didrocks> I don't know why there is this design
<seb128> didrocks, that wouldn't make a difference on the "can lock the apt db for a long time"
<rbalint> seb128, initrd should be lz4
<didrocks> seb128: it does add more time though, as apt everytime recompute the dep coherence
<rbalint> didrocks, upgrades are grouped to gracefully stop when needed between them, so you can shut down your system
<seb128> didrocks, it's a problem but I think it's orthogonal, even if we changed that, generating locales would still take 3 min on the inspiron and the apt db could still be locked for 10 min on a "non trivial" update which includes kernel and libc
<didrocks> I think the granularity is a little too small. Like 7 "transactions" in a 45 seconds sounds wrong
<rbalint> didrocks, /usr/share/doc/unattended-upgrades/NEWS.Debian.gz , 0.95 entry
<didrocks> seb128: yeah, but you suffer from fsyncing then 7 times instead of one, which is what adds up
<didrocks> I guess an intermediate granularity may be worth exploring (but we need to have an idea of the estimate time to isntall this group of packages, which is hard)
<rbalint> didrocks, i'm sorry but no, one failing package would fail the whole set
<didrocks> failing package is rare, so then a fallback on package by package is doable
<didrocks> which is more code, but more smartness to add to the system as well
<rbalint> didrocks, i plan further speed optimization of debs and u-u
<rbalint> didrocks, i'm thinking about randomizing the order of sets which is expected to cause bigger sets
<didrocks> interesting idea
<rbalint> didrocks, to avoid a single broken package blocking the installation of bigger sets
<mwhudson> who do i talk to about
<mwhudson> apt-esm-hook: hook.cc:186: int main(int, char**): Assertion `ppid == getppid_of("self")' failed.
<mwhudson> Aborted (core dumped)
<mwhudson> breaking all the livefs builds
<mwhudson> e.g. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/disco/ubuntu-server-live/+build/161947
<mwhudson> juliank: do you know about this one? ^^
<seb128> rbalint, anyway, back to other topics/work for me, thx for the discussion, it was interesting! and good to know you are more optimizations planned :) (also you might hear again from me on the topic if we decide to do the indicator, I might then bother you with how to best get the info we need out of u-u)
<rbalint> seb128, thank you too!
<rbalint> seb128, regarding indicating u-u's state i opened a bug some time ago and i think this is more annoying than the morning u-u runs LP: #180358
<ubottu> Launchpad bug 180358 in firefox (Ubuntu) "news paper cant read malayalam in firefox browser" [Undecided,Invalid] https://launchpad.net/bugs/180358
<seb128> rbalint, I guess you lack a digit in that bug number?
<rbalint> LP: #1803581
<ubottu> Launchpad bug 1803581 in gnome-shell (Ubuntu) "PrepareForShutdown() signal from logind is not handled" [Low,Triaged] https://launchpad.net/bugs/1803581
<seb128> rbalint, thx
<juliank> mwhudson: oh oh
<juliank> so I assume the problem is that there is no grandparent process of the hook
<juliank> but that's odd
<juliank> no hang on
<juliank> it's got no /proc/self I guess
<danyspin97> Can the distro revision of a package be numbered like -1ubuntuY.Z ?
<danyspin97> Does ubuntuY.Z instead represents the series that the package applies to?
<rbasak> danyspin97: you might find my writeup helpful: http://www.justgohome.co.uk/blog/2015/01/ubuntu-package-versions.html
<rbasak> danyspin97: also https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<danyspin97> rbasak: Thank you
<danyspin97> rbasak: > A tilde (~) is defined to sort before anything else. Is there any article/reference I can read more about this for PPA?
<rbasak> danyspin97: https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage maybe? And https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version for the actual spec, which should help it all make sense.
<danyspin97> rbasak: Ah, I see. It wasn't clear to me that ~ was in the Debian specification. Thank you!
<tsimonq2> vorlon, cyphermox: Any reason why the mokutils in Disco/Cosmic hasn't been upstreamed to Debian? There's an open RC bug in Debian citing Much Brokenness.
<cyphermox> you mean the int-signedness patch?
<cyphermox> because everything else is just upstream.
<tsimonq2> All of it. :)
<tsimonq2> vorlon is the maintainer, which is why I pinged.
<cyphermox> I'm sure vorlon would have no issues sponsoring your upload to update it
<tsimonq2> I'm a DD, I can upload myself if vorlon acks my NMU. ;)
<cyphermox> ah
<cyphermox> I don't want to speak for him but I'm reasonably sure that would be just fine ;)
<tsimonq2> I mean, unless he wants to do it. :P
<tsimonq2> cyphermox: One other reason I pinged is, I don't exactly know what I should test...
<tsimonq2> I would assume I should do some testing prior to an NMU.
<vorlon> tsimonq2: that RC bug should be downgraded, "this howto I followed somewhere didn't work thus mokutils is completely unusable" is not RC
<vorlon> but it's reasonable to also fix
<tsimonq2> ok
<tsimonq2> vorlon: How do you want to do this? 0-day NMU, DELAYED NMU, you do it...?
<vorlon> tsimonq2: you adopt the package? ;)
<tsimonq2> vorlon: Only if I can add you and cyphermox as comaintainers ;)
<tsimonq2> Sure, why not
<vorlon> nah
<tsimonq2> I mean, if you're serious, I can take it off your hands...
<vorlon> tsimonq2: I am serious; I'm not maintaining it, the Vcs-Bzr field points to an absolete location, there's no increase in my Debian time committment on the horizon
<tsimonq2> ack :)
<tsimonq2> cyphermox: I'll still offer to add you as a comaintainer ^^^
<[rg]> hello
<[rg]> is there a regular expression package names conform to?
<tsimonq2> [rg]: Try looking in Debian policy for that.
<teward> [rg]: though I don't think there's a *regex* that they conform to, more like a package naming convention instead...
<[rg]> teward: ok that convention should be similar to man page style option descriptons right
<infinity> teward: The naming convention can certainly be expressed as a regex.
<teward> infinity: it can?  *blinks* got such a regex?
<sarnold> so long as it doesn't require eg balanced parens.. :D
<teward> hah
<infinity> "Package names (both source and binary, see Package) must consist only of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). They must be at least two characters long and must start with an alphanumeric character."
<infinity> teward: No, I don't have said regex handy, but given any algorithm describing how to construct a string can be expressed as a regex, I leave it as an exercise to the user.
<infinity> [rg]: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-source
<teward> heh
<[rg]> infinity: yes I am fine doing that, was just looking for docs, thanks
<infinity> [a-z][a-z0-9+-.]. seems about right.
<teward> infinity: i must have missed that part, guess being tired hinders that side of the brain :)
<infinity> Maybe with some escaping necessary, depending on the language one's embedding that in. :P
<ddstreet> rbasak so with git ubuntu, with the pre-commit/post-checkout hooks, are we forced to use --no-verify with affected repos *forever*?  that's super annoying
<ddstreet> oh, i guess someone can upload a pkg removing the dir - just can't do it from git
<vorlon> seb128: hi, don't know if you saw my follow-up on LP: #1800542, but I could use some help figuring out how to provide proper debug info for nm-openvpn
<ubottu> Launchpad bug 1800542 in network-manager-openvpn (Ubuntu) "OpenVPN connection not stable after upgrade to 18.10 (udp, ipv6)" [High,Incomplete] https://launchpad.net/bugs/1800542
<seb128> vorlon, hey, I saw and I've it on my backlog to reply to, the week has been a bit crazy but hopefully on monday (I don't know offhand what changed/why the intructions are not working so I need to poke a bit)
<seb128> but eow for now, have a nice w.e!
<rbasak> ddstreet: you can remove the hook if you like. It does nothing apart from detect and warn you.
<rbasak> ddstreet: it's a workaround.
<ddstreet> rbasak well i can't remove it, snaps are r/o filesystems... :)
<ddstreet> but i can ignore it
<rbasak> ddstreet: I mean remove the hook from your local checkout directory
<ddstreet> ah
<rbasak> ddstreet: it's installed in .git/hooks. git ubuntu clone does that.
<ddstreet> nice definitely will remove that then
<rbasak> ddstreet: the thing to note is that it can break your build
<rbasak> Some builds require the empty directory to be present, and your checkout won't have it.
<rbasak> Hence the warning, etc.
<cyphermox> vorlon: you don't need to restart NM, but if you had just "closed" or lost the connection, then you need to wait a little bit before you change the .name file; then it'll work fine.
<vorlon> cyphermox: how long is a little bit?
<cyphermox> at most 30 seconds, I'd say
<cyphermox> there'd be a line in syslog that says something about killing the service IIRC
<cyphermox> also, make sure to run nm-openvpn-service as root
<tsimonq2> vorlon: (mokutil uploaded to Debian)
<Unit193> tsimonq2: Hmm, I seem to recall you claiming you'd fix pastebinit.
<tsimonq2> Oh, did I?
<tsimonq2> Got a link?
<Unit193> Link to?
<sarnold> he'd link you if he could, but pastebinit's busted...
 * sarnold runs
<Unit193> Truth!
<wxl> arc paste works wonderful (of course you need a phabricator instance) :)
<Unit193> Only on disco and busted, err, buster.
<Unit193> wxl: Sounds broken to me.
<wxl> works for me XD
<Unit193> sarnold: You popped up last time too, < sarnold> python :( || < sarnold> tsimonq2: just a recurring sadness
<sarnold> lol
<tsimonq2> Unit193: A link to what I'm supposed to be looking at.
<Unit193> Ah, Debian 916372, LP 1812232
<ubottu> Debian bug 916372 in pastebinit "pastebinit: multiple deprecation warnings under Python 3.7" [Normal,Open] http://bugs.debian.org/916372
<ubottu> Launchpad bug 1812232 in pastebinit (Ubuntu) "Deprecation warnings" [Low,Confirmed] https://launchpad.net/bugs/1812232
<Unit193> Patch attached in the Debian one, from someone that has a clue too.
<tsimonq2> Unit193: DELAYED/5 .
<Unit193> G'luck!
<tsimonq2> Too late for Disco, unless you think it's SRU-worthy.
<sarnold> it probably is if it's going to shout at the user every time they touch it
<Unit193> Got a dsc I can backport to a disco PPA? :)
<tsimonq2> sarnold: Good point.
<tsimonq2> Unit193: You mean the one you can find in the Debian archive once it's processed? ;)
<valorie> pastebinit is so useful when someone's in trouble
<valorie> bad install or so
<Unit193> Or to paste debdiffs, git format-patch, config, etc, etc.
<valorie> right, I don't spend much time in the console, but for those who do, I imagine endlessly useful
#ubuntu-devel 2019-04-13
<Eickmeyer> Have at it, everyone: http://iso.qa.ubuntu.com/qatracker/milestones/403/builds
<tsimonq2> cyphermox: Could you please update the Lubuntu packageset?
<tsimonq2> We're expecting golang to disappear.
#ubuntu-devel 2019-04-14
<gjasny> Hello, I'm the Debian maintainer of v4l-utils and would like to fix a FTBFS in my package in cosmic. I have a debdiff ready but I'm completely unfamiliar with the uploading and sponsoring process in Ubuntu. Could anyone please help me with: https://bugs.launchpad.net/ubuntu/+source/v4l-utils/+bug/1823650
<ubottu> Launchpad bug 1823650 in v4l-utils (Ubuntu) "v4l-utils ftbfs in cosmic" [High,New]
<danyspin97> Does the list of files for a package show symlinks?
<cjwatson> danyspin97: As in dpkg -L?  Yes
<cjwatson> $ dpkg -L openssh-server | grep /usr/share/doc/openssh-server
<cjwatson> /usr/share/doc/openssh-server
<cjwatson> $ ls -ld /usr/share/doc/openssh-server
<cjwatson> lrwxrwxrwx 1 root root 14 Feb 12  2013 /usr/share/doc/openssh-server -> openssh-client
<danyspin97> cjwatson: Thank you
<ejat> anyone can help on bug 1818772
<ubottu> bug 1818772 in grub2 (Ubuntu) "[disco-proposed] On the Boot splash screen, Grub does not show the 5.0 kernel installed." [Undecided,New] https://launchpad.net/bugs/1818772
<danyspin97> is ${misc:Depends} only useful when using dh to build a package? Or should it be added anyway?
#ubuntu-devel 2020-04-06
<RAOF> By my understanding that could only happen if you shipped an identical library in two different packages?
<RAOF> (Because the debugging symbols get put in a path dependent on their BuildID, and the BuildID is unique-per-build)
<Eickmeyer> RAOF: I looked, and I don't see any matching files in the packages, let alone libraries.
<RAOF> Eickmeyer: *are* you shipping the same `.so` in multiple packages (presumably in multiple filesystem locations)?
<Eickmeyer> RAOF: I don't believe so. I can double-check, but I couldn't find anything common between those three packages.
<RAOF> Yeah, those debugging symbols are generated in the debhelper machinery.
<RAOF> Hm. From a cursory look at the Makefile, it seems that the R3D library is getting installed in two different places.
<RAOF> That's what'd be causing this.
<Eickmeyer> Then Upstream goofed. I'll have to let them know.
<RAOF> They might need it in multiple places. You could fix this by making both packages depend on a 3rd package and symlinking the relevant library in the right place?
<Eickmeyer> I could probably do that.
<seb128> cjwatson, hey, what do you think about changing the maintainer on https://launchpad.net/ubiquity to maybe ubuntu-core-dev?  (which is what is done for update-manager/update-notifier/software-properties)
<cjwatson> seb128: Sure, done
<seb128> cjwatson, thanks!
<juliank> zsync -i focal-desktop-amd64.iso http://cdimage.ubuntu.com/ubuntustudio/releases/focal/beta/ubuntustudio-20.04-beta-dvd-amd64.iso.zsync
<juliank> let's see what that does!
<juliank> :D
 * juliank wonders how much he can reuse from the ubuntu image for studio
<juliank> heh it's still reading the seed file :/
<Saviq> didrocks: hey, FWIW my `bpool` did not have a cachefile set:
<Saviq> $  zpool get cachefile bpool
<Saviq> NAME   PROPERTY   VALUE      SOURCE
<Saviq> bpool  cachefile  -          default
<Saviq> not sure if that's meaningful or not - will try rebooting in a sec
<didrocks> Saviq: yeah, some had depending on when they installed it and if the generator set it. At least, itâs not set, which is the point
<didrocks> Saviq: keep me posted!
<Saviq> and the rest of your instructions were basically what I had to do to get my system in order (provided I didn't forgetâ¦ at which point I had to do it from a live USB)â¦
<Saviq> didrocks: is there a way to abort the grub upgrade if it didn't generate any sane entries?
<didrocks> Saviq: I donât know, each script is independent, so having "empty" results is valid (no ZFS for the zfs script, nothing in 10_linux if zfs entries, only os-prober entriesâ¦. Maybe a patch to grub-mkconfig directly to check that you at least have one entry will be a fix
<juliank> reuse was 21.2%
<juliank> better than nothing
<juliank> (re how much can I reuse my ubuntu iso when fetching studio iso=
<juliank> AFAICT, gnome-system-monitor produces completely wrong network bandwidth
<juliank> it like shows 15.6 Mbit/s, whereas iftop shows 8-9.5 Mbit/s
<juliank> it also says I
<juliank> 'm sending at 300-500 kbit/s
<juliank> when it's really just 140-200
<juliank> it's ... odd
<Saviq> I filed a bugâ¦ somewhereâ¦ about g-s-m bandwidthâ¦
<Saviq> didrocks: that didn't help, neither did adding "Before=boot-{efi-grub}.mount" to zfs-import-{scan,cache}.serviceâ¦
<juliank> Saviq: ah good
<didrocks> Saviq: please donât change the order for generator units, we shouldntâ use zfs-import-*
<didrocks> Saviq: so, do you have other .mount units in /run/systemd/generator/ ?
<Saviq> didrocks: yeah that was just me messing about, lemme remove
<Saviq> didrocks: https://paste.ubuntu.com/p/2XXKpBkn25/
<didrocks> ack, so you are missing boot.mount
<didrocks> my bet is that /etc/zfs/zfs-list.cache/bpool is empty
<didrocks> (but not /etc/zfs/zfs-list.cache/rpool)
<Saviq> didrocks: correct, no `bpool` there
<Saviq> something of a chicken'n'egg by now I suppose?
<didrocks> exactly!
<didrocks> you can either reset to the initial state
<didrocks> or just patch it as if nothing happened :p
<didrocks> I would suggest reverting to the initial state by creating the same cache metadata as a fresh install
<Saviq> didrocks: tell me how :)
<didrocks> (you need zfsutils-linux 0.8.3-1ubuntu11)
<Saviq> got it
<didrocks> echo "" > /etc/zfs/zfs-list.cache/bpool
<didrocks> echo "" > /etc/zfs/zfs-list.cache/rpool
<didrocks> to create those 2 empty files
<didrocks> ensure you have bpool and rpool in the bpool cache
<didrocks> grep bpool /etc/zfs/zpool.cache
<didrocks> grep rpool /etc/zfs/zpool.cache
<Saviq> matching
<didrocks> (and ensure you fixed /boot/grub /boot/efi as in the bug)
<didrocks> like /boot is empty
<didrocks> so umount them, rmâ¦
<didrocks> then reimport bpool which should now mount
<didrocks> then sudo mount -a for /boot/grub and /boot/efi
<didrocks> update-grub
<didrocks> and you should be reset to the same state than people who just installed the beta
<didrocks> (with your data ofc)
<Saviq> didrocks: /etc/zfs/zfs-list.cache/bpool now has contents - but rpool does not, that will happen on next boot, will it?
<didrocks> Saviq: yeah, the improt populated it, but you can empty it again, the boot will populate them
<didrocks> import*
<Saviq> ack, will report back
<didrocks> thx!
<Saviq> didrocks: yes, that finally helped \o/
<didrocks> Saviq: nice! Thanks for hanging on here :) So yeah, this confirms that new installs shouldnât be impacted (from beta). The issue of the generator failing unnoticed because systemd doesnât stop the boot is annoying. Weâll upstream to ZFS how we made the generator more robust + dropping to emergency if something bad happens to prevent then having your bpool messed by systemd
<Saviq> didrocks: ack, thanks :)
<juliank> OK, so ubuntustudio beta does not seem to launch in my kvm
<juliank> simple kvm with secure boot, -vga virtio, and -display gtk,gl=on
<Laney> Wimpress had some problems with GL & XFCE flavours
<juliank> Laney: aha
<juliank> Laney: turning that off helped, yes
<Laney> bug report would be useful I guess, not sure if one got filed
<juliank> Eickmeyer: testing now
<juliank> Eickmeyer: analysis posted
<juliank> xnox: you might want to review my analysis in https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1851346, just in case I missed something
<ubottu> Launchpad bug 1851346 in ubuntustudio-meta (Ubuntu Focal) "Ubuntu Studio 19.10 Installer Causes Wanted Programs to be Removed" [Undecided,Confirmed]
<juliank> xnox: The plugin was marking a ton of stuff for removal, and that stuff was depended upon by other critical stuff like plymouth themes
<juliank> xnox: Also you might just want a good scare
<juliank> The plugin assumed that any Recommends or Suggests of a metapackage could safely be removed, which is not the case
<juliank> Hence the solution is to remove the plugin, or make it only offer selected known-good removals
<juliank> I don't care which solution ubuntustudio takes
<xnox> Wimpress:  ^^^^
<xnox> my vote is to drop the plugin, unless people can come up with curated list of things they want to allow to drop
<xnox> ie. something akin of ubuntu-desktop-minimal install type
<juliank> example: ubuntustudio-desktop-core recommends fonts-ubuntu, hence fonts-ubuntu was offered for removal
 * xnox hm, actually Wimpress is not ubuntustudio lead, who was it?
<juliank> xnox: Eickmeyer
<ivoks> rafaeldtinoco around?
<xnox> Eickmeyer:  ^^^^
<rafaeldtinoco> ivoks: yep
<juliank> xnox: who I pinged first :)
<juliank> but i
<ivoks> rafaeldtinoco hey, why don't we just transfer existing LP group to you?
<juliank> 'm sure W impress is interested in all our flavors
<juliank> :D
<juliank> in them succeeding
<AsciiWolf> kenvandine, hi, is the fixed version (with fixes to make regular ubuntu packages available, not only snaps) of Snap Store available in Ubuntu 20.04?
<ivoks> rafaeldtinoco you have debian maintainer in there, etc
<rafaeldtinoco> ivoks: not sure, but we already had the ubuntu-server, i added a "ha" after it, and then discover there was an ubuntu-ha
<xnox> Eickmeyer:  juliank: reading the metapackage, it seems to me that ubuntustudio-*-core packages shouldn't be offered for removal
<rafaeldtinoco> ivoks: vivec ?
<ivoks> rafaeldtinoco maybe old debian maintainer :) i haven't look into these packages in a while
<juliank> xnox: None of the metapackages should be, really, only their Recommends/Suggests
<juliank> xnox: But then still problems
<ivoks> rafaeldtinoco loschwitz
<rafaeldtinoco> ah great
<juliank> ubuntustudio-desktop recommends fonts-ubuntu too
<rafaeldtinoco> can u put me in there then ?
<rafaeldtinoco> Ill transfer things later this week
<juliank> as does ubuntustudio-fonts
<juliank> same for other packages and dependencies
<xnox> urgh
<juliank> well, s/same/similar/
<juliank> :)
<juliank> You could build a list of removable recommends/suggests at live build time, I guess
<juliank> like try to remove each optional package, check that it does not remove metapackages
<juliank> if it does -> don't add it
<ivoks> rafaeldtinoco can you check if that's you ;)
<juliank> if metapackages remain installer -> add it
<juliank> store the list _somewhere_
<ivoks> it is
<ivoks> making you an admin
<juliank> but that requires livecdrootfs work
<juliank> so... meh
<rafaeldtinoco> ivoks: yep!
<AsciiWolf> kenvandine, it does not seem to be on my system, the last stable Snap Store is 20191114 for some reason... I have tried installing the latest edge version, core system snaps were no longer uninstallable, but regular Ubuntu packages were still missing... also, it broke the ubuntu-software integration/branding on my system, the Ubuntu Software icon disappeared
<rafaeldtinoco> ivoks: do u mind if I refresh things ?
<rafaeldtinoco> ivoks: deleting old ppa, keeping a staging one
<rafaeldtinoco> etc etc
<ivoks> rafaeldtinoco by all means
<ivoks> things are quite old there
<rafaeldtinoco> nice
<rafaeldtinoco> i'll point wiki to the server guide im creating also
<rafaeldtinoco> tku
<ivoks> rafaeldtinoco there's also https://launchpad.net/~ubuntu-ha-maintainers
<rafaeldtinoco> ivoks: hum.. E_TOOMANYGRPS ?
<ivoks> rafaeldtinoco i'll let you organize this any way you want
<ivoks> :)
<rafaeldtinoco> cool
<kanashiro> locutus_, to fix ruby stuff in proposed (reported by edos-distcheck) we still need to sync 3 packages: ruby-rchardet, ruby-redis and ruby-mini-magick
<kanashiro> I filed bugs for them
<kanashiro> #1871110 , #1871118 and #1871120
<kanashiro> there is another package missing (ruby-enumerable-statistics) but it is still in the Debian NEW queue
<kenvandine> AsciiWolf: latest/stable/ubuntu-20.04 is the branch you want
<kenvandine> AsciiWolf: there is still an issue with regular apt packages, which will be fixed in the next snapd
<kenvandine> once all that's in place it'll get promoted to stable
<kenvandine> AsciiWolf: but for now the stable branch is snap only and not the latest code
<AsciiWolf> kenvandine, ah, ok :-) thanks for your work, I appreciate it!
<kenvandine> AsciiWolf: np
<LocutusOfBorg> kanashiro, ruby-redis loooks saaaaaad https://launchpadlibrarian.net/473255574/buildlog_ubuntu-focal-amd64.ruby-redis_4.1.2-4_BUILDING.txt.gz
<LocutusOfBorg> retrying the build
<kanashiro> LocutusOfBorg, ok, if it still fails I can take a look
<LocutusOfBorg> it worked on the second try
<kanashiro> great :)
<rbasak> !dmb-ping
<ubottu> ddstreet, rafaeldtinoco, rbasak, sil2100, slashd, teward, tsimonq2: DMB ping
<rafaeldtinoco> rbasak: not sure it worked
<rafaeldtinoco> i got the ping by a highlight to my name only
<rbasak> rafaeldtinoco: that's all it does :)
<rafaeldtinoco> rbasak: but from ddstreet
<rafaeldtinoco> !dmb-ping test
<rbasak> rafaeldtinoco: that's probably just your IRC client's parsing
<rafaeldtinoco> you mean a web irc client is not good ? :P
<rbasak> rafaeldtinoco: maybe we should move all the Ubuntu IRC channels to Signal? :-P
 * rafaeldtinoco adding as a next dmb meeting item to discuss with your name on it
<rafaeldtinoco> "suggested by"
<seb128> cjwatson, hey, sorry for the direct ping but you seem to have dealt with most of those in the past ... do you have a tool/script to update the booloader.pot in gfxboot-theme-ubuntu?
<seb128> cjwatson, or is that done by manually calling po/bin/add_text for every string?
<blackboxsw> rbasak: bryce and other git gurus.... we have a development git ubuntu/<series> branch used for daily packaging recipe builds. Our packaging recipe build merges tip master of our project into the <series> branch and rebuilds to make sure our tip doesn't break <series>.
<blackboxsw> the complication comes during feature freeze, when we only cherry-pick changes into ubuntu/<series> and perform a release. After that event, we immediately revert the cherry-picks in ubuntu/<series> so daily recipes continue to build when merging tip
<cjwatson> seb128: I believe I always used my NOT AT ALL HACKY rosetta-merge (https://paste.ubuntu.com/p/gVyGkdfxrp/) + rosetta-merge-all (https://paste.ubuntu.com/p/MXjg4W3NQH/)
<cjwatson> and went over the VCS diff very carefully afterwards.  I can't remember exactly which combination of rosetta-merge-all options I used for gfxboot-theme-ubuntu though
<blackboxsw> rbasak:/bryce in this last feature freeze period we have released multiple times from ubuntu/devel with multiple sets of cherry picks which push on during each pkg release event, and pop off immediately afterward to ensure daily package builds succeed.
<blackboxsw> rbasak: / bryce it makes for a very dirty set of commit logs (and debian/changelog)
<cjwatson> You might have to experiment a bit.  Definitely at least "--apply --prefix bootloader-" but I can't remember whether I used --keep-old
<seb128> cjwatson, ok, thanks for the pointers,, I will play with that
<cjwatson> I was always sort of hoping somebody would write something that wasn't a giant hack :)
<bryce> blackboxsw, are you able to discard the dirty commits when you resync?  Does any of the 'chaff' end up in the released package, or is it contained just to ci?
<seb128> haha
<blackboxsw> rbasak: bryce. I'm looking at trying to avoid carrying very noisy sets of cherry-pick/push/pop commits on the series branch by leveraging git reset  HEAD~<cherry-pick-count> when we are trying to reapply cherry-picks during 2nd release.
<blackboxsw> bryce: rbasak yes I can discard the commits with something like the following....
<rbasak> blackboxsw: I suggest that you've got two things going on there: 1) you want to ensure that master is always backportable to stable releases, and 2) you want to maintain stable branches with cherry-picks during feature freeze
<rbasak> blackboxsw: could you disentangle the two? With two PPAs - one dedicated for the first purpose only.
<blackboxsw> rbasak: bryce this PR adds the --pop-all logic/flow https://github.com/CanonicalLtd/uss-tableflip/pull/45/files#diff-dc87560a3829792f8c7376e1cbffa698R103-R116
<blackboxsw> rbasak: yeah it does seem a bit like things are complicated because we are trying to do two things in one place
<blackboxsw> my question ultimately was going to be is there an easy way in a git commit range to "reset" certain commits in that range, but leave other interleaved/unrelated/non-cherry-pick commits
<bryce> blackboxsw, two separate systems makes sense to me too.  We do that with inkscape - a 'pure' master daily build, and a 'stable-daily' build that tracks the alpha/beta/pre-* stuff prior to the release.  The latter branch is quiescent most of the time but active leading up to release time
<rbasak> blackboxsw: there's "git revert -n"
<rbasak> You can use that to build up a set of reverts into a single commit
<blackboxsw> iiiinteresting.
<blackboxsw> ok that may be a stop gap too. and I'll talk to the team about potential separation of tasks... ppas
<seb128> cjwatson, you used those scripts to import the translations, not the template right?
<cjwatson> Yeah, I don't quite remember about the template I'm afraid
<seb128> no worry
<cjwatson> It may well have involved some ad-hoc script around add_text
<cjwatson> Sounds vaguely familiar
<seb128> I think I figured things enough to do it the hacky way
<seb128> I will do those add_text calls in a small script, looping with the strings and the flavor names
<seb128> cjwatson, thanks
<cjwatson> Yeah, I bet that's basically what I did.  Have fun
<seb128> thanks!
<jdstrand> rbalint: hi! looking at https://bugs.launchpad.net/snapd/+bug/1871148/comments/10
<ubottu> Launchpad bug 1871148 in snapd "services start before apparmor profiles are loaded" [Critical,Confirmed]
<jdstrand> rbalint:: so, zfs-on-root does different pools for /var such that local-fs.target is satisfied but /var/lib/snapd/apparmor/profiles does not exist at the time the service starts
<jdstrand> rbalint: so we were thinking of adding to apparmor.service: RequiresMountsFor=/var/lib/snapd/apparmor/profiles
<jdstrand> rbalint: do you feel that would be reasonable?
<zyga> FYI https://github.com/openzfs/zfs/blob/5a42ef04fd390dc96fbbf31bc9f3d05695998211/etc/systemd/system/zfs-mount.service.in#L8
<zyga> Perhaps this is buggy somehow
<jdstrand> zyga: oh, nice fine. what is /lib/systemd/system/*zfs*service ? are they using that service file or are the hand-grown?
<jdstrand> hand-made*
<jdstrand> or home-grown, but not hand-grown :)
<jdstrand> jibel: hey, I see you assigned that ^ to yourself. how are you planning on fixing it?
<rbasak> bryce: next MP up when you're ready please: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/381765
<rbasak> I expect this will take you some time to review, and there may be some back-and-forthing
<bryce> rbasak, ok noted
<jibel> jdstrand, hi, I just saw the bug when I EOD'd following all the pings on #snappy, I'll have a look tomorrow morning if anything can be done to reorder the zfs unit.
<jdstrand> jibel: ok. fyi, I will be adjusting RequiresMountsFor in apparmor
<xevious> I've been working with mlombard at Red Hat to resolve some LIO lockups in the kernel. The first patch set was merged to the upstream kernel recently. Our affected systems are all running Ubuntu 16.04 - what process should I follow to propose backporting those patches to fix the lockup?
<xevious> Here's the main fix commit: https://github.com/torvalds/linux/commit/57c46e9f33da530a2485fa01aa27b6d18c28c796#diff-b7557d7ed3ba34645f6e9d510f281d3a
<juliank> xevious: https://wiki.ubuntu.com/Kernel/FAQ/DevHowToPatch
<xevious> Thanks
<bdmurray> marcustomlinson: is somebody like L_aney going to upload update-manager soon for the POTFILES fix, or should I do that? I ask as I have another upload of update-manager to do.
<jwallden> Hey guys. I'm trying to set up a custom iso and are using preseeding for the install. I have a really strange behavior from Ubiquity now. When using file= to point to the preseed-file everything works as expeted. But when I use preseed/url= it downloads the file just fine but then then Ubiquity completely ignores everything
<jwallden> Furthermore I had to use preseed/url to get it to boot at all. Using just url made grub not find the bootdisk. So the documentation is wrong I think
#ubuntu-devel 2020-04-07
<alkisg> Hi, /etc/network/interfaces ships with "source-directory /etc/network/interfaces.d", which isn't supported since 16.04 and "source /etc/network/interfaces.d/*" should be used instead,
<alkisg> ...what creates that file, where should I file a bug?
<alkisg> Oh, my bad, ignore that please :)
<AsciiWolf> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1639863 - any chance that this three years old appstream-generator bug that is still happening could be fixed? it is assigned to fjkongm but there was no progress since and it blocks Firefox and Thunderbird from showing in GNOME Software (Snap Store)
<ubottu> Launchpad bug 1639863 in firefox (Ubuntu) "Firefox and Thunderbird don't appear in the (new) appstream metadata" [Undecided,In progress]
<zyga> hello
<zyga> are packages still migrating from debian to universe?
<zyga> or are we too late in the freeze
<zyga> the package I'm thinking about is a new package, not in universe yet
<tumbleweed> they stopped automatically syncing on Feb 27: https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule
<zyga> aha, I see
<zyga> oh well
<zyga> thanks!
<cjwatson> Manual syncs are still possible if there's a sufficiently good reason and somebody is looking after them
<cjwatson> (Subject to feature freeze exceptions, possibly)
<zyga> it's just my pet library
<zyga> it's not used by anything yet but I wanted to have it in Ubuntu
<zyga> leaf library
<zyga> the name is not "leaf"
<rbasak> bryce: I've posted https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/381849 for discussion with you please, but lower priority than the other branch. If you diff it against my commit-message-spec you should see the changes (Launchpad has generated an incorrect preview diff). I'd like to compromise on our usual quality level to get this landed, so can we discuss after you've
<rbasak> familiarized yourself with these proposed changes please?
<rbasak> Oh, the preview diff is accurate. Just the list of commits above it that is wrong.
<Eickmeyer[m]> juliank: FYI, I don't know if you saw, but I just decided to remove the plugin from ubuntustudio-live since it's so problematic. Might be a good thing going forward considering the plans the team and I now have.
<bryce> rbasak, noted, thanks
<zyga> jibel: https://bugs.launchpad.net/apparmor/+bug/1871148/comments/14
<ubottu> Launchpad bug 1871148 in apparmor (Ubuntu Focal) "services start before apparmor profiles are loaded" [Critical,Fix committed]
<xnox> Eickmeyer[m]: +1
<xnox> Indeed things diverged, to the point of not working anymore properly as a complete whole.
<Eickmeyer[m]> xnox: Exactly, and I don't have the know-how to get it to work properly, nor does anyone on my team.
#ubuntu-devel 2020-04-08
<mwhudson> why does reverse-depends print to stderr
<mwhudson> that seems odd
<jamespage> anyone looking at the sphinx autopkgtest failures in focal proposed?
<didrocks> rbalint: is that expected that /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal is kept running (started 3h30 half ago) and that I have /var/run/unattended-upgrades.lock and /var/run/unattended-upgrades.progress (latest with ProgressionÂ : 80.0 % (libegl1-mesa-dev) unchanged)
<rbalint> didrocks, yes, it is ok
<rbalint> didrocks, u-u.service is always running waiting for shutdown, then it gracefully stops u-u
<didrocks> rbalint: is it normal that the progress file is there. with the same % and stuck?
<didrocks> rbalint: also, I want to have an action hooked up before the first apt call and at the end of the unattended-upgrade transaction (after the last apt call). We are using apt hook currently, with some file to run it only once, but thatâs not clean nor fully fix it for unattended-upgrades ofc. Is there a way to hook us to unattended-upgrades that way?
<rbalint> didrocks, yes, because it is not used nor should be looked at
<didrocks> rbalint: ok, so it seems we canât use files to have our pre/post-hook, any hints on how we can do this? ^
<rbalint> didrocks, please open a PR/issue at https://github.com/mvo5/unattended-upgrades to discuss that
<didrocks> doing
<didrocks> rbalint: https://github.com/mvo5/unattended-upgrades/issues/266
<ricotz> hello, could someone approve vala 0.48.3-1 in focal/queue
<ricotz> infinity, hi :) ^
<RikMills> ricotz: I think inf1nity is unlikely to be around. I suspect other r-t members in that channel are a better bet
<Laney> There's no need to ping though, it'll get looked at
<RikMills> :)
<ricotz> RikMills, I see, I looked at https://wiki.ubuntu.com/ArchiveAdministration#Archive_days
<ricotz> Laney, sounds fair, but it doesn't seem that way
<Laney> It is that way
<Laney> I'm going to go through the queue later on today, for example
<ricotz> Laney, FIFO would be the concept to wish for here -- thanks
<Laney> ricotz: I'll start from the oldest. :P
<Laney> but I'm sure Jeremy's syncs will all be obviously great and correct, so very fast to review
<Laney> :)
<ricotz> that is what fifo means (just saying there are a lot of packages uploaded after vala which are gone already)
<ricotz> Laney, #1
<Laney> right
<infinity> ricotz: Yeah, it'll never be a FIFO, but hey, we get there.
<ricotz> infinity, ok :)
<jdstrand> jibel (cc zyga): I'm not sure the apparmor change is sufficient to address bug #1871148. See my latest comments
<ubottu> bug 1871148 in zsys (Ubuntu Focal) "services start before apparmor profiles are loaded" [Undecided,New] https://launchpad.net/bugs/1871148
<zyga> ack
<zyga> looking
<jdstrand> jibel (cc zyga): I'm going to ping diddledan in #snapcraft to retest. popey, you may want to as well ^
<jdstrand> .wu8
<jdstrand> erf
<popey> heh
<seb128> lathiat, hey, any reason avahi-daemon-check-dns.sh isn't being removed in Debian? I saw you suggested some fixes there on https://salsa.debian.org/utopia-team/avahi/-/commit/a856156a but bug #1870824 you suggest removing it? wouldn't that apply to Debian as well?
<ubottu> bug 1870824 in avahi (Ubuntu) "Errors in script /usr/lib/avahi/avahi-daemon-check-dns.sh" [Low,In progress] https://launchpad.net/bugs/1870824
<lathiat> Yeah it should also be removed in Debian. I guess just no one told them. I only thought of it recently as part of that person asking me about that bug seb128
<lathiat> seb128: Those other fixes were mainly because we had to backported that fix to bionic without the fixed nss-mdns
<jdstrand> popey: to be clear, I meant you may want to test if the issue is fixed, not ping diddledan ;)
<lathiat> Well when I say fixed I guess you could say improved
<popey> got it
 * diddledan pings jdstrand
<diddledan> you know. just for the giggle :-p
<seb128> lathiat, http://paste.ubuntu.com/p/7NGn4tfgrR/ looks good to you?
<jdstrand> hey diddledan :)
<jdstrand> jibel: fyi, after a reboot and upgrading apparmor, diddledan sees this: https://paste.ubuntu.com/p/3VjZhgQRyT/
<jdstrand> jibel: which looks correct. but I'm worried there is a race or something where var.lib.mount will sometimes be there and sometimes won't and people using snaps with root-on-zfs may hit an intermittent bug
<jdstrand> popey: actually, iirc, you had said that restarting apparmor worked to resolve the issue (which of course it would, it was way after /var/lib would be present), but did you always have to do this? just every once in a while?
<jdstrand> popey: (after reboot)
<popey> i almost never reboot
<jdstrand> jibel: (fyi, popey also saw this issue)
<jdstrand> yeah, I hear you
<popey> so this is not an issue I see very often, as a result of that
 * jdstrand nods
<lathiat> Seb128: Yeah that looks ok. While youâre at it thereâs half an Ubuntu patch Iâd want to drop as well the local host services only patch I merged half of it upstream in 0.8 which I released some weeks ago but i removed the line where it rewrites the hostname to localhost. That was originally needed by cups for ippusbxd but I got till to fix cups not to need it. And that fix should be in focal. Per here:
<lathiat> https://github.com/lathiat/avahi/commit/2fd76baeb8298ef1b5b177bf7fd70f6cda3eab00 - if you do prepare a package for either I can test them tomorrow (in about 10 hours)
<jdstrand> diddledan: you only just started seeing this, right? how often do you reboot? how long have you been using zfs-on-root?
<diddledan> I've been using ZFS-on-root since march 3rd.. I reboot sporadically.. sometimes multiple times a day and other times once in several days
<diddledan> I need to go to Winders to watch Westworld, so I've started rebooting at least once a week to do that ;-p
<jdstrand> jibel: I don't really know zfs: are there times when zfs is doing something on boot for housekeeping or similar that might cause a smallish delay in boot before its .mount units show up?
<jdstrand> diddledan: have fun!
<diddledan> every Sunday or Monday ;-)
<didrocks> jdstrand: zsys/zfs doesnât really do anything since we enabled the generator. Basically, we have a systemd generator which creates .mount files. Systemd is then ordering the units are mounting them
<didrocks> jdstrand: so, I think the issue comes from systemd itself
<didrocks> (I think if you create a similar partitionning on ext4 and let systemd mounting them on boot, you will end up with the same issue)
<didrocks> zfs-mount.service units are no-op in our configuration
<didrocks> would it be possible for systemd to have a race in the mount units ordering/picking when RequiresMount= is? unlikely, but maybe a regressionâ¦
<jdstrand> didrocks: idk. I only updated the apparmor unit for correctness and am just giving some ideas. I've not tried to create .mount units with ext4 with similar partitioning (cc zyga). but, does zfs perform some housekeeping on boot prior to when the mounts might show up?
<jdstrand> zfs-load-module.service, zfs-import-cache.service and zfs-import.target are all listed in https://paste.ubuntu.com/p/3VjZhgQRyT/ (a successful boot) prior to var.lib.mount
 * zyga checks backlog
<lathiat> Iâm
<jdstrand> perhaps one of those is taking too long, apparmor starts and var.lib.mount isn't generated
<jdstrand> and then at some later point it is
<zyga> about that topic
<zyga> I don't understand why apparmor starts
<zyga> if it has after local-fs.target
<zyga> can local-fs.target be reached before zfs probing is done?
<jdstrand> zyga: that is the question. see my comments in the bug
<zyga> ok, let me catch up with developments
<jdstrand> zyga: on one boot, local-fs.target had zfs in its critical-chain, on another it did not
<lathiat> Not sure if strictly related but the Zfs stuff basically doesnât work for hotplugged stuff including USB devices present at boot. Either in bionic or focal with my current testing (at least for multi device zfs). I thought the new generator stuff would help but it didnât seem to. The zpool import task seems to run and finish before the USBs appear. I was thinking the generated pool units need to depend on the
<lathiat> device paths but thatâs as far as I got looking into that.
<lathiat> So I have to run zpool import -a manually atm on my setup
<didrocks> jdstrand: when we do a manual mount in our tests (like create a pool and then run grub which mounts and immediatly accessing its content on next line), we didnât see any kind of latency (we ran the tests multiples thousands times on fast and slow machines/disks), so that seems unlikely at first glance, but not impossible ofc
<lathiat> So if youâre trying to reproduce a problem like that maybe try setup two USB drives
<jdstrand> zyga: the RequiresMountsFor change in apparmor is only going to work if there is a .mount unit at the time the apparmor service is started, aiui
<zyga> lathiat: here it was /dev/sda*, sata with zfs
<zyga> jdstrand: indeed
<lathiat> My setup is non root btw. Just a storage mount.
<zyga> jdstrand: note that systemd generates .mount units for every mount in the system (however it was created)
<zyga> but it is indeed possible to race
 * zyga checks the bug history 
<didrocks> lathiat: the generator is mostly done for root, it will create additional mounts only if you the zfs-list cache corresponding to your disk, otherwise, it will be the traditional import + zfs-mount systemd services
<nomad_fr> hi
<jdstrand> zyga: right. I think didrocks is right to point out there could be a bug in systemd. however, if there is something that takes a while for zfs to start up before the mount units can even be generated, that would be a bug somewhere else
<nomad_fr> I just discover Zsys it's perfect
<zyga> jdstrand: I wonder if we could see when local-fs.target was reached
<zyga> jdstrand: and compare that to when zfs was started / completed
<lathiat> Yeah I setup the list cache but it still fails (with or without).
<zyga> jdstrand: and when apparmor was started
<nomad_fr> does someone know if it's possible to swithc a non Zsys zfs install to a Zsys one ?
<didrocks> nomad_fr: if you donât know the internals, we disabled on purpose zsys on non zsys managed systems
<jdstrand> zyga: well, there is the systemd-analyze plot and dot, but we unfortunately saw that it didn't list apparmor once when it had obviously started :\
<zyga> jdstrand: oh, right
<zyga> that's so weird
<zyga> bugs bugs bugs :/
<didrocks> nomad_fr: so yeah, Zsys isnât perfect as it wonât manage manually installed setup :)
<nomad_fr> didrocks: I'm able to adapt my manually installed setup to match Zsys need
<nomad_fr> didrocks: I just need to know what is needed
<zyga> jdstrand: perhaps for 20.04 we could avoid it by _not_ making /var/lib a zpool
<didrocks> nomad_fr: so I suggest do a beta install, look at the datasets layout and mirror that out. You will need to also add the same user properties to your datasets
<zyga> whatever the bug is, we can fix it for +1
<didrocks> nomad_fr: or wait for a month, Iâll publish some blogs about the internals
<nomad_fr> didrocks: I'm so excited about this, I use beadm on FreeBSD it's almost the same
<nomad_fr> didrocks: what is your blog url ?
<didrocks> nomad_fr: https://didrocks.fr (but yeah, will be published in a month or so :p). Glad that you are excited :)
<didrocks> zyga: /var/lib is not a zpool, itâs a dataset and thatâs required for the server type layout
<zyga> oh
<zyga> sorry,
<zyga> well, it's a mount point
<zyga> I'm not sure how zfs installer defaults look like precisely, sorry
<didrocks> no worry :) we have a spec if interested in why this separation :)
<didrocks> Hower as I wrote, seeing the number of mounts + direct access to its content we have in our tests and how many of them we ran on different hardware, if there was even a slight delay between the mount exiting and the file system content to be available, we should have seen it
<didrocks> hence my pick on rather ordering on systemd mount units file
<didrocks> the mount units have Before=local-fs.target zfs-mount.service
<didrocks> so that ought to be ordred by systemd (/var/lib in particular) before local-fs.target
<didrocks> ah, but diddledan installation is before beta
<jdstrand> fyi, https://bugs.launchpad.net/apparmor/+bug/1871148/comments/21
<ubottu> Launchpad bug 1871148 in zsys (Ubuntu Focal) "services start before apparmor profiles are loaded" [Undecided,New]
<diddledan> did I break it, didrocks? :-p
<didrocks> diddledan: maybe your setup isnât compatible with the generator fix. However, I think jdstrand installed from beta
<jdstrand> I did a fresh install
<didrocks> diddledan: ensure you both have bpool and rpool in your /etc/zfs/pool.cache
<diddledan> I used a daily image from early march
<nomad_fr> I also have had trouble with kernel update and zfs.mount
<jdstrand> but note my bug comment. based on systemd-analyze plot, it looks ok on the system where systemd-analyze critical-chain looks like it might not be
<diddledan> cat: /etc/zfs/pool.cache: No such file or directory
<nomad_fr> didrocks: on aurai pu parler Francais
<jdstrand> I need to step away for a bit
<didrocks> diddledan: ensure you both have bpool and rpool in your /etc/zfs/pool.cache
<didrocks> oopsss
<diddledan> cat: /etc/zfs/pool.cache: No such file or directory :-p
<didrocks> jdstrand: yeah, however, the critical chain doesnât show up all units leading to an unit, no?
<didrocks> diddledan: :p
<didrocks> diddledan: /etc/zfs/zpool.cache
<jdstrand> didrocks: I did the critical chain on the unit itself
<jdstrand> sudo systemd-analyze critical-chain apparmor.service
<didrocks> jdstrand: isnât that the longest path leading to apparmor.service?
<jdstrand> maybe critical-chain isn't the right diagnostic tool to verify things are ok
<didrocks> so if those units took longer than var.lib.mount, itâs wait is pending
<didrocks> isnât not listed*
<jdstrand> the man page isn't clear on this point
 * jdstrand really has to go
<didrocks> I wonder how we can have something more precise from systemd :/
<diddledan> "precise? this is focal!"</troll>
<nomad_fr> didrocks: infact I've some 'special' request has I'm installing my computer parc (50 ubuntu) with tftp + preseed + salt. I really love this Zsys feature. I wan't to know how to build my preseed to match it's need.
<didrocks> nomad_fr: remember that Zsys will be kept as experimental this cycle, so not a really good time to install on a park :) But yeah, just wait on my technical blog posts you should have what you need
<nomad_fr> didrocks: cool thanks so Zsys will be 'stable' with 20.10 ?
<seb128> cjwatson, hey, sorry do bother you about that again, but looks like I screwed something in by adding those new strings to the gfxboot-theme-ubuntu  template .. do you have any idea what in http://launchpadlibrarian.net/473396220/gfxboot-theme-ubuntu_0.23.0_0.23.1.diff.gz could create bug #1871599
<ubottu> bug 1871599 in gfxboot-theme-ubuntu (Ubuntu) "Live image boot menu entries of Kubuntu are mistranslated" [Undecided,Confirmed] https://launchpad.net/bugs/1871599
<didrocks> nomad_fr: thatâs our goal, indeed
<cjwatson> seb128: Uh, no idea, sorry :(
<cjwatson> seb128: Oh maybe the txt_foo comments are parsed?
<seb128> cjwatson, could well be in seems...
<cjwatson> seb128: I don't remember by what, but that's probably where I'd start looking
<seb128> cjwatson, thanks, I will try to figure that out
<seb128> lathiat, I uploaded there, https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/transitions/+sourcepub/11174563/+listing-archive-extra , I would welcome if you could test tomorrow
<nomad_fr> didrocks: I just test it on my laptop It seems to work, but I have to manualy zfs mount my home dir
<nomad_fr> didrocks: en fait le parametre canmount de mon home est passe a noauto ... je crois
<didrocks> nomad_fr: you are missing the bootfs-dataset parameter on your user dataset to link to the root dataset
<nomad_fr> didrocks:oh !
<didrocks> this will be detailed on my blog for people interested in doing a manual transition
<nomad_fr> didrocks: ok
<didrocks> glad itâs almost working though for your first try :)
<seb128> cjwatson, another question for you (sorry), I was looking at applying those grub/gettext fixes to the package, looks like autoreconf does overwrite po/Makefile.in.in ... is there any mechanism in grub that could be used for that that I'm overlooking or does applying those patches from override_dh_autoreconf sound like the way to go?
<nomad_fr> didrocks: second
<didrocks> heh
<nomad_fr> didrocks: on a 'standard install' it works, and a non standard one not yet
<nomad_fr> so for the moment I set canmount to on
<nomad_fr> ?
<didrocks> nomad_fr: you have multiple user properties to set (I think you set the ones on the root pool already, correct?) and one on the user pool. I suggest until I publish the blog post to try to install 20.04 beta on a vm and compare those
<nomad_fr> didrocks: ok I really tried it a little to fast
<nomad_fr> didrocks: I will have trouble in the future with canmount=on
<nomad_fr> didrocks: bon je te laisse, en tout cas encore merci pour tout ca
<didrocks> nomad_fr: de rien :)
<seb128> sil2100, if you are not too busy and can sneak a small review in I submitted https://code.launchpad.net/~seb128/ubuntu-archive-tools/blocked_by_hints/+merge/381934
<seb128> sil2100, no hurry, I just ping because my previous ones didn't get picked by reviewers without a ping even after waiting a week so I'm unsure email notifications is good enough / something to rely on for that project reviews :)
<sil2100> seb128: hey! Let me look in a bit :)
<cjwatson> seb128: override_dh_autoreconf is probably best.  Switching to doing a full bootstrap would I suspect be a fair bit more complicated.
<seb128> cjwatson, ok thanks, I just wanted to sanity check with you before submit a mp
<cjwatson> seb128: Though I'm a little surprised that it can't be done without that
<cjwatson> Since autoreconf should just be using what's in the source package ...
<seb128> cjwatson, I'm unsure how? from what I can see autoreconf just replace po/Makefile.in.in with the system version
<jdstrand> jibel: ok, based on the conversation in backscroll (thanks didrocks!) I just marked the zsys task back to Invalid with this comment: https://bugs.launchpad.net/ubuntu/focal/+source/zsys/+bug/1871148/comments/22
<ubottu> Launchpad bug 1871148 in apparmor (Ubuntu Focal) "services start before apparmor profiles are loaded" [Critical,Fix released]
<jdstrand> jibel: please adjust as you see fit
<cjwatson> seb128: Ah, we maybe need to switch to bootstrap in the packaging somehow, but can't do that immediately
<cjwatson> Fiddly
<cjwatson> seb128: Feel free to hack it in the short term
<seb128> cjwatson, will do, thanks
<seb128> sil2100, sorry, I screwed the projects name/target :p
<seb128> sil2100, resubmitted as https://code.launchpad.net/~seb128/ubuntu-archive-scripts/report_blocked_hints/+merge/381936
<sil2100> hah, ok ;)
<teward> doko: you around?
<teward> if not doko, then sil2100 are you around?
<teward> disregard, issue resolved
<sarnold> hello friends :) can someone suggest to me if this is a user-error or if this is something broken in dpkg / apt / debconf / ucf / something else? I've seen this a few times recently https://launchpadlibrarian.net/473598994/DpkgTerminalLog.txt
<sarnold> the bug in question is https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1871615
<ubottu> Launchpad bug 1871615 in apparmor (Ubuntu) "package apparmor 2.13.3-7ubuntu4 failed to install/upgrade: end of file on stdin at conffile prompt" [Undecided,New]
<powersj> isn't the eof on stdin message mean it happened when there was no interactive shell?
<sarnold> powersj: I thought about that, but then I got scared of what that would mean for everybody who uses our GUI update tool
 * mwhudson wrote a thing https://discourse.ubuntu.com/t/please-test-autoinstalls-for-20-04/15250
#ubuntu-devel 2020-04-09
<sarnold> mwhudson: dude, this quickstart is awesome; it's easily the best documentation I've seen yet on supplying cloud-init metadata to a system, thanks :)
<mwhudson> sarnold: ah haha
<sarnold> mwhudson: way back when, I wanted to try writing my own libvirt kind of thing because libvirt annoys me; I spent two days trying to get the qemu parameters correct to feed cloud-init data to our cloud images and I don't think I ever actually got it to work
<mwhudson> sarnold: tbf if you don't boot with -initd/-kernel it is a lot harder
<sarnold> mwhudson: I can't recall now if I tried that or not, heh
<ginggs> juliank: are you aware your synaptic NMU FTBFS in Ubuntu? I was looking to sponsor LP: #1870900
<ubottu> Launchpad bug 1870900 in synaptic (Ubuntu) "Sync synaptic 0.90+nmu1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1870900
<juliank> ginggs: no
<seb128> lathiat, hey, did you have a chance to test the avahi built in the ppa?
<teward> seb128: RE: https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/1834270 - since you were on that bug back when it was opened, I'm going to NACK this as a sponsor because that seems to minor to fix for 19.10 as filed - unless this affects 20.04 as well in which case it needs patched there?  (Xubuntu related)
<ubottu> Launchpad bug 1834270 in ubiquity-slideshow-ubuntu (Ubuntu) "update link to xubuntu irc" [Medium,Triaged]
<teward> it's only on my radar since someone attached a patch ;)
<seb128> teward, looks like it's fixed in focal yes, closing sounds good to me, thanks for checking
<teward> seb128: yep.  even if I don't have to do sponsor work I'm on the sponsors team so when it shows up on my radar I take a look heh
<teward> marked as Eoan and Focal, Eoan=Won'tFix, Focal=FixReleased
<seb128> thx
<teward> yep.  sorry about the random ping but you were on the bug in the past so thought I'd check with you :0
<teward> :) *
<teward> not TIL or anything but always doesn't hurt with a second set of eyes :)
<AsciiWolf> kenvandine, hi, sorry for bothering you with this again, but since Snap Store still seems to be running without the Ubuntu Software branding (its window has "Snap Store" name/icon, menu entries for Software Sources instead of Software & Updates etc.) and without the regular (deb) packages support, I wonder if there is any way to track snapd releases other than manually checking its Launchpad page... I would like to help testing
<AsciiWolf> it, but I have Focal only in a VM and have to watch the Launchpad snapd page and/or start the VM and check for updates every day or two which is not ideal :/
<AsciiWolf> (oops, sorry for the longer text)
<AsciiWolf> or is there any ETA on when the new snapd release (which fixes the mentioned Snap Store issues) could happen?
<kenvandine> AsciiWolf: the fix will be in snapd 2.44.3 which i've been told should be release around the end of this week
<AsciiWolf> kenvandine, thanks!
<kenvandine> AsciiWolf: what revision of snap-store do you have?
<kenvandine> the branding fix is in latest/stable/ubuntu-20.04
<AsciiWolf> the latest stable one
<kenvandine> revision 345
<AsciiWolf> hmm
<AsciiWolf> I'll look
<kenvandine> oh, that's not what's intended for focal
<kenvandine> sometime next week i expect what's in latest/stable/ubuntu-20.04 will be promoted to stable
<kenvandine> assuming everything goes as planned
<AsciiWolf> "snap-store  20200403.d6b9c02  345"
<AsciiWolf> this is what I have
<AsciiWolf> kenvandine, by the way, I have just noticed a smaller issue with po files: https://bugs.launchpad.net/snap-store/+bug/1870777/comments/2
<ubottu> Launchpad bug 1870777 in snap-store "Make new Snap-related strings translatable on Launchpad" [Undecided,New]
<bdmurray> xnox: if bug 1870018 is fixed in casper can all the other tasks be closed?
<ubottu> bug 1870018 in xubuntu-artwork (Ubuntu Focal) "Option (Ctrl-C) not shown to disable ISO verification" [Undecided,New] https://launchpad.net/bugs/1870018
<xnox> bdmurray:  all other tasks are wishlist; ie. all of those themes have broken parsing of systemd-fsckd during normal boot.
<xnox> bdmurray:  casper only did "if old theme, use old messages, if new theme use new messages" but systemd-fsckd on boot only uses "new messages" which are still broken.
<pyusr> hi, question, i'm on Ubuntu 18.04 LTS and is it my imagination or is the documentation for memset in "man memset" and "man bstring" not the same ?!?
<pyusr> my friend who is on 18.04 LTS claims it's OK for him, WTF ?
<pyusr> sorry, for memmem in "man memmem" and "man bstring"
<Eickmeyer[q]> !support
<ubottu> The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<sarnold> https://manpages.ubuntu.com/manpages/trusty/man3/memmem.3.html
<sarnold> crazy, the trusty memmem manpage isn't about memmem at all
<pyusr> got disconnected, did anybody respond ?
<pyusr> there is a big bug in "'man bstring" in atleast ubuntu 18.04 LTS in memmem definition ! I used it, and it's wrong
<pyusr> any updates on getting https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1864766 closed ?
<ubottu> Launchpad bug 1864766 in python-pip (Ubuntu Xenial) "[SRU] pip in xenial is installing packages incompatible with Python 2.7 (and those are becoming common)" [Medium,In progress]
<Odd_Bloke> focal's Contents files on-mirror (e.g. http://archive.ubuntu.com/ubuntu/dists/focal/Contents-amd64.gz) are empty currently; who should I escalate this to?
<cjwatson> Odd_Bloke: That must be an LP bug - can you file it with us?
<cjwatson> They're empty on the master too
<Odd_Bloke> cjwatson: https://bugs.launchpad.net/launchpad/+bug/1871920
<ubottu> Launchpad bug 1871920 in Launchpad itself "Contents files for focal are currently empty" [Undecided,New]
<cjwatson> Thanks.  Not sure whether any of the people who are around Fri and Mon will be able to tackle that
<cjwatson> And yes, I remembered it happening before as well, so we'll need to refresh our memories of then
<cjwatson> IIRC it was a rare event that we happened to hit at a bad time for eoan.  I don't remember whether we actually fixed anything or just regenerated them
#ubuntu-devel 2020-04-10
<Unit193> kanashiro: (Re: https://lists.ubuntu.com/archives/devel-permissions/2020-April/001480.html) Good luck!
<Eickmeyer> juliank: I know you've been working on grub, so I thought I'd bring this to your attention: bug 1871968
<ubottu> bug 1871968 in grub-efi-amd64-signed (Ubuntu) "package grub-efi-amd64-signed (1.139+2.04-1ubuntu24) fails to upgrade on 20.04" [Undecided,Confirmed] https://launchpad.net/bugs/1871968
<juliank> Eickmeyer: apologies, this should be fixed (thanks xnox and vorlon)
<crockedgrind59> hello, I am working on a project to do an iso image to install ubuntu 20.04 on several computers (laptops mostly) and I would like to use Kicsktart on the new 20.04 lts but, I am using a script that I've found on gitub. It works like a charm for the ubuntu server 18.04 distro, but I cannot make it works for 20.04 Desktop, and I think that the problem is related to ubiquity, that ignores the boot txt.cfg I modify
<crockedgrind59> I have been helped on ubuntu-installer channel, but the solution a gentle guy gave me is to generate a usb to install the system, but I would need an iso to be able to install also a VM image
<crockedgrind59> does anyone here have a clue about how I could make it works  an automatically installation (with some questions, so, interactive) on a Desktop version of Ubuntu, please?
<crockedgrind59> any help would be more than appreciated!
<crockedgrind59> (or any clue!)
<seb128> lathiat, hey, did you have a chance to test avahi?
<blahdeblah> Hi all - is this a good place to talk about focal installer crashes, or is #ubuntu-server a better choice?
<blahdeblah> (or somewhere else entirely, if that's better)
<seb128> blahdeblah, you can try here or on #ubuntu-installer
<seb128> today might also not be the best day for questions, quite some people are off for Easter weekend
<blahdeblah> seb128: of course
<blahdeblah> I'll ask anyway, and try again Mon/Tue if no luck
<blahdeblah> My main question is: if I've told the installer to submit a crash report, how can a) check that it was submitted, and b) know if anything else needs doing to get the bug which caused the crash fixed
<blahdeblah> ?
<blahdeblah> I ended up having to go back to xenial to get a correct install with what I thought was a fairly vanilla disk layout: LVM on encrypted software RAID 1, then upgrade to bionic, then focal
<seb128> blahdeblah, was it a desktop or serverl install?
<blahdeblah> seb128: server
<seb128> blahdeblah, the automatic reports you sent can be seen on https://errors.ubuntu.com/user/ID where ID is the content of file /var/lib/whoopsie/whoopsie-id on the machine.
<blahdeblah> hmmm - that's long gone, because the installation failed
<seb128> or if you open a bug on launchpad you should know it/have seen the webbrowser page
<blahdeblah> so I reinstalled
<seb128> blahdeblah, well, the ID depends of the machine so it might be the same still with a new install
<blahdeblah> I'll have a look
<blahdeblah> Nope, no such directory
<seb128> :/
<seb128> I don't know then, best to wait for someone from server to be around or maybe ask mwhudson if that's a subiquity install you tried
<seb128> (though he's probably eow at this time)
<blahdeblah> No worries - thanks seb128
<seb128> np!
<jibel> vorlon, there is an issue with last upload of grub cf bug 1872077
<ubottu> bug 1872077 in grub2-signed (Ubuntu) "package grub-efi-amd64-signed 1.140+2.04-1ubuntu24 failed to install/upgrade with mount: /var/lib/grub/esp: special device /, does not exist" [Critical,Confirmed] https://launchpad.net/bugs/1872077
<jibel> actually juliank ^
<juliank> jibel: fascinating
<juliank> jibel: bug 1872100 is interesting too
<ubottu> bug 1872077 in grub2-signed (Ubuntu) "duplicate for #1872100 package grub-efi-amd64-signed 1.140+2.04-1ubuntu24 failed to install/upgrade with mount: /var/lib/grub/esp: special device /, does not exist" [Critical,Incomplete] https://launchpad.net/bugs/1872077
<juliank> Hmm wrong no
<juliank> bug 1872100
<juliank> Hurry up ubottu
<juliank> This is all confusing
<juliank> Who marked that as a duplicate? I unmarked it
<Eickmeyer> juliank, seb128: Do either of you have any insight on this? Bug 1871295 came up in #ubuntu-quality
<ubottu> bug 1871295 in ubiquity (Ubuntu) "Live CD 20.04 don't set correct keyboard layout after ubiquity" [Undecided,New] https://launchpad.net/bugs/1871295
#ubuntu-devel 2020-04-11
<kenvandine> AsciiWolf: https://github.com/snapcore/snapd/releases/tag/2.44.3
<kenvandine> AsciiWolf: that contains the snapd fix that's needed for snap-store.  It's in core in the beta channel now
<kenvandine> hopefully should make it to stable sometime next week
<wgrant> stgraber, vorlon: https://people.ubuntu.com/~wgrant/riscv64/ has a qemu-bootable image
<stgraber> wgrant: cool, thanks!
<jbicha> doko: does anything still use python-jujuclient? https://launchpad.net/ubuntu/+source/websocket-client/0.53.0-2ubuntu1
<TDO|Denton> sorry, dont' know. What does the dependencies say?
<doko> jbicha: sorry, no idea
<TJ-> doko: weechat's python.so is failing to link against libpython3  Bug #1866065
<ubottu> bug 1866065 in weechat (Ubuntu) "weechat python.so not linked against libpython3 (undefined symbol: _Py_NoneStruct)" [Undecided,Confirmed] https://launchpad.net/bugs/1866065
<fo0bar> <fo0bar, just now> libvirt box is now on focal; I wonder if wgrant's got a shiny riscv64 qemu image I can play with
<fo0bar> 2020-04-10 19:06:50 < wgrant> stgraber, vorlon: https://people.ubuntu.com/~wgrant/riscv64/ has a qemu-bootable image
#ubuntu-devel 2020-04-12
<themill> What's the oldest currently supported ubuntu release and what version of Python 3 does it have? I'm wondering what level of legacy cruft can be ditched from python-debian now.
<fo0bar> themill: for mainline support: https://packages.ubuntu.com/search?keywords=python3 -- though trusty (3.4.0) is in paid ESM
<themill> thanks; I think 3.4 is the newest version for which we have explicit compat code in there, so being able to set python 3.5 as the lowest limit would be reasonable from an Ubuntu perspective and would also allow lots of cleanup
<cjwatson> themill: I mean we aren't going to upgrade trusty to newer python-debian anyway ...
<Unit193> I'm perhaps a bit lax, but trimming up to Bionic seems pretty fine to me.
<cjwatson> Unit193: Selfishly, Launchpad runs on xenial and we often want to upgrade python-debian there (it's installed in a virtualenv)
<cjwatson> Though hopefully that'll be bionic in the near future
<cjwatson> (Python 2 on xenial, too, so upgrading to newer upstreams is getting more difficult in general anyway)
<Unit193> That would be rather rough.  Another Ubuntu server I know of is on Trusty..Doubtful ESM.
<cjwatson> We've been scrabbling to get things a bit more current but it is a lot of work.
<Unit193> IIRC you've said i386 too, with that and py2 it seems you'll be having a lot of that in the future. :/
<cjwatson> Unit193: I use i386 for my local test containers to save memory, but production is amd64
<Unit193> Ahh, OK.
<cjwatson> (And memory is probably less of an issue nowadays anyway, but old habits)
<cjwatson> https://git.launchpad.net/~cjwatson/launchpad/log/?h=py3 is a (non-fast-forwarding) Launchpad branch with various fixes to improve Python 3 support from which I've been landing various bits and pieces over time
<cjwatson> But it's at the stage of "you can start the test suite and it at least runs even though it produces a bazillion test failures"
<wgrant> doko, mwhudson: https://launchpad.net/~wgrant/+archive/ubuntu/nonvirt/+build/19151918 <- a riscv64 golang-1.14 if you want it
<doko> wgrant: but that doesn't build with the current golang-defaults, does it? for that we need to update golang-defaults to 1.4
<fo0bar> wgrant: you mentioned in your README that sshd wasn't included in the riscv64 image, but FWIW, I wasn't able to get openssh-server workin at all.  connections would always freeze during preauth
<fo0bar> dropbear works fine though, so I'm just pretending this is a consumer router :)
<fo0bar> when the system is under load, htop works for literally a second then will exit "Success".  and in general, I've noticed things like to ENOMEM even when they're plenty of free memory
<fo0bar> "besides that, Mrs. Lincoln..."
<fo0bar> would these be useful reporting anywhere?
 * fo0bar notices even more typing mistakes than usual above, and decides he should get coffee first
<cjwatson> fo0bar: Can you get anything from /var/log/auth.log?
<cjwatson> (for sshd)
<cjwatson> Or ssh -vvv
<fo0bar> cjwatson: https://pastebin.ubuntu.com/p/QDfyfcTSHk/
<fo0bar> stock server config except LogLevel DEBUG.  trying to do password auth to 127.0.0.1 results in basically the same thing
<fo0bar> speaking of syslog, I have syslog-ng installed because it looks like rsyslog isn't in yet.  is there a riscv64-specific ftbfs tracking page somewhere?
<cjwatson> Hm, sorry, not obvious without significantly more digging.  An strace might be worthwhile I guess
<fo0bar> ... and strace isn't in riscv64 yet :)  no worries, thanks
<fo0bar> interestingly, load doesn't go up during those two minutes, so it's not spinning per se
<cjwatson> I wondered if it might be a seccomp filter bug, but just a guess
<xnox> there appears to be a lot of linux-signed* handling in ubiquity & base-installer, which was just left there. Despite us stopping to use linux-signed
<xnox> also we have many different flavours now that one can use, yet somehow baseinstaller lists never got updated. I wonder how our kernel flavour selection works now.
<wgrant> fo0bar: I'd try with the old qemu if you can. The sshd hang, though, might be due to lack of entropy, so a virtio-rng might be an idea
<wgrant> qemu 4.2 made things very unstable. I've no idea why yet
